DOCSLIB.ORG

“Option Summary” in Using the GNU Compiler Collection (GCC)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
“Option Summary” in Using the GNU Compiler Collection (GCC) Using the GNU Compiler Collection For gcc version 5.4.0 (GCC) Richard M. Stallman and the GCC Developer Community Published by: GNU Press Website: http://www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 51 Franklin Street, Fifth Floor Tel 617-542-5942 Boston, MA 02110-1301 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988-2015 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being \Funding Free Software", the Front-Cover Texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled \GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Short Contents Introduction ::::::::::::::::::::::::::::::::::::::::::::: 1 1 Programming Languages Supported by GCC ::::::::::::::: 3 2 Language Standards Supported by GCC :::::::::::::::::: 5 3 GCC Command Options ::::::::::::::::::::::::::::::: 9 4 C Implementation-Defined Behavior :::::::::::::::::::: 359 5 C++ Implementation-Defined Behavior ::::::::::::::::: 367 6 Extensions to the C Language Family ::::::::::::::::::: 369 7 Extensions to the C++ Language :::::::::::::::::::::: 647 8 GNU Objective-C Features ::::::::::::::::::::::::::: 661 9 Binary Compatibility :::::::::::::::::::::::::::::::: 677 10 gcov|a Test Coverage Program ::::::::::::::::::::::: 681 11 gcov-tool|an Offline Gcda Profile Processing Tool ::::::: 691 12 Known Causes of Trouble with GCC :::::::::::::::::::: 695 13 Reporting Bugs ::::::::::::::::::::::::::::::::::::: 711 14 How To Get Help with GCC :::::::::::::::::::::::::: 713 15 Contributing to GCC Development ::::::::::::::::::::: 715 Funding Free Software ::::::::::::::::::::::::::::::::::: 717 The GNU Project and GNU/Linux::::::::::::::::::::::::: 719 GNU General Public License :::::::::::::::::::::::::::::: 721 GNU Free Documentation License ::::::::::::::::::::::::: 733 Contributors to GCC :::::::::::::::::::::::::::::::::::: 741 Option Index :::::::::::::::::::::::::::::::::::::::::: 759 Keyword Index ::::::::::::::::::::::::::::::::::::::::: 781 iii Table of Contents Introduction :::::::::::::::::::::::::::::::::::::::: 1 1 Programming Languages Supported by GCC ::::::::::::::::::::::::::::::::::::::::::::::::: 3 2 Language Standards Supported by GCC ::::: 5 2.1 C Language :::::::::::::::::::::::::::::::::::::::::::::::::::: 5 2.2 C++ Language :::::::::::::::::::::::::::::::::::::::::::::::: 6 2.3 Objective-C and Objective-C++ Languages :::::::::::::::::::: 7 2.4 Go Language::::::::::::::::::::::::::::::::::::::::::::::::::: 8 2.5 References for Other Languages :::::::::::::::::::::::::::::::: 8 3 GCC Command Options ::::::::::::::::::::::: 9 3.1 Option Summary::::::::::::::::::::::::::::::::::::::::::::::: 9 3.2 Options Controlling the Kind of Output ::::::::::::::::::::::: 26 3.3 Compiling C++ Programs :::::::::::::::::::::::::::::::::::: 31 3.4 Options Controlling C Dialect ::::::::::::::::::::::::::::::::: 32 3.5 Options Controlling C++ Dialect ::::::::::::::::::::::::::::: 38 3.6 Options Controlling Objective-C and Objective-C++ Dialects :: 49 3.7 Options to Control Diagnostic Messages Formatting ::::::::::: 53 3.8 Options to Request or Suppress Warnings ::::::::::::::::::::: 55 3.9 Options for Debugging Your Program or GCC ::::::::::::::::: 83 3.10 Options That Control Optimization ::::::::::::::::::::::::: 110 3.11 Options Controlling the Preprocessor:::::::::::::::::::::::: 168 3.12 Passing Options to the Assembler ::::::::::::::::::::::::::: 179 3.13 Options for Linking ::::::::::::::::::::::::::::::::::::::::: 179 3.14 Options for Directory Search :::::::::::::::::::::::::::::::: 184 3.15 Specifying Subprocesses and the Switches to Pass to Them :: 186 3.16 Specifying Target Machine and Compiler Version :::::::::::: 193 3.17 Hardware Models and Configurations ::::::::::::::::::::::: 193 3.17.1 AArch64 Options :::::::::::::::::::::::::::::::::::::: 193 3.17.1.1 `-march' and `-mcpu' Feature Modifiers :::::::::::: 196 3.17.2 Adapteva Epiphany Options ::::::::::::::::::::::::::: 196 3.17.3 ARC Options :::::::::::::::::::::::::::::::::::::::::: 198 3.17.4 ARM Options:::::::::::::::::::::::::::::::::::::::::: 204 3.17.5 AVR Options :::::::::::::::::::::::::::::::::::::::::: 210 3.17.5.1 EIND and Devices with More Than 128 Ki Bytes of Flash::::::::::::::::::::::::::::::::::::::::::::::::::: 214 3.17.5.2 Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers:::::::::::::::::::::::::::::::::::::: 216 3.17.5.3 AVR Built-in Macros:::::::::::::::::::::::::::::: 216 3.17.6 Blackfin Options ::::::::::::::::::::::::::::::::::::::: 218 iv Using the GNU Compiler Collection (GCC) 3.17.7 C6X Options::::::::::::::::::::::::::::::::::::::::::: 221 3.17.8 CRIS Options:::::::::::::::::::::::::::::::::::::::::: 222 3.17.9 CR16 Options ::::::::::::::::::::::::::::::::::::::::: 223 3.17.10 Darwin Options::::::::::::::::::::::::::::::::::::::: 224 3.17.11 DEC Alpha Options :::::::::::::::::::::::::::::::::: 227 3.17.12 FR30 Options :::::::::::::::::::::::::::::::::::::::: 232 3.17.13 FRV Options ::::::::::::::::::::::::::::::::::::::::: 232 3.17.14 GNU/Linux Options :::::::::::::::::::::::::::::::::: 236 3.17.15 H8/300 Options::::::::::::::::::::::::::::::::::::::: 236 3.17.16 HPPA Options:::::::::::::::::::::::::::::::::::::::: 237 3.17.17 IA-64 Options :::::::::::::::::::::::::::::::::::::::: 240 3.17.18 LM32 Options :::::::::::::::::::::::::::::::::::::::: 243 3.17.19 M32C Options :::::::::::::::::::::::::::::::::::::::: 244 3.17.20 M32R/D Options ::::::::::::::::::::::::::::::::::::: 244 3.17.21 M680x0 Options :::::::::::::::::::::::::::::::::::::: 245 3.17.22 MCore Options ::::::::::::::::::::::::::::::::::::::: 251 3.17.23 MeP Options ::::::::::::::::::::::::::::::::::::::::: 251 3.17.24 MicroBlaze Options ::::::::::::::::::::::::::::::::::: 253 3.17.25 MIPS Options :::::::::::::::::::::::::::::::::::::::: 255 3.17.26 MMIX Options ::::::::::::::::::::::::::::::::::::::: 268 3.17.27 MN10300 Options :::::::::::::::::::::::::::::::::::: 269 3.17.28 Moxie Options :::::::::::::::::::::::::::::::::::::::: 270 3.17.29 MSP430 Options:::::::::::::::::::::::::::::::::::::: 270 3.17.30 NDS32 Options ::::::::::::::::::::::::::::::::::::::: 271 3.17.31 Nios II Options ::::::::::::::::::::::::::::::::::::::: 273 3.17.32 Nvidia PTX Options :::::::::::::::::::::::::::::::::: 277 3.17.33 PDP-11 Options :::::::::::::::::::::::::::::::::::::: 277 3.17.34 picoChip Options ::::::::::::::::::::::::::::::::::::: 278 3.17.35 PowerPC Options::::::::::::::::::::::::::::::::::::: 279 3.17.36 RL78 Options::::::::::::::::::::::::::::::::::::::::: 279 3.17.37 IBM RS/6000 and PowerPC Options :::::::::::::::::: 279 3.17.38 RX Options :::::::::::::::::::::::::::::::::::::::::: 295 3.17.39 S/390 and zSeries Options :::::::::::::::::::::::::::: 298 3.17.40 Score Options::::::::::::::::::::::::::::::::::::::::: 301 3.17.41 SH Options ::::::::::::::::::::::::::::::::::::::::::: 301 3.17.42 Solaris 2 Options ::::::::::::::::::::::::::::::::::::: 309 3.17.43 SPARC Options :::::::::::::::::::::::::::::::::::::: 310 3.17.44 SPU Options ::::::::::::::::::::::::::::::::::::::::: 315 3.17.45 Options for System V ::::::::::::::::::::::::::::::::: 317 3.17.46 TILE-Gx Options ::::::::::::::::::::::::::::::::::::: 317 3.17.47 TILEPro Options ::::::::::::::::::::::::::::::::::::: 318 3.17.48 V850 Options ::::::::::::::::::::::::::::::::::::::::: 318 3.17.49 VAX Options ::::::::::::::::::::::::::::::::::::::::: 321 3.17.50 Visium Options ::::::::::::::::::::::::::::::::::::::: 321 3.17.51 VMS Options ::::::::::::::::::::::::::::::::::::::::: 322 3.17.52 VxWorks Options ::::::::::::::::::::::::::::::::::::: 322 3.17.53 x86 Options :::::::::::::::::::::::::::::::::::::::::: 323 3.17.54 x86 Windows Options::::::::::::::::::::::::::::::::: 339 v 3.17.55 Xstormy16 Options ::::::::::::::::::::::::::::::::::: 340 3.17.56 Xtensa Options ::::::::::::::::::::::::::::::::::::::: 340 3.17.57 zSeries Options ::::::::::::::::::::::::::::::::::::::: 342 3.18 Options for Code Generation Conventions ::::::::::::::::::: 342 3.19 Environment Variables Affecting GCC :::::::::::::::::::::: 353 3.20 Using Precompiled Headers ::::::::::::::::::::::::::::::::: 355 4 C Implementation-Defined Behavior ::::::: 359 4.1 Translation :::::::::::::::::::::::::::::::::::::::::::::::::: 359 4.2 Environment::::::::::::::::::::::::::::::::::::::::::::::::: 359 4.3 Identifiers:::::::::::::::::::::::::::::::::::::::::::::::::::: 359 4.4 Characters ::::::::::::::::::::::::::::::::::::::::::::::::::: 360 4.5 Integers:::::::::::::::::::::::::::::::::::::::::::::::::::::: 361 4.6 Floating Point ::::::::::::::::::::::::::::::::::::::::::::::: 361 4.7 Arrays and Pointers:::::::::::::::::::::::::::::::::::::::::: 362 4.8 Hints :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 363 4.9 Structures, Unions, Enumerations, and Bit-Fields::::::::::::: 363 4.10 Qualifiers ::::::::::::::::::::::::::::::::::::::::::::::::::: 364 4.11 Declarators ::::::::::::::::::::::::::::::::::::::::::::::::: 365 4.12 Statements :::::::::::::::::::::::::::::::::::::::::::::::::
Load more

Recommended publications
  • CSE 582 – Compilers
    CSE P 501 – Compilers Optimizing Transformations Hal Perkins Autumn 2011 11/8/2011 © 2002-11 Hal Perkins & UW CSE S-1 Agenda A sampler of typical optimizing transformations Mostly a teaser for later, particularly once we’ve looked at analyzing loops 11/8/2011 © 2002-11 Hal Perkins & UW CSE S-2 Role of Transformations Data-flow analysis discovers opportunities for code improvement Compiler must rewrite the code (IR) to realize these improvements A transformation may reveal additional opportunities for further analysis & transformation May also block opportunities by obscuring information 11/8/2011 © 2002-11 Hal Perkins & UW CSE S-3 Organizing Transformations in a Compiler Typically middle end consists of many individual transformations that filter the IR and produce rewritten IR No formal theory for order to apply them Some rules of thumb and best practices Some transformations can be profitably applied repeatedly, particularly if others transformations expose more opportunities 11/8/2011 © 2002-11 Hal Perkins & UW CSE S-4 A Taxonomy Machine Independent Transformations Realized profitability may actually depend on machine architecture, but are typically implemented without considering this Machine Dependent Transformations Most of the machine dependent code is in instruction selection & scheduling and register allocation Some machine dependent code belongs in the optimizer 11/8/2011 © 2002-11 Hal Perkins & UW CSE S-5 Machine Independent Transformations Dead code elimination Code motion Specialization Strength reduction
    [Show full text]
  • Stackable Lcc/Lcd Oven Instruction Manual
    C-195 P/N 156452 REVISION W 12/2007 STACKABLE LCC/LCD OVEN INSTRUCTION MANUAL Model Atmosphere Volts Amps Hz Heater Phase Watts LCC/D1-16-3 Air 240 14.8 50/60 3,000 1 LCC/D1-16N-3 Nitrogen 240 14.0 50/60 3,000 1 LCC/D1-51-3 Air 240 27.7 50/60 6,000 1 LCC/D1-51N-3 Nitrogen 240 27.7 50/60 6,000 1 Model numbers may include a “V” for silicone free construction. Model numbers may begin with the designation LL *1-*, indicating Models without HEPA filter. Prepared by: Despatch Industries 8860 207 th St. West Lakeville, MN 55044 Customer Service 800-473-7373 NOTICE Users of this equipment must comply with operating procedures and training of operation personnel as required by the Occupational Safety and Health Act (OSHA) of 1970, Section 6 and relevant safety standards, as well as other safety rules and regulations of state and local governments. Refer to the relevant safety standards in OSHA and National Fire Protection Association (NFPA), section 86 of 1990. CAUTION Setup and maintenance of the equipment should be performed by qualified personnel who are experienced in handling all facets of this type of system. Improper setup and operation of this equipment could cause an explosion that may result in equipment damage, personal injury or possible death. Dear Customer, Thank you for choosing Despatch Industries. We appreciate the opportunity to work with you and to meet your heat processing needs. We believe that you have selected the finest equipment available in the heat processing industry.
    [Show full text]
  • Introduction to Computer Systems 15-213/18-243, Spring 2009 1St
    M4-L3: Executables CSE351, Winter 2021 Executables CSE 351 Winter 2021 Instructor: Teaching Assistants: Mark Wyse Kyrie Dowling Catherine Guevara Ian Hsiao Jim Limprasert Armin Magness Allie Pfleger Cosmo Wang Ronald Widjaja http://xkcd.com/1790/ M4-L3: Executables CSE351, Winter 2021 Administrivia ❖ Lab 2 due Monday (2/8) ❖ hw12 due Friday ❖ hw13 due next Wednesday (2/10) ▪ Based on the next two lectures, longer than normal ❖ Remember: HW and readings due before lecture, at 11am PST on due date 2 M4-L3: Executables CSE351, Winter 2021 Roadmap C: Java: Memory & data car *c = malloc(sizeof(car)); Car c = new Car(); Integers & floats c->miles = 100; c.setMiles(100); x86 assembly c->gals = 17; c.setGals(17); Procedures & stacks float mpg = get_mpg(c); float mpg = Executables free(c); c.getMPG(); Arrays & structs Memory & caches Assembly get_mpg: Processes pushq %rbp language: movq %rsp, %rbp Virtual memory ... Memory allocation popq %rbp Java vs. C ret OS: Machine 0111010000011000 100011010000010000000010 code: 1000100111000010 110000011111101000011111 Computer system: 3 M4-L3: Executables CSE351, Winter 2021 Reading Review ❖ Terminology: ▪ CALL: compiler, assembler, linker, loader ▪ Object file: symbol table, relocation table ▪ Disassembly ▪ Multidimensional arrays, row-major ordering ▪ Multilevel arrays ❖ Questions from the Reading? ▪ also post to Ed post! 4 M4-L3: Executables CSE351, Winter 2021 Building an Executable from a C File ❖ Code in files p1.c p2.c ❖ Compile with command: gcc -Og p1.c p2.c -o p ▪ Put resulting machine code in
    [Show full text]
  • The LLVM Instruction Set and Compilation Strategy
    The LLVM Instruction Set and Compilation Strategy Chris Lattner Vikram Adve University of Illinois at Urbana-Champaign lattner,vadve ¡ @cs.uiuc.edu Abstract This document introduces the LLVM compiler infrastructure and instruction set, a simple approach that enables sophisticated code transformations at link time, runtime, and in the field. It is a pragmatic approach to compilation, interfering with programmers and tools as little as possible, while still retaining extensive high-level information from source-level compilers for later stages of an application’s lifetime. We describe the LLVM instruction set, the design of the LLVM system, and some of its key components. 1 Introduction Modern programming languages and software practices aim to support more reliable, flexible, and powerful software applications, increase programmer productivity, and provide higher level semantic information to the compiler. Un- fortunately, traditional approaches to compilation either fail to extract sufficient performance from the program (by not using interprocedural analysis or profile information) or interfere with the build process substantially (by requiring build scripts to be modified for either profiling or interprocedural optimization). Furthermore, they do not support optimization either at runtime or after an application has been installed at an end-user’s site, when the most relevant information about actual usage patterns would be available. The LLVM Compilation Strategy is designed to enable effective multi-stage optimization (at compile-time, link-time, runtime, and offline) and more effective profile-driven optimization, and to do so without changes to the traditional build process or programmer intervention. LLVM (Low Level Virtual Machine) is a compilation strategy that uses a low-level virtual instruction set with rich type information as a common code representation for all phases of compilation.
    [Show full text]
  • Ben Livshits 1 Basic Instrumentation
    Runtime monitoring CO444H Ben Livshits 1 Basic Instrumentation • Insert additional code into the program • This code is designed to record important events as they occur at runtime • Some examples • A particular function is being hit or a statement is being hit • This leads to function-level or line-level coverage • Each allocation to measure overall memory allocation 2 Levels of Instrumentation • Native code • Instrument machine code • Tools like LLVM are often used for rewriting • Bytecode • Common for languages such as Java and C# • A variety of tools are available for each bytecode format • JoeQ is in this category as well, although it’s a lot more general • Source code • Common for languages like JavaScript • Often the easiest option – parse the code and add more statements 3 Runtime Code Monitoring •Three major examples of monitoring • Purify/Valgrind • Detecting data races • Detecting memory leaks 4 5 Memory Error Detection Purify • C and C++ are not type-safe • The type system and the runtime fail to enforce type safety • What are some of the examples? • Possible to read and write outside of your intended data structures • Write beyond loop bounds • Or object bounds • Or overwrite the code pointer, etc. 6 Track Each Byte of Memory • Three states for every byte of tracker memory • Unallocated: cannot be read or written • Allocated but not initialized: cannot be read • Allocated and initialized: all operations are allowed 7 Instrumentation for Purify • Check the state of each byte at every access • Binary instrumentation: • Add
    [Show full text]
  • CERES Software Bulletin 95-12
    CERES Software Bulletin 95-12 Fortran 90 Linking Experiences, September 5, 1995 1.0 Purpose: To disseminate experience gained in the process of linking Fortran 90 software with library routines compiled under Fortran 77 compiler. 2.0 Originator: Lyle Ziegelmiller ([email protected]) 3.0 Description: One of the summer students, Julia Barsie, was working with a plot program which was written in f77. This program called routines from a graphics package known as NCAR, which is also written in f77. Everything was fine. The plot program was converted to f90, and a new version of the NCAR graphical package was released, which was written in f77. A problem arose when trying to link the new f90 version of the plot program with the new f77 release of NCAR; many undefined references were reported by the linker. This bulletin is intended to convey what was learned in the effort to accomplish this linking. The first step I took was to issue the "-dryrun" directive to the f77 compiler when using it to compile the original f77 plot program and the original NCAR graphics library. "- dryrun" causes the linker to produce an output detailing all the various libraries that it links with. Note that these libaries are in addition to the libaries you would select on the command line. For example, you might compile a program with erbelib, but the linker would have to link with librarie(s) that contain the definitions of sine or cosine. Anyway, it was my hypothesis that if everything compiled and linked with f77, then all the libraries must be contained in the output from the f77's "-dryrun" command.
    [Show full text]
  • The Lcc 4.X Code-Generation Interface
    The lcc 4.x Code-Generation Interface Christopher W. Fraser and David R. Hanson Microsoft Research [email protected] [email protected] July 2001 Technical Report MSR-TR-2001-64 Abstract Lcc is a widely used compiler for Standard C described in A Retargetable C Compiler: Design and Implementation. This report details the lcc 4.x code- generation interface, which defines the interaction between the target- independent front end and the target-dependent back ends. This interface differs from the interface described in Chap. 5 of A Retargetable C Com- piler. Additional infomation about lcc is available at http://www.cs.princ- eton.edu/software/lcc/. Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 http://www.research.microsoft.com/ The lcc 4.x Code-Generation Interface 1. Introduction Lcc is a widely used compiler for Standard C described in A Retargetable C Compiler [1]. Version 4.x is the current release of lcc, and it uses a different code-generation interface than the inter- face described in Chap. 5 of Reference 1. This report details the 4.x interface. Lcc distributions are available at http://www.cs.princeton.edu/software/lcc/ along with installation instruc- tions [2]. The code generation interface specifies the interaction between lcc’s target-independent front end and target-dependent back ends. The interface consists of a few shared data structures, a 33-operator language, which encodes the executable code from a source program in directed acyclic graphs, or dags, and 18 functions, that manipulate or modify dags and other shared data structures. On most targets, implementations of many of these functions are very simple.
    [Show full text]
  • Software Comprehension Using Open Source Tools: a Study
    International Journal of Computer Sciences and Engineering Open Access Survey Paper Vol.-7, Issue-3, March 2019 E-ISSN: 2347-2693 Software Comprehension Using Open Source Tools: A Study Jyoti Yadav Department of Computer Science, Savitribai Phule Pune University, Maharashtra, India *Corresponding Author: [email protected], Tel.: 9881252910 DOI: https://doi.org/10.26438/ijcse/v7i3.657668 | Available online at: www.ijcseonline.org Accepted: 12/Mar/2019, Published: 31/Mar/2019 Abstract: Software applications developed in recent times are written in lakhs of lines of code and have become increasingly complex in terms of structure, behaviour and functionality. At the same time, development life cycles of such applications reveal a tendency of becoming increasingly shorter, due to factors such as rapid evolution of supporting and enabling technologies. As a consequence, an increasing portion of software development cost shifts from the creation of new artefacts to the adaptation of existing ones. A key component of this activity is the understanding of the design, operation, and behaviour of existing artefacts of the code. For instance, in the software industry, it is estimated that maintenance costs exceed 80% of the total costs of a software product’s lifecycle, and software understanding accounts for as much as half of these maintenance costs. Software Comprehension is a key subtask of software maintenance and evolution phase, which is driven by the need to change software. This paper will help in enhancing the ability of the developers to read and comprehend large pieces of software in an organized manner, even in the absence of adequate documentation by using existing open source tools.
    [Show full text]
  • The Interplay of Compile-Time and Run-Time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel
    The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel To cite this version: Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel. The Interplay of Compile-time and Run-time Options for Performance Prediction. SPLC 2021 - 25th ACM Inter- national Systems and Software Product Line Conference - Volume A, Sep 2021, Leicester, United Kingdom. pp.1-12, 10.1145/3461001.3471149. hal-03286127 HAL Id: hal-03286127 https://hal.archives-ouvertes.fr/hal-03286127 Submitted on 15 Jul 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel Univ Rennes, INSA Rennes, CNRS, Inria, IRISA Rennes, France [email protected] ABSTRACT Both compile-time and run-time options can be configured to reach Many software projects are configurable through compile-time op- specific functional and performance goals. tions (e.g., using ./configure) and also through run-time options (e.g., Existing studies consider either compile-time or run-time op- command-line parameters, fed to the software at execution time).
    [Show full text]
  • Memory Leak Or Dangling Pointer
    Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer.
    [Show full text]
  • ICS803 Elective – III Multicore Architecture Teacher Name: Ms
    ICS803 Elective – III Multicore Architecture Teacher Name: Ms. Raksha Pandey Course Structure L T P 3 1 0 4 Prerequisite: Course Content: Unit-I: Multi-core Architectures Introduction to multi-core architectures, issues involved into writing code for multi-core architectures, Virtual Memory, VM addressing, VA to PA translation, Page fault, TLB- Parallel computers, Instruction level parallelism (ILP) vs. thread level parallelism (TLP), Performance issues, OpenMP and other message passing libraries, threads, mutex etc. Unit-II: Multi-threaded Architectures Brief introduction to cache hierarchy - Caches: Addressing a Cache, Cache Hierarchy, States of Cache line, Inclusion policy, TLB access, Memory Op latency, MLP, Memory Wall, communication latency, Shared memory multiprocessors, General architectures and the problem of cache coherence, Synchronization primitives: Atomic primitives; locks: TTS, ticket, array; barriers: central and tree; performance implications in shared memory programs; Chip multiprocessors: Why CMP (Moore's law, wire delay); shared L2 vs. tiled CMP; core complexity; power/performance; Snoopy coherence: invalidate vs. update, MSI, MESI, MOESI, MOSI; performance trade-offs; pipelined snoopy bus design; Memory consistency models: SC, PC, TSO, PSO, WO/WC, RC; Chip multiprocessor case studies: Intel Montecito and dual-core, Pentium4, IBM Power4, Sun Niagara Unit-III: Compiler Optimization Issues Code optimizations: Copy Propagation, dead Code elimination , Loop Optimizations-Loop Unrolling, Induction variable Simplification, Loop Jamming, Loop Unswitching, Techniques to improve detection of parallelism: Scalar Processors, Special locality, Temporal locality, Vector machine, Strip mining, Shared memory model, SIMD architecture, Dopar loop, Dosingle loop. Unit-IV: Control Flow analysis Control flow analysis, Flow graph, Loops in Flow graphs, Loop Detection, Approaches to Control Flow Analysis, Reducible Flow Graphs, Node Splitting.
    [Show full text]
  • Linking + Libraries
    LinkingLinking ● Last stage in building a program PRE- COMPILATION ASSEMBLY LINKING PROCESSING ● Combining separate code into one executable ● Linking done by the Linker ● ld in Unix ● a.k.a. “link-editor” or “loader” ● Often transparent (gcc can do it all for you) 1 LinkingLinking involves...involves... ● Combining several object modules (the .o files corresponding to .c files) into one file ● Resolving external references to variables and functions ● Producing an executable file (if no errors) file1.c file1.o file2.c gcc file2.o Linker Executable fileN.c fileN.o Header files External references 2 LinkingLinking withwith ExternalExternal ReferencesReferences file1.c file2.c int count; #include <stdio.h> void display(void); Compiler extern int count; int main(void) void display(void) { file1.o file2.o { count = 10; with placeholders printf(“%d”,count); display(); } return 0; Linker } ● file1.o has placeholder for display() ● file2.o has placeholder for count ● object modules are relocatable ● addresses are relative offsets from top of file 3 LibrariesLibraries ● Definition: ● a file containing functions that can be referenced externally by a C program ● Purpose: ● easy access to functions used repeatedly ● promote code modularity and re-use ● reduce source and executable file size 4 LibrariesLibraries ● Static (Archive) ● libname.a on Unix; name.lib on DOS/Windows ● Only modules with referenced code linked when compiling ● unlike .o files ● Linker copies function from library into executable file ● Update to library requires recompiling program 5 LibrariesLibraries ● Dynamic (Shared Object or Dynamic Link Library) ● libname.so on Unix; name.dll on DOS/Windows ● Referenced code not copied into executable ● Loaded in memory at run time ● Smaller executable size ● Can update library without recompiling program ● Drawback: slightly slower program startup 6 LibrariesLibraries ● Linking a static library libpepsi.a /* crave source file */ … gcc ..
    [Show full text]