[Bug analyzer/93543] [10 regression] bootstrap with clang 9.0.1 fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #2 from Sebastian Huber  ---
LLVM 8.0.1 is also affected by this. In

https://en.cppreference.com/w/cpp/language/reinterpret_cast

I found this note:

"9) The null pointer value of any pointer type can be converted to any other
pointer type, resulting in the null pointer value of that type. Note that the
null pointer constant nullptr or any other value of type std::nullptr_t cannot
be converted to a pointer with reinterpret_cast: implicit conversion or
static_cast should be used for this purpose."

Consider the following test program:

struct function;

function *g(void)
{
  return static_cast(nullptr);
}

function *f(void)
{
  return reinterpret_cast(nullptr);
}

$ clang -c test.cc
test.cc:10:10: error: reinterpret_cast from 'nullptr_t' to 'function *' is not
allowed
  return reinterpret_cast(nullptr);
 ^
1 error generated.

[Bug analyzer/93543] [10 regression] bootstrap with clang fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543

--- Comment #4 from Sebastian Huber  ---
(In reply to David Malcolm from comment #3)
> Thanks.  Does the patch in comment #1 fix it for you?

I tested the patch on FreeBSD 12.1 with LLVM 8.0.1 and it fixes the issue.

[Bug target/56561] Miscompilation with -Os -arm

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561



Sebastian Huber  changed:



   What|Removed |Added



 CC||sebastian.huber@embedded-br

   ||ains.de



--- Comment #3 from Sebastian Huber  
2013-03-08 07:59:54 UTC ---

The arm-eabi target is also affected by this bug.



(In reply to comment #2)

> The wrong-code on 4.6 branch is stopped by backporting r183512 aka PR48308 
> fix.



Is there a back port available as a patch?  A simple "git cherry-pick

eed2904aa7a3ce889e8a0dd8e7ec59f9190ce5fe" in the 4.6 branch does not work due

to undefined references to "alloc_insn_link".

[Bug target/53325] arm-rtems switch default target to EABI

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325



--- Comment #7 from Sebastian Huber  
2013-03-20 08:09:50 UTC ---

It is also fixed in the GCC 4.6 and 4.7 branches.

[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994



Sebastian Huber  changed:



   What|Removed |Added



 CC||sebastian.huber@embedded-br

   ||ains.de



--- Comment #7 from Sebastian Huber  
2013-03-20 09:20:24 UTC ---

The crucial thing is also that all these functions are recognized as builtins

and GCC knows what they are expected to do.  The failure also vanishes if

-fno-builtin is used.



Lets have a look at this example:



gcc 1.c 2.c 3.c -l4



I expect that the modules 1.o 2.o 3.o end up in the executable and unresolved

symbols inside this module set are resolved with definitions provided by the

library 4.  In particular if I have a global function f() in 2.c then I expect

to have this function in my executable even in case a global function f() is

also defined in the library 4.



This is wrong for builtins.  Here GCC seems to assume that implementations are

interchangeable.  It would be quite interesting to know what happens if we

compile libc with -flto.



In one failed GCC test f() is memcpy(), 2.c is 20010124-1-lib.c and lib4 is

libc.

[Bug target/48308] [4.6 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308



Sebastian Huber  changed:



   What|Removed |Added



 CC||sebastian.huber@embedded-br

   ||ains.de



--- Comment #26 from Sebastian Huber  
2013-03-22 08:28:44 UTC ---

In case this won't be fixed in 4.6, then it is probably good to set the status

to WONTFIX so people know that they have to deal with this on their own.

[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771



--- Comment #9 from Sebastian Huber  
2013-04-03 15:23:29 UTC ---

(In reply to comment #8)

> Patch committed to 4.7, 4.8 and SVN head.

> 

> Closing.



Can you please commit this also to the 4.6 branch.

[Bug rtl-optimization/38644] [4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644



--- Comment #70 from Sebastian Huber  
2013-04-05 07:15:34 UTC ---

(In reply to comment #69)

> (In reply to comment #68)

> > Is this problem resolved? The status is still set to "NEW" but "known to 
> > work"

> > shows that it either has been resolved in v4.7.0 or that version is somehow 
> > not

> > affected.

> 

> It was resolved with the patch in comment #59 and comment #62.  In GCC 4.6.0.



It was fixed in GCC 4.6.3 and above.

[Bug c++/55033] New: [4.6/4.7/4.8 Regression] PowerPC section type conflict error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033



 Bug #: 55033

   Summary: [4.6/4.7/4.8 Regression] PowerPC section type conflict

error

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: sebastian.hu...@embedded-brains.de





Created attachment 28513

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28513

Pre-processed C++ test file.



With GCC 4.6, 4.7, and 4.8 we have this error (GCC 4.5 works):



powerpc-rtems4.11-g++ -S -mcpu=8540 -msoft-float -meabi -msdata -fno-common

test.ii

dma_intf.CPP:264:133: error: elm_dsc_mod_file_ causes a section type conflict

[Bug c++/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033



Sebastian Huber  changed:



   What|Removed |Added



  Component|target  |c++



--- Comment #1 from Sebastian Huber  
2012-10-23 13:20:28 UTC ---

This error is also present in the PowerPC EABI configuration (the RTEMS and

EABI configurations are roughly the same):



powerpc-unknown-eabi-g++ --version --verbose

Using built-in specs.

COLLECT_GCC=powerpc-unknown-eabi-g++

COLLECT_LTO_WRAPPER=/home/sh/install-eabi/lib/gcc/powerpc-unknown-eabi/4.8.0/lto-wrapper

powerpc-unknown-eabi-g++ (GCC) 4.8.0 20121023 (experimental)

Copyright (C) 2012 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.





Target: powerpc-unknown-eabi

Configured with: /home/sh/archive/gcc-git/configure

--prefix=/home/sh/install-eabi --target=powerpc-unknown-eabi  --verbose

--with-gnu-as --with-gnu-ld --with-newlib --disable-libssp

--enable-languages=c,c++

Thread model: single

gcc version 4.8.0 20121023 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='--version' '-v'

 /home/sh/install-eabi/lib/gcc/powerpc-unknown-eabi/4.8.0/cc1 -quiet -v

help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version --version

-o /tmp/ccbQTCaZ.s

GNU C (GCC) version 4.8.0 20121023 (experimental) (powerpc-unknown-eabi)

compiled by GNU C version 4.6.2, GMP version 5.0.5, MPFR version 3.1.1,

MPC version 1.0.1

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

COLLECT_GCC_OPTIONS='--version' '-v'



/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/../../../../powerpc-unknown-eabi/bin/as

-v -mppc -many --version -o /tmp/ccYVhGeE.o /tmp/ccbQTCaZ.s

GNU assembler version 2.22.52 (powerpc-unknown-eabi) using BFD version (GNU

Binutils) 2.22.52.20120727

GNU assembler (GNU Binutils) 2.22.52.20120727

Copyright 2012 Free Software Foundation, Inc.

This program is free software; you may redistribute it under the terms of

the GNU General Public License version 3 or later.

This program has absolutely no warranty.

This assembler was configured for a target of `powerpc-unknown-eabi'.

COMPILER_PATH=/home/sh/install-eabi/lib/gcc/powerpc-unknown-eabi/4.8.0/:/home/sh/install-eabi/lib/gcc/powerpc-unknown-eabi/4.8.0/:/home/sh/install-eabi/lib/gcc/powerpc-unknown-eabi/:/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/:/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/:/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/../../../../powerpc-unknown-eabi/bin/

LIBRARY_PATH=/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/:/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/../../../../powerpc-unknown-eabi/lib/

COLLECT_GCC_OPTIONS='--version' '-v'

 /home/sh/install-eabi/lib/gcc/powerpc-unknown-eabi/4.8.0/collect2 -V -dn

-Bstatic --version ecrti.o crtbegin.o

-L/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0

-L/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/../../../../powerpc-unknown-eabi/lib

/tmp/ccYVhGeE.o -lgcc -lc -lgcc crtend.o ecrtn.o

collect2 version 4.8.0 20121023 (experimental)

/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/../../../../powerpc-unknown-eabi/bin/ld

-V -dn -Bstatic --version ecrti.o crtbegin.o

-L/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0

-L/home/sh/install-eabi/lib64/gcc/powerpc-unknown-eabi/4.8.0/../../../../powerpc-unknown-eabi/lib

/tmp/ccYVhGeE.o -lgcc -lc -lgcc crtend.o ecrtn.o

GNU ld (GNU Binutils) 2.22.52.20120727

  Supported emulations:

   elf32ppc

   elf32ppclinux

   elf32ppcsim

GNU ld (GNU Binutils) 2.22.52.20120727

Copyright 2012 Free Software Foundation, Inc.

This program is free software; you may redistribute it under the terms of

the GNU General Public License version 3 or (at your option) a later version.

This program has absolutely no warranty.

[Bug target/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033



--- Comment #2 from Sebastian Huber  
2012-10-23 15:03:37 UTC ---

#0  default_elf_select_section (decl=0x772b92d0, reloc=0, align=32) at

/home/sh/archive/gcc-git/gcc/varasm.c:6251

#1  0x00c57d4e in get_constant_section (align=,

exp=0x772b92d0) at /home/sh/archive/gcc-git/gcc/varasm.c:3021

#2  build_constant_desc (exp=0x772b92d0) at

/home/sh/archive/gcc-git/gcc/varasm.c:3091

#3  0x00c5c3f0 in tree_output_constant_def (exp=0x772b92d0) at

/home/sh/archive/gcc-git/gcc/varasm.c:3282

#4  0x008fe0a4 in gimplify_init_constructor (expr_p=0x7fffd108,

pre_p=0x7fffd2e8, post_p=0x7fffd088, want_value=false,

notify_temp_creation=false) at /home/sh/archive/gcc-git/gcc/gimplify.c:4085

#5  0x008feb16 in gimplify_modify_expr_rhs (expr_p=0x7fffd108,

from_p=0x768ed110, to_p=0x768ed108, pre_p=0x7fffd2e8,

post_p=0x7fffd088, want_value=false) at

/home/sh/archive/gcc-git/gcc/gimplify.c:4530

#6  0x009010ef in gimplify_modify_expr (want_value=false,

post_p=0x7fffd088, pre_p=0x7fffd2e8, expr_p=0x7fffd108) at

/home/sh/archive/gcc-git/gcc/gimplify.c:4840

#7  gimplify_expr (expr_p=0x7fffd108, pre_p=0x7fffd2e8,

post_p=0x7fffd088, gimple_test_f=0x8f7b70 ,

fallback=0) at /home/sh/archive/gcc-git/gcc/gimplify.c:7167

#8  0x00907429 in gimplify_stmt (stmt_p=,

seq_p=0x7fffd2e8) at /home/sh/archive/gcc-git/gcc/gimplify.c:5700

#9  0x00908fe3 in gimplify_and_add (t=0x768ed0f0, seq_p=) at /home/sh/archive/gcc-git/gcc/gimplify.c:371

#10 0x0090a0c0 in gimplify_decl_expr (stmt_p=,

seq_p=0x7fffd2e8) at /home/sh/archive/gcc-git/gcc/gimplify.c:1484

#11 0x008ffcd1 in gimplify_expr (expr_p=0x768bebf8,

pre_p=0x7fffd2e8, post_p=0x7fffd228, gimple_test_f=0x8f7b70

, fallback=0) at

/home/sh/archive/gcc-git/gcc/gimplify.c:7334

#12 0x00907429 in gimplify_stmt (stmt_p=,

seq_p=0x7fffd2e8) at /home/sh/archive/gcc-git/gcc/gimplify.c:5700

#13 0x00908c88 in gimplify_cleanup_point_expr (expr_p=0x772b93d0,

pre_p=0x7fffd5e8) at /home/sh/archive/gcc-git/gcc/gimplify.c:5477

#14 0x008ffa71 in gimplify_expr (expr_p=0x772b93d0,

pre_p=0x7fffd5e8, post_p=0x7fffd408, gimple_test_f=0x8f7b70

, fallback=0) at

/home/sh/archive/gcc-git/gcc/gimplify.c:7504

#15 0x00907429 in gimplify_stmt (stmt_p=,

seq_p=0x7fffd5e8) at /home/sh/archive/gcc-git/gcc/gimplify.c:5700

#16 0x008ff98c in gimplify_statement_list (pre_p=0x7fffd5e8,

expr_p=0x7656d8f0) at /home/sh/archive/gcc-git/gcc/gimplify.c:1537

#17 gimplify_expr (expr_p=0x7656d8f0, pre_p=0x7fffd5e8,

post_p=0x7fffd558, gimple_test_f=0x8f7b70 ,

fallback=0) at /home/sh/archive/gcc-git/gcc/gimplify.c:7556

#18 0x00907429 in gimplify_stmt (stmt_p=,

seq_p=0x7fffd5e8) at /home/sh/archive/gcc-git/gcc/gimplify.c:5700

#19 0x00908316 in gimplify_bind_expr (expr_p=0x762f2b98,

pre_p=0x7fffd7f8) at /home/sh/archive/gcc-git/gcc/gimplify.c:1230

#20 0x00900787 in gimplify_expr (expr_p=0x762f2b98,

pre_p=0x7fffd7f8, post_p=0x7fffd718, gimple_test_f=0x8f7b70

, fallback=0) at

/home/sh/archive/gcc-git/gcc/gimplify.c:7338

#21 0x00907429 in gimplify_stmt (stmt_p=,

seq_p=0x7fffd7f8) at /home/sh/archive/gcc-git/gcc/gimplify.c:5700

#22 0x00907522 in gimplify_body (fndecl=0x762f2b00, do_parms=true)

at /home/sh/archive/gcc-git/gcc/gimplify.c:8203

#23 0x00907a16 in gimplify_function_tree (fndecl=0x762f2b00) at

/home/sh/archive/gcc-git/gcc/gimplify.c:8337

#24 0x007adc98 in cgraph_analyze_function (node=0x7679f6f0) at

/home/sh/archive/gcc-git/gcc/cgraphunit.c:643

#25 0x007b0ad7 in cgraph_analyze_functions () at

/home/sh/archive/gcc-git/gcc/cgraphunit.c:928

#26 0x007b1991 in finalize_compilation_unit () at

/home/sh/archive/gcc-git/gcc/cgraphunit.c:2071

#27 0x005d46cc in cp_write_global_declarations () at

/home/sh/archive/gcc-git/gcc/cp/decl2.c:4286

#28 0x00a55b8d in compile_file () at

/home/sh/archive/gcc-git/gcc/toplev.c:560

#29 0x00a577f2 in do_compile () at

/home/sh/archive/gcc-git/gcc/toplev.c:1866

#30 toplev_main (argc=18, argv=0x7fffdb28) at

/home/sh/archive/gcc-git/gcc/toplev.c:1942

#31 0x7761223d in __libc_start_main () from /lib64/libc.so.6

#32 0x004ebbcd in _start () at ../sysdeps/x86_64/elf/start.S:113



The problem is that something in GCC calls default_elf_select_section(decl,

reloc, align) with categorize_decl_for_section(decl, reloc) == SECCAT_SRODATA. 

This in turn calls get_named_section (decl=0x0 == NULL_TREE, name=0x101b0bc

".sdata2", reloc=0) which leads to (gcc/varasm.c):



[...]

unsigned int

default_section_type_flags (tree decl, const char *name, int reloc)

{

  unsigned int flags;



  if (decl && TREE_CODE (de

[Bug c++/55058] New: [4.7/4.8 Regression] Unexpected invalid type conversion error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058



 Bug #: 55058

   Summary: [4.7/4.8 Regression] Unexpected invalid type

conversion error

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: sebastian.hu...@embedded-brains.de





Created attachment 28518

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28518

Sample code



The attached test file produces with "g++ -c test.cc" of GCC version 4.7 (e.g.

the one shipped with OpenSuse 12.2) and 4.8 the following output:



test.cc: In constructor 'C_DrvDataBuffer::C_DrvDataBuffer(ushort, ushort)':

test.cc:20748:34: error: invalid conversion from 'const T_SND_NODE

C_DrvSndDataBlock::* {aka const list_node C_DrvSndDataBlock::*}' to 'list_node C_DrvSndDataBlock::*' [-fpermissive]

test.cc:16667:1: error:   initializing argument 1 of 'list_base<

, , test_,

amp_>::list_base(const T_C_NODE_ T_::*, const char*, bool) [with T_ =

C_DrvSndDataBlock; lock_ = with_lock; test_ = oper_safe; bool amp_ = false;

list_base< , , test_,

amp_>::T_C_NODE_ = list_node]'

[-fpermissive]

test.cc:20748:34: error: invalid conversion from 'const T_SND_NODE

C_DrvSndDataBlock::* {aka const list_node C_DrvSndDataBlock::*}' to 'list_node C_DrvSndDataBlock::*' [-fpermissive]

test.cc:16667:1: error:   initializing argument 1 of 'list_base<

, , test_,

amp_>::list_base(const T_C_NODE_ T_::*, const char*, bool) [with T_ =

C_DrvSndDataBlock; lock_ = with_lock; test_ = oper_safe; bool amp_ = false;

list_base< , , test_,

amp_>::T_C_NODE_ = list_node]'

[-fpermissive]

test.cc:20748:34: error: invalid conversion from 'const T_RCV_NODE

C_DrvRcvDataBlock::* {aka const list_node C_DrvRcvDataBlock::*}' to 'list_node C_DrvRcvDataBlock::*' [-fpermissive]

test.cc:16667:1: error:   initializing argument 1 of 'list_base<

, , test_,

amp_>::list_base(const T_C_NODE_ T_::*, const char*, bool) [with T_ =

C_DrvRcvDataBlock; lock_ = with_lock; test_ = oper_safe; bool amp_ = false;

list_base< , , test_,

amp_>::T_C_NODE_ = list_node]'

[-fpermissive]



The test code can be compiled with the Comeau-Online-Compiler:



http://www.comeaucomputing.com/tryitout



The GCC 4.6 works also.

[Bug c++/55058] [4.7/4.8 Regression] Unexpected invalid type conversion error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058



--- Comment #2 from Sebastian Huber  
2012-10-24 16:12:39 UTC ---

(In reply to comment #1)

> can you reduce it to get rid of all the code that doesn't affect the failure?



I already reduced it quite a lot, but I try harder tomorrow.

[Bug c++/55058] [4.7/4.8 Regression] Unexpected invalid type conversion error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058



--- Comment #3 from Sebastian Huber  
2012-10-25 11:43:09 UTC ---

Created attachment 28527

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28527

Reduced smaple code.



This is the offending code reduced to the minimum.  The error is no longer

present, that means the surrounding code has an effect.

[Bug c++/55058] [4.7/4.8 Regression] Unexpected invalid type conversion error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058



Sebastian Huber  changed:



   What|Removed |Added



  Attachment #28518|0   |1

is obsolete||

  Attachment #28527|0   |1

is obsolete||



--- Comment #5 from Sebastian Huber  
2012-10-26 13:28:08 UTC ---

Created attachment 28537

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28537

Test case.



Thanks for the hint to the delta tool.  This is great for automatic test case

reduction.



The test code is now:



template 

struct A { };



template 

struct B {

  B(const A T::* p);

  typedef A D;

};



template 

B::B(const D T::* p) { }



struct C {

  C() : e() {};



  const A e;

};



B g(&C::e);



The crucial thing is the "typedef A D".  It works, if we move it before the

constructor declaration "B(const A T::* p)".  Removing the constructor

definition works also.

[Bug c++/54883] Name mangling of types in an unnamed namespace

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54883



Sebastian Huber  changed:



   What|Removed |Added



 CC||sebastian.huber@embedded-br

   ||ains.de



--- Comment #1 from Sebastian Huber  
2012-10-26 13:49:23 UTC ---

This bug is also present in x86-64 in GCC 4.6, 4.7, and 4.8.



echo "namespace { enum E { E1 }; } void f(E e) { }" | tee a.c b.c > /dev/null

g++ -c a.c -o a.o

g++ -c b.c -o b.o

objdump --syms a.o



a.o: file format elf64-x86-64



SYMBOL TABLE:

 ldf *ABS*   a.c

 ld  .text   .text

 ld  .data   .data

 ld  .bss    .bss

 ld  .comment.SUSE.OPTs 

.comment.SUSE.OPTs

 ld  .note.GNU-stack

.note.GNU-stack

 ld  .eh_frame   .eh_frame

 ld  .comment    .comment

 g F .text  0009 _Z1fN12_GLOBAL__N_11EE





objdump --syms b.o



b.o: file format elf64-x86-64



SYMBOL TABLE:

 ldf *ABS*   b.c

 ld  .text   .text

 ld  .data   .data

 ld  .bss    .bss

 ld  .comment.SUSE.OPTs 

.comment.SUSE.OPTs

 ld  .note.GNU-stack

.note.GNU-stack

 ld  .eh_frame   .eh_frame

 ld  .comment    .comment

 g F .text  0009 _Z1fN12_GLOBAL__N_11EE

[Bug c++/55058] [4.7/4.8 Regression] Unexpected invalid type conversion error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058



Sebastian Huber  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #6 from Sebastian Huber  
2012-10-30 09:18:03 UTC ---

If I revert parts of commit 44f861fca343148a1b0720105ec2b7f14bbcc849



diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c

index 1ff1c73..8f5b9f7 100644

--- a/gcc/cp/pt.c

+++ b/gcc/cp/pt.c

@@ -11015,9 +11015,7 @@ tsubst (tree t, tree args, tsubst_flags_t complain,

tree in_decl)

 complain | tf_ignore_bad_quals);

  return r;

}

-  else

-   /* We don't have an instantiation yet, so drop the typedef.  */

-   t = DECL_ORIGINAL_TYPE (decl);

+  /* Else we must be instantiating the typedef, so fall through.  */

 }



   if (type



mentioned in



http://gcc.gnu.org/ml/gcc/2012-10/msg00399.html



then, the test case compiles well.

[Bug c++/55137] New: [4.8 Regression] Unexpected static structure initialization

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137



 Bug #: 55137

   Summary: [4.8 Regression] Unexpected static structure

initialization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: sebastian.hu...@embedded-brains.de





Created attachment 28573

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28573

Test case.



The test case:



struct S {

  int a;

  int b;

};



struct S s = {

  sizeof(int),

  (((1024 * 8) * 2) - (1024 * 8))

+ ((int)(((1024 * 8)) + (2 * sizeof(int)) + 8 - 1))

};



yields:



gcc -xc++ -g -c test.cc -o test.o && gdb test.o -ex "p s" -ex quit

[...]

$1 = {a = 0, b = 0}



Correct is (sizeof(int) == 4):



gcc -xc -g -c test.cc -o test.o && gdb test.o -ex "p s" -ex quit

[...]

$1 = {a = 4, b = 16399}

[Bug c++/54883] Name mangling of types in an unnamed namespace

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54883



--- Comment #2 from Sebastian Huber  
2012-10-30 14:16:05 UTC ---

Known to work GCC 4.0.4, 4.1.2, and 4.2.4:



echo "namespace { enum E { E1 }; } void f(E e) { }" | tee a.c b.c

namespace { enum E { E1 }; } void f(E e) { }

/scratch/install-gcc-4.2.4/bin/g++ -c a.c -o a.o

/scratch/install-gcc-4.2.4/bin/g++ -c b.c -o b.o

nm a.o b.o



a.o:

 T _Z1fN32_GLOBAL__N_a.c__287815161EE

 U __gxx_personality_v0



b.o:

 T _Z1fN32_GLOBAL__N_b.c__BE213B141EE

 U __gxx_personality_v0



Known to fail 4.3.6, 4.4.7, 4.5.4, 4.6.3, 4.7.2, and 4.8.0.



Is this a bug or a feature?



In the GCC 4.3 release notes there is nothing about namespaces

(http://gcc.gnu.org/gcc-4.3/changes.html).



It would be nice if someone can point out the future direction of this PR, e.g.

NEW or RESOLVED/WONTFIX.

[Bug target/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033



--- Comment #4 from Sebastian Huber  
2012-11-06 13:18:15 UTC ---

(In reply to comment #3)

> Would this be testable on powerpc-apple-darwin8?



See also



http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02051.html



The -mcpu=8540 -msdata=eabi option is important.  I don't know how to trigger

this bug without the -mcpu=8540 option.

[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137



--- Comment #4 from Sebastian Huber  
2012-11-06 15:31:42 UTC ---

(In reply to comment #2)

> The change is that now the struct is dynamically initialized rather than

> statically as it used to.



What do you mean with dynamically initialized?



> So it is not wrong, just worse code quality.



You mean that the result of Paolo Carlini's test case is correct?

[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137



--- Comment #5 from Sebastian Huber  
2012-11-06 15:34:57 UTC ---

(In reply to comment #3)

> enum E { E1 = -1 + (int) (sizeof (int) - 1) };

> errors while it used to be accepted before.

> Dunno if that is valid or not.

> If it is valid, the series of foldings that result into the overflow are first

> folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and 
> later

> on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to

> -1 + (int) sizeof (int) + (int) 18446744073709551615UL.



Why is the ( ) ignored?  The sizeof (int) - 1 is clearly an unsigned integer

which can be converted to a signed integer.

[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137



--- Comment #7 from Sebastian Huber  
2012-11-06 15:50:38 UTC ---

(In reply to comment #6)

> What I mean that for your testcase while you have s: .zero 8

> instead of s: .long 4, 16399, there is also dynamic initialization:

> movl$4, s(%rip)

> movl$16399, s+4(%rip)

> (at -O2, at -O0 worse).



Ok, I should have looked at the assembler output.



I hit this problem on the RTEMS operating system.  It uses a supposed to be

statically initialized configuration structure for system initialization.  The

global constructors run in the initialization task (which would dynamically

initialize the configuration structure now).  To be able to start the

initialization task, we need the configuration.



>From my point of view this dynamic initialization is pretty bad here.

[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137



--- Comment #9 from Sebastian Huber  
2012-11-08 10:19:33 UTC ---

(In reply to comment #8)

> Created attachment 28624 [details]

> gcc48-pr55137.patch

> 

> Untested patch.



I tried this patch and GCC Git version 5838c24a86ac8a8afe77285f224a3ce50596954e

and I get this:



internal compiler error: in compute_antic, at tree-ssa-pre.c:2511



With an earlier snapshot 4.8-20120923 your patch solves my problem.

[Bug c/47751] New: Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751

   Summary: Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe
-Os on PowerPC
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11una


Created attachment 23349
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23349
Assembler code.

In the attached assembler file:

Line 371: Save of non-volatile registers via stmw 25,28(1)

Line 454: Restore of non-volatile registers via b _rest64gpr_25_x

This procedure is completely wrong, e.g. _rest64gpr_25_x loads the link
register from a wrong stack position with an arbitrary value.

[Bug c/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751

--- Comment #1 from Sebastian Huber  
2011-02-15 13:12:52 UTC ---
Created attachment 23350
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23350
C source code corresponding to the assembler code.

[Bug target/47847] New: PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47847

   Summary: PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common
-mfloat-gprs=double
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11-gcc


Created attachment 23432
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23432
Sample code.

Using the embedded 64-bit floating-point unit causes an internal compiler error
in combination with the small data area:

powerpc-rtems4.11-gcc -c paranoia.i -mcpu=8540 -meabi -msdata -fno-common
-mfloat-gprs=double -mabi=spe
/home/sh/rtems-sync/c/src/../../testsuites/samples/paranoia/paranoia.c: In
function 'paranoia':
/home/sh/rtems-sync/c/src/../../testsuites/samples/paranoia/paranoia.c:1955:1:
internal compiler error: output_operand: invalid %y value, try using the 'Z'
constraint

[Bug target/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751

--- Comment #3 from Sebastian Huber  
2011-02-22 11:18:29 UTC ---
(In reply to comment #2)
> -mfloat-gprs=double or -mspe without -mabi=spe does not correspond to any 
> standard ABI variant and is very likely to be broken.

Thanks for the hint.  Adding the -mabi=spe option fixed the problem.  A notice
in the -mfloat-gprs description of the documentation would be nice.

[Bug target/47847] PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47847

--- Comment #1 from Sebastian Huber  
2011-02-22 15:55:29 UTC ---
Adding the -mspe (in addition to -mabi=spe) option helped. It seems that only
few combinations of the -mcpu=8520, -mfloat-gprs=*, -mspe, and -mabi=spe flags
are well tested in GCC.  The following combinations worked:

(1) -mcpu=8540 -msoft-float
(2) -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=single
(3) -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double

[Bug target/47856] New: PowerPC: Wrong assembler output with -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856

   Summary: PowerPC: Wrong assembler output with -mcpu=8540 -meabi
-msdata -fno-common -mfloat-gprs=double -mspe
-mabi=spe
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11-gcc


Created attachment 23441
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23441
Sample code.

powerpc-rtems4.11-gcc -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double
-mspe -mabi=spe -c docomplexf.i
/tmp/ccIXOSTp.s: Assembler messages:
/tmp/ccIXOSTp.s:72: Warning: setting incorrect section attributes for .sdata2

We have:

.section.sdata2,"aw",@progbits

This should be:
.section.sdata2,"a",@progbits

[Bug target/55033] [4.7/4.8/4.9 Regression] PowerPC section type conflict error

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033

--- Comment #9 from Sebastian Huber  ---
If I run the tests on gcc1-power7.osuosl.org (which is target
powerpc64-unknown-linux-gnu), then the PR55033 test case shows up as
UNSUPPORTED:

grep -r pr55033 .
./gcc/testsuite/gcc/gcc.sum:UNSUPPORTED: gcc.target/powerpc/pr55033.c
./gcc/testsuite/gcc/gcc.log:UNSUPPORTED: gcc.target/powerpc/pr55033.c
./gcc/testsuite/gcc11/gcc.log.sep:UNSUPPORTED: gcc.target/powerpc/pr55033.c
./gcc/testsuite/gcc11/gcc.sum.sep:UNSUPPORTED: gcc.target/powerpc/pr55033.c

[Bug target/57865] New: Broken _save64gpr and _rest64gpr usage

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865

Bug ID: 57865
   Summary: Broken _save64gpr and _rest64gpr usage
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de

Created attachment 30483
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30483&action=edit
Test case.

The 64-bit GPR save and restore sequence is broken and destroys the link
register saved on the stack:

powerpc-eabi-gcc -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double -Os -S test.c

diff -u test-4.7.2.s test-4.8.1.s 
--- test-4.7.2.s2013-07-09 13:09:56.418360402 +0200
+++ test-4.8.1.s2013-07-09 13:31:59.097519823 +0200
@@ -6,7 +6,7 @@
 f:
stwu 1,-56(1)
mflr 0
-   addi 11,1,-88
+   addi 11,1,-80
stw 0,60(1)
bl _save64gpr_29
mr 29,3
@@ -15,16 +15,16 @@
stw 6,24(1)
bl g
lwz 5,16(1)
+   lwz 6,24(1)
+   evmergelo 31,3,4
stw 3,8(1)
stw 4,12(1)
mr 3,29
-   lwz 6,24(1)
mr 4,30
-   evldd 31,8(1)
bl h
-   addi 11,1,-88
+   addi 11,1,-80
efdctsiz 3,31
b _rest64gpr_29_x
.size   f, .-f
-   .ident  "GCC: (GNU) 4.7.2"
+   .ident  "GCC: (GNU) 4.8.1"
.gnu_attribute 4, 2

[Bug target/57865] Broken _save64gpr and _rest64gpr usage

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865

Sebastian Huber  changed:

   What|Removed |Added

 CC||amodra at gmail dot com
  Known to work||4.8.0

--- Comment #1 from Sebastian Huber  ---
I performed a git bisect.  This problem was introduced with this commit:

cef20746448f8897180eed3a49a3f8c68b0147f2 is the first bad commit
commit cef20746448f8897180eed3a49a3f8c68b0147f2
Author: amodra 
Date:   Wed Apr 25 02:32:56 2012 +

gcc/
* config/rs6000/rs6000 (SAVE_INLINE_VRS, REST_INLINE_VRS,
V_SAVE_INLINE, SAVRES_LR, SAVRES_SAVE, SAVRES_REG,
SAVRES_GPR, SAVRES_FPR, SAVRES_VR): Define.
(no_global_regs_above): Delete.
(no_global_regs): New function.
(rs6000_savres_strategy): Handle vector regs.  Use proper lr_save_p
value for load multiple test.
(savres_routine_syms): Increase size.
(rs6000_savres_routine_name, rs6000_savres_routine_sym,
ptr_regno_for_savres, rs6000_emit_savres_rtx): Pass in int selector
rather than a number of boolean flags.  Update all callers.
(rs6000_savres_routine_name): Generate vector save/restore names.
(rs6000_savres_routine_sym): Handle vector regs.  Delete forward decl.
(ptr_regno_for_savres, rs6000_emit_savres_rtx): Likewise.
(rs6000_emit_prologue): Delete saving_FPRs_inline, saving_GPRs_inline
and using_store_multiple.  Expand uses.  Don't always use r11 as
frame reg when needed for out-of-line saves.  Set up initial offset
for out-of-line vector saves when buying stack frame.  Handle pointer
reg setup for out-of-line fp save.  Emit call to out-of-line vector
save function.  Choose r11 or r12 for vrsave reg when available for
better scheduling.
(rs6000_output_function_prologue): Don't emit .extern for ELF.
(rs6000_emit_epilogue): Choose a better frame reg when restoring
from back-chain to suit out-of-line vector restore functions.  Emit
call to out-of-line vector restore function.  Adjust register used
for cr restore.  Tweak pointer register setup for gpr restore.
* config/rs6000/rs6000.h (FIRST_SAVED_GP_REGNO): Take into account
FIXED_R13.
* config/rs6000/sysv4.h (FP_SAVE_INLINE, GP_SAVE_INLINE): Simplify.
(V_SAVE_INLINE): Define.
* config/rs6000/altivec.md (save_vregs_*, restore_vregs_*): New insns.
libgcc/
* config/rs6000/crtsavevr.S: New file.
* config/rs6000/crtrestvr.S: New file.
* config/rs6000/t-savresfgpr: Build the above.
* config/rs6000/t-netbsd: Likewise.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186800
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 f8dd5a05848aed385c5d1a8ec6d6a6979ea3777c
c644e474189368b21c2c950e54c75ad2cada389c M  gcc
:04 04 4b65af83bd972aa70908f8d3f5efad7b22ac2ce2
51b8b2f6236f0261d920ff6b5823cfdb17d8871e M  libgcc

[Bug target/45208] powerpc-gcc -msdata breakdown on incomplete initializers

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #1 from Sebastian Huber  ---
I can no longer reproduce this problem with GCC 4.7 and 4.8.

[Bug target/47540] ARM THUMB crash with complex numbers

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #9 from Sebastian Huber  ---
I cannot reproduce this problem with GCC 4.6.4 and 4.8.1.

[Bug target/57865] Broken _save64gpr and _rest64gpr usage

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865

--- Comment #3 from Sebastian Huber  ---
(In reply to Alan Modra from comment #2)
> My guess is that it's this change
> 
> -#define FIRST_SAVED_GP_REGNO 13
> +#define FIRST_SAVED_GP_REGNO   (FIXED_R13 ? 14 : 13)
> 
> messing with ool_adjust.

I used this on the current 4.8 head:

diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 8a36084..d075915 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -952,7 +952,7 @@ extern unsigned rs6000_pointer_size;

 #define FIRST_SAVED_ALTIVEC_REGNO (FIRST_ALTIVEC_REGNO+20)
 #define FIRST_SAVED_FP_REGNO (14+32)
-#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13)
+#define FIRST_SAVED_GP_REGNO 13

 /* List the order in which to allocate registers.  Each register must be
listed once, even those in FIXED_REGISTERS.

This solves the problem above.  I don't know the other impact of the change.

[Bug target/57865] Broken _save64gpr and _rest64gpr usage

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865

--- Comment #5 from Sebastian Huber  ---
(In reply to Alan Modra from comment #4)
> Created attachment 30489 [details]
> Fix ool_adjust
> 
> Please verify that this fixes the problem

Yes, your patch fixes also the problem if applied to the 4.8 head.

Thanks a lot for the quick response.

[Bug target/57865] Broken _save64gpr and _rest64gpr usage

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865

--- Comment #6 from Sebastian Huber  ---
(In reply to Sebastian Huber from comment #5)
> (In reply to Alan Modra from comment #4)
> > Created attachment 30489 [details]
> > Fix ool_adjust
> > 
> > Please verify that this fixes the problem
> 
> Yes, your patch fixes also the problem if applied to the 4.8 head.
> 
> Thanks a lot for the quick response.

Test results:

http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00968.html
http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00980.html
http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00980.html

I didn't see new failures.

[Bug target/57865] Broken _save64gpr and _rest64gpr usage

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865

--- Comment #7 from Sebastian Huber  ---
(In reply to Sebastian Huber from comment #6)
> Test results:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00968.html
> http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00980.html

http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00985.html

[Bug target/58259] New: PowerPC: Atomic flag test and set generates NULL pointer read and write

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58259

Bug ID: 58259
   Summary: PowerPC: Atomic flag test and set generates NULL
pointer read and write
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de

The GCC C compiler generates a NULL pointer read and write for the atomic flag
test and set method in GCC 4.7, 4.8 and 4.9.  The GCC C++ compiler doesn't have
this problem.

C test case:

#include 

_Bool test_and_set(atomic_flag *flag)
{
  return atomic_flag_test_and_set_explicit(flag, memory_order_acquire);
}

C++ test case:

#include 

bool test_and_set(std::atomic_flag &flag)
{
  return flag.test_and_set(std::memory_order_acquire);
}

GCC assembler output:

powerpc-eabi-gcc-4.7.0 -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.file   "test.c"
.section".text"
.align 2
.globl test_and_set
.type   test_and_set, @function
test_and_set:
li 10,0
rlwinm 9,3,3,27,28
lbz 5,0(10) <--- HERE IS THE NULL POINTER READ
xori 9,9,24
li 7,255
li 6,1
rlwinm 3,3,0,0,29
slw 7,7,9
slw 5,5,9
slw 6,6,9
.L2:
lwarx 10,0,3
and 8,10,7
cmpw 0,8,5
andc 8,10,7
or 8,8,6
bne- 0,.L3
stwcx. 8,0,3
bne- 0,.L2
.L3:
isync
srw 10,10,9
li 9,0
mfcr 3
rlwinm 3,3,3,1
stb 10,0(9) <--- HERE IS THE NULL POINTER WRITE
blr
.size   test_and_set, .-test_and_set
.ident  "GCC: (GNU) 4.7.0 20120202 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

powerpc-eabi-gcc -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.file   "test.c"
.section".text"
.align 2
.globl test_and_set
.type   test_and_set, @function
test_and_set:
li 9,0
li 7,255
lbz 5,0(9)
rlwinm 9,3,3,27,28
xori 9,9,24
li 6,1
rlwinm 3,3,0,0,29
slw 7,7,9
slw 5,5,9
slw 6,6,9
.L2:
lwarx 10,0,3
and 4,10,7
andc 8,10,7
cmpw 0,4,5
or 8,8,6
bne- 0,.L3
stwcx. 8,0,3
bne- 0,.L2
.L3:
isync
srw 10,10,9
li 9,0
stb 10,0(9)
mfcr 3
rlwinm 3,3,3,1
blr
.size   test_and_set, .-test_and_set
.ident  "GCC: (GNU) 4.9.0 20130828 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

powerpc-eabi-g++ -std=c++11 -Wall -Wextra -O2 -S test.cc && cat test.s
.file   "test.cc"
.section".text"
.align 2
.globl _Z12test_and_setRSt11atomic_flag
.type   _Z12test_and_setRSt11atomic_flag, @function
_Z12test_and_setRSt11atomic_flag:
.LFB326:
.cfi_startproc
rlwinm 9,3,3,27,28
li 6,255
xori 9,9,24
li 7,1
rlwinm 8,3,0,0,29
slw 6,6,9
slw 7,7,9
.L2:
lwarx 3,0,8
andc 10,3,6
or 10,10,7
stwcx. 10,0,8
bne- 0,.L2
isync
srw 3,3,9
rlwinm 3,3,0,0xff
blr
.cfi_endproc
.LFE326:
.size   _Z12test_and_setRSt11atomic_flag,
.-_Z12test_and_setRSt11atomic_flag
.ident  "GCC: (GNU) 4.9.0 20130828 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

The ARMv7 architecture has a very similar atomic model and GCC generates valid
code:

arm-eabi-gcc -march=armv7-a -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.arch armv7-a
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file   "test.c"
.text
.align  2
.global test_and_set
.type   test_and_set, %function
test_and_set:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #0
mov r1, #1
ldrbr2, [r3]@ zero_extendqisi2
.L2:
ldrexb  r3, [r0]
cmp r3, r2
bne .L3
strexb  ip, r1, [r0]
cmp ip, #0
bne .L2
.L3:
mov r2, #0
dmb sy
movne   r0, #0
moveq   r0, #1
strbr3, [r2]
bx  lr
.size   test_and_set, .-test_and_set
.ident  "GCC

[Bug target/58259] ARM, PowerPC: Atomic flag test and set generates NULL pointer read and write

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58259

Sebastian Huber  changed:

   What|Removed |Added

 Target|powerpc-eabi|powerpc-eabi, arm-eabi
Summary|PowerPC: Atomic flag test   |ARM, PowerPC: Atomic flag
   |and set generates NULL  |test and set generates NULL
   |pointer read and write  |pointer read and write

--- Comment #1 from Sebastian Huber  ---
Sorry, also the ARMv7 has the NULL pointer read and write problem:

arm-eabi-gcc -march=armv7-a -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.arch armv7-a
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file   "test.c"
.text
.align  2
.global test_and_set
.type   test_and_set, %function
test_and_set:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #0
mov r1, #1
ldrbr2, [r3]@ zero_extendqisi2 <-- NULL POINTER READ
.L2:
ldrexb  r3, [r0]
cmp r3, r2
bne .L3
strexb  ip, r1, [r0]
cmp ip, #0
bne .L2
.L3:
mov r2, #0
dmb sy
moveq   r0, #1
strbr3, [r2] <-- NULL POINTER WRITE
movne   r0, r2
bx  lr
.size   test_and_set, .-test_and_set
.ident  "GCC: (GNU) 4.9.0 20130828 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

[Bug target/58259] ARM, PowerPC: Atomic flag test and set generates NULL pointer read and write

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58259

Sebastian Huber  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Sebastian Huber  ---
Sorry for the noise, this was due to a broken FreeBSD  header
file.

[Bug target/50106] New: [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

 Bug #: 50106
   Summary: [ARM] Wrong code with -march=armv5t -mthumb -Os
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: arm-rtemseabi4.11


Created attachment 25028
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25028
Sample code.

Command line:

arm-rtemseabi4.11-g++ -march=armv5t -mthumb -Os -S compiler1.test.ii -o
compiler1.test.eabi.Os.s
arm-rtemseabi4.11-g++ -march=armv5t -mthumb -O2 -S compiler1.test.ii -o
compiler1.test.eabi.O2.s

Relevant function:

extern _TestStruct _GetIDS(unsigned int Index)
{
  if (Index < _LIST_SIZE) {
return _List[Index];
  } else {
return _List[0];
  }
}

Partial content of compiler1.test.eabi.Os.s with comments:

.text
.align  1
.global _Z7_GetIDSj
.code   16
.thumb_func
.type   _Z7_GetIDSj, %function
_Z7_GetIDSj:
.fnstart
.LFB0:
.save   {r0, r1, r2, lr}
push{r0, r1, r2, lr}

Why do we save the volatile registers r0, r1, r2 here?

ldr r3, .L4
ldr r1, .L4+4
ldr r3, [r3]
cmp r0, r3
bcs .L2
lsl r0, r0, #1
add r1, r1, r0
.L2:
mov r2, #2
add r0, sp, #4
bl  memcpy

Here we copy two bytes from the table into the stack.

add r3, sp, #4
ldrbr0, [r3, #1]
ldrbr2, [r3]

Here we copy two bytes from the stack into two registers.

lsl r0, r0, #8
orr r0, r2

Here we combine the two registers into one.

@ sp needed for prologue
pop {r0, r1, r2, pc}

Here we overwrite our result (r0) with the value of r0 at the function entry.

.L5:
.align  2
.L4:
.word   .LANCHOR0
.word   .LANCHOR1

With -O2 the problem vanishes (because we don't use memcpy()).

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

--- Comment #1 from Sebastian Huber  
2011-08-17 08:53:00 UTC ---
Created attachment 25029
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25029
arm-rtemseabi4.11-g++ -march=armv5t -mthumb -Os -S compiler1.test.ii -o
compiler1.test.eabi.Os.s

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

--- Comment #2 from Sebastian Huber  
2011-08-17 08:54:55 UTC ---
Created attachment 25030
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25030
arm-rtemseabi4.11-g++ -march=armv5t -mthumb -O2 -S compiler1.test.ii -o
compiler1.test.eabi.O2.s

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

--- Comment #4 from Sebastian Huber  
2011-08-22 09:43:39 UTC ---
Yes, this patch fixes the problem.

It is still not clear to me why we save the volatile registers r0, r1, and r2
at all.  Also we restore r1, r2, and r3.  Does this make sense?  I think also
the the usage of memcpy() is not justified in this case.

_Z7_GetIDSj:
.fnstart
.LFB0:
.save   {r0, r1, r2, lr}
push{r0, r1, r2, lr}
ldr r1, .L4
cmp r0, #3
bhi .L2
lsl r0, r0, #1
add r1, r1, r0
.L2:
mov r2, #2
add r0, sp, #4
bl  memcpy
add r3, sp, #4
ldrbr0, [r3, #1]
ldrbr2, [r3]
lsl r0, r0, #8
orr r0, r2
@ sp needed for prologue
pop {r1, r2, r3, pc}

[Bug target/49641] [4.6 Regression] Wrong code for ARMv4T and stmia

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641

--- Comment #4 from Sebastian Huber  
2011-08-22 11:00:07 UTC ---
The patch from Bernd Schmidt fixes the problem in my case.  What is the status
of this patch?

[Bug target/41780] File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780

Sebastian Huber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Sebastian Huber  
2011-08-22 11:09:40 UTC ---
This problem is fixed:

http://gcc.gnu.org/viewcvs?view=revision&revision=156868

[Bug target/47856] PowerPC: Wrong assembler output with -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856

--- Comment #1 from Sebastian Huber  
2011-08-22 11:20:08 UTC ---
This bug is still present in GCC 4.6.1.

[Bug target/47856] PowerPC: Wrong assembler output with -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856

--- Comment #2 from Sebastian Huber  
2011-08-22 12:03:41 UTC ---
This bug is also present in GCC 4.7.0 20110820.

[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119

--- Comment #2 from Sebastian Huber  
2011-08-22 12:19:24 UTC ---
This bug is not present in GCC 4.7.0 20110820.  Does anyone know which commit
fixed this problem?  Is it possible to integrate the fix in GCC 4.6?

[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119

--- Comment #4 from Sebastian Huber  
2011-08-23 15:01:59 UTC ---
Created attachment 25084
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25084
Generated assembler file.

Command line:

powerpc-rtems4.11-gcc -O2 -save-temps -fverbose-asm -c bspstart.i -o bspstart.o

GCC configure options:

powerpc-rtems4.11-gcc --version --verbose
Using built-in specs.
COLLECT_GCC=powerpc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/opt/rtems-4.11/libexec/gcc/powerpc-rtems4.11/4.6.1/lto-wrapper
powerpc-rtems4.11-gcc (GCC) 4.6.1 20110513 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: powerpc-rtems4.11
Configured with: /home/sh/archive/gcc-4.6-20110513-work/configure
--prefix=/opt/rtems-4.11 --target=powerpc-rtems4.11  --verbose --with-gnu-as
--with-gnu-ld --with-newlib --disable-libstdcxx-pch --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-threads
--enable-newlib-io-c99-formats --enable-languages=c,c++
Thread model: rtems
gcc version 4.6.1 20110513 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='--version' '-v'
 /opt/rtems-4.11/libexec/gcc/powerpc-rtems4.11/4.6.1/cc1 -quiet -v -Dmpc750
help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version --version
-o /tmp/ccMl1sdZ.s
GNU C (GCC) version 4.6.1 20110513 (prerelease) (powerpc-rtems4.11)
compiled by GNU C version 4.4.1 [gcc-4_4-branch revision 150839], GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='--version' '-v'

/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/bin/as
-v -mppc -many --version -o /tmp/cckFLHZM.o /tmp/ccMl1sdZ.s
GNU assembler version 2.21.1 (powerpc-rtems4.11) using BFD version (GNU
Binutils) 2.21.1
GNU assembler (GNU Binutils) 2.21.1
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `powerpc-rtems4.11'.
COMPILER_PATH=/opt/rtems-4.11/libexec/gcc/powerpc-rtems4.11/4.6.1/:/opt/rtems-4.11/libexec/gcc/powerpc-rtems4.11/4.6.1/:/opt/rtems-4.11/libexec/gcc/powerpc-rtems4.11/:/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/:/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/:/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/bin/
LIBRARY_PATH=/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/:/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/lib/
COLLECT_GCC_OPTIONS='--version' '-v'
 /opt/rtems-4.11/libexec/gcc/powerpc-rtems4.11/4.6.1/collect2 --eh-frame-hdr -V
-dn -Bstatic --version
/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/lib/crt0.o
-L/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1
-L/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/lib
/tmp/cckFLHZM.o -lgcc -lc -lgcc
collect2 version 4.6.1 20110513 (prerelease) (PowerPC Embedded)
/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/bin/ld
--eh-frame-hdr -V -dn -Bstatic --version
/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/lib/crt0.o
-L/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1
-L/opt/rtems-4.11/lib/gcc/powerpc-rtems4.11/4.6.1/../../../../powerpc-rtems4.11/lib
/tmp/cckFLHZM.o -lgcc -lc -lgcc
GNU ld (GNU Binutils) 2.21.1
  Supported emulations:
   elf32ppc
GNU ld (GNU Binutils) 2.21.1
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119

Sebastian Huber  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.2
 Resolution||FIXED
  Known to fail||4.6.1

--- Comment #5 from Sebastian Huber  
2011-08-24 08:20:19 UTC ---
It seems that this problem is also fixed in GCC 4.6.2 20110819.

[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119

Sebastian Huber  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #7 from Sebastian Huber  
2011-08-24 10:34:05 UTC ---
Thanks for the pointer.

*** This bug has been marked as a duplicate of bug 49768 ***

[Bug tree-optimization/49768] [4.6/4.7 Regression] C99 style union initializations does not work as expected with optimizations

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #11 from Sebastian Huber  
2011-08-24 10:34:05 UTC ---
*** Bug 49119 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #43 from Sebastian Huber  
2011-09-06 07:45:29 UTC ---
How long will this middle to back end ping pong last until this bug is finally
fixed?  It is now open since 2008.

[Bug target/50329] New: [PowerPC] Unnecessary stack frame set up

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50329

 Bug #: 50329
   Summary: [PowerPC] Unnecessary stack frame set up
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-eabi-gcc


Created attachment 25229
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25229
Sample code.

Compiling the attached file with

powerpc-eabi-gcc -O3 -S test.c

yields:

.file   "test.c"
.section".text"
.align 2
.globl a
.type   a, @function
a:
stwu 1,-536(1)
lis 9,0x1234
lis 0,0x8000
ori 9,9,22136
stw 0,0(9)
addi 1,1,536
blr
.size   a, .-a
.ident  "GCC: (GNU) 4.6.2 20110819 (prerelease)"

This looks pretty good except that a stack frame is set up and teared down.

In case you use the structure definition for memory mapped devices on embedded
systems, then it would be a great deal to save stack space.

[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #46 from Sebastian Huber  
2011-09-12 08:42:59 UTC ---
I guess the local patch will look like this:

http://gcc.gnu.org/ml/gcc/2011-07/msg00459.html

[Bug target/49641] [4.6 Regression] Wrong code for ARMv4T and stmia

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641

Sebastian Huber  changed:

   What|Removed |Added

 Target|arm-rtemseabi4.11   |arm-eabi-gcc
  Known to fail||4.7.0

--- Comment #5 from Sebastian Huber  
2011-09-12 09:15:48 UTC ---
It would be nice if this can be fixed for 4.6.2 and 4.7.0.

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

Sebastian Huber  changed:

   What|Removed |Added

 Target|arm-rtemseabi4.11   |arm-eabi-gcc

--- Comment #5 from Sebastian Huber  
2011-09-12 09:23:29 UTC ---
It would be nice if this can be fixed for 4.6.2 and 4.7.0.

[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #52 from Sebastian Huber  
2011-10-15 08:48:10 UTC ---
In GCC 4.6.2 20111014 (prerelease) the problem is still not fixed and 
"arm-eabi-gcc -march=armv5t -mthumb -O2" produces wrong code.  Please don't let
it slip through the next release.

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

--- Comment #6 from Sebastian Huber  
2011-10-18 14:19:55 UTC ---
Created attachment 25543
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25543
arm-eabi-g++ -march=armv5t -mthumb -Os -S compiler1.test.ii -o
compiler1.test.eabi.GCC-4.5.4.Os.s

[Bug target/50106] [ARM] Wrong code with -march=armv5t -mthumb -Os

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106

--- Comment #11 from Sebastian Huber  
2011-10-20 11:07:09 UTC ---
Thank you very much.  With this change the GCC 4.6.2-RC-20111019 produces now
correct code in this case.

I know understand why the unused volatile registers are saved and restored. 
This is to get rid of the arithmetic stack adjustments.

--- test.Os.GCC-4.5.s   2011-10-20 13:04:15.384638860 +0200
+++ test.Os.GCC-4.6.s   2011-10-20 13:04:15.396639237 +0200
@@ -17,32 +17,29 @@
.thumb_func
.type   _GetIDS, %function
 _GetIDS:
-   push{lr}
-   ldr r2, .L4
-   sub sp, sp, #12
-   ldr r2, [r2]
-   mov r3, r0
+   push{r0, r1, r2, lr}
+   ldr r3, .L4
ldr r1, .L4+4
-   add r0, sp, #4
-   cmp r3, r2
+   ldr r3, [r3]
+   cmp r0, r3
bge .L2
-   lsl r3, r3, #1
-   add r1, r1, r3
+   lsl r0, r0, #1
+   add r1, r1, r0
 .L2:
mov r2, #2
+   add r0, sp, #4
bl  memcpy
add r3, sp, #4
ldrbr0, [r3, #1]
ldrbr2, [r3]
lsl r0, r0, #8
-   add sp, sp, #12
-   orr r0, r0, r2
+   orr r0, r2
@ sp needed for prologue
-   pop {pc}
+   pop {r1, r2, r3, pc}
 .L5:
.align  2
 .L4:
.word   _LIST_SIZE
.word   _List
.size   _GetIDS, .-_GetIDS
-   .ident  "GCC: (GNU) 4.5.4 20111013 (prerelease)"
+   .ident  "GCC: (GNU) 4.6.2 20111019 (prerelease)"

[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #53 from Sebastian Huber  
2011-10-24 13:06:03 UTC ---
I tested the above patch proposed by Mikael Pettersson (from 2010-05-26, more
than one year ago) with GCC 4.6 20111021.  It still fixes the test case
provided by Dave Murphy (from 2008-12-27, nearly three years ago).  I run the
GCC C and C++ testsuite with the arm-rtemseabi4.11 target and the results are
identical with and without the patch.  Even if we have no perfect solution yet,
it would be very kind if someone can check in an intermediate fix.

[Bug target/50883] New: [ARM] Suboptimal optimization for small structures

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

 Bug #: 50883
   Summary: [ARM] Suboptimal optimization for small structures
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: arm-eabi-gcc


Compared to PowerPC the optimization for the attached test case is suboptimal.

Command line:

arm-eabi-gcc -O2 -march=armv7-m -mthumb -S test-1.c -o test-1-arm.s
powerpc-rtems4.11-gcc -O2 -S test-1.c -o test-1-ppc.s

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #3 from Sebastian Huber  
2011-10-27 11:55:32 UTC ---
Created attachment 25630
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25630
PowerPC assembler.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #1 from Sebastian Huber  
2011-10-27 11:54:31 UTC ---
Created attachment 25628
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25628
Sample code.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #2 from Sebastian Huber  
2011-10-27 11:55:05 UTC ---
Created attachment 25629
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25629
ARM assembler.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #5 from Sebastian Huber  
2011-10-27 15:19:57 UTC ---
If we look at the function f (the function g is similar):

struct s {
  int alignment;
  unsigned char a;
  unsigned char b;
  unsigned char c;
  unsigned char d;
};

unsigned f(struct s x)
{
  return x.a | (x.b << 8) | (x.c << 16) | (x.d << 24);
}

Currently ARM GCC produces this:

f:
subsp, sp, #8
addr3, sp, #8
stmdbr3, {r0, r1}
ldrbr0, [sp, #6]
ldrbr3, [sp, #5]
lslsr0, r0, #16
ldrbr2, [sp, #4]
orrr0, r0, r3, lsl #8
ldrbr3, [sp, #7]
orrsr0, r0, r2
orrr0, r0, r3, lsl #24
addsp, sp, #8
bxlr

According to the ARM EABI, this structure is passed in registers r0 and r1. 
The return value is in r0.  This function may be reduced to:

f:
movr0, r1
bxlr

The PowerPC GCC performs this optimization.

[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #54 from Sebastian Huber  
2011-10-28 07:31:19 UTC ---
I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson.  It works
for -march=armv4t and -march=armv5t, but not for -march=armv5te:

--- test-armv5te.s  2011-10-28 09:22:24.627388063 +0200
+++ test-armv5t.s   2011-10-28 09:22:19.923643155 +0200
@@ -1,4 +1,4 @@
-   .arch armv5te
+   .arch armv5t
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
@@ -27,8 +27,8 @@
mov r1, r4
mov r2, #1
bl  doStreamReadBlock
-   add sp, sp, #8
ldrbr0, [r4]
+   add sp, sp, #8
@ sp needed for prologue
pop {r4, pc}
.size   readStream, .-readStream

Command line:

arm-eabi-gcc -O2 -march=armv5t -mthumb -S test.c -o test-armv5t.s
arm-eabi-gcc -O2 -march=armv5te -mthumb -S test.c -o test-armv5te.s

[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #58 from Sebastian Huber  
2011-10-31 10:45:43 UTC ---
I tested Jiangning Liu's latest patch.  With it GCC 4.6.2 produces valid code
for -march=armv4t, -march=armv5t, -march=armv5te, -march=armv6, and
-march=armv7-m.  GCC 4.6.2 produces valid code for -march-armv7-m also without
the patch, for all other listed options the code is wrong.

Testsuite results:

http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03523.html

[Bug rtl-optimization/38644] [4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #60 from Sebastian Huber  
2011-11-09 09:00:26 UTC ---
Jiangning Liu thank you very much for your update.

The target milestone is currently 4.4.7.  Are there plans to commit this fix
the the 4.4, 4.5, and 4.6 branches?

[Bug target/50329] [PowerPC] Unnecessary stack frame set up

[sebastian.hu...@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50329

Sebastian Huber  changed:

   What|Removed |Added

  Attachment #25229|0   |1
is obsolete||

--- Comment #1 from Sebastian Huber  
2012-07-19 08:11:15 UTC ---
Created attachment 27830
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27830
Sample code

On GCC 4.7.1 20120614 the situation is even more worse:

.file   "test.c"
.section".text"
.align 2
.globl a
.type   a, @function
a:
stwu 1,-536(1)
li 9,0
stw 9,8(1)
li 9,-128
stb 9,8(1)
lwz 9,8(1)
addi 1,1,536
stw 9,0(3)
blr
.size   a, .-a
.align 2
.globl b
.type   b, @function
b:
stwu 1,-544(1)
mflr 0
li 4,0
li 5,516
stw 31,540(1)
mr 31,3
addi 3,1,8
stw 0,548(1)
bl memset
li 9,-128
stb 9,8(1)
lwz 9,8(1)
stw 9,0(31)
lwz 0,548(1)
lwz 31,540(1)
mtlr 0
addi 1,1,544
blr
.size   b, .-b
.align 2
.globl c
.type   c, @function
c:
li 9,0
li 10,1
rlwimi 9,10,31,0,0
stw 9,0(3)
blr
.size   c, .-c
.ident  "GCC: (GNU) 4.7.1 20120614 (RTEMS
gcc-4.7.1-3.suse12.1/newlib-1.20.0-10.suse12.1)"

Here we see additional store and load operations to assemble the structure
value.

The test case (c) is also sub-optimal since two instructions are sufficient to
load a 32-bit constant.

[Bug tree-optimization/69196] [5 Regression] code size regression with jump threading at -O2

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196

--- Comment #29 from Sebastian Huber  ---
Just for reference some numbers for GCC 7.4.0 and GCC 9.0.0 20190104:

sparc-rtems5-gcc --version
sparc-rtems5-gcc (GCC) 7.4.0 20181206 (RTEMS 5, RSB
ddba5372522da341fa20b2c75dfe966231cb6790, Newlib
df6915f029ac9acd2b479ea898388cbd7dda4974)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

sparc-rtems5-gcc -c -O2 -o vprintk.7.4.0.o vprintk.i

sparc-rtems6-gcc --version
sparc-rtems6-gcc (GCC) 9.0.0 20190104 (RTEMS 6, RSB
cd4a4f61ea5bbd4236f7717a94cd5e67f8b3ad20, Newlib
34d9bb709390b14b4ed0b1ea2656bf6bf5a055c3)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

sparc-rtems6-gcc -c -O2 -o vprintk.9.0.0.o vprintk.i

size *.o
   textdata bss dec hex filename
688   0   0 688 2b0 vprintk.4.9.4.o
   1272   0   01272 4f8 vprintk.6.0.0.o
933   0   0 933 3a5 vprintk.7.4.0.o
825   0   0 825 339 vprintk.9.0.0.o

It seems the code size is quite volatile for this test case.

[Bug c++/88789] New: epiphany: memory_resource.cc:235:62: error: static assertion failed

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789

Bug ID: 88789
   Summary: epiphany: memory_resource.cc:235:62: error: static
assertion failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Build fails in libstdc++ currently:

libtool: compile: 
/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/./gcc/xgcc
-shared-libgcc
-B/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/./gcc
-nostdinc++
-L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/src
-L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/src/.libs
-L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/libsupc++/.libs
-nostdinc
-B/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/newlib/
-isystem
/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/newlib/targ-include
-isystem
/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/newlib/libc/include
-B/home/user/install/rtems/6/epiphany-rtems6/bin/
-B/home/user/install/rtems/6/epiphany-rtems6/lib/ -isystem
/home/user/install/rtems/6/epiphany-rtems6/include -isystem
/home/user/install/rtems/6/epiphany-rtems6/sys-include
-I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/../libgcc
-I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/include/epiphany-rtems6
-I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/include
-I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/libsupc++
-std=gnu++17 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-string-inst.lo -fimplicit-templates -g -O2 -c
../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/cow-string-inst.cc
-o cow-string-inst.o
../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/memory_resource.cc:
In member function 'void
std::pmr::monotonic_buffer_resource::_M_new_buffer(std::size_t, std::size_t)':
../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/memory_resource.cc:235:62:
error: static assertion failed
  235 | static_assert(alignof(monotonic_buffer_resource::_Chunk) == 1);
  |   ~~~^~~~

[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789

--- Comment #2 from Sebastian Huber  ---
I am not an epiphany expert. I just noticed this while testing the GCC builds
for RTEMS.

[Bug lto/88643] -Wl,--wrap not supported with LTO

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #2 from Sebastian Huber  ---
Is this somehow related to the problem that the LD --wrap does not work for
references internal to a translation unit? See:

https://www.sourceware.org/ml/binutils/2018-12/msg00210.html

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=4ea904edb7b04ad526bd8a5401729a6c1f5a982f

[Bug lto/88643] -Wl,--wrap not supported with LTO

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

--- Comment #5 from Sebastian Huber  ---
I think the basic problem is that the LD --wrap feature works only with
undefined symbols references and not relocations:

See also:

https://www.sourceware.org/ml/binutils/2019-01/msg00204.html

[Bug ada/89097] New: Ada build broken with long path names

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89097

Bug ID: 89097
   Summary: Ada build broken with long path names
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

I tried to build a native GCC with Ada support with a long build and source
directory:

pwd
/home/user/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012

ls -l
total 8
drwxr-xr-x 47 user user 4096 Jan 29 07:46 build
drwxr-xr-x 40 user user 4096 Jan 28 13:47 gnu-mirror-gcc-597c6d15f88

GCC configure:

~/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/gnu-mirror-gcc-597c6d15f88/configure
--prefix=$HOME/gcc-9 --disable-multilib --enable-languages='c,c++,ada'

The build fails due to an empty s-oscons.ads:

ls -l ./build/gcc/ada/rts/s-oscons*
-rw-r--r-- 1 user user   0 Jan 29 07:46 ./build/gcc/ada/rts/s-oscons.ads
-rw-r--r-- 1 user user   0 Jan 29 07:46 ./build/gcc/ada/rts/s-oscons.h
-rw-r--r-- 1 user user 1501290 Jan 29 07:46
./build/gcc/ada/rts/s-oscons-tmplt.i
-rw-r--r-- 1 user user  444600 Jan 29 07:46
./build/gcc/ada/rts/s-oscons-tmplt.s

Error message:
/home/user/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110121131141151161171

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #11 from Sebastian Huber  ---
(In reply to Chris Johns from comment #10)
> (In reply to Joel Sherrill from comment #9)
> > Yes. I believe it is the same bug. Use of GNU sed specifics on a system
> > without GNU sed.
> > 
> > I don't know if that changes the resolution.
> 
> For this bug that is true however the other bug is still open and so the
> issue is not resolved so I hope there is a chance someone with a suitable
> level of sed knowledge may take a look to see if the use can be made to be
> universal or highlight a bug in BSD sed. I had a look but I could not
> determine if the issue is in the sed expressions used or BSD sed.

I opened a FreeBSD bug:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293

[Bug target/83387] New: PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

Bug ID: 83387
   Summary: PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

I added support for the 64-bit PowerPC some months ago using a variant of the
ELFv2 ABI. I don't know which kind of long double support I use on this target.
This is difficult for me to understand how this works on 64-bit PowerPC. This
was no problem up to now since nobody used long double with RTEMS on this
target. I tried to build a GCC with Ada support today for the powerpc-rtems5
target. It ends up in infinite loops while building the Ada run-time multilib
for a 64-bit PowerPC variant. To reproduce the problem you can log in to gcc67:

cd /home/sh/tmp/b-gcc/gcc/ada/rts_me6500_m64_nof_noaltivec

gdb --args /home/sh/tmp/b-gcc/./gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc
-dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g
-mcpu=e6500 -msoft-float -gnatpg -mcpu=e6500 -m64 -msoft-float -mno-altivec
-gnatO a-scteio.o a-scteio.ads -o -
...
(gdb) bt
#0  spill_pseudos (set=0x7fffdf50) at
/home/sh/tmp/gcc/gcc/lra-eliminations.c:1164
#1  update_reg_eliminate(bitmap_head*) () at
/home/sh/tmp/gcc/gcc/lra-eliminations.c:1288
#2  0x00cfbbb3 in lra_eliminate(bool, bool) () at
/home/sh/tmp/gcc/gcc/lra-eliminations.c:1449
#3  0x00ce35ea in lra(_IO_FILE*) () at /home/sh/tmp/gcc/gcc/lra.c:2493
#4  0x00c9c6a2 in do_reload () at /home/sh/tmp/gcc/gcc/ira.c:5443
#5  (anonymous namespace)::pass_reload::execute(function*) () at
/home/sh/tmp/gcc/gcc/ira.c:5627
#6  0x00d61a1b in execute_one_pass(opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2497
#7  0x00d62255 in execute_pass_list_1(opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2586
#8  0x00d62267 in execute_pass_list_1(opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2587
#9  0x00d62299 in execute_pass_list(function*, opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2597
#10 0x00aabaee in cgraph_node::expand() () at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2139
#11 0x00aaccbc in expand_all_functions () at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2275
#12 symbol_table::compile() [clone .part.75] () at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2623
#13 0x00aaefaa in symbol_table::compile (this=0x7753c000) at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2537
#14 symbol_table::finalize_compilation_unit (this=0x7753c000) at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2716
#15 0x00e1efc3 in compile_file () at /home/sh/tmp/gcc/gcc/toplev.c:480
#16 0x0068be0b in do_compile () at /home/sh/tmp/gcc/gcc/toplev.c:2059
#17 toplev::main(int, char**) () at /home/sh/tmp/gcc/gcc/toplev.c:2194
#18 0x0068e07b in main (argc=25, argv=0x7fffe418) at
/home/sh/tmp/gcc/gcc/main.c:39

gdb --args /home/sh/tmp/b-gcc/./gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc
-dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g
-mcpu=e6500 -msoft-float -gnatpg -mcpu=e6500 -m64 -msoft-float -mno-altivec
-gnatO a-coteio.o a-coteio.ads -o -
...
(gdb) bt
#0  process_bb_lives(basic_block_def*, int&, bool) () at
/home/sh/tmp/gcc/gcc/lra-lives.c:726
#1  0x00cff3ea in lra_create_live_ranges_1(bool, bool) () at
/home/sh/tmp/gcc/gcc/lra-lives.c:1316
#2  0x00cffea0 in lra_create_live_ranges(bool, bool) () at
/home/sh/tmp/gcc/gcc/lra-lives.c:1380
#3  0x00ce36fa in lra(_IO_FILE*) () at /home/sh/tmp/gcc/gcc/lra.c:2434
#4  0x00c9c6a2 in do_reload () at /home/sh/tmp/gcc/gcc/ira.c:5443
#5  (anonymous namespace)::pass_reload::execute(function*) () at
/home/sh/tmp/gcc/gcc/ira.c:5627
#6  0x00d61a1b in execute_one_pass(opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2497
#7  0x00d62255 in execute_pass_list_1(opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2586
#8  0x00d62267 in execute_pass_list_1(opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2587
#9  0x00d62299 in execute_pass_list(function*, opt_pass*) () at
/home/sh/tmp/gcc/gcc/passes.c:2597
#10 0x00aabaee in cgraph_node::expand() () at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2139
#11 0x00aaccbc in expand_all_functions () at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2275
#12 symbol_table::compile() [clone .part.75] () at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2623
#13 0x00aaefaa in symbol_table::compile (this=0x7753c000) at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2537
#14 symbol_table::finalize_compilation_unit (this=0x7753c000) at
/home/sh/tmp/gcc/gcc/cgraphunit.c:2716
#15 0x00e1efc3 in compile_file () at /home/sh/tmp/gcc/gcc/toplev.c:480
#16 0x0068be0b in do_compile () at /home/sh/tmp/gcc/gcc/toplev.c:2059
#17 toplev::main(int, char**) () at /home/s

[Bug target/83387] PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #2 from Sebastian Huber  ---
(In reply to Peter Bergner from comment #1)
> Is the insn you're dying with contain FP operands?  I know the backend for
> 64-bit PowerPC assumes/requires 64-bit FP hardware is available and since
> you're using -msoft-float, I can imagine that you're running afoul of that
> somehow.

Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I just
copied the 32-bit multilibs without much thought.

> 
> FYI, I tried logging into gcc67 but couldn't for some reason.  I have no
> problems logging into other gcc farm systems.

My SSH config for gcc67 is:

Compression yes
Host gcc67
  User sh
  Hostname gcc67.fsffrance.org

[Bug target/83387] PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #4 from Sebastian Huber  ---
(In reply to Peter Bergner from comment #3)
> (In reply to Sebastian Huber from comment #2)
> > Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I
> > just copied the 32-bit multilibs without much thought.
> 
> It is used by the linux kernel, but they also explicitly do not use
> float/double types.  If you have float/double types in your source code and
> compile for 64-bit using -msoft-float, I could guess that you would run into
> some of the assumptions in the 64-bit backend that floating point hardware
> is always available.  It's just a guess though, without knowing what the
> insn / operand you're having problems with looks like.

If I remove the -msoft-float, the two example source files compile
(-mno-altivec seems to cause no harm).

How can I dump the instruction? I don't know Ada well enough to figure it out
from the source code.

[Bug target/83387] PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #6 from Sebastian Huber  ---
(In reply to Peter Bergner from comment #5)
> (In reply to Sebastian Huber from comment #4)
> > If I remove the -msoft-float, the two example source files compile
> > (-mno-altivec seems to cause no harm).
> 
> Well the first question, is do you really need to use -msoft-float?  Looking
> at the E6500 hardware doc seems to show that it has both hardware FP and
> Altivec units.

For some applications fast context switches are important and the FP/AltiVec
context is quite huge. It affects also the interrupt latency. I have to discuss
this with the application developers. We probably don't need it in a 64-bit
configuration.

> 
> 
> > How can I dump the instruction? I don't know Ada well enough to figure it
> > out from the source code.
> 
> I don't know Ada as well, but I mean what does the RTL insn look like? 
> You'll probably  need a debug build of your gcc for that so it isn't
> optimized away and then you can print it from gdb.

Ok, I will try to do this. I am not sure how it works with the cross compiler
build:

https://gcc.gnu.org/wiki/DebuggingGCC#gccbuilddebug

[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

Sebastian Huber  changed:

   What|Removed |Added

 Target|powerpc-rtems5  |powerpc64le-unknown-linux-g
   ||nu
Summary|PowerPC64 + Ada + RTEMS:|PowerPC64: Infinite loops
   |Infinite loops in   |in do_reload() with
   |do_reload() |-msoft-float

--- Comment #7 from Sebastian Huber  ---
It seems to be a general problem with -msoft-float on PowerPC64. I built a
native GCC on gcc112:

[sh@gcc2-power8 ~]$ cd /home/sh/b-gcc-git/gcc/ada/rts
[sh@gcc2-power8 rts]$ gdb --args /home/sh/b-gcc-git/gcc/gnat1 -gnatwa -quiet
-nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2
-Wextra -Wall -g -gnatpg -msoft-float -gnatO a-coteio.o a-coteio.ads -o -
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64le-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Warning: /home/sh/gcc-7-20161030/gcc: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/ada: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/c: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/cp: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/fortran: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/go: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/jit: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/lto: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/objc: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/objcp: No such file or directory.
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named gdbhooks
/home/sh/.gdbinit:13: Error in sourced command file:
Error while executing Python code.
Reading symbols from /home/sh/b-gcc-git/gcc/gnat1...done.
(gdb) r
Starting program: /home/sh/b-gcc-git/gcc/gnat1 -gnatwa -quiet -nostdinc
-nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g
-gnatpg -msoft-float -gnatO a-coteio.o a-coteio.ads -o -
.file   "a-coteio.ads"
.machine power7
.abiversion 2
.section".text"
.Ltext0:
.globl __truncdfsf2
^C
Program received signal SIGINT, Interrupt.
0x108158a0 in bitmap_and_compl_into (a=0x12c7a0b0, b=)
at /home/sh/gcc-git/gcc/bitmap.c:1181
1181  gcc_checking_assert (!a->current == !a->first
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.ppc64le
(gdb) bt
#0  0x108158a0 in bitmap_and_compl_into (a=0x12c7a0b0, b=) at /home/sh/gcc-git/gcc/bitmap.c:1181
#1  0x10c83208 in spill_pseudos () at /home/sh/gcc-git/gcc/bitmap.h:806
#2  lra_spill () at /home/sh/gcc-git/gcc/lra-spills.c:595
#3  0x10c56998 in lra (f=) at
/home/sh/gcc-git/gcc/lra.c:2514
#4  0x10bf216c in do_reload () at /home/sh/gcc-git/gcc/ira.c:5443
#5  (anonymous namespace)::pass_reload::execute (this=) at
/home/sh/gcc-git/gcc/ira.c:5627
#6  0x10d36f20 in execute_one_pass (pass=0x12a04650) at
/home/sh/gcc-git/gcc/passes.c:2497
#7  0x10d38114 in execute_pass_list_1 (pass=0x12a04650) at
/home/sh/gcc-git/gcc/passes.c:2586
#8  0x10d3812c in execute_pass_list_1 (pass=0x12a03570) at
/home/sh/gcc-git/gcc/passes.c:2587
#9  0x10d381b8 in execute_pass_list (fn=,
pass=) at /home/sh/gcc-git/gcc/passes.c:2597
#10 0x108cb178 in cgraph_node::expand (this=0x3fffaf68) at
/home/sh/gcc-git/gcc/context.h:48
#11 0x108ccf44 in expand_all_functions () at
/home/sh/gcc-git/gcc/cgraphunit.c:2275
#12 symbol_table::compile (this=0x3fffaf42) at
/home/sh/gcc-git/gcc/cgraphunit.c:2623
#13 0x108d084c in compile (this=0x3fffaf42) at
/home/sh/gcc-git/gcc/cgraphunit.c:2716
#14 symbol_table::finalize_compilation_unit (this=0x3fffaf42) at
/home/sh/gcc-git/gcc/cgraphunit.c:2716
#15 0x10e564b4 in compile_file () at /home/sh/gcc-git/gcc/toplev.c:480
#16 0x10277938 in do_compile () at /home/sh/gcc-git/gcc/toplev.c:2063
#17 toplev::main (this=0x3fffef50, argc=, argv=) at /home/sh/gcc-git/gcc/toplev.c:2198
#18 0x102798a8 in main (argc=, argv=0x3378) at
/home/sh/gcc-git/gcc/main.c:39

[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #12 from Sebastian Huber  ---
(In reply to Peter Bergner from comment #9)
[...]
> Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> builtin into the backend and tracking them all down and fixing them is not
> going to be easy.  That's why I asked earlier, if you really really need to
> disable HW FP for your builds.  If you do, then good luck to you finding
> them all.

Thanks for your investigations. I removed the 64-bit soft-float multilib.

Would it be possible to generate a proper ICE with a user friendly error
message if someone uses -msoft-float on this target?

[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #14 from Sebastian Huber  ---
(In reply to Peter Bergner from comment #13)
> (In reply to Sebastian Huber from comment #12)
> > (In reply to Peter Bergner from comment #9)
> > [...]
> > > Here, you can see that on ELFv2, we always assume HW FP regs are 
> > > avialable,
> > > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> > > reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> > > builtin into the backend and tracking them all down and fixing them is not
> > > going to be easy.  That's why I asked earlier, if you really really need 
> > > to
> > > disable HW FP for your builds.  If you do, then good luck to you finding
> > > them all.
> > 
> > Thanks for your investigations. I removed the 64-bit soft-float multilib.
> 
> I can't promise this is all you need, but does the following patch help?
> 
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 255700)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
>   homogeneous aggregates; these types are handled via the
>   targetm.calls.split_complex_arg mechanism.  Complex types
>   can be elements of homogeneous aggregates, however.  */
> -  if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> +  if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> +  && AGGREGATE_TYPE_P (type))
>  {
>machine_mode field_mode = VOIDmode;
>int field_count = rs6000_aggregate_candidate (type, &field_mode);
> 
> 
> 

With this patch I can build an Ada compiler with a -m64 and -msoft-float
multilib.

[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #15 from Sebastian Huber  ---
(In reply to Sebastian Huber from comment #14)
> (In reply to Peter Bergner from comment #13)
> > (In reply to Sebastian Huber from comment #12)
> > > (In reply to Peter Bergner from comment #9)
> > > [...]
> > > > Here, you can see that on ELFv2, we always assume HW FP regs are 
> > > > avialable,
> > > > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, 
> > > > aka
> > > > reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> > > > builtin into the backend and tracking them all down and fixing them is 
> > > > not
> > > > going to be easy.  That's why I asked earlier, if you really really 
> > > > need to
> > > > disable HW FP for your builds.  If you do, then good luck to you finding
> > > > them all.
> > > 
> > > Thanks for your investigations. I removed the 64-bit soft-float multilib.
> > 
> > I can't promise this is all you need, but does the following patch help?
> > 
> > Index: gcc/config/rs6000/rs6000.c
> > ===
> > --- gcc/config/rs6000/rs6000.c  (revision 255700)
> > +++ gcc/config/rs6000/rs6000.c  (working copy)
> > @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
> >   homogeneous aggregates; these types are handled via the
> >   targetm.calls.split_complex_arg mechanism.  Complex types
> >   can be elements of homogeneous aggregates, however.  */
> > -  if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> > +  if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> > +  && AGGREGATE_TYPE_P (type))
> >  {
> >machine_mode field_mode = VOIDmode;
> >int field_count = rs6000_aggregate_candidate (type, &field_mode);
> > 
> > 
> > 
> 
> With this patch I can build an Ada compiler with a -m64 and -msoft-float
> multilib.

How do we want to continue with this PR? Close it as WONTFIX or apply the patch
and close it as FIXED?

[Bug target/83090] ICE on lm32-rtems building newlib libm (in require, at machmode.h:282)

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090

Sebastian Huber  changed:

   What|Removed |Added

 CC||lekernel at gcc dot gnu.org,
   ||sebastian.huber@embedded-br
   ||ains.de

--- Comment #1 from Sebastian Huber  ---
ICE still exists with GCC 659f92d1990e0b84a6e30f6ecd76319552faf7b7 (20180103).

[Bug target/83670] New: m32c ICE in leaf_function_p, at final.c:4368

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670

Bug ID: 83670
   Summary: m32c ICE in leaf_function_p, at final.c:4368
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Created attachment 43016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43016&action=edit
Test program.

m32c-rtems5-gcc -O2 test.i
during RTL pass: pro_and_epilogue
test.c: In function 'main':
test.c:16:1: internal compiler error: in leaf_function_p, at final.c:4368
 }
 ^
0x103e7b8b leaf_function_p()
/home/sh/src/gcc/gcc/final.c:4368
0x10c3c61f m32c_leaf_function_p
/home/sh/src/gcc/gcc/config/m32c/m32c.c:4023
0x10c3c61f m32c_emit_prologue()
/home/sh/src/gcc/gcc/config/m32c/m32c.c:4077
0x10dfb8e3 gen_prologue()
/home/sh/src/gcc/gcc/config/m32c/prologue.md:26
0x10c35e57 target_gen_prologue
/home/sh/src/gcc/gcc/config/m32c/blkmov.md:359
0x1044e9d3 make_prologue_seq
/home/sh/src/gcc/gcc/function.c:5912
0x1044ed67 thread_prologue_and_epilogue_insns()
/home/sh/src/gcc/gcc/function.c:6029
0x1044f7af rest_of_handle_thread_prologue_and_epilogue
/home/sh/src/gcc/gcc/function.c:6520
0x1044f7af execute
/home/sh/src/gcc/gcc/function.c:6562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/83681] New: epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681

Bug ID: 83681
   Summary: epiphany: config/epiphany/epiphany.h:883:8: error:
unknown type name 'rtl_opt_pass'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

I cannot build an epiphany-rtems5 Ada compiler:

/run/user/10351/b-gcc-epiphany/./gcc/xgcc
-B/run/user/10351/b-gcc-epiphany/./gcc/ -nostdinc
-B/run/user/10351/b-gcc-epiphany/epiphany-rtems5/newlib/ -isystem
/run/user/10351/b-gcc-epiphany/epiphany-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/epiphany-rtems5/bin/
-B/home/sh/install/epiphany-rtems5/lib/ -isystem
/home/sh/install/epiphany-rtems5/include -isystem
/home/sh/install/epiphany-rtems5/sys-include-c -DCROSS_DIRECTORY_STRUCTURE
-DIN_GCC  -W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO\
-iquote /home/sh/src/gcc/gcc \
 -iquote . -iquote .. -iquote ../.. -iquote /home/sh/src/gcc/gcc/ada
-iquote /home/sh/src/gcc/gcc -I/home/sh/src/gcc/include  \
targext.c -o targext.o
In file included from ../../tm.h:21,
 from targext.c:46:
/home/sh/src/gcc/gcc/config/epiphany/epiphany.h:883:8: error: unknown type name
'rtl_opt_pass'
 extern rtl_opt_pass *make_pass_mode_switch_use (gcc::context *ctxt);
^~~~
/home/sh/src/gcc/gcc/config/epiphany/epiphany.h:883:52: error: expected ')'
before ':' token
 extern rtl_opt_pass *make_pass_mode_switch_use (gcc::context *ctxt);
^
)
/home/sh/src/gcc/gcc/config/epiphany/epiphany.h:884:8: error: unknown type name
'rtl_opt_pass'
 extern rtl_opt_pass *make_pass_resolve_sw_modes (gcc::context *ctxt);
^~~~
/home/sh/src/gcc/gcc/config/epiphany/epiphany.h:884:53: error: expected ')'
before ':' token
 extern rtl_opt_pass *make_pass_resolve_sw_modes (gcc::context *ctxt);
 ^
 )
In file included from ../../tm.h:23,
 from targext.c:46:
/home/sh/src/gcc/gcc/config/elfos.h:201: warning:
"READONLY_DATA_SECTION_ASM_OP" redefined
 #define READONLY_DATA_SECTION_ASM_OP "\t.section\t.rodata"

In file included from ../../tm.h:21,
 from targext.c:46:
/home/sh/src/gcc/gcc/config/epiphany/epiphany.h:671: note: this is the location
of the previous definition
 #define READONLY_DATA_SECTION_ASM_OP "\t.section .rodata"

[Bug target/83681] epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681

Sebastian Huber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Sebastian Huber  ---
Patch committed.

[Bug target/83761] New: bfin: ICE: in require, at machmode.h:292

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761

Bug ID: 83761
   Summary: bfin: ICE: in require, at machmode.h:292
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

make[4]: Entering directory
`/run/user/10351/b-gcc-bfin/bfin-rtems5/libgfortran'
/bin/sh ./libtool  --tag=CC   --mode=compile
/run/user/10351/b-gcc-bfin/./gcc/xgcc -B/run/user/10351/b-gcc-bfin/./gcc/
-nostdinc -B/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/ -isystem
/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/bfin-rtems5/bin/
-B/home/sh/install/bfin-rtems5/lib/ -isystem
/home/sh/install/bfin-rtems5/include -isystem
/home/sh/install/bfin-rtems5/sys-include-DHAVE_CONFIG_H -I.
-I/home/sh/src/gcc/libgfortran  -iquote/home/sh/src/gcc/libgfortran/io
-I/home/sh/src/gcc/libgfortran/../gcc
-I/home/sh/src/gcc/libgfortran/../gcc/config  -I../.././gcc
-I/home/sh/src/gcc/libgfortran/../libgcc -I../libgcc
-I/home/sh/src/gcc/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla  -fcx-fortran-rules
-ffunction-sections -fdata-sections   -g -O2 -MT sum_c8.lo -MD -MP -MF
.deps/sum_c8.Tpo -c -o sum_c8.lo `test -f
'/home/sh/src/gcc/libgfortran/generated/sum_c8.c' || echo
'/home/sh/src/gcc/libgfortran/'`/home/sh/src/gcc/libgfortran/generated/sum_c8.c
libtool: compile:  /run/user/10351/b-gcc-bfin/./gcc/xgcc
-B/run/user/10351/b-gcc-bfin/./gcc/ -nostdinc
-B/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/ -isystem
/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/bfin-rtems5/bin/
-B/home/sh/install/bfin-rtems5/lib/ -isystem
/home/sh/install/bfin-rtems5/include -isystem
/home/sh/install/bfin-rtems5/sys-include -DHAVE_CONFIG_H -I.
-I/home/sh/src/gcc/libgfortran -iquote/home/sh/src/gcc/libgfortran/io
-I/home/sh/src/gcc/libgfortran/../gcc
-I/home/sh/src/gcc/libgfortran/../gcc/config -I../.././gcc
-I/home/sh/src/gcc/libgfortran/../libgcc -I../libgcc
-I/home/sh/src/gcc/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT sum_c8.lo -MD -MP -MF
.deps/sum_c8.Tpo -c /home/sh/src/gcc/libgfortran/generated/sum_c8.c -o sum_c8.o
during RTL pass: reload
/home/sh/src/gcc/libgfortran/generated/sum_c8.c: In function 'sum_c8':
/home/sh/src/gcc/libgfortran/generated/sum_c8.c:191:1: internal compiler error:
in require, at machmode.h:292
 }
 ^
0x101e4f43 opt_mode::require() const
/home/sh/src/gcc/gcc/machmode.h:292
0x101e4f43 replace_reg_with_saved_mem
/home/sh/src/gcc/gcc/caller-save.c:1151
0x101e49a3 mark_referenced_regs
/home/sh/src/gcc/gcc/caller-save.c:1053
0x101e49f3 mark_referenced_regs
/home/sh/src/gcc/gcc/caller-save.c:1073
0x101e49f3 mark_referenced_regs
/home/sh/src/gcc/gcc/caller-save.c:1073
0x101e6e2f save_call_clobbered_regs()
/home/sh/src/gcc/gcc/caller-save.c:893
0x10771d27 reload(rtx_insn*, int)
/home/sh/src/gcc/gcc/reload1.c:981
0x1059e8bb do_reload
/home/sh/src/gcc/gcc/ira.c:5474
0x1059e8bb execute
/home/sh/src/gcc/gcc/ira.c:5646

[Bug target/83761] bfin: ICE: in require, at machmode.h:292

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761

--- Comment #1 from Sebastian Huber  ---
Created attachment 43086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43086&action=edit
Makefile to build the cross GCC

Use

make clone
make install/bin/bfin-rtems5-ld
make install/bin/bfin-rtems5-gcc

to build the cross GCC to reproduce the problem.

[Bug target/83761] bfin: ICE: in require, at machmode.h:292

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761

--- Comment #3 from Sebastian Huber  ---
Created attachment 43096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43096&action=edit
Test case.

/home/sh/b-gcc-bfin/./gcc/xgcc -B/home/sh/b-gcc-bfin/./gcc/ -c sum_c8.i -O2 -g

[Bug target/83785] New: sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785

Bug ID: 83785
   Summary: sh: ICE in maybe_record_trace_start, at
dwarf2cfi.c:2344
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Created attachment 43097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43097&action=edit
Test case.

/home/sh/b-gcc-sh/./gcc/xgcc -B/home/sh/b-gcc-sh/./gcc/ -c matmul_i8.i -O2 -g
-funroll-loops --param max-unroll-times=4
during RTL pass: dwarf2
/home/sh/src/gcc/libgfortran/generated/matmul_i8.c: In function 'matmul_i8':
/home/sh/src/gcc/libgfortran/generated/matmul_i8.c:2922:1: internal compiler
error: in maybe_record_trace_start, at dwarf2cfi.c:2344
 }
 ^
0x102bef2f maybe_record_trace_start
/home/sh/src/gcc/gcc/dwarf2cfi.c:2344
0x102bf587 create_trace_edges
/home/sh/src/gcc/gcc/dwarf2cfi.c:2440
0x102c40b7 scan_trace
/home/sh/src/gcc/gcc/dwarf2cfi.c:2653
0x102c4c77 create_cfi_notes
/home/sh/src/gcc/gcc/dwarf2cfi.c:2679
0x102c4c77 execute_dwarf2_frame
/home/sh/src/gcc/gcc/dwarf2cfi.c:3037
0x102c4c77 execute
/home/sh/src/gcc/gcc/dwarf2cfi.c:3525
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/83809] New: epiphany: a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83809

Bug ID: 83809
   Summary: epiphany: a-direct.ads:478:09: alignment for
"Search_Typeb119s" must be at least 8
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Created attachment 43112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43112&action=edit
Makefile to build the cross GCC

I tried to build an Ada compiler for epiphany-rtems5. I am not sure if it is
worth to support Ada on this target. I use in mainly to test the compiler
build.

/home/sh/b-gcc-epiphany/./gcc/xgcc -B/home/sh/b-gcc-epiphany/./gcc/ -nostdinc
-B/home/sh/b-gcc-epiphany/epiphany-rtems5/newlib/ -isystem
/home/sh/b-gcc-epiphany/epiphany-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/epiphany-rtems5/bin/
-B/home/sh/install/epiphany-rtems5/lib/ -isystem
/home/sh/install/epiphany-rtems5/include -isystem
/home/sh/install/epiphany-rtems5/sys-include-c -g -O2   -W -Wall -gnatpg
-nostdinc   a-direct.adb -o a-direct.o
a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8

The attached Makefile can be used to reproduce the build.

make clone
make native
make install/bin/epiphany-rtems5-ld
make install/bin/epiphany-rtems5-gcc

[Bug target/83810] New: sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83810

Bug ID: 83810
   Summary: sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays
smaller object
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Created attachment 43113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43113&action=edit
Makefile to build the cross GCC

I tried to build an Ada compiler for sh-rtems5. I am not sure if it is worth to
support Ada on this target. I use in mainly to test the compiler build.

/home/sh/b-gcc-sh/./gcc/xgcc -B/home/sh/b-gcc-sh/./gcc/ -nostdinc
-B/home/sh/b-gcc-sh/sh-rtems5/newlib/ -isystem
/home/sh/b-gcc-sh/sh-rtems5/newlib/targ-include -isystem
/home/sh/src/gcc/newlib/libc/include -B/home/sh/install/sh-rtems5/bin/
-B/home/sh/install/sh-rtems5/lib/ -isystem /home/sh/install/sh-rtems5/include
-isystem /home/sh/install/sh-rtems5/sys-include-c -g -O2 -m4-single-only 
-W -Wall -gnatpg -nostdinc -m4-single-only  s-scaval.adb -o s-scaval.o
s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object
s-scaval.adb:103:07: warning: program execution may be erroneous
s-scaval.adb:103:07: warning: size of "IV_Ilf" is 64
s-scaval.adb:103:07: warning: size of "IS_Ilf" is 32
s-scaval.adb:104:07: warning: "IV_Ill" overlays smaller object
s-scaval.adb:104:07: warning: program execution may be erroneous
s-scaval.adb:104:07: warning: size of "IV_Ill" is 96
s-scaval.adb:104:07: warning: size of "IS_Ill" is 64

The attached Makefile can be used to reproduce the build.

make clone
make native
make install/bin/sh-rtems5-ld
make install/bin/sh-rtems5-gcc

[Bug target/83090] ICE on lm32-rtems building newlib libm (in require, at machmode.h:282)

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090

--- Comment #2 from Sebastian Huber  ---
I was able to build GCC ab053afeec0450e64568a7a0d50d0e9a5ece2787 (20180116).

[Bug c++/67064] Register asm variable broken

[sebastian.hu...@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064

--- Comment #33 from Sebastian Huber  ---
(In reply to Eric Gallager from comment #32)
> (In reply to Martin Liška from comment #31)
> > Can the bug be marked as resolved?
> 
> WAITING on a reply.

From my point of view it is fixed

I guess since Daniel Gutson didn't get an answer in the last four years, he
will unlikely get it in the future.