[Bug libfortran/34745] collect array bounds checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34745 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Francois-Xavier Coudert --- Hadn't been picked up in year, and I am not entirely sure this is a good idea: bounds checking is better inlined, avoiding the function call and where compiler heuristics for branch prediction can fully play their role (runtime_error being noreturn, it is marked as unlikely automatically).
[Bug libfortran/35731] libfortran should use gettext to for localized error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35731 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Francois-Xavier Coudert --- Long-standing enhancement PR, but I've never heard users ask for this feature. No work done on it, low priority… I'm closing as WONTFIX,
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #2 from Richard Biener --- This is simply an inline class method which should be in a COMDAT section. The linker is free to pick either.
[Bug regression/67415] [5/6 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415 Richard Biener changed: What|Removed |Added Target||arm* Host||x86_64-*-* Target Milestone|--- |5.3 Summary|[5.1/5.2 Regression] -mcpu= |[5/6 Regression] -mcpu= |breaks -print-file-name for |breaks -print-file-name for |ARM crosscompilers |ARM crosscompilers --- Comment #2 from Richard Biener --- Well, it looks for the corresponding multilib which looks correct to me. I don't think we ever supported resolving to "compatible" libs from another multilib?
[Bug fortran/67414] [5/6 Regression] Error message on failed allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3 Summary|[5 Regression] Error|[5/6 Regression] Error |message on failed allocate |message on failed allocate
[Bug rtl-optimization/67413] Complex NOP expanded to several operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67413 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-01 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- My idea was always that the bswap pass would handle this kind of stuff...
[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3
[Bug middle-end/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid Known to work||4.9.3 Target Milestone|--- |5.3 Summary|tree-cfg.c dereferences a |[5/6 Regression] tree-cfg.c |NULL pointer|dereferences a NULL pointer --- Comment #2 from Richard Biener --- > g++-4.9 -fpermissive -S t.ii t.ii: In function ‘void f()’: t.ii:7: warning: jump to label ‘l2’ t.ii:4: warning: from here t.ii:7: error: enters catch block so that we allow this with -fpermissive is new and possibly not a good idea as seen from the crash.
[Bug c++/61753] poor diagnostic for constructor definition that starts with 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 1 08:39:47 2015 New Revision: 227361 URL: https://gcc.gnu.org/viewcvs?rev=227361&root=gcc&view=rev Log: /cp 2015-09-01 Paolo Carlini PR c++/61753 * decl.c (smallest_type_quals_location): New. (check_special_function_return_type): Use the latter; add int and const location_t* parameters. (grokdeclarator): Adjust check_special_function_return_type call. /testsuite 2015-09-01 Paolo Carlini PR c++/61753 * g++.dg/other/pr61753.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr61753.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61753] poor diagnostic for constructor definition that starts with 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #6 from Paolo Carlini --- Fixed.
[Bug middle-end/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 --- Comment #3 from Marek Polacek --- We stopped rejecting the code in r218328.
[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 Marek Polacek changed: What|Removed |Added CC||paolo at gcc dot gnu.org Component|middle-end |c++ --- Comment #4 from Marek Polacek --- I think back to the c++ component.
[Bug tree-optimization/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 --- Comment #8 from hs.naveen2u at gmail dot com --- Patch that implements the optimization referred by Richard and Andrew. https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00014.html
[Bug c/67418] New: resolution to constant fails between pointer on stack and pointer within argument structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67418
Bug ID: 67418
Summary: resolution to constant fails between pointer on stack
and pointer within argument structure
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Emmanuel.Thome at inria dot fr
Target Milestone: ---
Hi,
In the code below, gcc version 4.8.4, 4.9.3, and 5.2.0 fail to resolve the
expression temp != a->x as being a constant, while all succeed in resolving
temp != b.
It seems to me however that no valid code can reach either temp==b or
temp==a->x. Shouldn't gcc decide then that temp != a->x is constant and equal
to true in this case ? Please correct me if I am wrong.
[I've run into this as being the cause of an unexpected uninitialized warning,
whose root cause is this constant problem]
E.
struct container {
unsigned long * x;
};
int bang() __attribute__((error("should never be called")));
#define MUST_BE_CONSTANT(c) do { \
int n __attribute__((unused)) = __builtin_constant_p((c)) ? 0 : bang(); \
} while (0)
void test(struct container * a, unsigned long * b)
{
unsigned long temp[1];
MUST_BE_CONSTANT(temp != b); // passes ok.
MUST_BE_CONSTANT(temp != a->x);// fails to decide it holds
}
/*
$ ./gcc-5.2.0/bin/gcc -O2 -Wextra /tmp/a.c -c
/tmp/a.c: In function ‘test’:
/tmp/a.c:7:67: error: call to ‘bang’ declared with attribute error: should
never be called
int n __attribute__((unused)) = __builtin_constant_p((c)) ? 0 : bang(); \
^
/tmp/a.c:14:5: note: in expansion of macro ‘MUST_BE_CONSTANT’
MUST_BE_CONSTANT(temp != a->x);// fails to decide it holds
^
$ uname -a
Linux localhost 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64
GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (stretch)
Release:testing
Codename: stretch
$ ./gcc-5.2.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-5.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/opt/gcc-5.2.0
--enable-languages=c,c++
Thread model: posix
gcc version 5.2.0 (GCC)
*/
[Bug middle-end/67418] resolution to constant fails between pointer on stack and pointer within argument structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67418 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |middle-end Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This is just a missed optimization in sense GCC can't figure out that a->x can never be the address of temp.
[Bug middle-end/67418] resolution to constant fails between pointer on stack and pointer within argument structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67418 --- Comment #2 from Emmanuel Thomé --- ok thanks. Indeed it's more an enhancement request then.
[Bug target/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305 --- Comment #7 from Jiong Wang --- (In reply to Segher Boessenkool from comment #6) > The predicate here is "neon_permissive_struct_operand", and indeed > it is _very_ permissive ;-) > > This goes through neon_vector_mem_operand(op, 2, false) which immediately > says "ok!" because there is a frame pointer buried somewhere deep in > that huge expression. It looks like the "return !strict;" should read > "if (strict) return false;". agree. these blocks of code looks wrong to me. my understanding is virtual register elimination may cause the const_offset changed from out of range to within range, so we normally allow any const_offset if it's used with elim register like (plus elim_reg, const_offset) if strict_p == false. so here we should only allow eliminable registers if it's used together with a constant to form something like (plus elim_reg, const_offset), while we are allowing any rtx format when strict_p == false. And Richard, what's your opinion on the "right shift" back to "signed divide" issue at tree level?
[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 --- Comment #5 from Dominique d'Humieres --- Fixed by revisions r223321 for trunk (6.0) and r223405 for the 5-branch as expected for a duplicate of pr66044.
[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 --- Comment #3 from Dominique d'Humieres --- > I found it fixed in 5.2.0 and maybe already in 4.8.2 Are you sure of that? I am expecting an error for the test in comment 0, but I get none with trunk (6.0), 5.2, and 4.8: [Book15] f90/bug% gfc pr50555.f90 [Book15] f90/bug% gfortran pr50555.f90 [Book15] f90/bug% gfc48 pr50555.f90
[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 Paolo Carlini changed: What|Removed |Added CC|paolo at gcc dot gnu.org | --- Comment #5 from Paolo Carlini --- To clarify: pre-r218328 we didn't have a consistent status to which we may want to return: we had permerrors and then unconditional errors as part of the *explanations* (inform) of the permerrors. If we want unconditional errors instead of permerrors in some of those cases, it's certainly a different (easy) issue, just matter of going through all those we have and deciding which (we can also simplify a bit the code, the following informs are unconditional)
[Bug fortran/67419] New: gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 Bug ID: 67419 Summary: gfortran.dg/large_real_kind_2.F90 FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: fxcoudert at gcc dot gnu.org Target Milestone: --- Host: sparc*-sun-solaris2.12 Target: sparc*-sun-solaris2.12 Build: sparc*-sun-solaris2.12 The gfortran.dg/large_real_kind_2.F90 testcase FAILs on Solaris 12/SPARC (both 32 and 64-bit): FAIL: gfortran.dg/large_real_kind_2.F90 -O0 execution test Solaris 10 and 11 are both fine. Running it manually and under gdb, I find Program aborted. Backtrace: #0 0xFEAEEB37 [New Thread 1 (LWP 1)] Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xf2bba064 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) where #0 0xf2bba064 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xf2b07dc8 in raise () from /lib/libc.so.1 #2 0xf2ad6d14 in abort () from /lib/libc.so.1 #3 0xff2effd8 in _gfortrani_sys_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180 #4 0xff38e35c in _gfortran_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33 #5 0x00013504 in MAIN__ () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/large_real_kind_2.F90:45 which is TEST_FUNCTION(sqrt,789.1356) Rainer
[Bug fortran/67420] New: gfortran.dg/norm2_3.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67420 Bug ID: 67420 Summary: gfortran.dg/norm2_3.f90 FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: fxcoudert at gcc dot gnu.org Target Milestone: --- Host: sparc*-sun-solaris2.12 Target: sparc*-sun-solaris2.12 Build: sparc*-sun-solaris2.12 The gfortran.dg/norm2_3.f90 testcase FAILs on Solaris 12/SPARC (both 32 and 64-bit): FAIL: gfortran.dg/norm2_3.f90 -O0 execution test FAIL: gfortran.dg/norm2_3.f90 -O1 execution test FAIL: gfortran.dg/norm2_3.f90 -O2 execution test FAIL: gfortran.dg/norm2_3.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/norm2_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/norm2_3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/norm2_3.f90 -O3 -g execution test FAIL: gfortran.dg/norm2_3.f90 -Os execution test Running it under gdb reveals Program aborted. Backtrace: #0 0xFF2EEB37 Abort Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xf2bba064 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) where #0 0xf2bba064 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xf2b07dc8 in raise () from /lib/libc.so.1 #2 0xf2ad6d14 in abort () from /lib/libc.so.1 #3 0xff2effd8 in _gfortrani_sys_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180 #4 0xff38e35c in _gfortran_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33 #5 0x00011560 in MAIN__ () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/norm2_3.f90:28 Rainer
[Bug fortran/67420] gfortran.dg/norm2_3.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67420 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Francois-Xavier Coudert --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #2) >> I know, but only on Solaris 12. Also, there's >> gfortran.dg/large_real_kind_2.F90 that fails at -O0 only. I still mean >> to investigate what's going on there. > > CC me when you do: I'm the contact person for floating point and quad prec > stuff in the Fortran team :) Done now (PRs fortran/67419 and fortran/67420), no investigation beyond the location of the aborts. Thanks. Rainer
[Bug bootstrap/67373] Can't compile gcc snapshot for avr target with mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373 Senthil Kumar Selvaraj changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #1 from Senthil Kumar Selvaraj --- Looks like the build couldn't find an avr assembler that runs on the build machine. Building binutils with host=mingw creates an assembler that can only run on Windows. Can you try building binutils without setting host=mingw, add that to the PATH and then try building again?
[Bug target/67031] avr-gcc internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67031 Senthil Kumar Selvaraj changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #1 from Senthil Kumar Selvaraj --- Confirmed on gcc 5.2
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 --- Comment #5 from Rainer Orth --- Author: ro Date: Tue Sep 1 11:50:19 2015 New Revision: 227367 URL: https://gcc.gnu.org/viewcvs?rev=227367&root=gcc&view=rev Log: XFAIL gfortran.dg/execute_command_line_2.f90 (PR libfortran/67412) PR libfortran/67412 * gfortran.dg/execute_command_line_2.f90: XFAIL execution on *-*-solaris2.10. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/execute_command_line_2.f90
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 Rainer Orth changed: What|Removed |Added Status|NEW |SUSPENDED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- Suspended; might be fixed as a side-effect of PR target/40411. Rainer
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Francois-Xavier Coudert --- > (In reply to Rainer Orth from comment #0) >> It seems the old buggy Solaris /bin/sh is the culprit. According to the >> OpenSolaris sources, per default system(3C) uses /bin/sh, but if linked >> with values-xpg4.o (which isn't currently used, while the Studio c89 compiler >> does), /usr/xpg4/bin/sh is, which is a posix conformant shell and yields >> the correct exit code. >> >> I'm uncertain how best to handle this. > > In Fortran terms, this is really a corner case of the Fortran standard > interaction with the system. So I don't think it is a big deal, especially if > it is fixed on newer Solaris versions. > > I suggest simply XFAIL-ing the test case with a link to this PR. If that feels > OK to you, the patch is pre-approved. Thanks for reporting the issue! I'm fine with that: working around bugs of the prehistoric Solaris 10 /bin/sh doesn't exactly seem like a winning proposition to me ;-) Patch installed as pre-approved. Thanks. Rainer
[Bug tree-optimization/67312] [6 Regression] ICE: SIGSEGV in expand_expr_real_1 (expr.c:9561) with -ftree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67312 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67421 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/67421] New: gcc.dg/wide-shift-64.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67421 Bug ID: 67421 Summary: gcc.dg/wide-shift-64.c FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jiwang at gcc dot gnu.org Target Milestone: --- Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* Created attachment 36275 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36275&action=edit wide-shift-64.c.219r.combine The new gcc.dg/wide-shift-64.c testcase FAILs on SPARC for the 64-bit multilib only: FAIL: gcc.dg/wide-shift-64.c scan-rtl-dump-not combine "ior" I'm attaching the dump. Btw. I noticed a nit: both the ChangeLog entry and the commit message mention gcc.dg/wide_shift_64_1.c and gcc.dg/wide_shift_128_1.c, while the actual files are named gcc.dg/wide-shift-64.c and gcc.dg/wide-shift-128.c (similarly for the aarch64 testcase), which makes it harder to find when/by whom the files were committed. Rainer
[Bug fortran/67422] New: memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 Bug ID: 67422 Summary: memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: boris.carlsson at gmail dot com Target Milestone: --- The assembler code implementation for subroutine move_buggy(a, b, n) integer :: n, i integer, dimension(*) :: a, b do i = 1, n a(i) = b(i) end do end subroutine move_buggy generated with gfortran -S move_buggy.f90 -O3 or more "condensed" with gfortran -S move_buggy.f90 -O1 -ftree-loop-distribute-patterns -foptimize-sibling-calls -fstrict-overflow will replace the loop with a call to memcpy. memcpy is not guaranteed to work if the memory locations for a and b overlap, which could be the case here. Thus, the above code will not execute as expected (depending on the implementation of memcpy) when these optimizations are used. Thus, memcpy should not be used here. The bug is present in gfortran 5.2.1 and 4.9.3 (details below) but NOT in 4.7.2. > gfortran-5 -v Using built-in specs. COLLECT_GCC=gfortran-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-15' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20150808 (Debian 5.2.1-15) > gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.3-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.3 (Debian 4.9.3-4) > gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5)
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-01 Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert --- Can you run the following test and paste the output here? integer,parameter :: k = selected_real_kind (precision (0.0_8) + 1) real(kind=k) :: x real(kind=8) :: y print *, k x = 789.1356 y = 789.1356 print *, x print *, y print *, sqrt(x) print *, sqrt(y) print *, abs((sqrt(y)-sqrt(x))/sqrt(x)) end This should call sqrtl() and sqrt() on the same value, and check that the results are close enough to one another. But the threshold of the test case is really generous…
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Francois-Xavier Coudert --- > Can you run the following test and paste the output here? [...] Sure: 16 789.1356201171875 789.13562011718750 NaN 28.091557808658237 NaN The result is identical for both the mainline libgfortran.so.3 and the bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug introduced in Solaris 12. Rainer
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419
--- Comment #3 from Francois-Xavier Coudert ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> The result is identical for both the mainline libgfortran.so.3 and the
> bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
> introduced in Solaris 12.
What if you compile the following C source (with "gcc -lm") and run it?
int main (void)
{
long double x;
x = 789.1356;
__builtin_printf ("%.30Lg\n", x);
__builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
}
[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 --- Comment #1 from Andrew Pinski --- > memcpy is not guaranteed to work if the memory locations for a and b overlap, > which could be the case here. In Fortran code, they cannot be the same location and if they are then it is undefined code.
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Francois-Xavier Coudert ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #2)
>> The result is identical for both the mainline libgfortran.so.3 and the
>> bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
>> introduced in Solaris 12.
>
> What if you compile the following C source (with "gcc -lm") and run it?
>
> int main (void)
> {
> long double x;
> x = 789.1356;
> __builtin_printf ("%.30Lg\n", x);
> __builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
> }
I get
789.135595397956809029
-NaN
Rainer
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
>> --- Comment #3 from Francois-Xavier Coudert
>> ---
>> (In reply to r...@cebitec.uni-bielefeld.de from comment #2)
>>> The result is identical for both the mainline libgfortran.so.3 and the
>>> bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
>>> introduced in Solaris 12.
>>
>> What if you compile the following C source (with "gcc -lm") and run it?
>>
>> int main (void)
>> {
>> long double x;
>> x = 789.1356;
>> __builtin_printf ("%.30Lg\n", x);
>> __builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
>> }
>
> I get
>
> 789.135595397956809029
> -NaN
If I drop the __builtin_ and include and instead, I
get the expected
789.135595397956809029
28.0915574505935849505420666378
Rainer
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #3 from Alan Modra --- Yes, exactly. When a COMDAT group in another file is chosen, the rs6000 predicate current_file_function_operand gets the wrong answer. COMDAT group functions use weak symbols, and weak symbols more generally have the behaviour exhibited here by COMDAT group functions: A symbol defined in the same object file might be overridden by the same symbol defined in another file.
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419
--- Comment #6 from Francois-Xavier Coudert ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
>> int main (void)
>> {
>> long double x;
>> x = 789.1356;
>> __builtin_printf ("%.30Lg\n", x);
>> __builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
>> }
>
> I get
>
> 789.135595397956809029
> -NaN
OK, then it's definitely not Fortran-specific. The question is: is it just
because of GCC's built-in handling (e.g., because the math.h header does
something weird), or is it simply that the libm's sqrtl() is unusable?
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #7 from Francois-Xavier Coudert --- (In reply to r...@cebitec.uni-bielefeld.de from comment #5) > If I drop the __builtin_ and include and instead, I > get the expected Then the math.h header is playing tricks and GCC is not aware. This need to be fixed in the solaris back-end (the same sort of thing happened with darwin in the past, see darwin_patch_builtin in gcc/config/darwin.c). Best bet is to check in math.h how sqrtl() is defined. And then check the assembly code for both the __builtin_sqrtl() and the header-defined sqrtl().
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Francois-Xavier Coudert ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #4)
>>> int main (void)
>>> {
>>> long double x;
>>> x = 789.1356;
>>> __builtin_printf ("%.30Lg\n", x);
>>> __builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
>>> }
>>
>> I get
>>
>> 789.135595397956809029
>> -NaN
>
> OK, then it's definitely not Fortran-specific. The question is: is it just
> because of GCC's built-in handling (e.g., because the math.h header does
> something weird), or is it simply that the libm's sqrtl() is unusable?
I believe the results for invoking sqrtl instead of __builtin_sqrtl show
that gcc's builtin handling is wrong in some way. and friends
show no weird constructs that might cause this.
Rainer
[Bug fortran/67420] gfortran.dg/norm2_3.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67420 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2015-09-01 Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert --- Given the location of the failure, this is probably a duplicate of PR67420, because we use the built-in sqrtl() in NORM2. Marked as SUSPENDED for now.
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Francois-Xavier Coudert --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #5) >> If I drop the __builtin_ and include and instead, I >> get the expected > > Then the math.h header is playing tricks and GCC is not aware. This need to be > fixed in the solaris back-end (the same sort of thing happened with darwin in > the past, see darwin_patch_builtin in gcc/config/darwin.c). > > Best bet is to check in math.h how sqrtl() is defined. And then check the > assembly code for both the __builtin_sqrtl() and the header-defined sqrtl(). That's what I'll do next, together with comparing S11 and S12 and -O0 with -O1. Thanks. Rainer
[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #7 from Francois-Xavier Coudert >> --- >> (In reply to r...@cebitec.uni-bielefeld.de from comment #5) >>> If I drop the __builtin_ and include and instead, I >>> get the expected >> >> Then the math.h header is playing tricks and GCC is not aware. This need to >> be >> fixed in the solaris back-end (the same sort of thing happened with darwin in >> the past, see darwin_patch_builtin in gcc/config/darwin.c). >> >> Best bet is to check in math.h how sqrtl() is defined. And then check the >> assembly code for both the __builtin_sqrtl() and the header-defined sqrtl(). > > That's what I'll do next, together with comparing S11 and S12 and -O0 > with -O1. It's definitively a Solaris 12 bug: gcc creates identical code for the __builtin_sqrtl case between Solaris 11 and 12. It works on S11, but fails on S12. If I run the S12 binary to an S11 machine, it runs there just fine. I'll check with my contacts. Rainer
[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Indeed. Or the FE is buggy in translating it to move_buggy (integer(kind=4)[0:] * restrict a, integer(kind=4)[0:] * restrict b, integer(kind=4) & restrict n)
[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #20 from Vladimir Makarov ---
(In reply to Fredrik Hederstierna from comment #19)
> I'm not sure why bug 59535 was closed, same problem might still exist, quote:
>
> > Zhenqiang Chen 2014-09-03 06:17:44 UTC
> >
> > Here is a small case to show lra introduces one more register copy (tested
> > with trunk and 4.9).
>
> int isascii (int c)
> {
> return c >= 0 && c < 128;
> }
> With options: -Os -mthumb -mcpu=cortex-m0, I got
>
> isascii:
> mov r3, #0
> mov r2, #127
> mov r1, r3 //???
> cmp r2, r0
> adc r1, r1, r3
> mov r0, r1
> bx lr
>
> With options: -Os -mthumb -mcpu=cortex-m0 -mno-lra, I got
>
> isascii:
> mov r2, #127
> mov r3, #0
> cmp r2, r0
> adc r3, r3, r3
> mov r0, r3
> bx lr
>
> Testing 4.8.5 and 5.2.0 still still produces same bigger code in GCC 5.2.
> So something adds a register copy in this small case.
Thanks for providing a small test case. I've started to work on the PR. I
hope to provide a fix for the case today.
[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Resolution|INVALID |FIXED --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Boris Carlsson from comment #0) > The assembler code implementation for > > subroutine move_buggy(a, b, n) > integer :: n, i > integer, dimension(*) :: a, b > do i = 1, n > a(i) = b(i) > end do > end subroutine move_buggy > > generated with > > gfortran -S move_buggy.f90 -O3 > > or more "condensed" with > > gfortran -S move_buggy.f90 -O1 -ftree-loop-distribute-patterns > -foptimize-sibling-calls -fstrict-overflow > > will replace the loop with a call to memcpy. memcpy is not guaranteed to > work if the memory locations for a and b overlap, which could be the case > here. Thus, the above code will not execute as expected (depending on the > implementation of memcpy) when these optimizations are used. Thus, memcpy > should not be used here. > > The bug is present in gfortran 5.2.1 and 4.9.3 (details below) but NOT in > 4.7.2. > The memory locations for a and b cannot overlap in standard conforming code. This restriction goes back to at least Fortran 77, and it is a restriction on the programmer not the compiler.
[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295 --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Alexandre Oliva from comment #1) > I get exactly the same code with r226900, before the copyrename patch: > > cmp r1, #0 > rev16ne r0, r0 > uxthne r0, r0 > .L2: > sxthr0, r0 > b foos16 > > Did you use any other configuration flags or compiler options or assembler > version or something to get you the better-optimized code? Hmmm, I double checked, and with r226900 before the patch I definitely get: cmp r1, #0 revshne r0, r0 .L2: b foos16 The options are just -O2 -S. It is an arm-none-eabi toolchain (with newlib as the C-library) and the relevant configure options I can think of are: --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib --with-fpu=neon-fp-armv8 --with-arch=armv8-a --without-isl
[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #21 from Fredrik Hederstierna --- Great, thanks! Just a note as you are looking into this, neither GCC 4.8.x nor GCC 5.2.x produces the optimal code I think for this case, isn't it better to load result register r0, instead of go over r3? GCC 4.8.5 (good version): isascii: mov r2, #127 mov r3, #0 cmp r2, r0 adc r3, r3, r3 mov r0, r3 bx lr better ??: isascii: mov r2, #127 mov r3, #0 cmp r2, r0 + adc r0, r3, r3 <- put result in R0 directly? - adc r3, r3, r3 - mov r0, r3 bx lr This would save one more instruction if I'm thinking right. BR, Fredrik
[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 --- Comment #4 from Vittorio Zecca --- Sorry, you are right, the compiler should emit an error message instead it wrongly accepts the code. I was confused, this time the right behaviour is to emit an error message.
[Bug target/67405] ICE on invalid use of struct on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67405 --- Comment #1 from Ilya Enkovich --- Author: ienkovich Date: Tue Sep 1 14:38:42 2015 New Revision: 227373 URL: https://gcc.gnu.org/viewcvs?rev=227373&root=gcc&view=rev Log: gcc/ PR target/67405 * tree-chkp.c (chkp_find_bound_slots_1): Add NULL check. gcc/testsuite/ PR target/67405 * g++.dg/pr67405.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr67405.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c
[Bug libstdc++/67403] std::regex is not matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67403 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Jonathan Wakely --- Apart from that 4.8 is not supported anyway, so reporting bugs against it won't achieve anything except being asked to try a current, supported release. If you do that you will find it works in 4.9 and later.
[Bug preprocessor/55115] [4.9/5/6 Regression] missing headers as fatal breaks cproto logic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 RGomes changed: What|Removed |Added CC||Robert.Gomes at igt dot com --- Comment #16 from RGomes --- Hi, I have watched this thread for years expecting a switch to be introduced to allow the former GCC behavior of tolerating missing header files and I can no longer remain on the side lines. I echo the sentiment of others that the ability to permit missing headers is something we rely on to auto-generate said header files using cproto, and we've been doing this as far back as GCC 3.x. Of course missing headers should be an error during compilation, but pre-compile it is natural to auto-generate a variety of header files, at least in our situation. I find myself having to downgrade to GCC 4.4.7 in order to work around this issue, but I would prefer to continue to use future editions of GCC. Please see if a safety valve can be put in to allow the former behavior, it seems like this issue keeps getting bumped to future revisions but at some point we are going to be between a rock and a hard place with decisions about OS and GCC upgrades. Thank you for your anticipated consideration.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-01 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug regression/67415] [5/6 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-01 Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw --- Are you sure the two compilers were configured in exactly the same way? Hint, you haven't shown us the full output of "gcc -v"
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #1 from Jonathan Wakely --- I didn't think that code was usable on non-POSIX systems, and for POSIX they are the same type. I'll see what I can do about it.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #2 from Jonathan Wakely --- Created attachment 36276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36276&action=edit Handle recursive mutexes with different types. Does this work for your target?
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #3 from Jonathan Wakely --- Created attachment 36277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36277&action=edit Handle recursive mutexes with different types. Or this, which is probably easier on the compiler.
[Bug c/67423] New: printf.h does not compile with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 Bug ID: 67423 Summary: printf.h does not compile with O1 or above Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sl at dataconnection dot com Target Milestone: --- If I have a test file consisting of #include and I do "gcc -c -O1 ", the compile fails with /usr/include/printf.h:116:68: error: expected initializer before âthrowâ /usr/include/printf.h:122:70: error: expected initializer before âthrowâ Either the __wur and __THROW #defines on the following rows ... extern int register_printf_modifier (__const wchar_t *__str) __wur __THROW; /* Register variable argument handler for user type. The return value is to be used in ARGINFO functions to signal the use of the type. */ extern int register_printf_type (printf_va_arg_function __fct) __wur __THROW; ... are the wrong way round or gcc is not sufficiently tolerant on ordering here. Can you recommend the safest workaround for this problem? At the moment I'm putting in an override #define __wur and putting up with the compile warnings.
[Bug c/67423] printf.h does not compile with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-01 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- GCC 4.6 is not supported and hasn't been for some years, so even if there is a problem in GCC 4.6 it isn't going to get fixed. Please try to reproduce this with a current release. If you want a recommendation for a workaround then please try the gcc-help mailing list, or the #gcc IRC channel, rather than reporting a bug.
[Bug c/67423] printf.h does not compile with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 --- Comment #2 from Jonathan Wakely --- (In reply to sl from comment #0) > If I have a test file consisting of > > #include > > and I do "gcc -c -O1 ", the compile fails with > > /usr/include/printf.h:116:68: error: expected initializer before âthrowâ > /usr/include/printf.h:122:70: error: expected initializer before âthrowâ Also, please provide a proper (i.e. complete) test case and the real command, not an approximation and a modified command including placeholders like "" > are the wrong way round or gcc is not sufficiently tolerant on ordering here. My glibc headers have the same declaration and it compiles fine with all versions of GCC I tried.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #4 from Sebastian Huber --- Sorry, I should have linked my patch: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html I think the your second version doesn't work in case the types are equal, it looks similar to my first attempt to fix this which didn't work on Linux. I try your first version tomorrow.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #5 from Sebastian Huber --- (In reply to Sebastian Huber from comment #4) > I think the your second version doesn't work in case the types are equal, it > looks similar to my first attempt to fix this which didn't work on Linux. Please ignore this comment, you use different second parameter types.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #6 from Jonathan Wakely --- (In reply to Sebastian Huber from comment #4) > Sorry, I should have linked my patch: > > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html AH yes, that would work too, and doesn't require the compiler to do any overload resolution. N.B. all libstdc++ patches need to be CC'd to the libstdc++ list, I don't read gcc-patches. > I think the your second version doesn't work in case the types are equal, it > looks similar to my first attempt to fix this which didn't work on Linux. It works fine, because the second overload is a worse overload because it requires a conversion to void, so when the types are equal the first overload is lways used. When the types are not equal the first overload is not viable at all for recursive mutexes, so the second is used, and the second argument is cast back to the __gthread_time_t type.
[Bug c/67423] printf.h does not compile with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 sl at dataconnection dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from sl at dataconnection dot com --- Apologies - I wasn't aware that 4.6.3 is out of support. Perhaps it should be removed from the list of valid versions in the drop down box to save confusion in future? I've found a box running 4.8.4 and agree that that doesn't have the same problem (the ordering of the directives is the same, so presumably the compiler is now more tolerant of their ordering)
[Bug c/67423] printf.h does not compile with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |MOVED --- Comment #4 from Jonathan Wakely --- Reported as a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18907
[Bug other/67424] New: libcilkcrts fails to build on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67424 Bug ID: 67424 Summary: libcilkcrts fails to build on NetBSD Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gcc at rkeene dot org Target Milestone: --- GCC 5.2.0 fails to build a compiler for NetBSD on x86_64 by default. This is because libcilkrts/configure.tgt does not return unsupported for NetBSD on x86_64, but libcilkrts/runtime/os-unix.c #ifdefs return an #error directive for NetBSD.
[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #5 from Dominique d'Humieres --- Per comment 4 reset to NEW.
[Bug driver/67425] New: -frandom-seed documentation doesn't match code, incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67425 Bug ID: 67425 Summary: -frandom-seed documentation doesn't match code, incomplete Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- As discussed in the thread referenced below, the online documentation of the -frandom-seed option doesn't match its implementation in GCC 5.1. Specifically, while in GCC 4.9 and before, the option is documented to take a string as an argument, in GCC 5 it's documented to take a number, even though GCC still accepts arbitrary strings. https://gcc.gnu.org/ml/gcc-help/2015-08/msg00169.html I see two possible solutions: Either revert the documentation change to specify that the option takes a number, or adjust the implementation of the option to match the new documentation. If the former, a test case should be added to verify that the option can, in fact, accept a string argument and handles it correctly (i.e., by computing its CRC32 value and using that as the random seed). Currently there's only one test case for the option and it specifies a hex argument (gcc itself seems to use the option with an argument of 0). The option change was introduced in r216773: commit cf357977a8d0eadddf7f2f248553519dc622ffb8 Author: ygribov Date: Tue Oct 28 09:46:29 2014 + Allow to override Asan shadow offset. 2014-10-28 Yury Gribov gcc/ * asan.c (set_asan_shadow_offset): New function. (asan_shadow_offset): Likewise. (asan_emit_stack_protection): Call asan_shadow_offset. (build_shadow_mem_access): Likewise. * asan.h (set_asan_shadow_offset): Declare. * common.opt (fasan-shadow-offset): New option. (frandom-seed): Fixed parameter name. * doc/invoke.texi (fasan-shadow-offset): Describe new option. (frandom-seed): Fixed parameter name. * opts-global.c (handle_common_deferred_options): Handle -fasan-shadow-offset. * opts.c (common_handle_option): Likewise. gcc/testsuite/ * c-c++-common/asan/shadow-offset-1.c: New test.
[Bug c++/67324] Failures in Assignable concept's requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67324
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1 from Casey Carter ---
> template< class T, class U = T >
> concept bool
>Assignable( )
> {
>return
> requires( T&& a, U&& b ) {
>//{ forward(a) = forward(b) } -> Same;// #1
>//Same(a) = forward(b))>(); // #2
> };
> }
#2 is an expression constraint requiring "Same<...>()" to be a valid
expression. It notably does NOT require "Same<...>()" to be satisfied. You need
a nested-requirement to express this:
template< class T, class U = T >
concept bool
Assignable()
{
return
requires( T&& a, U&& b ) {
requires Same(a) = forward(b))>();
};
}
[Bug c++/67426] New: Ambiguous overload between different function templates, where one has non-deduced arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67426
Bug ID: 67426
Summary: Ambiguous overload between different function
templates, where one has non-deduced arg
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider this example (also in SO question
http://stackoverflow.com/q/32335523/2069064):
#include
template
using size_ = std::integral_constant;
// (1)
template
void f(size_, size_ )
{ }
// (2)
template
void f(size_, size_ )
{ }
int main()
{
f(size_<0>{}, size_<1>{});
}
gcc 5.2 declares this call ambiguous. Deduction from (1) to (2) succeeds
easily, should deduction from (2) to (1) not fail?
[Bug c++/67427] New: [concepts] Subsumption dependence on template parameter ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67427
Bug ID: 67427
Summary: [concepts] Subsumption dependence on template
parameter ordering
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
r227376 fails to compile this correct program with -std=gnu++1z:
template
concept bool Sentinel =
requires (I i) { i; };
Sentinel{S, I}
void distance(I first, S last) {}
template
concept bool SizedIteratorRange =
Sentinel && true;
#if FOO
template
#else
template
#endif
requires SizedIteratorRange
void distance(I first, S last) {}
int main() {
distance(42, 43);
}
with error:
~/gcc6-r227376/bin/g++ -std=gnu++1z ~/foo4.cpp -c
/home/casey/foo4.cpp: In function ‘int main()’:
/home/casey/foo4.cpp:21:18: error: call of overloaded ‘distance(int, int)’ is
ambiguous
distance(42, 43);
^
/home/casey/foo4.cpp:6:6: note: candidate: void distance(I, S) [with S = int; I
= int]
void distance(I first, S last) {}
^
/home/casey/foo4.cpp:18:6: note: candidate: void distance(I, S) [with I = int;
S = int]
void distance(I first, S last) {}
^
It does compile successfully when FOO is defined to 1, changing the declaration
order of the template parameters on the second overload of distance.
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 --- Comment #11 from Kai-Uwe Eckhardt --- > Does this mean that this PR can be closed? If yes, with which resolution? It is still unresolved. The commited patch requires pr64271 and pr67424 to be resolved first. I no longer run NetBSD and quite frankly I would suggest marking gfortran as unsupported under NetBSD. Over the years I have commited other patches for gfortran on NetBSD as well (for instance pr39570) but obviously the number of NetBSD people with commit rights is too low to keep up with the evergrowing speed of gcc development.
[Bug sanitizer/67258] "invalid vptr" false positive from ubsan for virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67258 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #1 from Avi Kivity --- I bisected a similar problem (with boost unit-tests) to: commit 6365c92707e013c1bc7c262bd762ac8bfacbdda3 Author: hubicka Date: Thu Jan 15 23:11:49 2015 + PR ipa/64612 * ipa-inline-transform.c (can_remove_node_now_p): Fix handling of comdat locals. (inline_call): Fix removal of aliases. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219696 138bc75d-0d04-0410-961f-82ee72b054a4 Strangely this is one commit after the commit that introduces -fsanitize=vptr, so maybe it's unrelated and the previous commit is guilty.
[Bug ipa/67428] New: lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 Bug ID: 67428 Summary: lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Host: x86-linux-gnu Target: i386 Build: x86-linux-gnu Following error (sources will follow) occurs when compiling == Command Line == $ gcc Bug.c e.c i.c -flto -Os -fipa-pta -o test.elf -save-temps -v $ avr-gcc -mmcu=atmega328p Bug.c e.c i.c -flto -Os -fipa-pta -o test.elf -save-temps -v == Error Message == lto1: fatal error: test.elf.ltrans0.o: section Foo is missing compilation terminated. lto-wrapper: fatal error: /local/gnu/install/gcc-6/bin/avr-gcc returned 1 exit status Foo is declared in module e.c == GCC configures as == Target: i686-pc-linux-gnu Configured with: ../../gcc.gnu.org/gcc-5-branch/configure --prefix=/mnt/nfs/home/georg/gnu/install/gcc-native-5 --disable-nls --enable-checking=release --enable-languages=c,c++,lto Thread model: posix gcc version 5.2.1 20150721 (GCC) Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-6 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld target_alias=avr --enable-languages=c,c++,lto --no-create --no-recursion Thread model: single gcc version 6.0.0 20150720 (experimental) (GCC) Target: avr Configured with: ../../gcc.gnu.org/gcc-5-branch/configure --target=avr --prefix=/local/gnu/install/gcc-5 --disable-nls --disable-shared --with-dwarf2 --with-gnu-ld --with-gnu-as target_alias=avr --enable-languages=c,c++,lto Thread model: single gcc version 5.2.1 20150816 (GCC)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #1 from Georg-Johann Lay --- Created attachment 36278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36278&action=edit Bug.c (C-source 1/3)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #2 from Georg-Johann Lay --- Created attachment 36279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36279&action=edit e.c (C-source 2/3)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #3 from Georg-Johann Lay --- Created attachment 36280 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36280&action=edit i.c (C-source 3/3)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #4 from Georg-Johann Lay --- Created attachment 36281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36281&action=edit output of gcc-5.2
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #5 from Georg-Johann Lay --- Created attachment 36282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36282&action=edit output of avr-gcc-6 (SVN trunk 227033)
[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #22 from Vladimir Makarov --- Author: vmakarov Date: Tue Sep 1 19:37:52 2015 New Revision: 227382 URL: https://gcc.gnu.org/viewcvs?rev=227382&root=gcc&view=rev Log: 2015-09-01 Vladimir Makarov PR target/61578 * lra-lives.c (process_bb_lives): Process move pseudos with the same value for copies and preferences * lra-constraints.c (match_reload): Create match reload pseudo with the same value from single dying input pseudo. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-lives.c
[Bug fortran/67429] New: [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 Bug ID: 67429 Summary: [5/6 Regression] Missing part of error messages. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: bur...@net-b.de, manu at gcc dot gnu.org Target Milestone: --- When compiling the test in pr65045 with r218570 I get the errors pr65045.f90:3.6: if (i>7.7) then 1 Error: Symbol at (1) is not appropriate for an expression pr65045.f90:5.7: else 1 Error: Unexpected ELSE statement at (1) pr65045.f90:6.6: i = 2.2 1 Error: 'i' at (1) is not a variable pr65045.f90:7.6: end if 1 Error: Expecting END BLOCK statement at (1) f951: internal compiler error: Segmentation fault: 11 f951: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort With revision r218658, the errors are pr65045.f90:3:6: Error: Symbol at (1) is not appropriate for an expression pr65045.f90:5:7: else 1 Error: Unexpected ELSE statement at (1) pr65045.f90:6:6: Error: 'i' at (1) is not a variable pr65045.f90:7:6: end if 1 Error: Expecting END BLOCK statement at (1) (null):0: confused by earlier errors, bailing out Likely r218619 or r218627. This may explain pr67174.
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #0) > When compiling the test in pr65045 with r218570 I get the errors > So, why isn't this a duplicate of PR65045?
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 --- Comment #2 from Dominique d'Humieres --- > So, why isn't this a duplicate of PR65045? Because PR65045 is about an ICE and this PR is about missing text in the error messages.
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 --- Comment #3 from Steve Kargl --- On Tue, Sep 01, 2015 at 08:05:33PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 > > --- Comment #2 from Dominique d'Humieres --- > > So, why isn't this a duplicate of PR65045? > > Because PR65045 is about an ICE and this PR is about missing text in the error > messages. > It's the same piece of code causing the problem. One needs to go to PR65045 to get the code, so this PR is superfluous. When the ICE is fixed, then error message should be addressed.
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 --- Comment #4 from Dominique d'Humieres --- > It's the same piece of code causing the problem. One > needs to go to PR65045 to get the code, so this PR > is superfluous. When the ICE is fixed, then > error message should be addressed. The piece of code is used as an example exhibiting a different problem than PR65045. Please read comment 0.
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 --- Comment #5 from Steve Kargl --- > > Please read comment 0. > I read comment #0. THERE IS NO CODE THERE. THERE IS NO CODE ATTACHED TO THIS PR. One needs to go to PR65045 to get the code that is causing the error message. Ergo, this is a duplicate of PR65045. When PR65045 is fixed. The issue with the error message should be addressed then.
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Created attachment 36283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36283&action=edit Patch for PR65045 that displays the problem
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 --- Comment #7 from Paul Thomas --- (In reply to Steve Kargl from comment #5) > > > > Please read comment 0. > > > > I read comment #0. > > THERE IS NO CODE THERE. > > THERE IS NO CODE ATTACHED TO THIS PR. > > One needs to go to PR65045 to get the code > that is causing the error message. Ergo, > this is a duplicate of PR65045. > > When PR65045 is fixed. The issue with the > error message should be addressed then. Steve, This is a problem that has surfaced with the change to the gcc error handling. Rainer Orth has encountered it on Solaris and it caused me to hold back on my patch for pointer function assignment. The patch for PR65045 is the simplest manifestation that I have found. I am very grateful to Dominique for posting this PR because the problem has been driving me crazy. I assumed that it was my patches that were wrong. However, Dominique proved by going through different revisions that the December 2014 patches to error.c are the culprits. Go easy on us both - it's getting a bit late here :-) Cheers Paul
[Bug libstdc++/66624] libstdc++ iostream uninitialized data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66624 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #5 from TC --- Is this not a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158?
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-01 Ever confirmed|0 |1 --- Comment #8 from Dominique d'Humieres --- > Created attachment 36283 [details] > Patch for PR65045 that displays the problem Paul, Your patch for gcc/fortran/decl.c does not apply on trunk: if (state == COMP_BLOCK) is now while (state == COMP_BLOCK)
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #4 from Alan Modra --- Author: amodra Date: Tue Sep 1 23:03:19 2015 New Revision: 227386 URL: https://gcc.gnu.org/viewcvs?rev=227386&root=gcc&view=rev Log: [RS6000] Weak functions may not be file local A weak symbol defined in the current object file may not turn out to be the definition used at link time, if other copies of the symbol exist. This means they can't be considered file local. PR target/67417 * config/rs6000/predicates.md (current_file_function_operand): Don't return true for weak symbols. * config/rs6000/rs6000.c (rs6000_function_ok_for_sibcall): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000.c
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #5 from Alan Modra --- Author: amodra Date: Tue Sep 1 23:04:58 2015 New Revision: 227387 URL: https://gcc.gnu.org/viewcvs?rev=227387&root=gcc&view=rev Log: [RS6000] Weak functions may not be file local A weak symbol defined in the current object file may not turn out to be the definition used at link time, if other copies of the symbol exist. This means they can't be considered file local. PR target/67417 * config/rs6000/predicates.md (current_file_function_operand): Don't return true for weak symbols. * config/rs6000/rs6000.c (rs6000_function_ok_for_sibcall): Likewise. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/predicates.md branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
[Bug ada/48013] generic instantiation breaks the restriction of No_Elaboration_Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48013 yuta tomino changed: What|Removed |Added Version|4.5.2 |6.0 Known to fail||4.5.2 --- Comment #2 from yuta tomino --- It has appeared on 6.0.0-20150823.
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #6 from Alan Modra --- Author: amodra Date: Tue Sep 1 23:25:48 2015 New Revision: 227389 URL: https://gcc.gnu.org/viewcvs?rev=227389&root=gcc&view=rev Log: [RS6000] Weak functions may not be file local A weak symbol defined in the current object file may not turn out to be the definition used at link time, if other copies of the symbol exist. This means they can't be considered file local. PR target/67417 * config/rs6000/predicates.md (current_file_function_operand): Don't return true for weak symbols. * config/rs6000/rs6000.c (rs6000_function_ok_for_sibcall): Likewise. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/predicates.md branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.4 --- Comment #7 from Alan Modra --- Fixed all active branches.
[Bug ada/48002] internal error on calling inherited, overloaded and abstract subprograms with string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48002 yuta tomino changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from yuta tomino --- I'm unsure about the rule of this Bugzilla, but allow me to close because this bug has already been fixed.
