Re: Fwd: Re: gcc 4.1.1 for mcore

[Nick Clifton]

Hi Alex,


this is the error message I'm getting:
/tmp/ccvk5vjH.s:38: Error: operand must be absolute in
range 1..32, not 53



I run on a Linux machine with AMD CPU (x86_64).


Ah yes this problem.  I have encountered it too.  Presumably you are 
using a 64-bit Linux ?  If you build in a 32-bit environment you can 
work around this problem.  I use this command line, suggested to me by 
Alex Oliva:


  CC="gcc -m32" CXX="g++ -m32" ABI="32" setarch i686 



I have a fix for the problem now, but the build fails later on (in 
newlib and then libiberty) so you'll have to give me another day to look 
at the problem.


Cheers
  Nick

Re: Fwd: Re: gcc 4.1.1 for mcore

[Nick Clifton]

Hi Alex,

  Right - you should be able to build the MCore port now.  At least as 
far as newlib/libgloss/libiberty anyway.  libstdc++-v3 does not build at 
the moment due to a problem unrelated to the 64-bit build OS issue, but 
I assume that this does not bother you.


(You will need the latest gcc and binutils sources for this...)

Cheers
  Nick

RFC: Extending --help

[Nick Clifton]

Hi Guys,

  Last month I submitted a patch to add a new switch to gcc:
  --print-optimizers.  The idea of this switch was that it would only
  display those switches that controlled optimizations, and that it
  would show their current status (activated/not activated).  Mark
  Mitchell suggested that it would be better to integrate this feature
  into the current --help switch, so here is my proposal:

  I would like to extend the --help switch so that, optionally, it
  takes a parameter describing what type of information is required:

--help Does exactly the same as before.

--help=target  Displays target specific switches only.
   --target-help now becomes an alias for this
   switch.

--help=warningsDisplays switches that control warnings.
   Displays switch status as described below.

--help=optimizers  Displays switches that control optimizations.
   Display switch status as described below.

--help={tool}  Displays the --help output of the specified
   tool (cpp, cc1, cc1plus, as, collect-ld, ld).

--help=pre-processor-symbols   Displays all the symbols predefined
   by the pre-processor.  (Not sure if this option
   will be popular.  I like it because I can never
   remember the magic incantation to get this
   information emitted into the .i file, and
   besides I do not want the information in a .i
   file, I want it listed to stdout).
   
  For the --help=warnings and --help=optimizers switch extra
  information is also displayed about each switch.  If the -Q switch
  has been enabled earlier on the command line, then the descriptive
  help text for each of the switches is displayed alongside the
  switch.  Otherwise the help text is omitted and instead an
  indication is given as to whether the switch is currently enabled or
  disabled.  This information is sensitive to the position of the
  --help=... switch on the command line, so that it is possible for
  example to use:

gcc -O2 --help=optimizers

  to find out which optimizations are active at -O2, or even:

gcc -O3 --help=optimizers > /tmp/O3-opts
gcc -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled

  to find out which extra optimizations are enabled by the -O3 switch.

  This enabled/disabled output will also be in a well defined format,
  making it machine parsable.  This is helpful for another project we
  are working on - the automatic selection of the most effective
  optimization options to compile any given particular application.

  For switches which are not binary in nature, the current state of
  the switch would be displayed.

  What do you think ?

Cheers
  Nick

Re: Why does linker fail to resolve dependencies within the same .a file?

[Nick Clifton]

Hi Christian,


/usr/bin/c++ -fPIC "CMakeFiles/simpleIO.dir/main_IO.o" -o
simpleIO -rdynamic
-L/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ -lGL
-lglut -Wl,-Bstatic -luriVision -luriVision -Wl,-Bdynamic
-Wl,-rpath,/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++


Note: Placing "-luriVision" twice on the command line next to each other 
like that will not actually gain you anything.  The only reason to 
include a library more than once on a linker command line is if it 
contains symbols that are referenced by files that are placed after the 
first occurrence of the library on the command line.  eg:


  foo.o -lbar baz.o -lbar

The second "-lbar" is only needed if baz.o includes references to 
symbols that are defined in libbar.a which will not be pulled in when 
resolving the references made by foo.o.



In function `uriVideoSources::ImageReader::getFrame(bool,
uriBase::RasterImage*)':
ImageReader.cpp:(.text+0x90): undefined reference to
`uriVideoSources::ImageReader_gen::getFrame_(bool,
uriBase::RasterImage*)'



[EMAIL PROTECTED]:~$ nm --demangle
/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a 
| grep outputFrame


As has already been pointed out you are greping for 'outputFrame' when 
the error message you have reported was for a missing 'getFrame_' 
symbol.  I assume therefore that you are also getting error messages 
about a missing reference to 'outputFrame_' ?



002c T uriMovieEditing::ImageWriter::outputFrame(uriBase::RasterImage*)
 T uriMovieEditing::ImageWriter::outputFrame(uriBase::RasterImage*,
bool)
   U 
uriMovieEditing::ImageWriter_gen::outputFrame_(uriBase::RasterImage*,

bool)


Which if the above assumption is correct means that the linker is right. 
  uriMovieEditing does contain an unresolved reference to an 
outputFrame_ symbol.  You will need to add whichever library or object 
file contains that symbol to the linker command line, and if it is a 
library that contains it, then it must come *after* -luriVision on the 
command line.


Cheers
  Nick

Re: Why does linker fail to resolve dependencies within the same .a file?

[Nick Clifton]

Hi Christian,

  [I have restored the CC to gcc@gcc.gnu.org as there may be other 
people interested in this discussion].



   foo.o -lbar baz.o -lbar

The second "-lbar" is only needed if baz.o includes references to
symbols that are defined in libbar.a which will not be pulled in when
resolving the references made by foo.o.


I'm not so sure that's true, because someone said that putting "bar.a"
on the linker command line is pretty much identical in effect to
listing, on the command line, the files that got bundled up into
bar.a.  So if bar.a is made up of x.o, y.o and z.o, and z.o contains a
function that depends on a function in x.o, then I really do need to
list bar.a twice in order to resolve that dependency. No?


No.  :-)

A library is not, quite, the same thing as a bunch of object files.  For 
one thing the linker *will* repeatedly search a library until no more 
undefined symbols can be resolved.  So in your example x.o will be 
pulled into the link because it is needed to resolve a reference in z.o 
(which is presumably needed to resolve a reference from an object file 
earlier on in the linker command line).


This is all described in the linker documentation as well.  Have a look 
at the description of the linker command line option --start-group.




I pasted an irrelevant example by accident, but I really am seeing the
problem in question (I think).  Here's the link command and my first
error message from it:

/usr/bin/c++  -fPIC "CMakeFiles/simpleIO.dir/main_IO.o"   -o
simpleIO -rdynamic
-L/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ -lGL
-lglut -Wl,-Bstatic -luriVision -luriVision -Wl,-Bdynamic
-Wl,-rpath,/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++


/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a(ImageReader.o): 
In function `uriVideoSources::ImageReader::getFrame(bool,

uriBase::RasterImage*)':
ImageReader.cpp:(.text+0x90): undefined reference to
`uriVideoSources::ImageReader_gen::getFrame_(bool,
uriBase::RasterImage*)'

and here's the (hopefully) telling nm/grep statement:

[EMAIL PROTECTED]:~$ nm --demangle
/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a 


| grep "uriVideoSources::ImageReader_gen::getFrame"
U uriVideoSources::ImageReader_gen::getFrame_(bool)
U uriVideoSources::ImageReader_gen::getFrame_(bool,
uriBase::RasterImage*)


Well this tells me that ...getFrame_(bool.uriBase::RasterImage*) is an 
*undefined* symbol referenced from inside liburiVision.a.  (Hence the 
'U' attribute as displayed by nm).  Hence the linker is correct in 
complaining that it cannot resolve the reference and hence you do need 
to tell the linker where to find this symbol.


Where do you think the ...getFrame_(bool.uriBase::RasterImage*) symbol 
is defined ?


Cheers
  Nick

Re: help regarding ld

[Nick Clifton]

Hi Aram,
   i am using the arm-elf-gcc compiler to generate the assembly code
arm-elf-gcc -mthumb -S new.c
after this i use the arm-elf-as for genrating machine code
arm-elf-as new.s
Note - these two steps could be combined into one by using the -c switch 
instead of the -S switch:

  arm-elf-gcc -mthumb -c new.c
it produces one a.out file.. 
Note: Despite its name this "a.out" file is not an executable program it 
is just an object file that still needs to be linked.  Naming the file 
a.out is a "feature" of the assembler.

arm-elf-ld a.out
produces error like 

arm-elf-ld: warning: cannot find entry symbol _start; not setting start address
how do i type the correct command line option for this 
Try using gcc to control the entire process from compilation to final 
link, like this:

  arm-elf-gcc new.c
Cheers
  Nick

Re: gcc with arm -vfp instructions

[Nick Clifton]

Hi Aram,
  i like to know whether gcc can generate vfp instructions.. 
This is a GCC question not a binutils question.  Please ask it on the 
gcc mailing list: [EMAIL PROTECTED]


if then, whether it will be supported on binutils and the gdb simulator
The assembler and linker will support vfp instructions if they are 
generated by the compiler, or indeed if they are in hand written 
assembler source files.

Cheers
  Nick

Re: Obsoleting more ports for 4.0.

[Nick Clifton]

Hi Kazu,

> fr30
> 
>
>   The same justification as
>
>http://gcc.gnu.org/ml/gcc/2004-06/msg01113.html
>
>  Nobody showed an interest in keeping this port.


I would like to keep this port alive.  I happen to know that Fujitsu
are still involved with developing and marketing it and that they will
be contributing patches for the gcc port at some point in the future.

Cheers
  Nick
  

Assembling pending decls before writing their debug info

[Nick Clifton]

Hi Guys,

  There is a problem with unit-at-a-time compilation and DWARF debug
  info generation.  Consider this small test case which has been
  derived from GDB's observer.c source file:

int observer_test_first_observer = 0;
int observer_test_second_observer = 0;
int observer_test_third_observer = 0;

void observer_test_first_notification_function (void)
{
  observer_test_first_observer++;
}

void observer_test_second_notification_function (void)
{
  observer_test_second_observer++;
}

void observer_test_third_notification_function (void)
{
  observer_test_third_observer++;
}

  When compiled with the current mainline gcc sources for an x86
  native target and with "-g -O2 -dA" on the command line the
  following debug info is produced:

[snip]
.long   .LASF0  # DW_AT_name: "observer_test_first_observer"
.byte   0x1 # DW_AT_decl_file
.byte   0x1 # DW_AT_decl_line
.long   0x37# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x5 # DW_AT_location
.byte   0x3 # DW_OP_addr
.long   observer_test_first_observer
.uleb128 0x3# (DIE (0x37) DW_TAG_base_type)
.ascii "int\0"  # DW_AT_name
.byte   0x4 # DW_AT_byte_size
.byte   0x5 # DW_AT_encoding
.uleb128 0x4# (DIE (0x3e) DW_TAG_variable)
.long   .LASF1  # DW_AT_name: "observer_test_second_observer"
.byte   0x1 # DW_AT_decl_file
.byte   0x2 # DW_AT_decl_line
.long   0x37# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x0 # DW_AT_const_value
[snip]

  Note how observer_test_first_observer is correctly defined as having
  a DW_AT_location and a DW_OP_addr whereas
  observer_test_second_observer is incorrectly defined as having a
  DW_AT_const_value.  ie the debug info is saying that it is a
  variable without a location in memory.

  The reason for this behaviour is that the debug information is being
  written out before the variables have been fully resolved.  In
  particular DECL_SET() for the second and third observer functions is
  NULL when the debug info is generated, which is why they are being
  given the DW_AT_const_value attribute.
  
  In trying to solve this I found that switching the order of the
  calls to lang_hooks.decls.final_write_globals() and 
  cgraph_varpool_assemble_pending_decls() in compile_file() worked,
  and this seemed to be intuitively correct.  But when I reran the gcc
  testsuite I found that the change introduced a regression:
  gcc.dg/varpool-1.c now had the variable
  "unnecessary_static_initialized_variable" still defined at the end
  of compilation.

  I have investigated some more but not gotten much further, so I am
  asking for help.  Can anyone suggest where the conflict between
  generating the debug info and deciding if the variable is going to
  be emitted should really be resolved ?

Cheers
  Nick
  

Re: Any plan to support Windows/x86-64?

[Nick Clifton]

Hi H. J.

Is there any plan to support Windows/x86-64? 


No and yes.  I think that we would like to support this target, but we 
just need contributers to work on it.  (I am pretty sure that some 
people are working on it, but they may not be ready to contribute yet).



What are needed for the port?


Support for the 64-bit PE file format I guess.

Cheers
  Nick

June 2015 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  In this month's news we have:

  * GCC now supports a "noplt" function attribute.  This specifies
that the annotated function should not be called via the PLT
mechanism.

  * GCC now supports a "target ()" function attribute to
enable target specific options on individual functions.  The ARM
port now uses this mechanism to allow programmers to individually
specify whether a function should use ARM or THUMB instructions.
For example:

  int foo __attribute__((target("thumb")));

Any functions inlined into the attributed function will inherit
that function's attributes.

  * GCC now supports attributes on enums values, although only one
such attribute is currently available:

  enum E {
oldval __attribute__((deprecated)),
newval
  };

The deprecated attribute results in a warning if the enumerator
value is used anywhere in the source file.  This is useful when
identifying enumerators that are expected to be removed in a
future version of a program.


  * GCC now supports a new warning option: -Wlto-type-mismatch

During the link-time optimization the compiler will issue warnings
about type mismatches between duplicate global declarations found
in different compilation units.  This option is enabled by default
when LTO optimization is being performed.


  * The ARM port of GCC now recognises the ARMv8,1 architecture
extensions including the Large System Extension instructions,
Privileged Access Never, Limited Ordering Regions and Advanced
SIMD instructions.


  * In GDB support for process record-replay and reverse debugging on
AArch64 targets has been added.

  * Also in GDB support for Sun's version of the "stabs" debug file
format has been removed. 


  * The linker has a new command line option: -print-memory-usage

This makes the linker print out the used size and total size of
each memory region specified by the link script and used by the
executable, which can be helpful to programmers trying to squeeze
every last byte out of a particularly small region.  The output
has a fixed format which is human readable and machine parsable.
For example:

  Memory region   Used Size  Region Size  %age Used
 ROM:256 KB 1 MB 25.00%
 RAM:  32 B 2 GB  0.00%


  * The assembler and linker now support the compact exception handler
sections as used by MIPS toolchains.  The new gas pseudo ops:

  .cfi_personality_id  
  .cfi_fde_data[ ,...]
  .cfi_inline_lsda []

Are provided to help specify the contents of this new type of
section.


  * The assembler has a new option to enable section name substitution:

   --sectname-subst  

If enabled then section names may include the "%S" sequence which
will be substituted for the name of the current section.  For
example:
   
  .macro gen_exceptions 
  .section %S.exception
  [...]
  .previous
  .endm

  .text
  [...]
  gen_exceptions
  [...]
  .section .init
  [...]
  gen_exceptions
  [...]

This will create four sections: .text, .text.exception, .init and
.init.exception.  In the future other substitution sequences in
addition to %S may be provided.


  * Support for the ARMv8.1 architecture has been added to the AArch64
and ARM ports.  This includes support for the Adv.SIMD, LOR and
PAN architecture extensions.

Cheers
  Nick

July/August GNU Toolchain update

[Nick Clifton]

Hi Guys,

  Sorry for the delay in bringing you this update; I have been very
  busy in the last few months.  Anyway the highlights of the changes
  to the GNU Toolchain are as follows:

   * The GDB 7.10 branch has been created.  Expect a release soon.

   * Support for tracepoints on aarch64-linux was added in GDBserver.

   * A point update of the FSF Binutils - 2.25.1 - has been released.
 No new features but lots of important bug fixes.

   * GCC 5.2 has been released.  This is a bug-fix update to the
 previous 5.1 release.

   * The linker now has experimental support for the removal of
 redundant sections from COFF and PE format files.  This is
 enabled via the --gc-sections linker command line option.

   * A new linker command line option --require-defined= has
 been added.  This behaves in much the same way as the
 --undefined= option in that it creates a reference to an
 undefined symbol that should force a library to be pulled into
 the link or garbage collection not to remove a specific section.
 The difference between --require-defined and --undefined is that
 with the former the linker will issue an error message if the
 specified symbol has not been defined by the end of the link.

  * The --disassemble (or -d) and --disassemble-all (or -D) options to
objdump have received a subtle change.  With -d objdump will
assume that any symbols present in a code section occur on the
boundary between instructions and so it will refuse to disassemble
across such a boundary.  With -D however this assumption is
suppressed.  This means that it is possible for the output of
-d and -D to differ if, for example, data is stored in a code
section.

  * GCC has a couple of new warning options available:

  -Wframe-address

This generates a warning when the __builtin_frame_address or
__builtin_return_address are called with an argument greater than
0.  Such calls may return indeterminate values or crash the
program.

  -Wtautological-compare

This generates a warning if a self-comparison always evaluates to
true or false.  This detects various mistakes such as:

  int i = 1;

  if (i > i) { ... }

  * With the Nios II port of GCC it is now possible to specify the
target architecture variant with -march=r1 or -march=r2.  It is
also possible to explicitly enable or disable the use of the r2
BMX (bit manipulation) and CDX (code density) instructions via the
use of the new -mbmx -mno-bmx -mcdx and -mno-cdx options.

Cheers
  Nick

September 2015 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  There are lots of things to report in this month's update...

  * The G++ ABI has been increased to version 10.
  
This adds mangling of attributes that affect type identity, such
as ia32 calling convention attributes (e.g. stdcall).

ABI conflicts can be detected with -Wabi.  This option can also be
used with an explicit version number to warn about compatibility
with a particular version level, e.g. -Wabi=2 to warn about
changes relative to ABI version 2.


  * GCC has a new configure time option: --enable-default-ssp
This turns on -fstack-protector-strong by default.


  * Several new warning options have been added to GCC:
  
-Wtemplates 

  Warns when a primary template declaration is encountered. 

-Wmultiple-inheritance

  Warns when a class is defined with multiple direct base classes.

-Wvirtual-inheritance

  Warns when a class is defined with a virtual direct base classes.

-Wnamespaces

  Warns when a namespace definition is opened.

These warnings are provided to support coding rules that disallow
certain features of C++.  The warning are automatically disabled
when parsing system header files.

-Wunused-const-variable

  Warns whenever a constant static variable is unused aside from
  its declaration.  This warning is enabled by -Wunused-variable
  for C, but not for C++.   In C++ this is normally not an error
  since const variables take the place of #define's in C++. 
 
-Wsubobject-linkage

  Warns if a class type has a base or a field whose type uses the
  anonymous namespace or depends on a type with no linkage.  If a
  type A depends on a type B with no or internal linkage, defining
  it in multiple translation units would be an ODR violation
  because the meaning of B is different in each translation unit.
  If A only appears in a single translation unit, the best way to
  silence the warning is to give it internal linkage by putting it
  in an anonymous namespace as well.  The compiler doesn't give
  this warning for types defined in the main .C file, as those are
  unlikely to have multiple definitions.


  * Some new target specific options have been added as well:

For AArch64 targets the command line option -mtls-size= can
be used to specify bit size of immediate TLS offsets.  Valid
values are 12, 24, 32, 48.

Also for AArch64, the option -mpc-relative-literal-loads enables
PC relative literal loads.  If this option is used, literal pools
are assumed to have a range of up to 1MiB and an appropriate
instruction sequence is used.

For MIPS targets the option -mcompact-branches= can be used
to control the form of generated branches.  A value of 'never'
ensures that compact branch instructions will never be generated.
'Always' means that a compact branch instruction will be generated
if available.  Otherwise a delay slot form of the branch will be
used instead.  A value of 'optimal' (which is the default) will
cause a delay slot branch to be used if one is available in the
current ISA and the delay slot is successfully filled.  If the
delay slot is not filled, a compact branch will be chosen if one
is available.

For S/390 systems the option -mhtm can be used to enable the
builtins that support the transactional execution facility.  This
option is enabled by default when -march=zEC12 is used.

Also for the S/390 the -mvx option enables the generation of code
using the vector extension instructions.  This option involves a
change to the ABI that affects vector types.  It is enabled by
default when -march=z13 is used.
A second option: -mzvector can be used to enable 'vector' as a new
language type, and to enable builtin functions associated with the
z13 vector instructions.  This option is disabled by default.

The Intel x86_64 Skylake architecture is now supported as a
parameter to the -march= and -mtune command line options.  The
values 'skylake' or 'skylake-avx512' can be used.

The Xtensa target has a new option -mauto-litpools which will
intersperse literal pools in the text section, possibly with
multiple pools per function.  This option allows the compilation
of very big functions, which may not be possible when the
-mtext-section-literals is used on its own.
 

  * The linker has enhanced its handling of orphan sections.  (Orphan
sections are section in the input files whose placement is not
specified by the linker script being used).  The new option:

  --orphan-handling=[place|warn|error|discard]

tells the linker what to do.  The default is 'place' which gives
the current behaviour, 'warn' and 'error' issue a warning or error
message respectively, and 'discard' will silently discard any and
all orphan sections.


  * The new PowerPC64 specific linker command line opt

Re: September 2015 GNU Toolchain Update

[Nick Clifton]

Hi Alan,


On Fri, Sep 25, 2015 at 01:33:34PM +0100, Nick Clifton wrote:

   * The new PowerPC64 specific linker command line option
 --no-save-restore-funcs  tells the linker not to provide the
 out-of-line register save and restore functions used by -Os compiled
 code.  The default is to provide any such referenced function for
 a normal final link, but not do so for a relocatable link.


Actually, --save-restore-funcs and --no-save-restore-funcs have been
around since 2014-02.  The recent new PowerPC64 option is
--tls-get-addr-optimize, a complement to --no-tls-get-addr-optimize.


Doh!  Sorry about that.

Cheers
  Nick

Commit: MSP430: Add support for more MCUs

[Nick Clifton]

Hi Guys,

  I am applying the attached patch to add support for more MSP430 MCUs
  to the MSP430 target.  The names and data have been copied directly
  from the the latest devices.csv file released by TI.

  The patch also updates the documentation on the MSP430's -mmcu option
  to note that if the MCU name is not recognised the compiler will
  assume that is only supports the MSP430 instruction set, and that it
  does not have any hardware multiply support.
  
  Tested with no regressions on an msp430-elf toolchain.

Cheers
  Nick

gcc/ChangeLog
2015-10-12  Nick Clifton  

* config/msp430/msp430.c (msp430_mcu_names): Rename to
msp430_mcu_data, add fields for ISA and hardware multiply
support.  Import latest data from the devices.csv file.
(msp430_override_option): Use the data from the new array.
(msp430_use_f5_series_hwmult): Likewise.
(use_32bit_hwmult): Likewise.
(msp430_no_hwmult): Likewise.
* config/msp430/t-msp430 (MULTILIB_MATCHES): Add matches for new
MCU names.
* doc/invoke.texi (MSP430 Options): Note that if the MCU name is
not recognised then no hardware multiply support is assumed and
that only the MSP430 ISA is allowed.



fred
Description: Binary data

October/November GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  Sorry for the delay between these updates.  My new job is keeping
  me very busy...  Anyway here are the highlights of the changes in
  the GNU toolchain over the last two months:


  The compiler and assembler now have support for the ARC EM/HS and
  ARC600/700 architectures and the Power9 variant of the PowerPC
  architecture.  


  The GCC mainline sources are now in Stage 3 (bug fixes only) which
  means that a branch may be happening soon.


  The Binutils sources have branched, getting ready for a 2.26 release
  soon.


  GDB's record instruction-history command accepts a new modifier: /s.
  This behaves exactly like the /m modifier and prints mixed source +
  disassembly into the history.


  GDB now supports displaced stepping on AArch64 GNU/Linux.


  GCC's named address space feature has been extended to add address
  spaces for the x86 architecture.  Here variables may be declared as
  being relative to the %fs or %gs segments using the __seg_fs and
  __seg_gs attributes.  Alternatively if one of these segments is used
  for thread local storage then the __seg_tls attribute can be used
  access the correct segment.


  GCC's function attribute feature has been extended to support
  another attribute:
  
target_clones ()

  This is used to specify that a function is to be cloned into
  multiple versions compiled with different target options than
  specified on the command line.  The supported options and
  restrictions are the same as for target attribute.

  For instance on an x86, you could compile a function with
  target_clones("sse4.1,avx").   It will create 2 function clones,
  one compiled with -msse4.1 and another with -mavx.  At the function
  call it will create resolver ifunc, that will dynamically call a
  clone suitable for current architecture.


  A new type attribute has been added to specify the endianness of the
  fields in a struct, union or array:

scalar_storage_order ("")

  This attribute sets the storage order, aka endianness, of the scalar
  fields of the type to either "big-endian" or "little-endian".  The
  attribute has no effects on fields which are themselves a union, a
  struct or an array whose component is a union or a struct, and it is
  possible to have fields with a different scalar storage order than
  the enclosing type.

  Additional restrictions are enforced for types with the reverse
  scalar storage order with regard to the scalar storage order of the
  target: 

* Taking the address of a scalar field of a union or a struct with
  reverse scalar storage order is not permitted and will yield an
  error.

* Taking the address of an array field, whose component is scalar,
  of a union or a struct with reverse scalar storage order is
  permitted but will yield a warning, unless the option
  -Wno-scalar-storage-order is specified.

* Taking the address of a union or a struct with reverse scalar
storage order is permitted. 

  These restrictions exist because the storage order attribute is lost
  when the address of a scalar or the address of an array with scalar
  component is taken, so storing indirectly through this address will
  generally not work.  The second case is nevertheless allowed to be
  able to perform a block copy from or to the array.


  A new warning option: -Wduplicated-cond will produce messages
  whenever a condition is duplicated in an if-else-if chain.  For
  example:
  
if (p->q != NULL) { ... }
else if (p->q != NULL) { ... }


  A new option: -fkeep-static-functions will make sure that gcc will
  generate code for static functions that are never used.


  The block reordering optimization in gcc can now be tuned via the
  option: -freorder-blocks-algorithm=.  The default for
  optimization levels below -O2 (or at -Os) is the "simple" algorithm 
  which does not increase code size.  The new "stc" algorithm stands
  for "software trace cache" and it tries to put all often executed
  code together, minimizing the number of branches executed by
  making extra copies of code.


  The ARM backend supports a new option: -mlow-precision-recip-sqrt
  which uses two steps instead of three for double-precision
  reciprocal square root calculations.  (It also uses one step instead
  of two steps for single-precision calculations).  This reduces the
  latency and precision of the operation.


  The x86 and x86_64 backends support a new option: -mms-bitfields
  This enables a bit-field layout compatible with the native Microsoft
  Windows compiler.   This option is enabled by default for Windows
  targets.
  

  The x86 and x86_64 backends also support the new option:
  
-mmitigate-rop

  This tries to avoid generating code sequences that contain
  unintended return opcodes, to mitigate against certain forms of
  attack.  At the moment, this option is limited in what it can do and
  should not be relied on to provide serious protection.


  The assembler and linker now supp

December/January (15/16) GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  First of all I have an apology to make.  I managed to reformat my
  hard drive over the holidays, wiping away all of my notes for this
  blog.  In particular I was contacted by a reader about an
  enhancement to gcc's inline assembler support which I have now
  totally lost. :-(  So, dear reader, wherever you are, I apologise,
  and if you contact me again I will make sure that the extended asm
  enhancement gets mentioned in the next blog post.

  The big news, for me at least, is that binutils 2.26 is now out.
  This release contains lots of bug fixes of course, plus a few new
  features:

*  A new configure option:

 --enable-compressed-debug-sections={all,gas,gold,ld,none}
 
  which decides whether DWARF debug sections should be compressed
  by default.  By default this option is off for all of the tools,
  although of course it can be enabled via command line options.
  In future releases of binutils however, the option will be
  enabled by default.

* Support for the ARC EM/HS and ARC600/700 architectures.

* Support for the LLVM plugin.

* Experimental support for linker garbage collection (--gc-sections)
  for COFF and PE based targets.

* A new linker command line option:

--orphan-handling=[place|warn|error|discard]

  is available which adjusts how orphan sections are handled.  The
  default is 'place' which gives the normal behaviour.  'warn' and
  'error' issue a warning or error respectively when an orphan
  section is found, and 'discard' will discard the section entirely.

 * The objcopy tool has a new option insert symbols into a file:
 
 --add-symbol =[:][,]

   It also has a new option to replace the contents of an existing
   section with the contents of a specified file:
   
  --update-section =

 * In the assembler, symbol and label names can now be enclosed in
   double quotes (") which allows them to contain characters that
   are not part of valid symbol names in high level languages.

 * Support for the ARMv8.1 architecture has been added to the
   AArch64 and ARM ports.


  The next binutils release (2.27) should be happening in July of
  this year as the project attempts to move to a 6 month release
  schedule.

  In the development binutils there is now support for ARM NOREAD
  sections.  These are executable sections which contain code which
  the user is not allowed to see.


  Next - there is a new release of the Newlib C library.  Version
  2.3.0 contains several enhancements and improvements, including:

   - Dynamic atexit logic fixed.
   - ARM performance enhancements.
   - New version of strtold.
   - ARC platform support redone.
   - Strftime improvements/enhancements.
   - Complex math enhancements.
   - Visium platform support added.
   - OR1K platform support added.



  GCC meanwhile continues working on reducing bug numbers so that a
  version 6 branch can be created.  In practice this means that new
  features are not being added to the sources at this point, although
  there is one new warning option to report:
  
-Winvalid-memory-model

  This warns for invocations of__atomic Builtins, __sync Builtins, and
  the C11 atomic generic functions with a memory consistency argument
  that is either invalid for the operation or outside the range of
  values of the memory_order enumeration.  For example, since the
  __atomic_store and __atomic_store_n built-ins are only defined for
  the relaxed, release, and sequentially consistent memory orders the
  following code will produce a warning: 

 void store (int *i)
 {
   __atomic_store_n (i, 0, memory_order_consume);
 }

  This option is enabled by default.

  The development version of GCC also no longer supports DWARF Version
  1, which is substantially different than Version 2 and later.  For
  historical reasons, some other DWARF-related options (including
  -feliminate-dwarf2-dups and -fno-dwarf2-cfi-asm) retain a reference
  to DWARF Version 2 in their names, but apply to all
  currently-supported versions of DWARF. 


  The GDB debugger continues to improve as well, and in the last
  couple of months these new features have been added to the
  development version:

* Support for debugging kernel-based threads on FreeBSD.

* Thread numbers are now per inferior instead of global.  If
  you are debugging multiple inferiors, GDB displays thread IDs
  using a qualified INF_NUM.THR_NUM form.  For example:

 (gdb) info threads
   Id   Target Id Frame
   1.1  Thread 0x77fc2740 (LWP 8155) (running)
   1.2  Thread 0x77fc1700 (LWP 8168) (running)
 * 2.1  Thread 0x77fc2740 (LWP 8157) (running)
   2.2  Thread 0x77fc1700 (LWP 8190) (running)

 As consequence, thread numbers as visible in the $_thread
 convenience variable and in Python's InferiorThread.num attribute
 are no longer 

February/March 2016 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  There are lots of new features to report about this time, so here
  goes:

  * GDB 7.11 has been released.

This release brings many new features and enhancements, including:

+ Per-inferior thread numbers.
  (thread numbers are now per inferior instead of being global).

+ GDB now allows users to specify breakpoint locations using a
  more explicit syntax (named "explicit location").

+ When hitting a breakpoint or receiving a signal while debugging
  a multi-threaded program, the debugger now shows which thread
  triggered the event.

+ Record btrace now supports non-stop mode.

+ Various improvements on AArch64 GNU/Linux:
   - Multi-architecture debugging support.
   - Displaced stepping.
   - Tracepoint support added in GDBserver.

+ Kernel-based threads support on FreeBSD.


  * Not to be outdone the GLIBC team have also announced a major new
release - version 2.23.  Full details can be found here:

  https://www.sourceware.org/ml/libc-alpha/2016-02/msg00502.html

But here are some highlights:
  
  + Unicode 8.0.0 Support

  + getaddrinfo now detects certain invalid responses on an internal
netlink socket.

  + A defect in the malloc implementation could result in the
unnecessary serialization of memory allocation requests across 
threads.  The defect is now corrected.  Users should see a
substantial increase in the concurrent throughput of allocation
requests for applications which used to trigger this bug.
Affected applications typically create and destroy threads
frequently.

  + There is now a --disable-timezone-tools configure option for
disabling the building and installing of the timezone related
utilities (zic, zdump, and tzselect).

  + The obsolete header  has been removed.  Programs that
require this header must be updated to use  instead.

  + Optimized string, wcsmbs and memory functions for IBM z13.


  Meanwhile in GCC land, work on getting the code ready for the GCC 6
  branch continues at a furious pace.  Some new features have made it
  in over the last couple of months however, and here are the details:
  
  * Initial support for the C++ Extensions for Concepts Technical
Specification, ISO 19217 (2015), has been added to G++.  This allows
code like this:

  template  concept bool Addable = requires (T t) { t + t; };
  template  T add (T a, T b) { return a + b; }

  * The new GCC warning option "-Wnonnull-compare" can be used to
generate a warning when comparing a variable with the "nonnull"
attribute against null.

  * The -Wunused-const-variable option has been extended.  A setting of
-Wunused-const-variable=1 only generates warnings about unused
static const variables in the main compilation unit, and not in
headers.  A setting of -Wunused-const-variable=2 also warns about
unused static const variables in non-system header files.  This
second setting corresponds to the old -Wunused-const-variable
behaviour but it must now be explicitly requested since in C++ it
is not an error and in C it might be hard to clean up all headers
involved.
  
  * The -fshort-double command line option has now been deprecated.

  * The ARC backend of GCC now supports a -mfpu= command line option to
select the type of floating point operations that can be used.

  * A GCC enhancement was made a while ago, but I totally failed to
report on it.  Fortunately reader David Wolfherd pointed this out
to me, so here is the news:
 
The inline assembler feature in GCC now has the ability to specify
the flags set in the condition code register as part of the output
of the asm.  This helps the compiler as it can now use that
information to improve the code that it generates after the inline
asm.

For more details see:
 
  https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#FlagOutputOperands

and:

  
http://developerblog.redhat.com/2016/02/25/new-asm-flags-feature-for-x86-in-gcc-6/


  There are also some changes to report in the binutils:

   * The binutils for ELF based targets can now handle commons as either
 the STT_COMMON or STT_OBJECT type.  A configure time option can
 select the default, and command line options to ld, gas and objcopy
 can be used to specify exactly which type should be used.
   
   * The LD linker now supports a couple of new features:

 + The command line option "-z noreloc-overflow" in the x86-64 ELF
   linker to disable relocation overflow check.
 
 + The command line options "-z nodynamic-undefined-weak" in the x86
   ELF linker can be used to avoid generating dynamic relocations
   against undefined weak symbols in executable.

   * The GAS assembler can now set ELF section flags and types via
 numeric values.  This allows extra or unusual bits in thes

April/May 2016 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  Well now that GCC 6 is out lets see what new features have started
  to appear in the toolchain:

  Several new warning options have been added to GCC:
  
  * The option -Wno-duplicate-decl-specifier has been added to
generate warnings whenever a declaration contains duplicate const,
volatile, restrict or _Atomic specifiers.  This warning is enabled
by -Wall.

  * The option -Wignored-attributes warns when an attribute is
correctly assigned, but the compiler decided to ignore it anyway.
This is different from the -Wattributes which warns when an
attribute is either unknown or used in the wrong place.

  * The option -Wswitch-unreachable warns whenever a switch statement
contains statements between the controlling expression and the
first case label, which will never be executed.  For example:

  switch (cond)
{
  i = 15;
  case 5:
 

The option does not warn if the statement(s) between the
controlling expression and the first case label are just variable
declarations:

  switch (cond)
{
  int i;
  case 5:
 

  * The option -Wdangling-else warns about constructions where there
may be confusion to which if statement an else branch belongs.
For example:

   if (a)
 if (b)
   foo ();
   else
 bar ();

  * The option -Wmemset-elt-size warns about suspicious calls to
the memset function, if the first argument references an array,
and the third argument is a number equal to the number of
elements, but not equal to the size of the array in memory.
For example:

  int array[10];
  memset (array, 0, 10);  // Should be: memset (array, 0, 10 * sizeof 
(int));


  A new point release of GDB is out: 7.11.1.  This is a bugfix release
  addressing these issues:

* PR remote/19863 (7.10 regression: gdb remote.c due to "setfs" with
  gdbserver < 7.7)
* PR gdb/19829 (gdb crashes with PT and reverse next)
* PR gdb/19676 (gdb fails with assert error if /proc is not mounted)
* PR gdb/19828 (7.11 regression: non-stop gdb -p : internal error)
* PR remote/19840 (gdb crashes on reverse-stepi)
* PR gdb/19858 (GDB doesn't register the JIT libraries on attach)
* PR gdb/19958 (Breakpoints/watchpoints broken on MIPS Linux <= 4.5)
* PR build/20029 (symfile.c ambiguous else warning)
* PR python/20037 (GDB use-after-free error)
* PR gdb/20039 (Using MI/all-stop, can't interrupt multi-threaded
  program after continue)a

  In the development GDB sources a couple of new features have been
  added:
  
* Fortran: Support structures with fields of dynamic types and 
  arrays of dynamic types.

* Rust language support.
  GDB now supports debugging programs written in the Rust
  programming language.


  Development in the binutils has mostly concentrated on bugfixing,
  but there have been a few new features added:

  * The ARM port of GAS now has support for the ARMv8-M architecture,
including the security and DSP extensions.

  * The ARC port of GAS now accepts .extInstruction, .extCondCode, 
.extAuxRegister, and .extCoreRegister pseudo-ops that allow an
user to define custom instructions, conditional codes, auxiliary
and core registers.

  * The MIPS port of GAS can now generate code for the DSP Release 3
Application Specific Extension.

  * Linker scripts can now use a NOCROSSREFSTO directive.  This is
like the NOCROSSREFS directive which ensures that two or more
output sections are entirely independent from each other, except
that it does allow one way referencing. The NOCROSSREFS_TO
directive takes a list of output section names and complains if
the first section is referenced from any of the other sections. 

Cheers
  Nick

August 2016 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  It has been a long time since my last post, so there is lots to tell
  you about.  First of all there have been major releases of most of
  the tools:

  GCC 6.2 is here.  This is mostly a bug-fix release over gcc 6.1 of
  course, but it does also include a few enhancements for the SPARC
  target:

 Support for --with-cpu-32 and --with-cpu-64 configure
 options has been added on bi-architecture platforms.

 Support for the SPARC M7 (Niagara 7) processor has
 been added.

 Support for the VIS 4.0 instruction set has been added.

  Binutils 2.27 has now been released.  In addition to enhancements
  mentioned in previous postings, this release also includes:

 A configure option --enable-relro={yes|no} to decide
 whether -z relro should be the default behaviour for
 the linker in ELF based targets.  If this configure
 option is not specified then relro will be enabled
 automatically for all Linux based targets except FRV,
 HPPA, IA64 and MIPS.

 Linux/x86 targets now default to enabling the compression
 of debug sections.  This change can be reverted by using
 the --enable-compressed-debug-sections=no configure option.
 
 The assembler now supports a --no-pad-sections command
 line option to prevent it from padding the end of each
 section up to its alignment boundary.  This can be useful
 on systems with very tight memory constraints.

 The ARC port of gas now accepts a --with-cpu=TYPE
 configure option to specify the default cpu type.


  GDB 7.12 is out.  This release includes:

 GDB and GDBserver are now built with a C++ compiler by default.
 The configure option --disable-build-with-cxx can be used to
 build with a C compiler instead, although this option will soon
 be deprecated.

 GDB now supports a negative repeat count in the 'x' command to
 examine memory *backwards* from the given address.
 
 GDB now supports a new mechanism that allows front-ends to provide
 fully featured GDB console views, as a better alternative to
 building such views on top of the "-interpreter-exec console"
 command.  Front-ends can now start GDB in the traditional
 command-line mode running in an embedded terminal emulator
 widget, and create a separate MI interpreter running on a
 specified i/o device.  In this way, GDB handles line editing,
 history, tab completion, etc. in the console all by itself, and
 the GUI uses the separate MI interpreter for its own control and
 synchronization, invisible to the command line.


  In addition the development versions of these tools continue to add
  new features and abilities.  For example:

G++ has a new command line option -fconstexpr-loop-limit= which
sets the maximum number of iterations for a loop in C++14
constexpr functions.  A limit is needed to detect infinite loops
during constant expression evaluation.

G++ now also supports -fstrong-eval-order which forces the
evaluation of member access, array subscripting, and shift
expressions in left-to-right order, and assignments in
right-to-left order, as adopted for C++17.  This option is enabled
by default when -std=c++1z is used.

The compiler now supports a new command line option: 
-fdiagnostics-parseable-fixits
This option tells the compiler to extend the diagnostic messages
that it displays by adding an extra line.  This line is intended
to be a machine parseable hint for consumption by an IDE.  The
hint starts with the text "fix-it:" and the rest gives information
about the source code location involved.  For example:

   fix-it:"test.c":{45:3-45:21}:"function_foo"


The compiler now supports a new optimization: -fcode-hoisting
This tries to move the evaluation of expressions executed on all
paths to as early as possible in the function.  This is especially
useful as a code size optimization, but it often helps for code
speed as well.

GCC now has support for the _Float and _Floatx types as
defined by the ISO/IEC TS 18661-3:2015 standard.  The actual set
of types supported depends upon the target architecture however.
So for example the _Float128 type is supported on all systems
where __float128 is supported or where long double has the IEEE
binary128 format.  The _Float64x type is supported on all systems
where __float128 is supported.  The _Float32 type is supported on
all systems supporting IEEE binary32.  The _Float64 and Float32x
types are supported on all systems supporting IEEE binary64.
Currently there are no target architectures that would support
the _Float16 or _Float128x types.

The ARM port of the toolchain now supports the ARMv8.2-A
architecture extensions.  In addition revisions older than ARMv4t
are now deprecated.

The PowerPC port of the compiler now supports the use of built-in
functions that allo

Re: [PATCH MIPS] Work around Bash 4.2 bug

[Nick Clifton]

Hi Maciej,

>>> The patch below works around the Bash 4.2 bug described at
>>> .
>>
>>> * emulparams/elf32bmipn32-defs.sh: Shift quote of
>>> "x$EMULATION_NAME" to the left to work around
>>> .
>>>
>>
>>>
>>> -case x"$EMULATION_NAME" in
>>> +case "x$EMULATION_NAME" in
>>>  xelf32*n32*) ELFSIZE=32 ;;
>>
>> Random comment from the sideline: pretty please add a comment
>> regarding the bug workaround *on top of the actual changed code*
>> (remember: the "why" goes in the code, not in the changelog), so
>> it has a better chance of not being inadvertently reverted but
>> instead propagating elsewhere.
> 
>  CC-ing  as this might affect them too.
> 
>  Hmm, the shell construct is so common that I think rather than auditing 
> all the scripts throughout our tree I'd rather made a `configure' check 
> for the buggy shell feature and reject any shell affected at the top level 
> and across subdirectories.  This way we won't have to keep an eye too for 
> future script changes which might reintroduce the construct elsewhere.
> 
>  Nick, WDYT?

Hmm - well it has been 5 years since bug was fixed, but if we are receiving
error reports connected to it today then buggy versions must still be in use.

A quick grep shows that there are quite a few places in the gcc and binutils
configure scripts that use the problematic form, so I agree that fixing them
all, and stopping the problem from recurring in the future, would be hard to
do.

All in all, I think that your idea is the best way forwards, so yes, I would
support it.

Cheers
  Nick

November 2016 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  Long time, no post.  Sorry about that.  So, in order to make up for
  it, here is an extra long update on the state of the GNU toolchain:

  In GCC land, 6.2 has now been released and GCC 7 is almost ready to
  branch.  Here are the new features that you can expect to find in
  GCC 7:

  * LRA is now the default register allocator for new targets and most
of the major targets now use it.

  * Suggestions for corrections to misspelt identifiers has been
expanded to include function names, macro names, enum values, type
names and preprocessor directives.

  * The output from -fverbose-asm has been extended to add comments
showing the source lines that correspond to the assembly.  For
example:

  # example.c:4:   int total = 0;
   xorl%eax, %eax  # 
  # example.c:6:   for (i = 0; i < n; i++)
   xorl%edx, %edx  # i
  .L2:
  # example.c:6:   for (i = 0; i < n; i++)
   cmpl%edi, %edx  # n, i
   jge .L5 #
  # example.c:7: total += i * i;
   movl%edx, %ecx  # i, tmp92
   imull   %edx, %ecx  # i, tmp92
  # example.c:6:   for (i = 0; i < n; i++)
   incl%edx# i
  # example.c:7: total += i * i;
   addl%ecx, %eax  # tmp92, 
   jmp .L2 #

   * Attributes can now be set on null statements.  For example:

   case 1:
 bar (1);
 __attribute__((fallthrough));
   case 2:

 (The fallthrough attribute is also new.  Its use should be
 obvious).

   * Built-in functions have been added to allow access to the PowerPC
 ISA 3.0 instructions.

  * Experimental support for C++17 has been added.  This includes:

+ A command line option -faligned-new enables support for
  allocating memory for types that require more alignment than
  void*::operator new(std::size_t) provides.  A numeric argument
  such as -faligned-new=32 can be used to specify how much
  alignment (in bytes) is provided by that function, but few users
  will need to override the default of alignof(std::max_align_t).

+ The option -fnew-inheriting-ctors which enables the P0136
   adjustment to the semantics of C++11 constructor inheritance.

  * Some new warnings have been added as well:
  
+ -Wregister which warns when the register keyword is used as a
  storage class specifier, (except when it is part of the GNU
  Explicit Register Variables extension).  The use of the
  register keyword as storage class specifier has been deprecated
  in C++11 and removed in C++17. 

+ -Wformat-length (or -Wformat-length=) warns about calls
  to formatted input/output functions such as sprintf that might
  overflow the destination buffer, or about bounded functions such
  as snprintf that might result in output truncation.

  When the exact number of bytes written by a format directive
  cannot be determined at compile-time it is estimated based on
  heuristics that depend on the  argument and on the
  optimization level in use.

  -Wformat-length=1 employs a conservative approach that warns
  only about calls that most likely overflow the buffer or result
  in output truncation.  For example, this call to sprintf below
  would be diagnosed:

   extern int a, b;
   char buf [12];
   sprintf (buf, "a = %i, b = %i\n", a, b);

  Increasing the buffer size by 1 however would stop the warning
  from being generated as it is possible that overflow will not
  occur if both a and b are small.

  -Wformat-length=2 also warns about calls where numeric arguments
  with maximal values would overflow.  So in the example above the
  warning will be generated unless the buffer is at least 34 bytes
  long in order to allow for both a and b having a value of
  INT_MAX.

+ -Wimplicit-fallthrough (or -Wimplicit-fallthrough=) warns
   when a switch case falls through.  For example: 

 switch (cond)
 {
 case 1: a = 1; break;
 case 2: a = 2;
 case 3: a = 3; break;
 }

  This warning does not warn when the last statement of a case
  cannot fall through, e.g. when there is a return statement or a
  call to function declared with the noreturn attribute.

  Since there are occasions where a switch case fall through is
  desirable, GCC provides an attribute, __attribute__((fallthrough)),
  that is to be used along with a null statement to suppress this
  warning that would normally occur.  C++17 also provides a
  standard way to suppress the -Wimplicit-fallthrough warning
  using [[fallthrough]]; instead of the GNU attribute.

  Instead of the these attributes, it is also possible to add a
  fallthrough comment to silence the warning.  The whole body of
  the C or C++ style comment should mat

April GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  This is an experimental posting of an extended version of my gcc
  blog.  Every month I post an update covering changes in gcc, the
  binutils, newlib, and gdb here:

http://nickclifton.livejournal.com/

  It was suggested that readers of this mailing list might be interested
  in the information too, so I am posting this trial run.  If you hate
  it, please let me know and I will stop.  If you like then please also
  let me know and I will continue.  If you find mistakes or omissions,
  then I will not be surprised, but I will be very glad to hear them.

  The blog itself came about because every month I perform a merge
  between the public FSF sources and Red Hat's internal, development
  sources.  During the course of this merge I often find out about
  changes and updates that I had not even realised had happened.  I also
  try to keep track of how well different targets are building and
  performing in order to get an overall feel for the state of the
  sources.

Cheers
  Nick

---
  There are several things to report this month:

  * The GCC version 5 branch has been created.  No releases have been
made from this branch yet, but when one happens it will be GCC
5.1.  Meanwhile the mainline development sources have been
switched to calling themselves GCC version 6.


  * Support has been added for configuring targets that use the Nuxi
CloudABI.  More details of this ABI can be found here:

  https://github.com/NuxiNL/cloudlibc


  * The linker and assembler now support an option to control how
DWARF debug sections are compressed:

  --compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi]

Selecting NONE disables compression.  This is the default
behaviour if this option is not used.  Selecting ZLIB or ZLIB-GNU
compresses the sections and then renames them to start with a .z.
This is the old method of indicating that a debug section has been
compressed.  Selecting ZLIB-GABI compresses the sections, but
rather than renaming them they instead have the new SHF_COMPRESSED
bit set in their ELF section header.

The other binutils tools have been updated to recognise and handle
this SHF_COMPRESSED bit.  More information on the new bit can be
found here:

  https://groups.google.com/forum/#!msg/generic-abi/dBOS1H47Q64/PaJvELtaJrsJ

In another, related change, the binutils will no longer compress a
debug section if doing so would actually make it bigger.

Also the zlib compression/decompression library sources have now
been brought in to the binutils git repository and are now a
standard part of a binutils release.


* The linker has a new command line option:

--warn-orphan

  This option tells the linker to generate a warning message
  whenever it has to guess at the placement of a section in the
  output file.  This happens when the linker script in use does
  not specify where the section should go.


* The compiler has a new option:

-fsanitize-sections=sec1,sec2,...

  This tells the address sanitizer to add protection to global
  variables defined in the named section(s).  By default any
  globals in sections with user defined names are not sanitized as
  the compiler does not know what is going to happen to them.  In
  particular variables in such sections sometimes end up being
  merged into an array of values, where the presence of address
  sanitization markers would break the array.


   * The AVR port of the compiler has a new command line option:
   
   -nodevicelib

 This tells the compiler not to link against AVR-LibC's device
 specific library libdev.a. 

  * The RX port of GCC has a new command line option to disable the
use of RX string instructions (SMOVF, SUNTIL, etc).  This matters
because it is unsafe to use these instructions if the program
might access the I/O portion of the address space.

  * The RL78 port of GCC now has support the multiply and divide
instructions provided by the G14 cpu, and the divide hardware
peripheral provided by the G13 core.



  * GDB now honours the content of the file /proc/PID/coredump_filter
(PID is the process ID) on GNU/Linux systems.  This file can be
used to specify the types of memory mappings that will be included
in a corefile.  For more information, please refer to the manual
page of "core(5)".  GDB also has a new command: "set
use-coredump-filter on|off".  It allows to set whether GDB will
read the content of the /proc/PID/coredump_filter file when
generating a corefile.

  * GDB's "info os cpus" command on GNU/Linux can now display
information on the cpus/cores on the system.

  * GDB has two new commands: "set serial parity odd|even|none" and
"show serial parity".  These allows to set or show parity for the
remote serial I/O.

Che

May 2015 Toolchain Update

[Nick Clifton]

Hi Guys,

  There are several things to report this month:

* GCC now supports targets configured to use the MUSL C library: 
http://www.musl-libc.org/


* The Compiler has a new warning option: -Wmisleading-indentation

  This generates warnings when the indentation of the code does
  not reflect the block structure.  For example:

if (some_condition ())
  foo ();
  bar ();  /* Gotcha: this is not guarded by the "if".  */

  The warning is disabled by default.


* The Compiler also has a new shift warning: -Wshift-negative-value
  
  This generates warnings when left shifting a negative value.
  The warning is enabled by -Wextra in C99 and C++11 modes (and
  newer).  The warning can be suppressed by an appropriate cast.
  For example:
  
val |= ~0 << loaded;// Generates warning
val |= (unsigned) ~0 << loaded; // Does not warn


* GCC supports a new option: -fno-plt

  When compiling position independent code this tells the compiler
  not to use PLT for external function calls.  Instead the address
  is loaded from the GOT and then branched to directly.  This
  leads to more efficient code by eliminating PLT stubs and
  exposing GOT load to optimizations.

  Not all architectures support this option, and some other
  optimization features, such as lazy binding, may disable it.


* GCC's sanitizer has a new option: -fsanitize=bounds-strict

  This option enables strict instrumentation of array bounds.
  Most out of bounds accesses are detected, including flexible
  array members and flexible array member-like arrays.


* The AArch64 backend supports a new option to enable a workaround
  for the ARM Cortex-A53 erratum number 843419.  The workaround
  itself is implemented in the linker, but it can be enabled via
  the compiler option:

-mfix-cortex-a53-843419
  
  Note, specifying -mcpu=cortex-a53 is not enough to enable this
  option as not all versions of the A53 need the erratum.


* The AArch64 backend also supports a new core type of "native".
  When used as -mcpu=native or -mtune=native it tells the backend
  to base its core selection on the host system.  If the compiler
  cannot recognise the processor of the host system then the
  option does nothing.


* The Linker now supports the Intel MCU architecture:
https://groups.google.com/forum/#!topic/ia32-abi/cn7TM6J_TIg


* GDB 7.9.1 has been released!

  GDB 7.9.1 brings the following fixes and enhancements over GDB 7.9:

 + PR build/18033 (C++ style comment used in gdb/iq2000-tdep.c and
   gdb/compile/compile-*.c)
 + PR build/18298 ("compile" command cannot find compiler if tools
   configured with triplet instead of quadruplet)
 + PR tui/18311 (Random SEGV when displaying registers in TUI mode)
 + PR python/18299 (exception when registering a global
   pretty-printer in verbose mode)
 + PR python/18066 (argument "word" seems broken in Command.complete
   (text, word))
 + PR pascal/17815 (Fix pascal behavior for class fields with testcase)
 + PR python/18285 (ptype expr-with-xmethod causes SEGV)

Cheers
  Nick



 GCC Merge:

Toolchains that do not build GCC successfully:

  None.

Toolchains that do not build LIBGCC successfully:

  mep-elf: ICE: in pre_and_rev_post_order_compute, at cfganal.c

Toolchains that do not build NEWLIB successfully:

  None.

Toolchains that do not build the target LIBIBERTY successfully:
   
  None.

Toolchains that do not build LIBSTDC++-V3 successfully:

  cr16-elf:ICE: in gen_rtx_SUBREG in emit-rtl.c
  m32c-elf:ICE: in connect_traces, at dwarf2cfi.c

Toolchains that fail to build GDB:

  Not supported:

arc-elf cr16-elfepiphany-elf
ia64-elfmcore-elf   mmix-mmixware
nds32le-elf nios2-elf   pdp11-aout
tilepro-gnu-linux   visium-elf

  No sim:
  
mips64vr-elf

Toolchains that DO build all their target libraries and gdb:

aarch64-elf arm-eabiavr-elf
bfin-elfc6x-elf cris-elf
frv-elf h8300-elf   i386-elf
iq2000-elf  lm32-elfm32r-elf
mipsisa32-elf   mipsisa64-elf   mn10300-elf
moxie-elf   msp430-elf  rl78-elf
powerpc-eabispe powerpc-elf rx-elf
sh-elf  sh64-elfspu-elf
tx39-elfv850e-elf   visium-elf
xstormy16-elf 



[SIM based] GCC DG Testsuite Results

  The chart below is sorted on the number of unexpected
  failures, rather than alphabetically, in order to provide a
  small guide to toolchain quality.  [The better/worse number
  shows how the re

RFC: Treat plugins as first class citizens

[Nick Clifton]

Hi Guys,

 I was thinking that it would be nice to make plugins a "first-class
 citizen" in the gcc world by having a proper directory structure and
 integration into the rest of gcc.  For example:

gcc/plugins   <-- Everything plugin-y starts here
gcc/plugins/Make-lang.in  <-- Makefile fragment.
gcc/plugins/src   <-- Maybe move gcc/plugins.[c|h|def] here ?
gcc/plugins/doc   <-- Actual documentation, wow!
gcc/plugins/testsuite <-- Tests for the plugins and their integration 
into gcc
gcc/plugins/config<-- Subdirectories of this directory contain each 
real plugin
gcc/plugins/config/annobin  <-- For example, this is where my pet plugin 
would go

  Plus there could be an official plugins maintainer.  (I am willing to
  volunteer, so is Aldy Hernandez).  The documentation would be compiled
  along with the rest of gcc's documentation and the testsuite would be
  run as part of gcc's normal testing process.  Ideally I would also
  like to see plugin test failures be considered as blockers for new
  releases, but that is something for the future.

  So, what do you think ?  Should I create a patch and submit it for
  official review ?
  
Cheers
  Nick

Re: RFC: Treat plugins as first class citizens

[Nick Clifton]

Hi Richard,

>>  I was thinking that it would be nice to make plugins a "first-class
>>  citizen" in the gcc world by having a proper directory structure and
>>  integration into the rest of gcc.

> I believe plugins are currently a hack due to the lack of a clearly defined
> API to access GCC internals.  Unless that is resolved somehow, see various
> half-way finished patch prototypes from two (or three?) years ago treating
> them as "first class" would be a blatant labeling lie.  It's at most
> "first class mess".

One of the goals of this proposal is to help combat this mess by making plugins
a respected and official part of gcc.  Such that, when the plugins fail to 
build,
test or install, the problem would be considered a blocker and it would have to 
be fixed before the sources are released.

At the moment nobody (well almost nobody) cares about 


> The most obvious "proof" of the broken current state is that plugins are 
> broken
> all the time because at make install time we forget to install another
> of the GCC internal headers.  The bug is of course that we need those at all.

Presumably you are talking about the ability to build plugins using an installed
version of gcc ?  This is separate from this proposal which is about building 
and
installing plugins at the same time that gcc is built and installed.  One 
possible
way to address this problem is to state that plugins should not be built 
outside of
a gcc build tree.  Or at least any plugins that require intimate access to gcc's
internal headers.


> I'm still convinced that 99% of all (valid) plugin uses involve only
> introspection or well-defined instrumentation.

I agree, and I would like to see a move towards officially accepting these 
plugins 
into gcc's ecosystem.

Cheers
  Nick

Re: November 2016 GNU Toolchain Update

[Nick Clifton]

Hi Gerald,

> Thanks for that update, Nick.  Surely interesting reading.
> Are you planning another update for March or so? ;-)

Thanks for the ping!  I have been intending to write another
update for the last month or so, but I keep on letting it slip. :-(
I will make it my top priority for this week.

Cheers
  Nick

March 2017 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  There is a lot to tell you about this time.  First up is glibc:
  
The GNU C Library version 2.25 is now available.  In this version you
will find:

  * Provisional support for ISO/IEC TR 24731-1:2010 which provides
replacement versions of many of the memory allocation functions
that include bounds checking.

  * Provisional support for ISO/IEC TR 24731-2:2010 which provides
replacement versions of many of the memory allocation functions
that use dynamically allocated memory to ensure that buffer
overflow do not occur.

  * Provisional support for *some* of the new features that are
defined in ISO/IEC TS 18661-4:2015, which is an implementation of
the ISO/IEC/IEEE 60559:2011 floating point standard.

  * Full support for ISO/IEC TS 18661-1:2014 standard which implements 
support for binary floating-point arithmetic conforming to
ISO/IEC/IEEE 60559:2011.  This does not cover decimal
floating-point arithmetic, nor does it cover many of the optional
features of IEC 60559.

  * Glibc can now be built with the stack smashing protector enabled.
This means that distributions can build glibc with 
--enable-stack-protector=strong defined and expect it to work. 

  * The function explicit_bzero, from OpenBSD, has been added to glibc.
It is intended to be used instead of memset() to erase sensitive
data after use; the compiler will not optimize out calls to
explicit_bzero even if they are "unnecessary" (in the sense that
no _correct_ program can observe the effects of the memory clear).

  * On ColdFire, MicroBlaze, Nios II and SH3, the float_t type is now
defined to float instead of double.  This does not affect the ABI of
any libraries that are part of the GNU C Library, but may affect the
ABI of other libraries that use this type in their interfaces.

  * On x86_64, when compiling with -mfpmath=387 or -mfpmath=sse+387,
the float_t and double_t types are now defined to long double
instead of float and double.  These options are not the default,
and this does not affect the ABI of any libraries that are part of
the GNU C Library, but it may affect the ABI of other libraries
that use this type in their interfaces, if they are compiled or
used with those options.

  * The getentropy and getrandom functions, and the 
header file have been added.

  * The buffer size for byte-oriented stdio streams is now limited to
8192 bytes by default.  Previously, on Linux, the default buffer
size on most file systems was 4096 bytes (and thus remains
unchanged), except on network file systems, where the buffer size
was unpredictable and could be as large as several megabytes.

  * GDB pretty printers have been added for mutex and condition
variable structures in POSIX Threads. When installed and loaded in
gdb these pretty printers show various pthread variables in
human-readable form when read using the 'print' or 'display'
commands in gdb.

  * A tunables feature has been added to allow tweaking of the runtime
for an application program.  This feature can be enabled with the
'--enable-tunables' configure flag when glibc is built.  The GNU C
Library manual has details on usage and README.tunables file has
instructions on adding new tunables to the library.

Meanwhile in the mainline development sources of glibc you can also
find these new features:

  * Unicode 9.0.0 Support: Character encoding, character type info,
and transliteration tables are all updated to Unicode 9.0.0.

  * The rpcgen, librpcsvc and related headers will only be built and
installed when glibc is configured with --enable-obsolete-rpc.
This allows alternative RPC implementations, like TIRPC, to be
used by default.  Applications needing features missing from TIRPC
should consider the rpcsvc-proto project developed by Thorsten
Kukuk (SUSE).


GDB 7.12.1 has been released.   This is a point release over 7.12
and so it only contains bug-fixes rather then new features, but if you
have been using 7.12 then it is worth upgrading to 7.12.1.

Version 5 of the DWARF debug standard has now been officially
released.  This has improvements in many areas, such as: better data
compression, separation of debugging data from executable files,
improved description of macros and source files, faster searching for
symbols, improved debugging of optimized code, as well as numerous
improvements in functionality and performance.

If you want to read the new standard it is here:
  http://dwarfstd.org/doc/DWARF5.pdf

Meanwhile in the development sources:

  * GDB can now access to the PKU register on x86_64 GNU/Linux. The
register is added by the Memory Protection Keys for Userspace
feature which will be available in future Intel CPUs.

  * Python scripts can now start, stop and access a running btrace
recording.

  * GDB now supports recording and replaying rdrand and rdseed Intel 

Summer 2017 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  It has been a long time since my last post on the developments in
  the toolchain, so there is lots to report:

---
Binutils:

  Version 2.29 has been released.

  In addition to previous changes already detailed in this blog, this
  release also contains:

* Support for placing sections into special memory areas on
  systems that use virtual memory managers.  This is like the
  MEMORY command in linker scripts except that that only works
  on systems without a memory management unit.

  With the new system sections can be marked as requiring a
  particular kind of special memory.  The linker collects together
  all of the sections with the same requirements and places them
  into a specially marked segment.  The loader can then detect
  this segment's requirements and ensure that the right kind of
  memory is used.

* Support for the WebAssembly file format and conversion to the
  wasm32 ELF format.

* The PowerPC assembler now checks that the correct register class
  is used in instructions.

* The ARM assemblers now support the ARMv8-R architecture and
  Cortex-R52 processors.

* The linker now supports ELF GNU program properties.  These are
  run-time notes intended for the loader that tell it more about
  the binary that it is initializing.

* The linker contains support for Intel's Indirect Branch Tracking
  (IBT) enhancement.  This is a technology intended to help fight
  malicious code that abuses the stack to force unwanted behaviour
  from a program.  For more information see:
  
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

* Section groups can now be resolved (the group deleted and the
  group members placed like normal sections) at partial link time
  either using the new linker option --force-group-allocation or
  by placing FORCE_GROUP_ALLOCATION into the linker script.
  
* The MIPS port now supports:

+ MicroMIPS eXtended Physical Addressing (XPA) instructions.
+ Release 5 of the ISA.
+ Imagination interAptiv MR2 processor.
+ MIPS16e2 ASE for assembly and disassembly.

* The SPARC port now supports the SPARC M8 processor, which
  implements the Oracle SPARC Architecture 2017.

* Objdump's --line-numbers option can now be augmented via the new
  --inlines option so that inlined functions will display their
  nesting information. 

* Objcopy now has an option '--merge-notes' to reduce the size of
  notes in a binary file by merging and deleting redundant entries. 

* The AVR assembler has support for the __gcc_isr
  pseudo-instruction.  This instruction is generated by GCC when
  it wants to create the prologue or epilogue of an interrupt
  handler.  The assembler then ensures that the most optimal code
  possible is generated.

  Meanwhile in the mainline binutils sources:

  * The assembler now has support for location views in DWARF debug
line information.  This is part of a project to help improve the
source code location information that the compiler provides to the
debugger:

https://developers.redhat.com/blog/2017/07/11/statement-frontier-notes-and-location-views/#more-437095


GDB

  Version 8.0 has been released.  This release contains:

* Support for C++ rvalue references.

* Python scripting enhancements:
  + New functions to start, stop and access a running btrace
recording.
  + Rvalue reference support in gdb.Type.

* GDB commands interpreter:
  + User commands now accept an unlimited number of arguments.
  + The "eval" command now expands user-defined arguments.

* DWARF version 5 support

* GDB/MI enhancements:
  + New -file-list-shared-libraries command to list the shared
libraries in the program. 
  + New -target-flash-erase command, to erase flash memory.

* Support for native FreeBSD/mips (mips*-*-freebsd)

* Support for the Synopsys ARC and FreeBSD/mips targets.

  For a complete list and more details on each item, please see the
  gdb/NEWS file in the release sources.

  Meanwhile in the development sources the following new features have
  been added:

* On Unix systems, GDBserver now does globbing expansion and
  variable substitution in inferior command line arguments.

* New commands  
  + set debug separate-debug-file
  + show debug separate-debug-file
  These control the display of debug output about separate debug
  file search.

--
GCC

  Version 7.1 has been released.  Most of the enhancements and new
  features in this release have already been reported in earlier
  versions of th

RFC: Update top level libtool files

[Nick Clifton]

Hi Guys,

  I would like to update the top level libtool files (libtool.m4,
  ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by
  gcc, gdb and binutils.  Currently we have version 2.2.7a installed in
  the source trees and I would like to switch to the latest official
  version: 2.4.6.

  The motivation for doing this is an attempt to reduce the number of
  patches being carried round by the Fedora binutils releases.
  Currently one of the patches there is to fix a bug in the 2.2.7a
  libtool which causes it to select /lib and /usr/lib as the system
  library search paths even for 64-bit hosts.  Rather than just bring
  this patch into the sources however, I thought that it would be better
  to upgrade to the latest official libtool release and use that
  instead.

  I have successfully run an x86_64 gcc bootstrap, built and tested lots
  of different binutils configurations, and built and run an x86_64 gdb.
  One thing that worries me though, is why hasn't this been done before?
  Ie is there a special reason for staying with the old 2.2.7a libtool ?
  If not, then does anyone object to my upgrading the gcc, gdb and
  binutils mainline sources ?
  
Cheers
  Nick

Re: RFC: Update top level libtool files

[Nick Clifton]

Hi Joseph,

> As per previous discussions on the issue: it's necessary to revert libtool 
> commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see 
> .

OK - thanks for that pointer.

> I do not know 
> if there are other local libtool changes that are not in version 2.4.6; it 
> would be necessary to check all differences from 2.2.7a to determine 
> whether any need to be re-applied to 2.4.6.

*sigh*  It seems that 2.2.7a was not an official release.  At least I could
not find a tarball for that specific version on the ftp.gnu.org/libtool archive.
(There is a 2.2.6b release and a 2.2.8 release but no 2.2.7).  So it
looks like we have been using a modified set of sources for a long time now.

Maybe I would be better off not rocking the boat, and just submit the Fedora
sys_path patch for consideration instead...

 
> For that matter, these trees are also using very old autoconf and automake 
> versions and using the current versions of those (2.69 and 1.15.1) would 
> be a good idea as well.  Hopefully version dependencies are loose enough 
> that it's possible to update one tool at a time (so update libtool without 
> needing to update autoconf or automake at the same time).

Oh gosh - I would love to see that done.  But the last time I tried I ended 
up going down a rabbit hole of autoconf/automake problems that just never 
ended.  So I gave up. :-(  Maybe someone with more autoconf-fu than me will
have a go one day though.

Cheers
  Nick

Fall 2017 GNU Toolchain Update

[Nick Clifton]

Hi Guys,

  A new version of GLIBC and a whole boatload of new GCC features
  means that there is lots to report this time.

---
GLIBC:

  Version 2.26 is now out.  There are loads of new features and bug
  fixes in this release.  Some of the highlights include:

  * A per-thread cache has been added to malloc. Access to the cache
requires no locks and therefore significantly accelerates the fast
path to allocate and free small amounts of memory. Refilling an
empty cache requires locking the underlying arena. Performance
measurements show significant gains in a wide variety of user
workloads. Workloads were captured using a special instrumented
malloc and analyzed with a malloc simulator.

  * Unicode 10.0.0 Support.

  * The tunables feature is now enabled by default.  This allows users
to tweak behavior of the GNU C Library using the GLIBC_TUNABLES
environment variable.

  * New function reallocarray, which resizes an allocated block (like
realloc) to the product of two sizes, with a guaranteed clean
failure upon integer overflow in the multiplication.

  For the full announcement see: 
https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html

---
GCC:

  Gcc is currently in stage 1 and open for all kinds of exciting new
  features.  Here are some that have made it in already:
  
  -fstd=c++2a
   Enables support for the next revision of the ISO C++ standard,
   tentatively planned for 2020.  Support is highly experimental, and
   will almost certainly in incompatible ways in future releases.

  -Wsuggest-attribute=cold
   Warn about functions that might be candidates for the (cold)
   attribute.  This is based on static detection and generally will
   only warn about functions which always leads to a call to another
   cold function such as wrappers of C++ throw or fatal error
   reporting functions leading to abort. 

  -Wcast-align=strict
   Warn whenever a pointer is cast such that the required alignment of
   the target is increased.  For example, warn if a "char *" is
   cast to an "int *" regardless of the target machine.

  -fstack-clash-protection
   Generate code to prevent stack clash style attacks.  When this
   option is enabled, the compiler will only allocate one page of
   stack space at a time and each page is accessed immediately after
   allocation.  Thus, it prevents allocations from jumping over any
   stack guard page provided by the operating system.

   Most targets do not fully support stack clash protection.  However,
   on those targets the option will protect dynamic stack allocations.
   The option may also provide limited protection for static stack
   allocations if the target supports the -fstack-check=specific
   option.
 
  -fsanitize=pointer-overflow
   This option enables instrumentation of pointer arithmetics.  If the
   pointer arithmetics overflows, a run-time error is issued.

  -fsanitize=builtin
   This option enables instrumentation of arguments to selected
   builtin functions.  If an invalid value is passed to such
   arguments, a run-time error is issued.  E.g. passing 0 as the
   argument to __builtin_ctz or __builtin_clz invokes undefined
   behavior and is diagnosed by this option.

  -fcf-protection==[full|branch|return|none]
   Enable code instrumentation of control-flow transfers to increase
   program security by checking that target addresses of control-flow
   transfer instructions (such as indirect function calls, function
   returns and indirect jump) are valid.  This prevents diverting the
   flow of control to an unexpected target.  This is intended to
   protect against such threats as Return-oriented Programming (ROP),
   and similarly call/jmp-oriented programming (COP/JOP).

  -fpatchable-function-entry=[,]
   Generate  NOPs right at the beginning of each function, with the
   function entry point before the  is omitted, it
   defaults to 0 so the function entry points to the address just at
   the first NOP.

   The NOP instructions reserve extra space which can be used to patch
   in any desired instrumentation at run time, provided that the code
   segment is writable.

   For run-time identification, the starting addresses of these areas, 
   which correspond to their respective function entries minus ,
   are additionally collected in the __patchable_function_entries
   section of the resulting binary.

  -static-pie
   Produce a static position independent executable on targets that
   support it.  A static position independent executable is similar to
   a static executable, but can be loaded at any address without a
   dynamic linker.  For predictable results, you must specify the
   same set of options used for compilation (-fpie, -fPIE, or model
   suboptions) when you specify this linker option. 
 
  There is also a new variable attribute:

   nonstring 
This sp

RFC: Collecting together binary file attributes into a single file.

[Nick Clifton]

Hi Guys,

  All I wanted to do was to make GCC's ARM assembler output slightly
  easier to read...

  I would like to propose a patch to create a new header file in the
  include/ directory.  This file would contain enums describing the
  attributes that be can found in SHT_GNU_ATTRIBUTES sections.  The
  purpose of the file is to provide a single place where these values
  are defined, and to share the information between GCC, BINUTILS and
  GDB.

  The patch also includes an update to readelf to make it use the
  enumerated values and an example of a patch to the ARM backend of GCC
  to include the attribute names in its assembler output.


  So - what do people think ?  Any objections to this idea ?

Cheers
  Nick

*** /dev/null   2011-09-29 08:15:18.023000106 +0100
--- include/binary-file-attributes.h2011-09-29 10:21:09.615305343 +0100
***
*** 0 
--- 1,317 
+ /* binary-file-attributes.h -- contains descriptions of generic and target
+specific attributes found in ELF sections with the SHT_GNU_ATTRIBUTES
+section type.
+ 
+Copyright 2011 Free Software Foundation, Inc.
+ 
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3 of the License, or
+(at your option) any later version.
+ 
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+ 
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
+MA 02110-1301, USA.  */
+ 
+ /* Note: This file is placed in the include/ directory, rather than the
+include/elf subdirectory so that it can be shared between GCC and the
+BINUTILS.  */
+ 
+ /* Note: This header does not have a #define to prevent multiple inclusions.
+In fact if necessary, it can be included more than once.  Each section
+however does have its own #define to prevent redefinition.  */
+ 
+ #ifndef _GNU_ATTRIBUTES_DEFINED_
+ #define _GNU_ATTRIBUTES_DEFINED_
+ 
+ enum
+ {
+   Tag_GNU_Generic_File_attributes = 1,
+   Tag_GNU_Generic_Section_attributes = 2,
+   Tag_GNU_Generic_Symbol_attributes = 3,
+   Tag_GNU_Generic_compatibility = 32
+ };
+ 
+ #endif /* _GNU_ATTRIBUTES_DEFINED_ */
+ 
+ 
+ 
+ #ifdef  _ARM_EABI_ATTRIBUTES_
+ #ifndef _ARM_EABI_ATTRIBUTES_DEFINED_
+ #define _ARM_EABI_ATTRIBUTES_DEFINED_
+ 
+ /* EABI object attributes.  */
+ enum
+ {
+   /* 0-3 are generic.  */
+   Tag_CPU_raw_name = 4,
+   Tag_CPU_name = 5,
+   Tag_CPU_arch = 6,
+   Tag_CPU_arch_profile = 7,
+   Tag_ARM_ISA_use = 8,
+   Tag_THUMB_ISA_use = 9,
+   Tag_FP_arch = 10,
+   Tag_WMMX_arch = 11,
+   Tag_Advanced_SIMD_arch = 12,
+   Tag_PCS_config = 13,
+   Tag_ABI_PCS_R9_use = 14,
+   Tag_ABI_PCS_RW_data = 15,
+   Tag_ABI_PCS_RO_data = 16,
+   Tag_ABI_PCS_GOT_use = 17,
+   Tag_ABI_PCS_wchar_t = 18,
+   Tag_ABI_FP_rounding = 19,
+   Tag_ABI_FP_denormal = 20,
+   Tag_ABI_FP_exceptions = 21,
+   Tag_ABI_FP_user_exceptions = 22,
+   Tag_ABI_FP_number_model = 23,
+   Tag_ABI_align_needed = 24,
+   Tag_ABI_align_preserved = 25,
+   Tag_ABI_enum_size = 26,
+   Tag_ABI_HardFP_use = 27,
+   Tag_ABI_VFP_args = 28,
+   Tag_ABI_WMMX_args = 29,
+   Tag_ABI_optimization_goals = 30,
+   Tag_ABI_FP_optimization_goals = 31,
+   /* 32 is generic (Tag_compatibility).  */
+   Tag_undefined33 = 33,
+   Tag_CPU_unaligned_access = 34,
+   Tag_undefined35 = 35,
+   Tag_FP_HP_extension = 36,
+   Tag_undefined37 = 37,
+   Tag_ABI_FP_16bit_format = 38,
+   Tag_undefined39 = 39,
+   Tag_undefined40 = 40,
+   Tag_undefined41 = 41,
+   Tag_MPextension_use = 42,
+   Tag_undefined43 = 43,
+   Tag_DIV_use = 44,
+   /* Note: 45 - 63 are currently undefined/unused.  */
+   Tag_nodefaults = 64,
+   Tag_also_compatible_with = 65,
+   Tag_T2EE_use = 66,
+   Tag_conformance = 67,
+   Tag_Virtualization_use = 68,
+   Tag_undefined69 = 69,
+   Tag_MPextension_use_legacy = 70,
+ 
+   /* The following tags are legacy names for other tags.  */
+   Tag_VFP_arch = Tag_FP_arch,
+   Tag_ABI_align8_needed = Tag_ABI_align_needed,
+   Tag_ABI_align8_preserved = Tag_ABI_align_preserved,
+   Tag_VFP_HP_extension = Tag_FP_HP_extension
+ };
+ 
+ /* Values for the Tag_CPU_arch EABI attribute.  */
+ enum
+ {
+   TAG_CPU_ARCH_PRE_V4,
+   TAG_CPU_ARCH_V4,
+   TAG_CPU_ARCH_V4T,
+   TAG_CPU_ARCH_V5T,
+   TAG_CPU_ARCH_V5TE,
+   TAG_CPU_ARCH_V5TEJ,
+   TAG_CPU_ARCH_V6,
+   TAG_CPU_ARCH_V6KZ,
+   TAG_CPU_ARCH_V6T2,
+   TAG_CPU_ARCH_V6K,
+   TAG_CPU_ARCH_V7,
+   TAG_CPU_ARCH_V6_M,
+   TAG_CPU_ARCH_V6S_M,
+   TAG_CPU_ARCH_V7E_M,
+   MAX_TAG_CPU_ARCH = TAG_CPU_ARCH_V7E_M,
+   /* Pseudo-architecture to allow objects to be compatible with the subset of
+

Re: RFC: Collecting together binary file attributes into a single file.

[Nick Clifton]

Hi Richard,


I don't think it's a good idea to have the attributes of
every CPU we support in a single file.  That's going to
get unmaintainable very quickly.


Really - why ?

These attributes are mostly static.  Some new ones might be added from 
time to time, but baring the introduction of new ports I do not see any 
other changes that re likely to happen.


Cheers
  Nick

Re: Support for VLE code in PowerPC

[Nick Clifton]

Hi Kaushik,


We are planning to support the same in binutils, gcc and newlib.
Please let us know if you have any suggestions to implement this support
for easier FSF approval.


Please make sure that you have an FSF Binutils Copyright assignment in 
place.


Please follow the GNU Coding Standards:
  http://savannah.gnu.org/projects/gnustandards

Please try to include one or more assembler test cases to check the 
assembly and disassembly of the new instructions.


Cheers
  Nick

Re: New Failure in GCC testsuite from PR35318

[Nick Clifton]

Hi Jakub,


The test needs double, otherwise it wouldn't fail with a buggy cc1 on i?86.
I've been initially contemplating putting the testcase into
gcc.target/i386/, but then thought it would be good to test this on a couple
of other arches too.  Guess it can be limited to a couple of targets which
are supposed to handle this, or it can have a list of targets which aren't
supposed to compile this.


Well my tests show that it fails on:

 am33-*-*
 arc-*-*
 avr-*-*
 h8300-*-*
 frv-*-*
 hppa64-*-*
 m32c-*-*
 m32r-*-*
 m68hc1*-*-*
 mmix-*-*
 mn10300-*-*
 powerpc*-*-*
 sh-*-*
 vax-*-*

I have a patch to add a "dg-skip-if" line to the pr35318.c file for 
these targets.  Shall I submit it officially ?


Cheers
  Nick

New Failure in GCC testsuite from PR35318

[Nick Clifton]

Hi Jakub,

  You recently added gcc.c-torture/compile/pr35318.c to the gcc
  testsuite.  This has introduced a new group of failures for the m32c
  port because of this error message:

pr35318.c: In function 'foo':
pr35318.c:7: error: can't find a register in class 'GENERAL_REGS' while 
reloading 'asm'
pr35318.c:7: error: 'asm' operand has impossible constraints

  Looking at the test it appears to assume that a double can be put
  into register class "r", but this is not true for the m32c (and
  probably other 16-bit ports as well), since doubles occupy two
  registers.

  I can add an xfail for the m32c, but I was wondering if it would
  break the importance of the test if the "double" type was changed to
  "float" ?  This would allow the test to pass for the m32c as well.

Cheers
  Nick

Re: [Ada] runtime license wording change and Ada bootstrap, gcc/ada/scn.adb Determine_License

[Nick Clifton]

Hi Laurent,


The license wording will soon be changed and Ada gcc/ada/scn.adb
(function Determine_License) currently checks about licence.
Any change to the wording breaks Ada bootstrap as Jakub found out.

How should we proceed?


I have already changed the patch under development so that the text in 
the ada files now reads:


 As a special exception under Section 7 of GPL version 3, you
 are granted additional permissions described in the GCC Runtime
 Library Exception, version 3.1, as published by the Free Software
 Foundation.

This includes the magic words "As a special exception" which should 
satisfy the license scanner.


Cheers
  Nick

Re: For backend maintainers: changes for C++ compatibility

[Nick Clifton]

Hi Ian,


I would like to ask the maintainers for backends which
I did not mention to bootstrap their targets if possible, and/or to
build them with a newly built mainline compiler, to see if there are new
warnings about C++ compatibility.


For the record I have tested the fr30, iq2000, m32r, mcore, v850 and 
xstormy16 backends and they have no problems.


Cheers
  Nick

Re: gcc --help for options which are not warnings or optimizations

[Nick Clifton]

Hi Ian,


Nick, how is gcc --help supposed to work for options which are neither
warnings nor optimizations?  For example, -fstack-protector.  Is there a
--help option which will display it?


Yes - but only the generic "--help --verbose" rather than a more 
qualified version.


My original goal with the qualifiers for --help was to enable to 
automatic collection of all optimization options available in a 
particular version of gcc.  These would then be plugged in to a script 
to try out various different combinations of those options in the hopes 
of find the optimum selection.


I suppose we could add another qualifier along the lines of 
"--help=not-otherwise-shown" but that seems rather klunky.


Cheers
  Nick

Re: gcc --help for options which are not warnings or optimizations

[Nick Clifton]

Hi Ian, Hi Diego,

> Diego Novillo wrote:

--help=other?


That works. :-)

Actually, there already is a qualifier which will select 
-fstack-protector, I had just forgotten about it:


  % gcc --help=common | grep stack
  -Wstack-protector   Warn when not issuing stack smashing 
protection

  -fdefer-pop Defer popping functions args from stack until
  -fomit-frame-pointerWhen possible do not generate stack frames
  -fstack-check   Insert stack checking code into the program
  -fstack-limit   This switch lacks documentation
  -fstack-limit-register= Trap if the stack goes past 
  -fstack-limit-symbol= Trap if the stack goes past symbol 
  -fstack-protector   Use propolice as a stack protection method
  -fstack-protector-all   Use a stack protection method for every 
function


Cheers
  Nick

Re: Alignment error

[Nick Clifton]

Hi Thomas,

[Note: You sent this to g...@sourceware.org but the correct address to 
use is g...@gcc.gnu.org].



int* pInt   = (int*)0x10002004;  //word-aligned
char* pChar = (char* )0x10003005;  //non-word-aligned

*pInt = 0x34;
*pChar = 'A';

The assembly mnemonics for the above two statements are STR and STRB
respectively.

This I made part of the u-boot and build successfully for the smdk2400
platform. But when I debugged with GDB, *pChar = 'A' throwed an
exception.


What kind of exception ?  There should be no restrictions on byte 
accesses to memory, unless the memory region itself is restricted to 
Priviledged access only.




So, the same source code and also the same ASM mnemonic works
differently with the code generation commands(i.e., gcc).

In this regard, I am searching for the gcc command line argument present
in the u-boot makefile which throws exception in GDB for accessing
non-word-aligned address that corresponds to char*.

Kindly give me useful tips.


If you add "-v" to the gcc command line that is being generated by your 
u-boot makefile then gcc will display the command line that it uses to 
invoke the compiler, assembler and linker.


If that does not work then you could try placing a small script in the 
execution search path ahead of the real gcc that echos its arguments and 
then calls the real gcc.


Cheers
  Nick

Re: RFC: Add zlib source to src CVS resposity

[Nick Clifton]

Hi Guys,

>>> So this becomes a question for the binutils maintainers: do

the binutils want to be self-contained, or do they want to follow the
path of gcc and require additional libraries to be installed before a
build can succeed?


As I see it the pros of having a copy of the zlib sources in the 
binutils tree are that:


  * The tools can be built on a host that does not have
zlib installed.

  * We can be sure exactly which version of zlib is being
used.

  * It simplifies our configure scripts and sources.  We
always know that zlib is present and the API to use.

Whereas the cons of having our own copy of zlib are that:

  * We have to manually import any bug-fixes or enhancements
to the official zlib sources.  Which means that we have
to watch the zlib sources and be ready to evaluate any
changes.

  * We have to make sure that zlib will build on all of the
hosts that we care about.  Should the situation arise
where the zlib does not build on a particular host, and
the zlib maintainers are not interested in making it
build there, then it will be down to us to fix it.  Or
else abandon compression support on that host.

  * It is essentially a waste of space on hosts that already
have zlib installed.

At the moment I feel that the pros outweigh the cons.  What do other 
people think ?


Cheers
  Nick

Re: RFC: Add zlib source to src CVS resposity

[Nick Clifton]

Hi H.J.

  Right - this decision has been made.  We are not going to include 
zlib the in the binutils sources.


  Thanks for suggesting the idea and working on the patch, but in the 
end it was just not a path we wanted to go down.


Cheers
  Nick Clifton

Re: PATCH: Update src/intl from gcc/intl

[Nick Clifton]

Hi Steve,


OK, Here is an official patch proposal to replace the contents of the
src/intl tree with the bits from gcc/intl.



2006-05-19  Steve Ellcey  <[EMAIL PROTECTED]>

* MAINTAINERS: Change intl updating instructions.
* config.rpath: Copy from GCC tree.
* intl: Replace contents of intl directory with intl from GCC tree.


Approved for binutils.

Cheers
  Nick

Re: type consistency of gimple

[Nick Clifton]

Hi Diego,


Jeff's point about our optimizers is also true.  Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago?  I didn't follow most of the details, but it involved ivopts and
sign issues.  Could you send a summary?


Sure:

  I was looking at how a gcc 4.1 based compiler optimized a fast 
fourier transform algorithm for the MIPS target.  What I found was the 
it was producing much worse code than a similarly configured gcc 3.4 
based compiler, and the culprit was the creation of the induction 
variables used in the inner loop.


The nested loops look like this:

signed short i,j,k,DataSizeExponent,DataSize;
signed short RealBitRevData[MAX], ImagBitRevData[MAX];
signed short * CosineV, * SineV;

for (k = 1; k <= DataSizeExponent; k++)
{
signed short n1 = 1 << k;
signed short n2 = n1 >> 1;
signed short ArgIndex = 0;
signed short DeltaIndex = (DataSize >> 1) / n2;

for (j = 0; j < n2; j++)
{
signed int WReal = CosineV[ArgIndex];
signed int WImag = SineV[ArgIndex];

ArgIndex += DeltaIndex;
for (i = j; i < DataSize; i += n1)
{
signed short l = i + n2;
signed int tRealData = (WReal * RealBitRevData[l]) + 
(WImag * ImagBitRevData[l]);
signed int tImagData = (WReal * ImagBitRevData[l]) - 
(WImag * RealBitRevData[l]);


tRealData = tRealData >> BUTTERFLY_SCALE_FACTOR;
tImagData = tImagData >> BUTTERFLY_SCALE_FACTOR;
RealBitRevData[l] = RealBitRevData[i] - tRealData;
ImagBitRevData[l] = ImagBitRevData[i] - tImagData;
RealBitRevData[i] += tRealData;
ImagBitRevData[i] += tImagData;
}
}
}

and the inner loop was being transformed into:

  short int D.2046, D.2043;
  long int D.2038, D.2035;
  int D.2033, D.2024,  D.2020, D.2008, D.2001;
   [...]

:;
  D.2033 = (int) (signed short) ivtmp.67;
  D.2035 = (long int) RealBitRevData[D.2033];
  D.2038 = (long int) ImagBitRevData[D.2033];
  tRealData = WReal * D.2035 + WImag * D.2038;
  tImagData = WReal * D.2038 - WImag * D.2035;
  D.2001 = (int) i;
  D.2043 = (short int) (tRealData >> 15);
  RealBitRevData[D.2033] = RealBitRevData[D.2001] - D.2043;
  D.2046 = (short int) (tImagData >> 15);
  ImagBitRevData[D.2033] = ImagBitRevData[D.2001] - D.2046;
  RealBitRevData[D.2001] = D.2043 + RealBitRevData[D.2001];
  ImagBitRevData[D.2001] = D.2046 + ImagBitRevData[D.2001];
  i = (signed short) ((short unsigned int) i + ivtmp.78);
  ivtmp.68 = ivtmp.68 + ivtmp.78;
  ivtmp.67 = ivtmp.67 + ivtmp.78;
  if (DataSize > (signed short) (ivtmp.68 - ivtmp.78)) goto ; else 
goto ;



The net result of these induction variables, and especially the type 
translations necessary to go between signed and unsigned and shorts and 
ints was an inner loop consisting of 42 instructions, as opposed to an 
inner loop of 32 instructions as produced by the gcc 3.4 compiler.


Cheers
  Nick

Re: BFD Error a regression?

[Nick Clifton]

Hi Jerry,

While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the 
following error message:


BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at 
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in


If you are able to reproduce this bug, then please try using the latest 
version of the binutils from the mainline of the CVS repository.  If the 
bug still exists there please submit a binutils bug report (at: 
http://sourceware.org/bugzilla/) and we will be happy to investigate. 
(If you can include a simple test case that reproduces the problem, 
preferably without needing to build a special compiler, that will help 
immensely).


Cheers
  Nick

Re: Stepping down as SH maintainer

[Nick Clifton]

Hi Joern,


I have decided to accept employment at ARC International, so effective
11th December 2006, I will step down as an active SH maitainer.


Thank you very much for all the hard work you have out in to maintaining 
the SH port (not just in binutils, but in gcc as well).


Cheers
  Nick

Re: interworking problem

[Nick Clifton]

Hi Aram,
   i have gone through the a.out file after this error. 
> that is producing full of arm instructions other than the main
function(which is compiled for -mthumb). 
where should i change for this corresponding error. 
It is not clear what question you are asking here.
Ian has pointed out that you should be compiling your program with the 
-mthumb-interwork switch specified on the gcc command line.

   i have added one new add instruction in thumb mode. based on that
i have written one sample program to emit the corresponding new 
instruction. gcc works fine. when i assemble the function it emits 
> correct opcode. but when i give the same function to the ld it
> emits full of arm instructions instead of thumb instructions.
> which routine checks for this corresponding change.
Again this is not clear.  Do you mean that when the linker is creating 
the executable that it is inserting some ARM-encoded instructions into 
the output, or that it is somehow magically transforming your 
THUMB-encoded instructions into ARM-encoded instructions ?

Perhaps it would help if you could provide a *small* example program and 
 the command lines you use to compile it, as well as description of 
what is wrong with the resulting executable.

Cheers
  Nick

mips64vr-elf fails to build

[Nick Clifton]

Hi Eric, Hi Richard,

The mips64vr-elf target currently fails to build in FSF mainline
because:

  libgcc/unwind-dw2.c:1159:1: internal compiler error: in output_555, at 
config/mips/mips.md:6024

which is here:

(define_insn "casesi_internal_mips16_"
  [(set (pc)
   (if_then_else
 (leu (match_operand:SI 0 "register_operand" "d")
  (match_operand:SI 1 "arith_operand" "dI"))
 (unspec:P
  [(match_dup 0)
   (label_ref (match_operand 2 "" ""))]
  UNSPEC_CASESI_DISPATCH)
 (label_ref (match_operand 3 "" ""
 (clobber (match_scratch:P 4 "=d"))
 (clobber (match_scratch:P 5 "=d"))
 (clobber (reg:SI MIPS16_T_REGNUM))]
"TARGET_MIPS16_SHORT_JUMP_TABLES"
  {
rtx diff_vec = PATTERN (next_real_insn (operands[2]));

=>  gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
  
I am not sure of the best way to fix this, so I am punting to you
guys. :-)

Cheers
  Nick
 

No documentation of -fsched-pressure-algorithm

[Nick Clifton]

Hi Richard,

  I have just noticed that the new -fsched-pressure-algorithm= gcc
  command line option is not documented in gcc/doc/invoke.texi.  Was
  this an oversight ?

Cheers
  Nick

Re: No documentation of -fsched-pressure-algorithm

[nick clifton]

Hi Richard,


   I have just noticed that the new -fsched-pressure-algorithm= gcc
   command line option is not documented in gcc/doc/invoke.texi.  Was
   this an oversight ?


No, it was deliberate.  It's not supposed to be a user-level option.


Then why is there a user-visible command line option ?

Also - why shouldn't it be a user-level option ?  In my experience gcc's 
instruction scheduling tends to be very sensitive to the algorithm being 
compiled.  For some applications it does a good job, but for others it 
actually makes the performance worth.  Being able to tune the behaviour 
of the scheduler (via the various -fsched-... options) has been very 
helpful in getting good benchmark results.


Cheers
  Nick

Re: No documentation of -fsched-pressure-algorithm

[nick clifton]

Hi Richard,


Also - why shouldn't it be a user-level option ?  In my experience gcc's
instruction scheduling tends to be very sensitive to the algorithm being
compiled.  For some applications it does a good job, but for others it
actually makes the performance worth.  Being able to tune the behaviour
of the scheduler (via the various -fsched-... options) has been very
helpful in getting good benchmark results.


But the idea is that if you get good benchmark results with it
(as for A8, A9 and s390), you should enable it by default.


OK, but what if it turns out that the new algorithm improves the 
performance of some benchmarks/applications, but degrades others, within 
the same architecture ?  If that turns out to be the case (and I suspect 
that it will) then having a documented command line option to select the 
algorithm makes more sense.


Besides, this is open software.  Why exclude toolchain users just 
because they are not developers.  Not everyone who uses gcc reads the 
gcc mailing list, but they still might be interested in trying out this 
option and maybe pinging the maintainer of their favourite backend if 
they find that the new algorithm makes for better instruction scheduling.


Cheers
  Nick

Re: No documentation of -fsched-pressure-algorithm

[nick clifton]

Hi Richard,


Well, given the replies from you, Ian and Vlad (when reviewing the patch),
I feel once again in a minority of one here :-) but... I just don't
think we should be advertising this sort of stuff to users.


OK, what about Ian's suggestion of controlling the algorithm selection 
via a --param instead of a -f option ?




Not because
I'm trying to be cliquey, but because any time the user ends up having
to use stuff like this represents a failure on the part of the compiler.


A nice idea in principle, but in practice GCC already has a ton of these 
specialist options.  Maybe you feel that we should not be adding another 
one to this list, but I think that we are already too far gone.  GCC and 
its long list of command line options is an established norm.


Perhaps now is the time to consider embracing projects like Acovea and 
Milepost and making them an official, easier-to-use meta front end to gcc ?




I mean, at what level would we document it?


Well I rather like David's suggestion - a split gcc invocation manual 
with options like -fsched-pressure-algorithm only appearing in the 
here-be-dragons section.




  "Here, we happen to have two algorithms to do this.
   Treat them as black boxes, try each one on each

>source file, and see what works out best."

Or:

"Here, we have two algorithms to do this. You can
 treat them as black boxes, try both and see which
 works best for your application.  Or you can delve
 into their intricacies to see which ought to be the
 better one for your target. See this post  for a description of the algorithms.
 Either way we would be interested in hearing about
 which algorithm works best for you, what your application
 looks like and which architecture you are using.
 Please contact us at "


Cheers
  Nick

Unable to build M32C gcc port

[Nick Clifton]

Hi Richard, Hi DJ,

  I am currently unable to build m32c gcc port because the
  set_optab_handler function has been deleted:

gcc/config/m32c/m32c.c:1873: undefined reference to `set_optab_handler'

  I looked at the code in m32c.c:

static void
m32c_init_libfuncs (void)
{
  /* We do this because the M32C has an HImode operand, but the
 M16C has an 8-bit operand.  Since gcc looks at the match data
 and not the expanded rtl, we have to reset the optab so that
 the right modes are found. */
  if (TARGET_A24)
{
  set_optab_handler (cstore_optab, QImode, CODE_FOR_cstoreqi4_24);
  set_optab_handler (cstore_optab, HImode, CODE_FOR_cstorehi4_24);
  set_optab_handler (cstore_optab, PSImode, CODE_FOR_cstorepsi4_24);
}
}

  But I could not see an obvious way to fix it.  Should I be using
  swap_optab_handler as a replacement function ?

Cheers
  Nick

Help: ICE in variable_post_merge_new_vals()

[Nick Clifton]

Hi Guys,

  The RX port is not currently building in the mainline sources because
  of the following ICE:

  libgcc/unwind-dw2-fde.c: In function 'add_fdes':
  libgcc/unwind-dw2-fde.c:721:1: internal compiler error: in 
variable_post_merge_new_vals, at var-tracking.c:4303
 }
 ^
  0x86f0bed variable_post_merge_new_vals
/work/sources/gcc/current/gcc/var-tracking.c:4301
  0x885c774 htab_traverse_noresize
/work/sources/gcc/current/libiberty/hashtab.c:784
  0x86f4a1c dataflow_post_merge_adjust
/work/sources/gcc/current/gcc/var-tracking.c:4413
  0x86f4a1c vt_find_locations
/work/sources/gcc/current/gcc/var-tracking.c:6821
  0x86fd34a variable_tracking_main_1
/work/sources/gcc/current/gcc/var-tracking.c:10034
  0x86fd34a variable_tracking_main()
/work/sources/gcc/current/gcc/var-tracking.c:10080

  I am not familiar with this code, so I would be very grateful if
  someone could explain what this error really means and maybe point me
  towards a solution.

Cheers
  Nick
  

Re: stabs support in binutils, gcc, and gdb

[nick clifton]

Hi David,


What is the status of STABS support?


Essentially it is in maintenance mode.  But this is due to lack of 
developers interested in extending STABS support, rather than a policy 
of maintenance-only.




Are there any plans to deprecate STABS support?


No, none.



If STABS enhancements were made and
posted would they be frowned upon?  Or would they be reviewed for
possible inclusion in a future release?


No, they would be reviewed and, assuming that they are suitable, they 
would be accepted for inclusion in future releases.




Switching to DWARF causes our build products directory (which contains
*NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB.
Ouch!  The DWARF ELF files are 8-12 times the size of the STABS ELF
files.

If the DWARF files were, say, a factor of 2 the size of the STABS files,
I could probably sell people on switching to DWARF; but, a factor of 8
to 12 is too much.


Have you tried using a DWARF compression tool like dwz ?

  http://gcc.gnu.org/ml/gcc/2012-04/msg00686.html

Or maybe the --compress-debug-sections option to objcopy ?

Cheers
  Nick

Re: GCC 4.3 target deprecation proposals

[Nick Clifton]

Hi Joseph,

  Well the IQ2000 port is still of interest to us, and I am still happy
  to maintain it, so here are some test results:

Test Run By nickc on Wed Jan 23 10:37:48 2008
Target is iq2000-unknown-elf
Host   is i686-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
iq2000-sim
[...]
=== gcc Summary ===

# of expected passes43656
# of unexpected failures186
# of unexpected successes   1
# of expected failures  84
# of unresolved testcases   129
# of untested testcases 35
# of unsupported tests  395
/work/builds/gcc/current/iq2000-elf/gcc/xgcc  version 4.3.0 20080123 
(experimental) [trunk revision 131756] (GCC)

[...]
=== g++ Summary ===

# of expected passes15563
# of unexpected failures295
# of expected failures  81
# of unresolved testcases   121
# of unsupported tests  172
/work/builds/gcc/current/iq2000-elf/gcc/g++  version 4.3.0 20080123 
(experimental) [trunk revision 131756] (GCC)


Cheers
  Nick

Re: GCC 4.3 target deprecation proposals

[Nick Clifton]

Hi Joseph,

  I have posted some results for the xstormy16-elf target.  They are not great 
(614 failures) but I do hope that this can target can be removed from the 
potential deprecations list.


Cheers
  Nick

Re: GNU linker ld

[Nick Clifton]

Hi Duncan,


I am in the process of verifying that the GNU linker (gcc 3.3.2 VxWorks AE653)


The GNU linker is not part of the GCC project.  It is part of the 
Binutils project, so this question really should be asked on the 
binutils mailing list:  [EMAIL PROTECTED]


However, does ld include a decompression feature, 


No it does not.

Cheers
  Nick

Re: GNU LD fails to generate correct ARM Thumb veneer

[Nick Clifton]

Hi Aaron,


  - the first file to be linked is an ARM assembly .s file
that contains the ARM vector table and handler addresses.
the vector table is in a separate section called .VhaInit.


Did you know that you can use the KEEP directive in a linker script (or 
a linker script fragment) in order to make sure that the .VhaInit 
section is not garbage collected ?




- when i add code to access .VhaInit entries from .text to prevent the
  garbage collection of .VhaInit, Thumb Interworking code is ZERO. the
  entries are present, but no interworking code is present.


What sort of code are you adding and how are you adding it ?


- when i remove code that accesses .VhaInit, Interworking code is
  correct.

- when i disable -ffunction-sections, -fdata-sections, and
  -gc-sections, and when i still access data in .VhaInit from .text,
  Interworking is correct.

so, what's going on? 8-)

i think its a bug in GNU LD.

any help will be gratefully accepted.


You try to isolate whether this really is a linker bug.  (It certainly 
sounds like it is).  If you can reproduce the problem just using 
assembler source files then please file a bug report with the binutils 
project (at http://sourceware.org/bugzilla).  Including a *small* test 
case will really help.


Cheers
  Nick

Re: RFH: GPLv3

[Nick Clifton]

Hi Mark,


Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?


I volunteer.


It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception.  Therefore,
no changes to


to what ?  :-)  I assume that there is a missing part of that last 
sentence which reads "these files will take place at the moment".


I think however that a small change to such files may be necessary.  If 
I change the contents of the COPYING file over to GPLv3, then I think 
that it might be wise to create a new file - COPYING_v2 - which contains 
the GPLv2 and which can be referred to in the copyright notice of files 
which are still under the GPLv2.



It has also not yet been decided whether backports of bug-fixes from
GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
will result in the patched compilers being GPLv3.  If you have thoughts
about that, you might wish to contact the FSF.


This is what the FSF had to say when I raised this issue with them for 
the binutils project:


: Since the previous releases were licensed under GPLv2 or later, all
: maintainers need to do is upgrade their backport to GPLv3 or later --
: then they'll be able to incorporate patches that were never released
: under GPLv2.

Cheers
  Nick

Re: RFH: GPLv3

[Nick Clifton]

Hi David,

2. Turn off public access to the code while changing license text in the 
source.


This is not necessary.  (I am assuming here that by "public access to 
the code" you mean access to the svn repository, not access to the 
various release tarballs).  The repository sources are not an official 
release.  They are part of the development process for future releases. 
 Anyone using these sources should be aware of this and not expect them 
to remain constant.  In particular, in the context of this discussion, 
no-one should expect that the mainline repository sources will all exist 
under the governance of just one version of the GPL.


I will be as quick as I can in updating the mainline sources, but it is 
going to take me a couple of days.  I am going to perform the upgrade in 
an incremental fashion as I do not have the bandwidth to perform a 
single pass commit of all of the sources.


Cheers
  Nick

Re: RFH: GPLv3

[Nick Clifton]

Hi Krzysztof,


I hope the COPYING or similar file will contain the licence text
under which the code is distributed?


Actually the plan is to create a new file - COPYING_v3 - which will 
contain the GPL version 3 and then change the copyright header in source 
files over to say "version 3 (or later)" and have them refer the reader 
to the COPYING_v3 file.  Files which remain under the GPL version 2 will 
then not need to be changed to refer the reader to some file other than 
COPYING.


Cheers
  Nick

PS.  I am also going to be creating a COPYING.LIB_v3 file, although I am 
not sure if it will be needed just yet.

Accessing fields in the global_options structure from out-of-sync plugins

[Nick Clifton via Gcc]

Hi Guys,

  With the annobin plugin for gcc I have a problem accessing some of the
  fields in the global_options structure.  Although the plugin can use
  the macros defined in options.h, this only works if the plugin is in
  sync with gcc.  If the plugin was built for one version of gcc, but
  run from another version, then the access can become invalid if the
  fields in struct gcc_options have changed.  (This does seem to happen
  quite a lot).

  Whilst forcing the plugin to stay in sync with gcc is one possible
  solution, it does have its own problems.  So I am looking for another
  solution.  Using the cl_options array and the flag_var_offset field
  does help.  But cl_options only has entries for some of the fields in
  global_options, not all of them.  (Eg: main_input_filename,
  flag_sanitize, optimize).

  One method that would work would be to enhance the optc-gen.awk and
  opth-gen.awk scripts so that they create a set of accessor functions.
  eg get_main_input_filename() or get_flag_sanitize().  These would not
  have to be used by the current gcc code, but their presence in the
  executable would allow them to be accessed from plugins.
  Alternatively a single accessor function which takes a parameter
  indicating the desired field and which returns its current value would
  also work.

  What do people think ?  Is this idea practical, or is there a better
  solution ?

Cheers
  Nick

Re: Making *-netbsd-* to mean ELF not a.out for all CPUs

[Nick Clifton via Gcc]

Hi John,


But they did offer some tentative support for my second suggestion of changing the meaning of bare 
"netbsd" --- "netbsdaout" would still be available to unambiguously request 
a.out for anyone that wants it.


I think that this would be OK for the binutils, providing that when configuring 
for
just "netbsd" there was a prominentant message in the config log saying 
something like:
"netbsd format now treated as ELF based.  Use netbsdaout if you want a.out format 
files".
(Probably with slightly better wording than that).

Cheers
  Nick

Re: [CVE] zlib (< 1.2.12) memory corruption

[Nick Clifton via Gcc]

Hi Luis,


There is a CVE [1] for zlib < 1.2.12 (released march 27th).

GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory 
from GCC. The recommendation is to get it updated to 1.2.12, which contains the 
proper fix [2].


I am all for updating the binutils-gdb copy of zlib.  I will wait a couple of
days to see if anyone else has any comments or concerns, but if not, then I
will apply the patches myself.

Cheers
  Nick

Re: [CVE] zlib (< 1.2.12) memory corruption

[Nick Clifton via Gcc]

Hi Luis,


There is a CVE [1] for zlib < 1.2.12 (released march 27th).

GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory 
from GCC. The recommendation is to get it updated to 1.2.12, which contains the 
proper fix [2].



Right - I have now updated the binutils-gdb mainline sources with this release.

Whilst it is true that the gcc version of zlib sources had diverged slightly 
from
the 1.2.11 release sources, I think that it was just some changes cherry picked
from the developments that went in to 1.2.12.  So a simple rebase should be 
safe.

Cheers
  Nick

Re: [committed] exec-stack warning for test which wants executable stacks

[Nick Clifton via Gcc]

Hi Jeff,


I used -z execstack rather than --no-warn-execstack as the former is recognized 
by older versions of ld, but the latter is a new option.

Thanks for it.
Unfortunately, I should have looked at the other failures that have popped up over the last week.  Essentially all the nested function tests are failing on some targets due 
to the same linker warning.


Either pruning or adding  the option to all those tests is going to be 
necessary ;(


Sorry for causing you so much hassle.  If it helps, Alan has already added
some pruning code to binutils/testsuite/lib/binutils-common.exp in the
prune_extra_warnings proc...

Cheers
  Nick

Re: [committed] exec-stack warning for test which wants executable stacks

[Nick Clifton via Gcc]

Hi Jeff,

  Just FYI - I am also looking at adding in another warning.  This time for
  when the linker creates a PT_LOAD segment which has all of the RWX flags
  set.  At the moment my testing seems to show that it only causes problems
  when a custom linker script is used that defines its own program headers
  and does not provide separate headers for code and data.

Cheers
  Nick

Re: Counting static __cxa_atexit calls

[Nick Clifton via Gcc]

Hi Florian,


What would be the most ELF-flavored way to implement this?  After the
final link, I expect that the count (or counts, we need a separate
counter for thread-local storage) would show up under a new dynamic tag
in the dynamic segment.  This is actually a very good fit because older
loaders will just ignore it.  But the question remains what GCC should
emit into assembler & object files, so that the link editor can compute
the total count from that.


(It would worthwhile asking this question of the LLVM community too,
since ideally we would like to use the same method in both compilers).


This sounds like an opportunity to add a couple of new GNU object
attributes:

  .gnu_attribute Tag_gnu_destructor_count, 
  .gnu_attribute Tag_gnu_tld_count, 

Which would then translate into a GNU object attribute notes in the
object file.

Cheers
  Nick

Re: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)

[Nick Clifton via Gcc]

Hi Thomas,



+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"


..., Tom rightfully asked:


[...] I wonder, normally we don't pass -v to ld, and need -Wl,-v for
that.


So, on my quest for making things uniform/simple, I now wonder: should we
also forward GCC '-v' to binutils linker, or is there a reason to not do
that?


Not really no.  Historically of course this has not been done, so changing
it now might surprise a few users.  But it should not be that big of an
issue.



So, any particular reason why we would do things differently for
nvptx?


Nope, none at all.

Harmonizing the effect of the -v option sounds like a good idea to me.

Cheers
  Nick

Re: Error: attempt to get value of unresolved symbol `L0'

[Nick Clifton via Gcc]

Hi Pali, Hi Richard,


Interesting... Another test case which is working fine:

   kernoffs:
   .word 0x4 - (. - 0x0)


This works because this expression can be converted into an instruction
and a relocation in the object file:

  % as t.s -o t.o
  % objdump -dr t.o
  Disassembly of section .text:

   :
   0:   0003fffc.word   0x0003fffc
0: R_ARM_REL32  *ABS*

Which shows that when this object file is linked the word at offset 0
inside the .text section should be converted into an absolute value of
(pc - 0x4000), where pc is the address of the word.

This instruction however:

.word - (. - 0x80008000)

Cannot be converted since the linker would need to compute ((pc - 0x800800) * 
-1)
which cannot be expressed by a single relocation.  Similarly:

.word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE)

Cannot be expressed by a single value, modified by a single relocation, even
when the KERNEL_OFFSET and CONFIG_SYS_TEXT_BASE values are known at assembly
time.

A clever assembler might be able to rearrange the expression, assuming that
overflow is unimportant, but gas does not do that.  But just for reference
the following would work:

.word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - .


I agree however that this message:

t.s: Error: attempt to get value of unresolved symbol `L0'

is unhelpful.  So I am going to check in a patch to change it to:

t.s: Error: expression is too complex to be resolved

I looked into providing a file name and line number with the error
message, but this would involve reworking a lot of the assembler's
internal expression parser.

Cheers
  Nick

Re: Error: attempt to get value of unresolved symbol `L0'

[Nick Clifton via Gcc]

Hi Pali, Hi Richard,


Having file name and line number would be also useful as it took me
some time to figure out where is the issue...


Right - I have tried a little harder and come up with a follow up patch.
This is now checked in, and given an input file that looks like this:

  % cat t.s
  kernoff:
.set KERNEL_OFFSET, 0x4
.set CONFIG_SYS_TEXT_BASE, 0x80008000
.word 44
.word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE)
.word - (. - 0x80008000)
.word 0x4 - (. - 0x0)

The assembler now produces the following output:

  t.s: Assembler messages:
  t.s:5: Error: expression is too complex to be resolved or converted into 
relocations
  t.s:6: Error: expression is too complex to be resolved or converted into 
relocations

Note - some targets do support applying multiple relocations to a
single address, but even then there can be expressions that cannot
be resolved this way.  That is why the error message refers to
"converted into relocations" rather than just "converted into a
relocation".

Cheers
  Nick

Re: Problems when building NT kernel drivers with GCC / LD

[Nick Clifton via Gcc]

Hi Pali,


Hello! I would like to remind this thread for gcc/binutils developers.
Most of these issues are still present and cause problems for compiling
native PE binary. If you have questions or you need any other information
please let me know.


Have bug reports been filed for the individual issues ?  If not, please
could they be created.  The URLs for filing bugs are:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
  https://gcc.gnu.org/bugzilla/enter_bug.cgi

It would *really* help if the bug reports include a simple test case
to reproduce the specific problems.

If it is not clear which tool is the source of the problem, then I would
suggest choosing the binutils first.  If it turns out that specific issue
is actually caused by a problem in gcc, the bug report can always be moved
later on.

Cheers
  Nick

Re: Problems when building NT kernel drivers with GCC / LD

[Nick Clifton via Gcc]

Hi Pali,


Hello! Just for a record, I filled individual issues to bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=30004
https://sourceware.org/bugzilla/show_bug.cgi?id=30139
https://sourceware.org/bugzilla/show_bug.cgi?id=30140
https://sourceware.org/bugzilla/show_bug.cgi?id=30141
https://sourceware.org/bugzilla/show_bug.cgi?id=30142
https://sourceware.org/bugzilla/show_bug.cgi?id=30143
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
https://sourceware.org/bugzilla/show_bug.cgi?id=30145


Hello! Should I do something more regarding these issues?


Hitting me with a big hammer ?

*sigh* I was really hoping that someone else would step up to look at these
issues as I am not a Windows expert.

It looks like the first one (30004) has been fixed, and 30140 may have been
resolved - assuming that you agree with the explanation in comment #2.  But
the others all need addressing.  I will try to make time for them in the next
few weeks.

If you do have any suggestions for fixes to any of these problems, please do
feel free to add them to the relevant bug reports.

Cheers
  Nick

Re: How to remove extra assembly code

[Nick Clifton via Gcc]

Hi Ericxu833,


gcc.exe -g -O0 -x c -fno-exceptions -fno-stack-protector -fno-ident test.c -o 
test.exe

I used IDA pro to reverse engineer test.exe and found that gcc added "call __main" to the 
front of the assembly code, and then executed "jmp __do_global_ctors". I guess this code 
means to instantiate C++ objects.
My code is pure C language and does not need this code. How to remove the extra 
assembly code.


Try adding -nostartfiles to your command line.

That extra code is coming from the startup file(s) that are added by
default when you use gcc to compile and then link your program.

Of course without those startup files you may not be able to run
your code, but I assume that that does not matter to you.

Cheers
  Nick