[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #25 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #23)
> Fixed on the trunk will backport to GCC 13 after 13.2.0 is released (since
> the branch is frozen except for RM approvals).

Now that GCC 13.2.0 has been released, would it be possible to backport the
fix, please?

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 55616 [details]
> gcc14-pr110755.patch
> 
> Updated patch.

Thanks. I have just tested it, and I confirm it fixes the reported issue.

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 55594 [details]
> gcc14-pr110755.patch
> 
> Untested patch.

Thanks for the patch, I confirm it works as expected, now the result is a
positive 0 when using -frounding-math.

[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #18 from Aurelien Jarno  ---
(In reply to Andreas Schwab from comment #17)
> I don't think you need -fno-omit-frame-pointer.

I confirm that CRTSTUFF_T_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables is enough to fix the issue.

[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #15 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #14)
> Created attachment 55614 [details]
> patch for someone to test out
> 
> The problem is the similar across many targets so I basically copied what
> was done for another target.

Thanks for the patch, unfortunately it doesn't work as is. However, as commit
3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 enabled both
-fno-asynchronous-unwind-tables and -fno-unwind-tables, I have tried to add
-fno-unwind-tables to riscv/t-crtstuff and that works.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #12 from Aurelien Jarno  ---
Backtrace with debug symbols in libgcc_eh.a:

Program received signal SIGSEGV, Segmentation fault.
classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/unwind-dw2-fde.c:727
727 ../../../gcc/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt full
#0  classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/unwind-dw2-fde.c:727
last_cie = 0x8a43a
count = 1
encoding = 0
base = 0
#1  0x0005277c in __register_frame_info_bases (dbase=0x0, tbase=0x0,
ob=0xe2da0 , begin=) at
../../../gcc/libgcc/unwind-dw2-fde.c:129
range = {4294854026, 4294854042}
range = 
#2  __register_frame_info_bases (dbase=0x0, tbase=0x0, ob=0xe2da0 ,
begin=) at ../../../gcc/libgcc/unwind-dw2-fde.c:109
range = 
range = 
#3  __register_frame_info (begin=, ob=0xe2da0 ) at
../../../gcc/libgcc/unwind-dw2-fde.c:145
No locals.
#4  0x00010728 in frame_dummy ()
No symbol table info available.
#5  0x00010a2a in call_init (envp=0x3ff3d0, argv=0x3ff3b8,
argc=2) at libc-start.c:189
i = 0
size = 
size = 
size = 
i = 
i = 
#6  __libc_start_main_impl (main=0x105f8 , argc=2, argv=0x3ff3b8,
init=, fini=, rtld_fini=,
stack_end=)
at libc-start.c:355
ev = 0x3ff3d0
auxvec = 
stack_chk_guard = 
pointer_chk_guard = 
#7  0x00010638 in _start () at ../sysdeps/riscv/start.S:61

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #11 from Aurelien Jarno  ---
I have bisected the issue, and I found it has been introduced by the following
commit:

commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8
Author: Andreas Schwab 
Date:   Wed Jan 25 12:00:09 2023 +0100

riscv: Enable -fasynchronous-unwind-tables by default on Linux

This follows the example of aarch64.

gcc/:
* common/config/riscv/riscv-common.cc
(riscv_option_optimization_table)
[TARGET_DEFAULT_ASYNC_UNWIND_TABLES]: Enable
-fasynchronous-unwind-tables and -funwind-tables.
* config.gcc (riscv*-*-linux*): Define
TARGET_DEFAULT_ASYNC_UNWIND_TABLES.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Aurelien Jarno from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
> 
> Yep, I'll do that, but it will probably take some time to get the results.
>

I built a cross-compiler so it went faster than expected. However reverting
that commit doesn't change anything, the generated crtbeginT.o is unchanged, so
the issue is still there.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #9 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #5)
> Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?

Yep, I'll do that, but it will probably take some time to get the results.

(In reply to Andrew Pinski from comment #6)
> Also can you attach the two versions of crtbeginT.o (the one from GCC 12 and
> one from GCC 13).
> If anything there has to be some extra null pointer happening ...

I have just done that.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #8 from Aurelien Jarno  ---
Created attachment 55610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55610=edit
crtbeginT.o GCC 12 version

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #7 from Aurelien Jarno  ---
Created attachment 55609
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55609=edit
crtbeginT.o GCC 12 version

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #4 from Aurelien Jarno  ---
This is also reproducible with the tst-gmon-static test from glibc 2.38, when
compiled with GCC 13, while the test passes fine with GCC 12.

A very basic debugging shows that the problem is triggered by using crtbeginT.o
from GCC 13. The test passes when compiling everything with GCC 13, but using
crtbeginT.o from GCC 12.

The backtrace is the following:

Program received signal SIGSEGV, Segmentation fault.
0x000516e2 in classify_object_over_fdes ()
(gdb) bt
#0  0x000516e2 in classify_object_over_fdes ()
#1  0x00052690 in __register_frame_info ()
#2  0x00010570 in frame_dummy ()
#3  0x00010872 in call_init (envp=0x3ff3e0, argv=0x3ff3c8,
argc=2) at libc-start.c:189
#4  __libc_start_main_impl (main=0x10448 , argc=2, argv=0x3ff3c8,
init=, fini=, rtld_fini=,
stack_end=) at libc-start.c:355
#5  0x00010488 in _start () at ../sysdeps/riscv/start.S:61

[Bug target/110755] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #2 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #1)
> Hmm, this might be the case where you need -frounding-math since we don't
> expectly implement the pragma.

Indeed the original glibc code is compiled with -frounding-math. However adding
it or not doesn't change the resulting code.

[Bug target/110755] New: Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

Bug ID: 110755
   Summary: Wrong optimization of fabs on ppc64el at -O1
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

The following code, extracted and simplified from the PowerPC implementation of
nearbyintf() in the GNU libc is wrongly optimized at -O1 and -O2 on ppc64el
with GCC 13. The fabs is removed, while it is not the case with GCC 12

#include 
#include 
#include 

static float my_nearbyintf (float x)
{ 
  float r = x;

  if (x > 0.0)
{ 
  r += 0x1p+23;
  r -= 0x1p+23;
  r = fabs (r);
}

  return r;
}

int main()
{
volatile float in = 0.5f;

fesetround (FE_DOWNWARD);
printf("mynearbyintf(in) = %lf\n", my_nearbyintf(in));
}

This causes the result to have the wrong sign.

[Bug target/104338] RISC-V: Subword atomics result in library calls

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #18 from Aurelien Jarno  ---
Thanks Patrick for working on that and for the backport to the gcc-13 branch. I
wonder if the following patch should also be backported, as it doesn't make
sense to link with -latomic anymore with inline subword atomic operations:

commit 203f3060dd363361b172f7295f42bb6bf5ac0b3b
Author: Andreas Schwab 
Date:   Sat Apr 23 15:48:42 2022 +0200

riscv/linux: Don't add -latomic with -pthread

Now that we have support for inline subword atomic operations, it is no
longer necessary to link against libatomic.  This also fixes testsuite
failures because the framework does not properly set up the linker flags
for finding libatomic.
The use of atomic operations is also independent of the use of libpthread.

gcc/
* config/riscv/linux.h (LIB_SPEC): Don't redefine.

[Bug target/104338] RISC-V: Subword atomics result in library calls

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #10 from Aurelien Jarno  ---
I am not subscribed to the mailing list, but I am not able to see any more
mails after the v3. Any update?

[Bug debug/103874] [11 Regression] ICE in internal_error on riscv64 and -gsplit-dwarf

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #11 from Aurelien Jarno  ---
Thanks for the patch! I confirm the issue is fixed on the trunk. I also tried
to apply it on the GCC 11 branch (which is basically renaming dwarf2out.cc into
dwarf2out.c in the patch) and this also works fine.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #5 from Aurelien Jarno  ---
A bisect pointed me to that commit:

commit 4b33c5aaab9e863da162942ab8bcd54070b705af
Author: Jakub Jelinek 
Date:   Wed Mar 31 21:25:58 2021 +0200

dwarf2out: Fix up ranges for -gdwarf-5 -gsplit-dwarf [PR99490]

For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into section, not sure for what
reason exactly).
When DWARF5 support was being added, we've started using .debug_rnglists
section, added DW_AT_rnglists_base to the DW_TAG_skeleton_unit, kept
DW_AT_ranges with DW_FORM_sec_offset in the skeleton and switched
over to DW_FORM_rnglistx for DW_AT_ranges in .debug_info.dwo.
But the DWARF5 spec actually means for the ranges section (at least
everything for those DW_AT_ranges in .debug_info.dwo) to sit
in .debug_rnglists.dwo section next to the .debug_info.dwo, rather than
having consumers look it up in the binary/shared library instead.
Based on some discussions in the DWARF discuss mailing list:
   
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-March/thread.html#4765
this patch mostly follows what LLVM emits for that right now:
1) small .debug_rnglists section (when needed) just to cover the
   skeleton DW_AT_ranges (if present); the content of the section
   uses the Split DWARFy DW_RLE_* codes with addrx encodings where
   possible
2) DW_AT_ranges in the skeleton uses DW_FORM_sec_offset (difference
   from LLVM which uses DW_FORM_rnglistx, which makes it larger
   and ambiguous)
3) DW_AT_rnglists_base attribute is gone from the skeleton (again,
   unlike LLVM where it is just confusing what exactly it means because
   it is inherited; it would make sense if we emitted DW_FORM_rnglistx
   in non-split DWARF, but unless ranges are shared, I'm afraid we'd
   make DWARF larger with fewer relocations by that)
4) usually big .debug_rnglists.dwo section again with using DW_RLE_*x*
   where possible
5) DW_AT_ranges with DW_FORM_rnglistx from .debug_info.dwo referring to
   that .debug_rnglists.dwo ranges

2021-03-31  Jakub Jelinek  

PR debug/99490
* dwarf2out.c (debug_ranges_dwo_section): New variable.
(DW_RANGES_IDX_SKELETON): Define.
(struct dw_ranges): Add begin_entry and end_entry members.
(DEBUG_DWO_RNGLISTS_SECTION): Define.
(add_ranges_num): Adjust r initializer for addition of *_entry
members.
(add_ranges_by_labels): For -gsplit-dwarf and force_direct,
set idx to DW_RANGES_IDX_SKELETON.
(use_distinct_base_address_for_range): New function.
(index_rnglists): Don't set r->idx if it is equal to
DW_RANGES_IDX_SKELETON.  Initialize r->begin_entry and
r->end_entry for -gsplit-dwarf if those will be needed by
output_rnglists.
(output_rnglists): Add DWO argument.  If true, switch to
debug_ranges_dwo_section rather than debug_ranges_section.
Adjust l1/l2 label indexes.  Only output the offset table when
dwo is true and don't include in there the skeleton range
entry if present.  For -gsplit-dwarf, skip ranges that belong
to the other rnglists section.  Change return type from void
to bool and return true if there are any range entries for
the other section.  For dwarf_split_debug_info use
DW_RLE_startx_endx, DW_RLE_startx_length and DW_RLE_base_addressx
entries instead of DW_RLE_start_end, DW_RLE_start_length and
DW_RLE_base_address.  Use use_distinct_base_address_for_range.
(init_sections_and_labels): Initialize debug_ranges_dwo_section
if -gsplit-dwarf and DWARF >= 5.  Adjust ranges_section_label
and range_base_label indexes.
(dwarf2out_finish): Call index_rnglists earlier before finalizing
.debug_addr.  Never emit DW_AT_rnglists_base attribute.  For
-gsplit-dwarf and DWARF >= 5 call output_rnglists up to twice
with different dwo arguments.
(dwarf2out_c_finalize): Clear debug_ranges_dwo_section.

 gcc/dwarf2out.c | 255 ++--
 1 file changed, 211 insertions(+), 44 deletions(-)

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #4 from Aurelien Jarno  ---
This is a better backtrace after building a riscv64 cross compiler from the
releases/gcc-11 branch:

/tmp/onnxifi_loader.c.i:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xadad0f crash_signal
/home/aurel32/git/gcc/gcc/toplev.c:327
0x76ef21 output_rnglists
/home/aurel32/git/gcc/gcc/dwarf2out.c:12174
0x7b7782 dwarf2out_finish
/home/aurel32/git/gcc/gcc/dwarf2out.c:32058
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #3 from Aurelien Jarno  ---
I have been able to reduce the reproducer code to almost nothing, so I guess
the issue is mostly related to the options and not to the source code.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

  Attachment #52099|0   |1
is obsolete||

--- Comment #2 from Aurelien Jarno  ---
Created attachment 52100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52100=edit
Minimal reproducer

[Bug c/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #1 from Aurelien Jarno  ---
Sorry I submitted the bug by mistake without filling a comment.

pytorch failed to build in Debian on riscv64 following the switch to GCC 11 by
default:
https://buildd.debian.org/status/fetch.php?pkg=pytorch=riscv64=1.8.1-2%2Bb3=1640951671=0

I have extracted a reproducer (attached), here are the output with GCC 10, 11
and 12:

aurel32@beaglev:~/pytorch$ gcc-10 -v
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/10/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.3.0-13'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libsanitizer
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 2027 (Debian 10.3.0-13)
aurel32@beaglev:~/pytorch$ /usr/bin/gcc-10 -gsplit-dwarf -O2 -g -fPIC -std=c90
-c ./onnxifi_loader.c.i
aurel32@beaglev:~/pytorch$


aurel32@beaglev:~/pytorch$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/11/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-13)   
(sid-riscv64)aurel32@beaglev:~/pytorch$ /usr/bin/gcc-11 -gsplit-dwarf -O2 -g
-fPIC -std=c90 -c ./onnxifi_loader.c.i
/home/aurel32/pytorch/pytorch-1.8.1/debian/foxi/foxi/onnxifi_loader.c:212:1:
internal compiler error: Segmentation fault
  212 | }
  | ^
0xa26915 internal_error(char const*, ...)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
aurel32@beaglev:~/pytorch$


aurel32@beaglev:~/pytorch$ gcc-12 -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/12/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12-20211217-1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211217 (experimental) [master r12-6027-g774269aa4b9]
(Debian 12-20211217-1)

[Bug c/103874] New: [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Bug ID: 103874
   Summary: [11/12 Regression] ICE in internal_error on riscv64
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

Created attachment 52099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52099=edit
Reproducer

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[aurelien at aurel32 dot net]

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

--- Comment #5 from Aurelien Jarno  ---
(In reply to Jim Wilson from comment #3)
> Newlib incidentally uses (x-x)/(x-x) where x is the input value, so there
> are no constants involved, and the divide does not get optimized away.  This
> still works with gcc-10.  The result is a subtract followed by a divide.

This is also what is used for acosf and asinf, that's why the problem only
appears with the double variant.

[Bug target/95115] New: [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[aurelien at aurel32 dot net]

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

Bug ID: 95115
   Summary: [10 Regression] RISC-V 64: inf/inf division optimized
out, invalid operation not raised
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: riscv64-unknown-linux-gnu
Target: riscv64-unknown-linux-gnu
 Build: riscv64-unknown-linux-gnu

Created attachment 48525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48525=edit
Testcase

On 64-bit RISC-V, the acos/asin tests from the glibc testsuite fails when it is
built with GCC 10, as the invalid operation flag is not raised for invalid
input values. The glibc code uses the following code to generate a NaN and
raise an invalid input [1]:

  else {
u.i[HIGH_HALF]=0x7ff0;
v.i[HIGH_HALF]=0x7ff0;
u.i[LOW_HALF]=0;
v.i[LOW_HALF]=0;
return u.x/v.x;
  }

With GCC 9, this results in the following code:
li  a1,2047
sllia1,a1,52
fmv.d.x fa5,a1
li  a0,16
fdiv.d  fs0,fa5,fa5

With GCC 10, the division is optimized out and the result is directly loaded as
a constant, causing the invalid operation not to be raised.

I have attached a small testcase to reproduce the issue.

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #10 from Aurelien Jarno  ---
Thanks!

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
Thanks a lot for the fix. Would it be possible to backport it to the GCC 9
branch? Note that it requires backporting r273174 first.

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #5 from Aurelien Jarno  ---
(In reply to Dragan Mladjenovic from comment #4)
> Hi,
> 
> This fix is propbably nothing more than:

Thanks for the fix. I have just tried it and I confirm it fixes the issue. Note
that when backporting it to the 9 branch, it might be a good idea to also
backport r273174.

[Bug target/91769] [9 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
This is the change introduced by the commit:

--- gnuplot-testcase.s.r269878
+++ gnuplot-testcase.s.r269880
@@ -73,8 +73,7 @@
lw  $3,12($3)
.loc 1 37 15 view $LVU16
ldc1$f2,64($sp)
-   mtc1$2,$f0
-   mtc1$3,$f1
+   ldc1$f0,8($3)
c.le.d  $fcc5,$f0,$f2
bc1t$fcc5,$L28
mov.d   $f0,$f2

[Bug target/91769] [9 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
I have just done a build of trunk (r275723) and I confirm the bug is still
reproducible.

[Bug target/91769] [9 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||law at redhat dot com,
   ||paul.hua.gm at gmail dot com

--- Comment #1 from Aurelien Jarno  ---
This has started with r269880. Adding Jeff Law and Chenghua Xu to the CC list
has they have touch that part of the code recently.

[Bug target/91769] New: [9 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

Bug ID: 91769
   Summary: [9 regression] wrong code with -O2 on MIPS
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-unknown-linux-gnu
Target: mipsel-unknown-linux-gnu
 Build: mipsel-unknown-linux-gnu

Created attachment 46881
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46881=edit
Testcase

GCC 9.2 generates wrong code for the attached testcase file (extracted from
gnuplot and simplified) when compiled with -O2 -march=mips32r2. This doesn't
happen at -O1 level. This also doesn't happen with GCC 8.3. This is however
reproducible with a snapshot of trunk from 2019-08-28.

Here is the relevant part of the generated assembly code:
   0x00400780 <+80>:lw  v0,8(v1)
   0x00400784 <+84>:lw  v1,12(v1)

Here v1 is clobbered

   0x00400788 <+88>:ldc1$f2,64(sp)
=> 0x0040078c <+92>:ldc1$f0,8(v1)

So it crashes when the double value is loaded from the array.

[Bug d/91628] New: libdruntime uses glibc internal symbol on s390

[aurelien at aurel32 dot net]

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

Bug ID: 91628
   Summary: libdruntime uses glibc internal symbol on s390
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: aurelien at aurel32 dot net
CC: ibuclaw at gcc dot gnu.org
  Target Milestone: ---
  Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
 Build: s390x-ibm-linux-gnu

libdruntime on s390 uses a GNU libc internal symbol: __tls_get_addr_internal.
Things might break if the symbol is changed on the GNU libc side.

[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Zack Weinberg from comment #5)
> The C standard doesn't say malloc _will_ set errno on failure, but it also

Well at least POSIX says:

Otherwise, it shall return a null pointer and set errno to indicate the error. 

> doesn't say it _won't_, and all library functions are allowed to clobber the
> value of errno unless it is specifically documented that they won't (N1570
> 7.5 [Errors], para 3, last sentence).

I fully agree with that.

[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #1)
> IIRC malloc setting errno also non standard.

According to POSIX:

The malloc() function shall fail if:

[ENOMEM]
[CX] [Option Start] Insufficient storage space is available. [Option
End]

In that case malloc returns a NULL pointer. However even after adding a check
for the return value, GCC still optimizes-out saving and restoring errno.

[Bug c/88576] New: -fno-math-errno causes GCC to consider that malloc does not set errno

[aurelien at aurel32 dot net]

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

Bug ID: 88576
   Summary: -fno-math-errno causes GCC to consider that malloc
does not set errno
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

With the -fno-math-errno option, GCC optimizes-out saving and restoring errno
around a malloc call. Here is a testcase, derived from the GNU libc
string/strerror.c, to reproduce it:


typedef long unsigned int size_t;

extern char *__strerror_r (int __errnum, char *__buf, size_t __buflen);

extern void *malloc (size_t __size) __attribute__ ((__nothrow__)) __attribute__
((__malloc__));

extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec")));

static char *buf;

char *strerror (int errnum)
{
  int saved_errno;
  saved_errno = __libc_errno;
  buf = malloc (1024);
  (__libc_errno = (saved_errno));
  return __strerror_r (errnum, buf, 1024);
}


Compile with: gcc -fmath-errno -Wall -O2 -fPIC -S -c strerror.i

Without -fno-math-errno, we can see in the output assembly code that errno is
saved around the malloc call:

strerror:
.LFB0:
.cfi_startproc
pushq   %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq   %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
movl%edi, %ebp
movl$1024, %edi
pushq   %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
movq__libc_errno@gottpoff(%rip), %rbx
movl%fs:(%rbx), %r12d
callmalloc@PLT
movl%ebp, %edi
movl$1024, %edx
movl%r12d, %fs:(%rbx)
movq%rax, %rsi
popq%rbx
.cfi_def_cfa_offset 24
popq%rbp
.cfi_def_cfa_offset 16
popq%r12
.cfi_def_cfa_offset 8
jmp __strerror_r@PLT
.cfi_endproc


With -fno-math-errno, saving and restoring errno is optimized out:

strerror:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl%edi, %ebx
movl$1024, %edi
callmalloc@PLT
movl%ebx, %edi
movl$1024, %edx
popq%rbx
.cfi_def_cfa_offset 8
movq%rax, %rsi
jmp __strerror_r@PLT
.cfi_endproc


This is reproducible with 6.5, 7.4, 8.2 and a snapshot of trunk from
2018-12-17.

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Aurelien Jarno  ---
(In reply to Jim Wilson from comment #8)
> (In reply to Aurelien Jarno from comment #7)
> > Should I just close this bug and open a new one on the glibc side?
> 
> That is fine if you want to do that.

As this actually a GNU libc bug, I have opened the following bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=23125

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Jim Wilson from comment #3)
Thanks a lot Jim for finding out the issue without using gdb, that was quite a
challenge.

(In reply to Jim Wilson from comment #6)
> I suggest you handle the glibc patch.

Should I just close this bug and open a new one on the glibc side?

> Note that you can probably also fix this by adding unwind direcives to
> _start to say that the return address is in x0.  This would avoid the minor
> code size increase, but takes a little more effort to figure out how to add
> the right unwind directives to assembly code to make this work.  I haven't
> tried that.

I think this should be done with the cfi_undefined directive, like in the patch
below:

--- a/sysdeps/riscv/start.S
+++ b/sysdeps/riscv/start.S
@@ -43,6 +43,8 @@
__libc_start_main wants this in a5.  */

 ENTRY (ENTRY_POINT)
+   /* Mark ra as undefined in order to stop unwinding here!  */
+   cfi_undefined (ra)
call  .Lload_gp
mva5, a0  /* rtld_fini.  */
/* main may be in a shared library.  */

[Bug target/85492] New: riscv64: endless when throwing an exception from a constructor

[aurelien at aurel32 dot net]

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

Bug ID: 85492
   Summary: riscv64: endless when throwing an exception from a
constructor
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

Created attachment 44002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44002=edit
test case

The attached C++ code, extracted from googletest, tries to throw an exception
from a constructor. On riscv64, the processes goes into an endless loop using
100% of the CPU instead. This is reproducible even at -O0, with GCC 7.3.0 and
GCC 8 snapshot from 20180414, under both QEMU and real hardware (SiFive
Unleashed).

[Bug target/84475] pthread doesn't define _REENTRANT in preprocessor on riscv-linux

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #4 from Aurelien Jarno  ---
(In reply to Jonathan Wakely from comment #1)
> Does it need to define it?

Some software, like libmicrohttpd, check in there configure script if
_REENTRANT is correctly defined. This might be wrong, but I guess riscv-linux
should just behave like other platforms.

Could someone with commit rights please backport this to the gcc 7 branch?

[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[aurelien at aurel32 dot net]

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

--- Comment #12 from Aurelien Jarno  ---
(In reply to Richard Biener from comment #11)
> Fixed.

Thanks!

[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[aurelien at aurel32 dot net]

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

--- Comment #8 from Aurelien Jarno  ---
(In reply to Richard Biener from comment #7)
> Patch has been applied to our GCC 7 with no issues sofar (but fixing the
> reported issues).

Given all is fine with this patch, do you think it can be backported to the GCC
7 branch?

[Bug target/81803] Miscompilation at -O1 on mips64el

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
(In reply to James Cowgill from comment #1)
> Here's another testcase which is reduced a bit further using creduce. It
> requires -O2 to trigger the bug (but that may be unrelated).

I reported it as a miscompilation with -O1, as at least in the clamav case, the
bug is not reproducible with -O0, but is reproducible with both -O1 and -O2.
But it seems this bug is quite dependent on the surrounding code, so my guess
is that the issue is not triggered by a specific optimization.

[Bug target/81803] New: Miscompilation at -O1 on mips64el

[aurelien at aurel32 dot net]

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

Bug ID: 81803
   Summary: Miscompilation at -O1 on mips64el
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mips64el-unknown-linux-gnu
Target: mips64el-unknown-linux-gnu
 Build: mips64el-unknown-linux-gnu

Created attachment 41965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41965=edit
testcase

Since the switch to GCC 7 as the default compiler, Debian sees many
miscompilations on mips64el where variables which are stored on the stack and
smaller than 8 bytes long (e.g. uint16_t, bool) are wrongly reloaded with the
LD instruction.

I unfortunately haven't been able to get a self-contained reduced testcase, but
the attached testcase (from apparmor) should show the issue.

The aa_policy_cache_new function takes a uint16_t as the fourth argument. It
gets passed the max_caches, which also has a uint16_t type. When compiled with
g++  -Wfatal-errors -g -O2 -fstack-protector-strong -c -o testcase.o
testcase.ii the generated code contains:

 164:   dea5ld  a1,0(s5)
164: R_MIPS_GOT_OFST.bss+0x38
164: R_MIPS_NONE*ABS*+0x38
164: R_MIPS_NONE*ABS*+0x38
 168:   dfa8ld  a4,0(sp)
 16c:   2406ff9cli  a2,-100
 170:   0320f809jalrt9
170: R_MIPS_JALRaa_policy_cache_new
170: R_MIPS_NONE*ABS*


As you can see, a4 is loaded with the LD instruction, so the upper bytes are
just garbage and causes the aa_policy_cache_new to not function correctly.

[Bug other/79030] Compilation failure due to virtual memory exhaustion

[aurelien at aurel32 dot net]

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

--- Comment #1 from Aurelien Jarno  ---
Created attachment 40480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40480=edit
Testcase

[Bug other/79030] New: Compilation failure due to virtual memory exhaustion

[aurelien at aurel32 dot net]

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

Bug ID: 79030
   Summary: Compilation failure due to virtual memory exhaustion
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-linux-gnu
Target: mipsel-linux-gnu
 Build: mipsel-linux-gnu

The attached testcase fails to compile on a 32-bit MIPS machine due to virtual
memory exhaustion. The machine has plenty of available memory, but the virtual
address space is limited to 2GB:

$ g++ -O2 -fno-var-tracking-assignments -g -c ceph_dencoder.ii
cc1plus: out of memory allocating 3195232 bytes after a total of 32043008 bytes
$

However it compiles successfully when tunning ggc-min-expand:
$ g++ -O2 -fno-var-tracking-assignments -g -c ceph_dencoder.ii --param
ggc-min-expand=5
$

[Bug other/78971] ggc-min-expand default value is probably obsolete

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #1)
> Actually it would be better if we reduce the need to allocate as much memory.
> 
> >In 2017 it's quite common to have a machine with 1GB of RAM.
> 
> Actually is is quite common to have a machine with more than 32G of memory
> especially servers.

Yes, exactly my point. It means the heuristic now almost always uses the same
value, that is 100%.


> But really ggc-min-expand is not the problem rather the amount of GC memory
> being allocated.

Ok. I'll do that.

[Bug other/78971] New: ggc-min-expand default value is probably obsolete

[aurelien at aurel32 dot net]

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

Bug ID: 78971
   Summary: ggc-min-expand default value is probably obsolete
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

According to the manpage (and to the code) the default ggc-min-expand value
defaults to: "30% + 70% * (RAM/1GB) with an upper bound of 100% when RAM >=
1GB."

In 2017 it's quite common to have a machine with 1GB of RAM, especially on a
machine used to compile code. For example both the Raspberry Pi 2 and 3 have
1GB of RAM. I therefore think this default should be updated.

On 32-bit machines, it's getting more and more common to get a "virtual memory
exhausted: Cannot allocate memory" error and not be able to compile some code.
This is especially true on MIPS32 as the virtual memory space is limited to
2GB. A workaround is to use --ggc-min-expand=20, which shows the default value
is not optimal.

[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
(In reply to Maciej W. Rozycki from comment #2)
> I can't reproduce your problem with either test case and:
> 
> mips-mti-linux-gnu-gcc (GCC) 7.0.0 20161117 (experimental)
> 
> -- code produced assembles correctly and visual inspection of the
> assembly reveals no odd-numbered FGR operands throughout.
> 
> Would you therefore please reconfirm this issue still triggers with
> current HEAD, and if so, then report the details of your compilation as
> shown with the `-v' flag added to your invocation line?

Sorry about that. I think the trick there is that Debian defaults to mips32r2.
Indeed, I am not able to reproduce the problem with -march=mips32. I have tried
again, I am still able to reproduce the issue for both testcases when using GCC
6.2.1, but only with the non-reduced testcase when using GCC trunk (through I
used the one in Debian, so a slightly older version than you from 20161106).
Here is the output with the -v flag added:

$ gcc -mfpxx -O2 -c fun-p86c.i -v
Using built-in specs.
COLLECT_GCC=gcc
Target: mips-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20161106-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot
--program-prefix= --enable-
shared --enable-linker-build-id --disable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disa
ble-libquadmath --enable-plugin --enable-default-pie --with-system-zlib
--enable-multiarch --enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx
--enable-targets=all --with-arch-64=mips64r2 --disable-werror
--enable-checking=yes --build=mi
ps-linux-gnu --host=mips-linux-gnu --target=mips-linux-gnu
Thread model: posix
gcc version 7.0.0 20161106 (experimental) [trunk revision 241885] (Debian
20161106-1)
COLLECT_GCC_OPTIONS='-mfpxx' '-O2' '-c' '-v' '-march=mips32r2' '-mllsc'
'-mips32r2' '-EB' '-mabi=32'
 /usr/lib/gcc-snapshot/libexec/gcc/mips-linux-gnu/7.0.0/cc1 -fpreprocessed
fun-p86c.i -meb -quiet -dumpbase fun-p86c.i -mfpxx -march=mips32r2 -mllsc
-mips32r2 -mabi=32 -auxbase fun-p86c -O2 -version -o /tmp/ccbT7qjh.s
GNU C11 (Debian 20161106-1) version 7.0.0 20161106 (experimental) [trunk
revision 241885] (mips-linux-gnu)
compiled by GNU C version 7.0.0 20161106 (experimental) [trunk revision
241885], GMP version 6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (Debian 20161106-1) version 7.0.0 20161106 (experimental) [trunk
revision 241885] (mips-linux-gnu)
compiled by GNU C version 7.0.0 20161106 (experimental) [trunk revision
241885], GMP version 6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b5d3035afeb69ed786f0bd6e5bf73e96
COLLECT_GCC_OPTIONS='-mfpxx' '-O2' '-c' '-v' '-march=mips32r2' '-mllsc'
'-mips32r2' '-EB' '-mabi=32'
 as -v -EB -mips32r2 -O2 -no-mdebug -mabi=32 -march=mips32r2 -mfpxx -KPIC -o
fun-p86c.o /tmp/ccbT7qjh.s
GNU assembler version 2.27.51 (mips-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.27.51.20161118
/tmp/ccbT7qjh.s: Assembler messages:
/tmp/ccbT7qjh.s:1859: Error: float register should be even, was 15
/tmp/ccbT7qjh.s:2567: Error: float register should be even, was 15

[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #1 from Aurelien Jarno  ---
Created attachment 39824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39824=edit
Reduced testcase

[Bug target/78012] New: -mfpxx produces assembly code using odd FP registers on MIPS

[aurelien at aurel32 dot net]

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

Bug ID: 78012
   Summary: -mfpxx produces assembly code using odd FP registers
on MIPS
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-linux-gnu
Target: mipsel-linux-gnu
 Build: mipsel-linux-gnu

Created attachment 39823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39823=edit
Original testcase

The attached testcase (taken from the ergo software [1]) produces assembly code
with odd FP registers when using the FPxx abi.

$ gcc -mfpxx -O2 -c fun-p86c.i
/tmp/ccpv3phk.s: Assembler messages:
/tmp/ccpv3phk.s:1883: Error: float register should be even, was 15
/tmp/ccpv3phk.s:2586: Error: float register should be even, was 15

I have also attached a reduced version of the testcase, that said it also
outputs a lot of warnings about uninitialized variables.

[1] http://ergoscf.org/

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #1 from Aurelien Jarno  ---
I have tried to identified when this behavior has been introduced. It appears
that even GCC 4.9 is producing similar code. However what cause ld to reject it
is the following change in the assembly code:

-   .text
+   .section   
.text._ZN1HIiE5m_fn4ERK1G.isra.1,"axG",@progbits,_ZN1HIiE5m_fn5ERK1G,comdat

It seems the optimization is somehow correct when all the code is in the same
section, but that's no the case anymore when it is in multiple sections.

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #10 from Aurelien Jarno  ---
I have just posted a new version of the patch:

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01198.html

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #9 from Aurelien Jarno  ---
(In reply to ramana.radhakrishnan from comment #8)
> On 14/07/16 12:15, aurelien at aurel32 dot net wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833
> > 
> > --- Comment #7 from Aurelien Jarno  ---
> > (In reply to Ramana Radhakrishnan from comment #6)
> >> (In reply to Aurelien Jarno from comment #5)
> >>> (In reply to Ramana Radhakrishnan from comment #4)
> >>>> Need to apply Aurelien's patch - looks like that's slipped through the
> >>>> cracks.
> >>>
> >>> What was missing to the patch was a testcase which compiles on all 
> >>> platform.
> >>> This has happened recently, as part of the testcase for PR61441. I 
> >>> therefore
> >>> guess this patch can now be applied.
> >>
> >> Do you mind pinging it after another round of testing ? 
> >>
> > 
> > I have just done a another round on testing on trunk:
> > - The patch is still necessary.
> > - The patch still applies, but with fuzz. I'll resend an update patch.
> > - The patch still works as expected.
> > - The testcase for PR61441 does not seems to work for this bug as it is
> > compiled with -O1. GCC 6 does constant propagation and the resulting binary 
> > do
> > not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his 
> > bug.
> > Is there a way to specify that a test should run with both -O0 and -O1? That
> > would avoid writing an almost identical testcase.
> 
> An option might be to move the test into gcc.c-torture/execute and then it
> will torture over all optimization levels and add the option needed with
> dg-additional-options ?

Ok, in that case, i'll add a patch specific for this bug. I am currently doing
a test rebuild, I'll send a new version of the patch in the next days.

Aurelien

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Ramana Radhakrishnan from comment #6)
> (In reply to Aurelien Jarno from comment #5)
> > (In reply to Ramana Radhakrishnan from comment #4)
> > > Need to apply Aurelien's patch - looks like that's slipped through the
> > > cracks.
> > 
> > What was missing to the patch was a testcase which compiles on all platform.
> > This has happened recently, as part of the testcase for PR61441. I therefore
> > guess this patch can now be applied.
> 
> Do you mind pinging it after another round of testing ? 
> 

I have just done a another round on testing on trunk:
- The patch is still necessary.
- The patch still applies, but with fuzz. I'll resend an update patch.
- The patch still works as expected.
- The testcase for PR61441 does not seems to work for this bug as it is
compiled with -O1. GCC 6 does constant propagation and the resulting binary do
not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his bug.
Is there a way to specify that a test should run with both -O0 and -O1? That
would avoid writing an almost identical testcase.

Aurelien

[Bug middle-end/71155] New: symbol in wrong section .data.rel.local on mips64el

[aurelien at aurel32 dot net]

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

Bug ID: 71155
   Summary: symbol in wrong section .data.rel.local on mips64el
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mips64el-linux-gnuabi64
Target: mips64el-linux-gnuabi64
 Build: mips64el-linux-gnuabi64

Created attachment 38503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38503=edit
preprocessed source file

When compiling the GNU libc on mips64el-linux-gnuabi64 with GCC >= 4.9, the
resulting libc causes lua 5.2 to not work correcty. It happens this is due to
wrong the compilation of libio/oldstdfiles.c. When using GCC <= 4.8, the
_IO_stdin_ symbol ends up in the data.rel section just like _IO_stdout_ and
_IO_stderr_. When using GCC >= 4.9, the _IO_stdin_ symbol is moved to the
.data.rel.local section, while the two others are unchanged.

This is also reproducible with GCC 5 and GCC 6.

The issue seems to have been introduced by the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01169.html

I have attached the preprocessed source file, the original source file can be
found there:
https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/oldstdfiles.c;h=609b7d9ef2d78f851a29b3d25efbb03f9c76ca91;hb=HEAD

[Bug target/68273] [5/6/7 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[aurelien at aurel32 dot net]

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

--- Comment #33 from Aurelien Jarno  ---
(In reply to Hector Oron from comment #32)
> (In reply to Richard Biener from comment #31)
> > eipa_sra introduces the remaining SSA name with non-default alignment via
> 
> [PATCH]
> 

For the record, Debian now have the patch from comment #32 in its version of
GCC 5 and 6. This fixes a few more issues than reported here, in addition to
graphviz, it also fixes subversion and jq.

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[aurelien at aurel32 dot net]

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

--- Comment #29 from Aurelien Jarno  ---
(In reply to Richard Biener from comment #25)
> Re-adding GCC 6 as regression, though graphviz is not gsoap.

Indeed the patch that has been committed (or the same one backported to the GCC
5 branch) correctly fixes the gsoap issue. It doesn't fixes the graphviz one,
that said while the issue looks similar it might actually be a different one.

[Bug debug/67355] [5 Regression] ICE compiling LTP testcase, endless cselib recursion from var-tracking

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #12 from Aurelien Jarno  ---
*** Bug 68302 has been marked as a duplicate of this bug. ***

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #21 from Aurelien Jarno  ---
(In reply to Steve Ellcey from comment #20)
> I have still not been able to reproduce this or understand what is happening.
> 
> Aurelien, could you try applying the patch that has been submitted for PR
> 69129
> to see if that helps?  The failure modes for this bug and 69129 don't look
> the same but I think both may be related to uninitialized memory usage and I
> can't reproduce either one so I am hoping maybe they have the same root
> cause.
> 
> Patch for PR 69129:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01407.html

It happens I am not able to reproduce the problem given the problem has been
fixed in the meantime. It is actually the same bug than PR67355.

Sorry for not noticing that earlier, and thanks for your help debugging this
issue.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #22 from Aurelien Jarno  ---
This bug is a duplicate of PR67355

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

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #5 from Aurelien Jarno  ---
(In reply to Ramana Radhakrishnan from comment #4)
> Need to apply Aurelien's patch - looks like that's slipped through the
> cracks.

What was missing to the patch was a testcase which compiles on all platform.
This has happened recently, as part of the testcase for PR61441. I therefore
guess this patch can now be applied.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #19 from Aurelien Jarno  ---
Please find below the output produced by gcc when compiling with -v

Reading specs from /home/aurel32/work/mips-gcc/build/./gcc/specs
COLLECT_GCC=/home/aurel32/work/mips-gcc/build/./gcc/xgcc
Target: mipsel-linux-gnu
Configured with: /home/aurel32/git/gcc/configure --enable-languages=c
--prefix=/usr --target=mipsel-linux-gnu
--includedir=/usr/mipsel-linux-gnu/include
Thread model: posix
gcc version 5.3.1 20151221 (GCC)
COLLECT_GCC_OPTIONS='-v' '-B' '/home/aurel32/work/mips-gcc/build/./gcc/' '-O2'
'-g' '-o' 'test.o' '-c' '-march=mips32r2' '-mllsc' '-mips32r2' '-mno-shared'
'-EL' '-mabi=32'
 /home/aurel32/work/mips-gcc/build/./gcc/cc1 -quiet -v -iprefix
/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/
-isystem /home/aurel32/work/mips-gcc/build/./gcc/include -isystem
/home/aurel32/work/mips-gcc/build/./gcc/include-fixed test.c -mel -quiet
-dumpbase test.c -march=mips32r2 -mllsc -mips32r2 -mno-shared -mabi=32
-auxbase-strip test.o -g -O2 -version -o /tmp/cc4pCfly.s
GNU C11 (GCC) version 5.3.1 20151221 (mipsel-linux-gnu)
compiled by GNU C version 5.3.1 20151207, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/include-fixed"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/include-fixed"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/aurel32/work/mips-gcc/build/./gcc/include
 /home/aurel32/work/mips-gcc/build/./gcc/include-fixed
End of search list.
GNU C11 (GCC) version 5.3.1 20151221 (mipsel-linux-gnu)
compiled by GNU C version 5.3.1 20151207, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e3226672ebc300cae5ef5d0d012ad534

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #17 from Aurelien Jarno  ---
Created attachment 37098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37098=edit
output log with cselib.c patched

Please find attached the output with your cselib.c patch. Sorry for the delay.

If you want I can also try to setup a virtual machine image that can be used to
reproduce the problem.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #14 from Aurelien Jarno  ---
Created attachment 36970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36970=edit
Output log 2

Unfortunately it still fails, though the output log is now slightly different.
Please find it attached.

I have also tried to build this mipsel cross gcc using gcc 4.9 as the base
compiler, but it doesn't change the result.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #12 from Aurelien Jarno  ---
Created attachment 36965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36965=edit
Output log

Please find attached the output log of gcc running patched as you requested.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Steve Ellcey from comment #8)
> Where in CC1 do you segfault?  Can you show me the error message you get
> when compiling the test program using the latest gcc-5-branch sources.

The only message I got when compiling it is the following:

xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

If I try to run cc1 with gdb, I get the following backtrace:

#0  0x0063cc5f in rtx_equal_for_cselib_1 (x=0x768a0480,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:866
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#1  0x0063cd72 in rtx_equal_for_cselib_1 (x=,
y=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:907
t = 
l = 0x15deb28
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#2  0x0063d1d9 in rtx_equal_for_cselib_1 (x=x@entry=0x769c7738,
y=0x769c7720, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1023
j = 
code = 
fmt = 
i = 1
__FUNCTION__ = "rtx_equal_for_cselib_1"
#3  0x0063cdda in rtx_equal_for_cselib_1 (x=0x769c7738,
y=0x15de2b8, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:924
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#4  0x0063d002 in rtx_equal_for_cselib_1 (x=0x769c7720,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#5  0x0063cd72 in rtx_equal_for_cselib_1 (x=,
y=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:907
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#6  0x0063d002 in rtx_equal_for_cselib_1 (x=x@entry=0x769c7738,
y=0x769c7720, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#7  0x0063cdda in rtx_equal_for_cselib_1 (x=0x769c7738,
y=0x15de2b8, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:924
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#8  0x0063d002 in rtx_equal_for_cselib_1 (x=0x769c7720,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#9  0x0063cd72 in rtx_equal_for_cselib_1 (x=,
y=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:907
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#10 0x0063d002 in rtx_equal_for_cselib_1 (x=x@entry=0x769c7738,
y=0x769c7720, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#11 0x0063cdda in rtx_equal_for_cselib_1 (x=0x769c7738,
y=0x15de2b8, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:924
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#12 0x0063d002 in rtx_equal_for_cselib_1 (x=0x769c7720,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 

It continues like that probably up to stack exhaustion. It looks like two
mutually recursive functions.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
I am using gcc 5.2 from Debian unstable to build the cross compiler. Please
also note that I have the same issue when using the native GCC 5.2 compiler on
a mips or mipsel system.

How can I help debugging that? Is there any output I can provide that might
help?

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
I built GCC with the following options:

configure --enable-languages=c --prefix=/usr --target=mipsel-linux-gnu
--includedir=/usr/mipsel-linux-gnu/include 

Then I build the file with -O2  -g -o test.o -c test.c -march=mips32r2.

The ICE disappears when I don't use -g.

All that said, I am still able to reproduce the issue with the gcc-5-branch,
but not with trunk. I start to wonder if I correctly tested trunk or if the
problem has been fixed in the meantime. Anyway if it's not reproducible with
trunk, that's something that can be bisected. I'll do that.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #4 from Aurelien Jarno  ---
The bisection shows that this commit has fixed the issue on trunk:

2015-07-23  Richard Biener  

PR middle-end/66916
* match.pd: Guard widen and sign-change comparison simplification
with single_use.

That said, it just seems to be a side effect of this commit and not a fix for
the original issue.

[Bug debug/68302] New: [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

Bug ID: 68302
   Summary: [5/6 Regression] ICE with debugging enabled on mips
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-linux-gnu
Target: mipsel-linux-gnu
 Build: mipsel-linux-gnu

Created attachment 36691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36691=edit
Reduced testcase

The attached testcase, when compiled on mips with debugging enabled and with -g
-O2 -march=mips32r2 causes an internal compiler error: Segmentation fault
(program cc1). Removing one of this three options causes the issue to
disappear.

The problem appears on both  gcc-5-branch and trunk from today. It can be
reproduced with a native compiler or a cross-compiler targeting mips or mipsel.

[Bug ipa/68273] New: Wrong code on mips/mipsel with -fno-ipa-sra

[aurelien at aurel32 dot net]

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

Bug ID: 68273
   Summary: Wrong code on mips/mipsel with -fno-ipa-sra
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-linux-gnu
Target: mipsel-linux-gnu
 Build: mipsel-linux-gnu

Created attachment 36676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36676=edit
preprocessed source

gsoap version 2.8.22 does not compile correctly on mips and mipsel with GCC
5.2.1 or trunk, while it compiles correctly on GCC 4.9. The resulting binary
segfaults.

A bit of analysis shows this is due to wrong code optimization at -O2 level,
and more specifically with the  -fipa-sra option, which calls functions with
arguments in the wrong register.

I have not been able to get a simple testcase yet, but it is possible to
reproduce the issue with the attached preprocessed code. The problem occurs in
this function:

  case 34:
# 436 "soapcpp2_yacc.y"
{ if ((yyvsp[-1].rec).sto & Stypedef)
 { sprintf(errbuf, "invalid typedef qualifier for '%s'",
(yyvsp[0].sym)->name);
semwarn(errbuf);
 }
 printf("%p\n", (yyvsp[0].sym));
 p = enter(sp->table, (yyvsp[0].sym));
 p->info.typ = (yyvsp[-1].rec).typ;
 p->info.sto = (yyvsp[-1].rec).sto;
 p->info.hasval = False;
 p->info.offset = sp->offset;
 if (sp->grow)
sp->offset += p->info.typ->width;
 else if (p->info.typ->width > sp->offset)
sp->offset = p->info.typ->width;
 sp->entry = p;
   }
# 2290 "soapcpp2_yacc.c"
break;

When compiled with -O2, GCC outputs the following corresponding code:

$L380:  
lw  $25,%call16(__printf_chk)($28)
lw  $21,%got(sp)($28)
lui $5,%hi($LC37)
move$6,$7
addiu   $5,$5,%lo($LC37)
sw  $7,13452($sp)
.reloc  1f,R_MIPS_JALR,__printf_chk
1:  jalr$25
li  $4,1# 0x1

lw  $28,88($sp)
lw  $2,0($21)
lw  $7,13452($sp)
lw  $4,0($2)
lw  $25,%call16(enter)($28)
nop
.reloc  1f,R_MIPS_JALR,enter
1:  jalr$25
move$6,$7

Note how the second argument is loaded in $6 (ie a2) instead of $5 (ie a1) when
calling enter.

When compiled with -O2 -fno-ipa-sra the correct register is used:

-O2 -fno-ipa-sra

$L387:  
lw  $25,%call16(__printf_chk)($28)
lw  $21,%got(sp)($28)
lui $5,%hi($LC37)
move$6,$7
sw  $7,13500($sp)
addiu   $5,$5,%lo($LC37)
.reloc  1f,R_MIPS_JALR,__printf_chk
1:  jalr$25
li  $4,1# 0x1

lw  $28,136($sp)
lw  $2,0($21)
lw  $7,13500($sp)
lw  $4,0($2)
lw  $25,%call16(enter)($28)
nop
.reloc  1f,R_MIPS_JALR,enter
1:  jalr$25
move$5,$7

However it is first loaded to $7 for no obvious reason, especially this is not
a saved register, so its value is lost after the call. I am note sure it is
something related, but loading the value through this intermediate register is
due to the use of -O2, this is not the case -O1:

$L370:  
lw  $2,0($16)
nop
sw  $2,13476($sp)
move$6,$2
lui $5,%hi($LC37)
addiu   $5,$5,%lo($LC37)
li  $4,1# 0x1
lw  $25,%call16(__printf_chk)($28)
nop
.reloc  1f,R_MIPS_JALR,__printf_chk
1:  jalr$25
nop

lw  $28,136($sp)
nop
lw  $17,%got(sp)($28)
nop
lw  $2,0($17)
lw  $5,13476($sp)
lw  $4,0($2)
lw  $25,%call16(enter)($28)
nop
.reloc  1f,R_MIPS_JALR,enter
1:  jalr$25
nop

[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #11 from Aurelien Jarno  ---
For the record this bug badly affects the MIPS target when using
-mtune=mips32r2, option which is implied by the -march=mips32r2 option. This
causes for example ffmpeg to be miscompiled, which causes its testsuite to fail
completely.

It's not a problem anymore now that the bug has been fixed on the gcc-5-branch,
however I prefer to mention it here, so that people debugging this issue find
this bug.

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
The ffmpeg testsuite is successful on mips64el-linux-gnu with this patch
applied.

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
Thanks for the patch. I have just tested it, and it indeed fixes the issue from
the testcase. I am currently trying to build ffmpeg, from which the testcase
has been extracted to see if all the issues are really fixed.

[Bug target/67736] New: Wrong optimization with -fexpensive-optimizations on mips64el

[aurelien at aurel32 dot net]

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

Bug ID: 67736
   Summary: Wrong optimization with -fexpensive-optimizations on
mips64el
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mips64el-unknown-linux-gnu
Target: mips64el-unknown-linux-gnu
 Build: mips64el-unknown-linux-gnu

The following code is wrongly compiled on a mips64el target when using
-fexpensive-optimizations:

#include 
#include 

int compare(uint64_t state, uint32_t *last, uint8_t buf)
{
if (*last == ((state | buf) & 0x)) {
printf("B %"PRIx64" %"PRIx32"\n", state, *last);
return 0;
}
return 1;
}

It produces the following code:

09a0 :
 9a0:   30c200ffandiv0,a2,0xff
 9a4:   8ca6lw  a2,0(a1)
 9a8:   00441025or  v0,v0,a0
 9ac:   10460004beq v0,a2,9c0 <compare+0x20>
 9b0:   24020001li  v0,1
 9b4:   03e8jr  ra
 9b8:   nop
 9bc:   nop
...

Note how the comparison is done incorrectly, dropping the & 0x and
sign-extending the value when loading *last.

Using -fno-expensive-optimizations produces the following valid code:
09a0 :
 9a0:   30c200ffandiv0,a2,0xff
 9a4:   8ca6lw  a2,0(a1)
 9a8:   00441025or  v0,v0,a0
 9ac:   7cc3f803dextv1,a2,0x0,0x20
 9b0:   7c42f803dextv0,v0,0x0,0x20
 9b4:   10620004beq v1,v0,9c8 <compare+0x28>
 9b8:   24020001li  v0,1
 9bc:   03e8jr  ra
 9c0:   nop
 9c4:   nop
 9c8:   67bdfff0daddiu  sp

Here both values are zero extended to 32-bit before the comparison.

Alternatively, when removing the line with the printf, GCC also produces
correct code, which is more optimized:

0960 :
 960:   30c600ffandia2,a2,0xff
 964:   00c42025or  a0,a2,a0
 968:   9ca2lwu v0,0(a1)
 96c:   7c86f803dexta2,a0,0x0,0x20
 970:   00c21026xor v0,a2,v0
 974:   03e8jr  ra
 978:   0002102bsltuv0,zero,v0
 97c:   nop

Note that at least gcc 4.8.5, 4.9.3 and 5.2.1 are affected.

[Bug target/61441] New: ARM aarch64 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

Bug ID: 61441
   Summary: ARM aarch64 fails to quiet signaling NaN
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Host: aarch64-unknown-linux-gnu
Target: aarch64-unknown-linux-gnu
 Build: aarch64-unknown-linux-gnu

Consider the following code:

#define _GNU_SOURCE
#include stdio.h
#include math.h

int main (void)
{
  float sNaN = __builtin_nansf ();
  double x = (double) sNaN;
  return issignaling(x);
}

It correctly returns 0 at -O0 optimisation level, but returns 1 at -O1 and -O2
optimisation levels.

Here is the generated assembly code at -O0:
00400630 main:
  400630:   a9be7bfdstp x29, x30, [sp,#-32]!
  400634:   910003fdmov x29, sp
  400638:   18000160ldr w0, 400664 main+0x34
  40063c:   b9001fa0str w0, [x29,#28]
  400640:   b9401fa0ldr w0, [x29,#28]
  400644:   1e27fmovs0, w0
  400648:   1e22c000fcvtd0, s0
  40064c:   9e66fmovx0, d0
  400650:   f9000ba0str x0, [x29,#16]
  400654:   fd400ba0ldr d0, [x29,#16]
  400658:   978ebl  400490 __issignaling@plt
  40065c:   a8c27bfdldp x29, x30, [sp],#32
  400660:   d65f03c0ret
  400664:   7fa0.word   0x7fa0

Here is the generated assembly code at -O1:
00400630 main:
  400630:   a9bf7bfdstp x29, x30, [sp,#-16]!
  400634:   910003fdmov x29, sp
  400638:   5c80ldr d0, 400648 main+0x18
  40063c:   9795bl  400490 __issignaling@plt
  400640:   a8c17bfdldp x29, x30, [sp],#16
  400644:   d65f03c0ret
  400648:   .word   0x
  40064c:   7ff4.word   0x7ff4

As you can see at -O1, the sNaN constant is propagated, and the propagated
value is loaded and passed directly to issignaling. Quoting the IEEE Std 754
standard:
Under default exception handling, any operation signaling an invalid operation
exception and for which a floating-point result is to be delivered shall
deliver a quiet NaN.

So it looks like the copy propagation is not done correctly, the sNaN should be
silenced in the process.

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno aurelien at aurel32 dot net ---
Please note that the following patch fixes the issue:

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01421.html

[Bug target/61219] New: float to double conversion do not silence sNaN on soft-float ARM

[aurelien at aurel32 dot net]

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

Bug ID: 61219
   Summary: float to double conversion do not silence sNaN on
soft-float ARM
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Host: armv5tejl-unknown-linux-gnueabi
Target: armv5tejl-unknown-linux-gnueabi
 Build: armv5tejl-unknown-linux-gnueabi

Consider the following code:

#define _GNU_SOURCE
#include stdio.h
#include math.h

int main (void)
{
  float sNaN = __builtin_nansf ();
  double x = (double) sNaN;
  return issignaling(x);
}

It returns 1 on soft-float ARM, but 0 on hard-float ARM or other architecture.
Quoting the IEEE Std 754 standard:

Under default exception handling, any operation signaling an invalid operation
exception and for which a floating-point result is to be delivered shall
deliver a quiet NaN.

Given the soft float ARM code ignores exceptions and always provides a result,
a float to double conversion of a signaling NaN should return a quiet NaN. This
case is not handled in extendsfdf2.

This bug is basically present since the ARM EABI support has been added to GCC.

Patch will follow on the gcc-patches mailing list.

[Bug target/61219] float to double conversion do not silence sNaN on soft-float ARM

[aurelien at aurel32 dot net]

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

--- Comment #1 from Aurelien Jarno aurelien at aurel32 dot net ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01421.html

[Bug libgcc/59412] New: __fixunsdfDI triggers wrong inexact exceptions

[aurelien at aurel32 dot net]

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

Bug ID: 59412
   Summary: __fixunsdfDI triggers wrong inexact exceptions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net

__fixunsdfDI triggers an inexact exception even when converting an integer
number from double to long long, while it shouldn't. This is due to this part
of the code:

UDWtype
__fixunsdfDI (DFtype a)
{
  /* Get high part of result.  The division here will just moves the radix
 point and will not cause any rounding.  Then the conversion to integral
 type chops result as desired.  */
  const UWtype hi = a / Wtype_MAXp1_F;

As said in the comment, the division just moves the radix, so it doesn't
triggers an inexact exception. However then the value then have some decimal
parts and the convertsion from double to int triggers the inexact exception.
This is reproducible for example on powerpc32 and causes errors in the glibc
testsuite.

[Bug target/49376] ICE when compiling linux kernel on mipsel

[aurelien at aurel32 dot net]

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

Aurelien Jarno aurelien at aurel32 dot net changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Aurelien Jarno aurelien at aurel32 dot net ---
I am able to reproduce the problem with GCC 4.4.5 or 4.4.5, but not with GCC
4.4.7 nor with GCC 4.8.2. I am therefore marking the bug as resolved fixed.

[Bug target/52258] __builtin_isgreaterequal is sometimes signaling on ARM

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno aurelien at aurel32 dot net 2012-02-19 
11:30:36 UTC ---
Created attachment 26700
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26700
Testcase

[Bug target/52258] New: __builtin_isgreaterequal is sometimes signaling on ARM

[aurelien at aurel32 dot net]

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

 Bug #: 52258
   Summary: __builtin_isgreaterequal is sometimes signaling on ARM
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aurel...@aurel32.net
  Host: armv7l-unknown-linux-gnueabihf
Target: armv7l-unknown-linux-gnueabihf
 Build: armv7l-unknown-linux-gnueabihf


__builtin_isgreaterequal is supposed to be non-signaling in case a qNaN is
provided in input. It works when the function is alone, but when combined with
another test, it sometimes triggered an invalid FP exception at -O1 and above
optimization levels.

For example:
int sel_fmax (double x, double y)
{
  return __builtin_isgreaterequal(x, y) || isnan(y);
}


At -O0, the corresponding assembly code is:
 sel_fmax:
   0:   b580push{r7, lr}
   2:   b084sub sp, #16
   4:   af00add r7, sp, #0
   6:   ed87 0b02   vstrd0, [r7, #8]
   a:   ed87 1b00   vstrd1, [r7]
   e:   ed97 6b02   vldrd6, [r7, #8]
  12:   ed97 7b00   vldrd7, [r7]
  16:   eeb4 6b47   vcmp.f64d6, d7
  1a:   eef1 fa10   vmrsAPSR_nzcv, fpscr
  1e:   bfacite ge
  20:   2300movge   r3, #0
  22:   2301movlt   r3, #1
  24:   b2dbuxtbr3, r3
  26:   f083 0301   eor.w   r3, r3, #1
  2a:   b2dbuxtbr3, r3
  2c:   2b00cmp r3, #0
  2e:   d106bne.n   3e selfmax+0x3e
  30:   ed97 0b00   vldrd0, [r7]
  34:   f7ff fffe   bl  0 __isnan
34: R_ARM_THM_CALL  __isnan
  38:   4603mov r3, r0
  3a:   2b00cmp r3, #0
  3c:   d002beq.n   44 selfmax+0x44
  3e:   f04f 0301   mov.w   r3, #1
  42:   e001b.n 48 selfmax+0x48
  44:   f04f 0300   mov.w   r3, #0
  48:   4618mov r0, r3
  4a:   f107 0710   add.w   r7, r7, #16
  4e:   46bdmov sp, r7
  50:   bd80pop {r7, pc}
  52:   bf00nop


At -O1, the corresponding assembly code is:
 sel_fmax:
   0:   b508push{r3, lr}
   2:   eeb4 0bc1   vcmpe.f64   d0, d1
   6:   eef1 fa10   vmrsAPSR_nzcv, fpscr
   a:   da07bge.n   1c selfmax+0x1c
   c:   eeb0 0b41   vmov.f64d0, d1
  10:   f7ff fffe   bl  0 __isnan
10: R_ARM_THM_CALL  __isnan
  14:   3000addsr0, #0
  16:   bf18it  ne
  18:   2001movne   r0, #1
  1a:   bd08pop {r3, pc}
  1c:   f04f 0001   mov.w   r0, #1
  20:   bd08pop {r3, pc}
  22:   bf00nop


Note how the vcmp.f64 is changed into a vcmpe.f64, triggering an invalid
exception. This means that a lot of the FP functions in the GNU libc trigger an
invalid exception where they should not, therefore rendering FP exceptions
unusable on ARM.

[Bug other/50916] -Os, -D_FORTIFY_SOURCE breaks strcpy others if inlined

[aurelien at aurel32 dot net]

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

Aurelien Jarno aurelien at aurel32 dot net changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #2 from Aurelien Jarno aurelien at aurel32 dot net 2011-10-30 
10:21:29 UTC ---
Maybe GCC fixes the GLIBC headers, but how is it supposed to work if the GLIBC
is reinstalled after GCC? This solution doesn't really seem to scale very well
given the chicken and egg problem between GCC and GLIBC.

[Bug target/49696] ICE on mips when compiling drizzle

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno aurelien at aurel32 dot net 2011-10-06 
06:40:46 UTC ---
I confirm the issue is fixed in trunk. Thanks!

[Bug target/49821] [4.6 regression] ICE in dwarf2out_cfi_begin_epilogue, at dwarf2out.c:3015

[aurelien at aurel32 dot net]

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

--- Comment #1 from Aurelien Jarno aurelien at aurel32 dot net 2011-07-29 
19:15:19 UTC ---
Created attachment 24866
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24866
Testcase

Here is a reduced testcase, the bug can be reproduced with:

g++ -c -fvisibility=hidden -g -Os testcase-min.ii

[Bug target/49696] New: ICE on mips when compiling drizzle

[aurelien at aurel32 dot net]

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

   Summary: ICE on mips when compiling drizzle
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aurel...@aurel32.net
  Host: mips-unknown-linux-gnu
Target: mips-unknown-linux-gnu
 Build: mips-unknown-linux-gnu


Created attachment 24731
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24731
Testcase to reproduce the issue

When building drizzle on mips, g++ crash with an internal compiler error. The
problem is reproducible with versions 4.4, 4.5 and 4.6, but not with version
4.3 (I didn't test earlier versions). I have attached a reduced testcase.

$ g++ -c ./testcase-min.ii
./testcase-min.ii: In member function 'drizzled::internal::gcc_traitsT,
D::value_type drizzled::internal::gcc_traitsT, D::fetch(const volatile
value_type*) const volatile [with T = bool, D = bool,
drizzled::internal::gcc_traitsT, D::value_type = bool]':
./testcase-min.ii:12:5: error: unrecognizable insn:
(insn 16 15 17 3 (parallel [
(set (reg:SI 205)
(mem/v:SI (reg:SI 200) [-1 S4 A32]))
(set (mem/v:SI (reg:SI 200) [-1 S4 A32])
(unspec_volatile:SI [
(reg:SI 203)
(reg:SI 204)
(plus:SI (reg:SI 205)
(const_int 0 [0]))
] UNSPEC_SYNC_OLD_OP_12))
(clobber (scratch:SI))
]) ./testcase-min.ii:11 -1
 (nil))
./testcase-min.ii:12:5: internal compiler error: in extract_insn, at
recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c/49376] New: ICE when compiling linux kernel on mipsel

[aurelien at aurel32 dot net]

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

   Summary: ICE when compiling linux kernel on mipsel
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aurel...@aurel32.net
  Host: mipsel-unknown-linux-gnu
Target: mipsel-unknown-linux-gnu
 Build: mipsel-unknown-linux-gnu


Created attachment 24493
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24493
Testcase to reproduce the issue

Compiling the linux kernel on mipsel with GCC 4.4 ends in an internal compiler
error. I have reduced the testcase, so it can be reproduced with the attached
testcase and the following options:

$ gcc-4.4 -Os -mno-branch-likely -c testcase.i
testcase.i: In function 'lpfc_sli4_cq_event_release_all':
testcase.i:102: warning: passing argument 3 of 'dev_printk' makes pointer from
integer without a cast
testcase.i:16: note: expected 'const char *' but argument is of type 'uint32_t'
testcase.i:113: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug debug/45387] New: mips: non-dynamic relocations refer to dynamc symbol

[aurelien at aurel32 dot net]

In some conditions on mips/mipsel, when compiling with -g, ld fails to link the
resulting objects (see attached testcase):

| gcc -O2 -g -fPIC -shared -o libb.so yb.c
| gcc -O2 -g -o ya.o -c ya.c
| gcc -O2 -g -o y ya.o -L. -lb
| /usr/bin/ld: non-dynamic relocations refer to dynamic symbol xxprogname
| /usr/bin/ld: failed to set dynamic section sizes: Bad value
| collect2: ld returned 1 exit status

This bug is a regression from the gcc 4.3 branch, and is already fixed in the
4.5 branch by the following patch:

| http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02070.html

Unfortunately this patch is not trivial to backport, that's why I am opening
this bug.


-- 
   Summary: mips: non-dynamic relocations refer to dynamc symbol
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: mips-linux-gnu
  GCC host triplet: mips-linux-gnu
GCC target triplet: mips-linux-gnu


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

[Bug debug/45387] mips: non-dynamic relocations refer to dynamc symbol

[aurelien at aurel32 dot net]

--- Comment #1 from aurelien at aurel32 dot net  2010-08-23 18:15 ---
Created an attachment (id=21550)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21550action=view)
Testcase


-- 


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

[Bug middle-end/38969] [4.3 Regression] -foptimize-sibling-calls generates wrong code on alpha

[aurelien at aurel32 dot net]

--- Comment #7 from aurelien at aurel32 dot net  2009-01-27 20:00 ---
Thanks a lot, I confirm it also fixes the original problem, that is problem in
glibc testsuite (test-float and test-ifloat failing on most of the complex
number functions).


-- 


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

[Bug c/38969] New: -foptimize-sibling-calls generates wrong code

[aurelien at aurel32 dot net]

gcc 4.3 on alpha generates wrong code when -foptimize-sibling-calls is
used (which is enabled at -O2). It was not the case with gcc 4.2, and
this is still reproducible with gcc from trunk from 20090106. This is
the reason why most of the complex tests of the glibc testsuite are
failing with gcc 4.3.

Here is a reduced testcase:

$ cat main.c
#include math.h
#include complex.h

__complex__ float my_print_complex (__complex__ float x);

int main()
{
  __complex__ float a;
  __real__ a = 9;
  __imag__ a = 42;

  my_print_complex(a);

  return 0;
}
$ cat print.c
#include complex.h
#include math.h
#include stdio.h

__complex__ float internal_print_complex (__complex__ float x)
{

  printf(%f+%fi\n, __real__ x, __imag__ x);

  if (__real__ x  0)
  {
 __real__ x = -__real__ x;
  }

  return x;
}

__complex__ float my_print_complex (__complex__ float x)
{
  return internal_print_complex (x);
}
$ gcc-4.3 -Wall -c main.c -o main.o
$ gcc-4.3 -O1 -foptimize-sibling-calls -Wall -c print.c -o print.o
$ gcc-4.3 -o test main.o print.o
$ ./test
0.00+0.00i

When print.o is not compiled with -foptimize-sibling-calls, the result
is:
$./test
9.00+42.00i
$


-- 
   Summary: -foptimize-sibling-calls generates wrong code
on alpha
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: alphaev68-unknown-linux-gnu
  GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu


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

[Bug target/36466] New: internal compiler error: in choose_reload_regs, at reload1.c:6190

[aurelien at aurel32 dot net]

gcc fails to build the attached testcase with optimization levels above -O0.
The problem occurs with all versions from the gcc 4.x branch. Versions gcc 3.x
do not expose the problem. Note that the ICE occurs on both old-ABI and EABI.

Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.0-5'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi
--target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.1 20080523 (prerelease) (Debian 4.3.0-5)


-- 
   Summary: internal compiler error: in choose_reload_regs, at
reload1.c:6190
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

[aurelien at aurel32 dot net]

--- Comment #1 from aurelien at aurel32 dot net  2008-06-08 14:31 ---
Created an attachment (id=15731)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15731action=view)
reduced testcase


-- 


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

[Bug target/36415] New: internal compiler error: in extract_insn, at recog.c:1990

[aurelien at aurel32 dot net]

gcc 4.3 fails to build the attached testcase with optimization levels above
-O0. Note that the problem does not occur on arm oldabi, and that it doesn't
exists in gcc 4.2

Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.0-5'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi
--target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.1 20080523 (prerelease) (Debian 4.3.0-5)


-- 
   Summary: internal compiler error: in extract_insn, at
recog.c:1990
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug target/36415] internal compiler error: in extract_insn, at recog.c:1990

[aurelien at aurel32 dot net]

--- Comment #1 from aurelien at aurel32 dot net  2008-06-02 05:10 ---
Created an attachment (id=15711)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15711action=view)
Reduced testcase


-- 


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

[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi

[aurelien at aurel32 dot net]

--- Comment #14 from aurelien at aurel32 dot net  2008-05-13 10:34 ---
Created an attachment (id=15633)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15633action=view)
Patch to fix the problem

This patch fixes the problem. It has been extracted from
gfortran-armel-updates.dpatch.


-- 


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

[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi

[aurelien at aurel32 dot net]

--- Comment #13 from aurelien at aurel32 dot net  2008-05-13 10:32 ---
 (The Unshare RTX earlier... one). Andrew and I actually did this work (ObjC


Good catch, I confirm that this part of the patch fixes the problem. This is
clearly a regression from gcc 4.2.


-- 


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

[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi

[aurelien at aurel32 dot net]

--- Comment #8 from aurelien at aurel32 dot net  2008-05-10 08:28 ---
I confirm that those patches actually fix the problem on ARM oldabi, so the
problem is *not* fixed in the gcc 4.3 branch.


-- 


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