[Bug sanitizer/66452] [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #4 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #2)
> > > 2. Once (1) is fixed, bootstrap then fails with:
> > >
> > > /GCC/gcc-trunk/gcc/ipa-pure-const.c:1640:1: error:
> > > ‘{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)’
> > > defined but not used [-Werror=unused-function]
> > > pass_ipa_pure_const::
> > >
> > > A --disable-werror boostrap completes, but there are a number of
> > > constructors and destructors that report "declared but not used". AFAICT,
> > > it's only constructors/destructors.
> > >
> > > This is occurring at stage #2, and I thought maybe that the stage#1
> > > compiler
> > > could have been mis-compiled by the bootstrap; however, gcc-4.9, 5.1 and
> > > clang (xcode 5.1.1) bootstraps all give the same result.
> >
> > Jason, is pass_ipa_pure_const::pass_ipa_pure_const() really declared but not
> > used?
>
> I bet a drink that it is an incharge vs outofcharge construct/deconstruct
> issue. Darwin does not support aliases so the function itself is cloned.
*sigh*, that seems believable - although I thought we'd ironed out most of the
alias/no-alias issues when dealing with the ipa-icf stuff last year.
This assessment is also likely consistent with duplicate debug information
being reported.
So perhaps there are multiple entries and (somehow) only one is marked as
"used"?
(if there's something specific needed debug-wise that needs a Darwin system let
us know and we'll try to extract what's needed).
[Bug c/66348] Simple loop never exits with -O1, exits with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #13 from Sebastiano Vigna --- I can confirm that compiling/running with ubsan and asan no problem is reported. The bug does not show up.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 --- Comment #4 from vries at gcc dot gnu.org --- Created attachment 35713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35713&action=edit tentative patch with testcase
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 --- Comment #5 from vries at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > The testcase has been reduced from much larger testcase, the content of the > fn1 function matters only for the IPA-RA analysis, so can be changed to > something else, and the other functions supposedly can be defined in a > dg-additional-sources file. Though, the hardcoding of the constant in the > pointer arithmetics makes it more difficult (the testcase would have to > simulate there is something mapped at that address (or mmap there something > - the constant can be changed to something more suitable). I managed to write the testcase in such a way that it doesn't dereference the hardcoded pointer.
[Bug sanitizer/66452] [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452 --- Comment #2 from Marek Polacek --- Started with r224161 aka debug-early branch merge.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 --- Comment #6 from Jakub Jelinek --- The 0xe0UL constant is probably not very good for ilp32 targets. Try some < 4GB one if it still reproduces without the patch, or conditionalize it on __SIZEOF_POINTER__.
[Bug sanitizer/66452] [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452 --- Comment #3 from Dmitry G. Dyachenko --- r224136 PASS r224161 FAIL (stage1 compiler due broken bootstrap)
[Bug libstdc++/66455] is_always_equal unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66455 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- No, it's new for C++17. It was voted into the WP in November 2014.
[Bug sanitizer/66452] [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452 --- Comment #4 from Marek Polacek --- I'm testing --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -534,6 +534,7 @@ check_global_declaration (tree decl) to handle multiple external decls in different scopes. */ && ! (DECL_NAME (decl) && TREE_USED (DECL_NAME (decl))) && ! DECL_EXTERNAL (decl) + && ! DECL_ARTIFICIAL (decl) && ! TREE_PUBLIC (decl) /* A volatile variable might be used in some non-obvious way. */ && ! TREE_THIS_VOLATILE (decl) (Maybe we should also test !TREE_NO_WARNING but the above is enough to fix this.)
[Bug tree-optimization/66449] [6 Regression] ICE: in build2_stat, at tree.c:4376 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66449 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 Ever confirmed|0 |1
[Bug tree-optimization/66436] Don't dump low gimple functions in gimple dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66436 --- Comment #3 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jun 8 08:57:50 2015 New Revision: 224210 URL: https://gcc.gnu.org/viewcvs?rev=224210&root=gcc&view=rev Log: Don't dump low gimple functions in gimple dump 2015-06-08 Tom de Vries PR tree-optimization/66436 * cgraphunit.c (cgraph_node::analyze): Don't dump function to gimple dump file. * gimplify.c: Add tree-dump.h include. (gimplify_function_tree): Dump function to gimple dump file. * stor-layout.c (finalize_size_functions): Don't dump function to gimple dump file. * gcc.dg/gomp/dump-new-function-2.c: New test. * gcc.dg/gomp/dump-new-function-3.c: Same. * gcc.dg/gomp/dump-new-function.c: Same. Added: trunk/gcc/testsuite/gcc.dg/gomp/dump-new-function-2.c trunk/gcc/testsuite/gcc.dg/gomp/dump-new-function-3.c trunk/gcc/testsuite/gcc.dg/gomp/dump-new-function.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/gimplify.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/66435] Add debug msg to dump_file in add_new_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66435 --- Comment #3 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jun 8 08:57:39 2015 New Revision: 224209 URL: https://gcc.gnu.org/viewcvs?rev=224209&root=gcc&view=rev Log: Add debug msg to dump_file in add_new_function 2015-06-08 Tom de Vries PR tree-optimization/66435 * cgraphunit.c (cgraph_node::add_new_function): Dump message on new function. * gcc.dg/gomp/notify-new-function-2.c: New test. * gcc.dg/gomp/notify-new-function-3.c: Same. * gcc.dg/gomp/notify-new-function.c: Same. Added: trunk/gcc/testsuite/gcc.dg/gomp/notify-new-function-2.c trunk/gcc/testsuite/gcc.dg/gomp/notify-new-function-3.c trunk/gcc/testsuite/gcc.dg/gomp/notify-new-function.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/66436] Don't dump low gimple functions in gimple dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66436 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from vries at gcc dot gnu.org --- patch and testcases committed, marking resolved-fixed
[Bug tree-optimization/66435] Add debug msg to dump_file in add_new_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66435 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from vries at gcc dot gnu.org --- patch and testcases committed, marking resolved-fixed
[Bug c++/66451] Array not fully destructed if element destructor throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66451 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Dodd from comment #0) > If an array element throws during destruction, undestructed elements in that > array are not destructed. Other local variables are destructed. Clang calls > destructors on all automatic objects, regardless whether in or out of an > array. Not always ;-) https://llvm.org/bugs/show_bug.cgi?id=22877 This is probably related to PR66139
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #9 from Mikhail Maltsev --- Created attachment 35714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35714&action=edit Code compiled with r212399
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #10 from Mikhail Maltsev --- Created attachment 35715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35715&action=edit Code compiled with r212400 There is a change from arithmetic shift to logical shift.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 --- Comment #7 from vries at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #6) > The 0xe0UL constant is probably not very good for ilp32 targets. > Try some < 4GB one if it still reproduces without the patch, or > conditionalize it on __SIZEOF_POINTER__. I've tried with 0xe000U. The m64 case still reproduces. With -m32 -mregparm=1 we get: ... .cfi_startproc callbar sall$4, %eax leal-536870912(%eax), %edx movl%edx, %eax callfn1 movl%edx, %eax callfn2 xorl%eax, %eax ret ... The reload_combine doesn't trigger for this case.
[Bug libstdc++/66456] New: regex memory corruption on large input strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66456
Bug ID: 66456
Summary: regex memory corruption on large input strings
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: morandidodo at gmail dot com
Target Milestone: ---
I noticed a memory corruption with regex when using long input strings in
combination with multiple occurrences of a pattern. I built a simple testcase
to verify that.
regex_fault.cpp:
#include
#include
int main()
{
static const std::regex reFloats(R"(^(\s*-?\d+\.\d+)+\s*$)");
std::string input;
std::getline(std::cin, input);
if(std::regex_match(input, reFloats))
std::cout << "List of floats matched." << std::endl;
return 0;
}
$ g++ -Wall -Wextra -std=c++11 regex_fault.cpp -o regex_fault
$ echo "0.000 1.000 2.000" | ./regex_fault
List of floats matched.
$ OUT=""; for i in `seq 1`; do OUT="$OUT 0."; done; echo $OUT |
./regex_fault
Segmentation fault
The problem occurs also with the non-capture version of the regex. It does not
matter if I append the "-fno-strict-aliasing -fwrapv" flags to the compiler
options.
I do not know if this is a duplicate of 61582 or not.
I am using the last version of GCC supplied by Arch Linux on a x86_64 machine.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 --- Comment #8 from Jakub Jelinek --- (In reply to vries from comment #7) > (In reply to Jakub Jelinek from comment #6) > > The 0xe0UL constant is probably not very good for ilp32 targets. > > Try some < 4GB one if it still reproduces without the patch, or > > conditionalize it on __SIZEOF_POINTER__. > > I've tried with 0xe000U. The m64 case still reproduces. > > With -m32 -mregparm=1 we get: > ... > .cfi_startproc > callbar > sall$4, %eax > leal-536870912(%eax), %edx > movl%edx, %eax > callfn1 > movl%edx, %eax > callfn2 > xorl%eax, %eax > ret > ... > The reload_combine doesn't trigger for this case. It is very well possible it triggers only on x86_64-linux (or perhaps some other 64-bit targets), but still it would be better if the testcase could be compiled and run everywhere, so I'm all for using 0xe000UL or similar constant instead.
[Bug libstdc++/66417] std::codecvt_utf16 generates incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66417 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-08 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/66457] New: gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457
Bug ID: 66457
Summary: gcc generates an extra "mov ??, %edx" before "call
mcount" when "-pg" is enabled in cross compilation
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: leedypku at gmail dot com
Target Milestone: ---
# On Darwin, with cross compilation, some code omitted
$ echo 'int main(){}' | i386-jos-elf-gcc -pg -m32 -S -x c -o - -
main:
pushl %ebp
movl%esp, %ebp
.LP0:
movl$.LP0,%edx # this line
call_mcount
popl%ebp
ret
.ident "GCC: (GNU) 4.9.2"
# On Linux, some code omitted
$ echo 'int main(){}' | gcc -pg -S -m32 -x c -o - -
main:
pushl %ebp
movl%esp, %ebp
callmcount
popl%ebp
ret
.ident "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2"
1. It happens only in cross compilation.
2. The target is i386-jos-elf and the host is Darwin.
3. I've tested with GCC version 4.6.1, 4.6.4 and 4.9.2.
4. How can I disable it?
[Bug libfortran/66458] New: Loading libgfortran.so changes the FPU exception flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458
Bug ID: 66458
Summary: Loading libgfortran.so changes the FPU exception flags
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jan at epgmod dot phys.tue.nl
Target Milestone: ---
It appears that the mere act of loading libgfortran.so changes the FPU
exception mask. It looks as if the library contains initialization code that I
would have expected to appear in the program's start-up code. (Indeed it
appears to do so in line 266 of libgfortran/runtime/main.c.)
The problem can be reproduced by compiling the following C program:
// fpuflags
#include
#include
int main(int argc, char* argv[])
{
volatile double d=0;
feenableexcept(FE_ALL_EXCEPT);
if (argc==2)
{
dlopen(argv[1],RTLD_NOW);
}
// I expect the expression 1/d to generate an FPU exception:
return 1/d;
}
> gcc fpuflags.c -ldl -lm
> ./a.out
Floating point exception
> ./a.out /usr/lib64/libstdc++.so.6
Floating point exception
> ./a.out /usr/lib64/gcc/x86_64-suse-linux/4.8/libgfortran.so
> #nothing happens
After merely loading libgfortan.so, no FPU exceptions are generated anymore.
Loading libstdc++.so does not result in such problem.
This is a problem in my numerical application where libgfortran.so is loaded as
a depency of a plugin library that is loaded at runtime.
At first sight, this problem may be similar to that in PR20788.
[Bug target/66457] gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457 --- Comment #1 from Andrew Pinski --- Which compiler are you using to compile the cross compiler on Darwin? I can't tell if you have tried a cross compiler to elf under linux either, only the native one.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.0.1
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 Richard Biener changed: What|Removed |Added Target Milestone|4.0.1 |6.0
[Bug target/66457] gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457 --- Comment #2 from Dangyi Liu --- (In reply to Andrew Pinski from comment #1) > Which compiler are you using to compile the cross compiler on Darwin? I > can't tell if you have tried a cross compiler to elf under linux either, > only the native one. I compiled the cross compiler using clang. Now I'm trying to reproduce this bug under Linux.
[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458 --- Comment #1 from Andrew Pinski --- This is done on purpose.
[Bug middle-end/66432] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66432 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 Component|libgomp |middle-end Version|unknown |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458 Jan van Dijk changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Host||x86_64-unknown-linux-gnu Build||x86_64-unknown-linux-gnu --- Comment #2 from Jan van Dijk --- Could you elaborate on the rationale? I this behaviour is implementation-defined, this may need to be marked a documentation issue (assuming that I did not miss existing docs about the subject).
[Bug tree-optimization/66430] IPA CP alignment information is not used for expression simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66430 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 CC||rguenth at gcc dot gnu.org Component|ipa |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm. Visiting statement: _4 = _3 & 7; which is likely CONSTANT Lattice value changed to CONSTANT 0x0 (0x5). Adding SSA edges to worklist. marking stmt to be not simulated again so you expect it to be optimized to 5 but CCP does not propagate known misalignment.
[Bug target/66457] gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457
--- Comment #3 from Dangyi Liu ---
This still happens on Linux.
$ echo 'int main(){}' | ./i386-jos-elf-gcc -pg -m32 -S -x c -o - -
main:
pushl %ebp
movl%esp, %ebp
.LP0:
movl$.LP0,%edx
call_mcount
popl%ebp
.LCFI2:
ret
.ident "GCC: (GNU) 4.8.4"
$ ./i386-jos-elf-gcc -v
Using built-in specs.
COLLECT_GCC=./i386-jos-elf-gcc
COLLECT_LTO_WRAPPER=/home/leedy/gcc-4.8.4/bin/libexec/gcc/i386-jos-elf/4.8.4/lto-wrapper
Target: i386-jos-elf
Configured with: ../configure --prefix=/home/leedy/gcc-4.8.4/bin
--target=i386-jos-elf --disable-werror --disable-libssp --disable-libmudflap
--disable-multilib --disable-nls --without-headers --enable-languages=c
Thread model: single
gcc version 4.8.4 (GCC)
Did I do something wrong during with the configuration?
[Bug tree-optimization/66413] [6 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66413 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/66411] False positive in array bound check in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66411 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #1 from Richard Biener --- This has been fixed for 4.9.3
[Bug target/66457] gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457 --- Comment #4 from Andrew Pinski --- Yes you don't define NO_PROFILE_COUNTERS . That is the default i386-elf target defaults to NO_PROFILE_COUNTERS not being defined.
[Bug target/66457] gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- Invalid as explained.
[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66419 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I suppose we vectorize the init_data function. I will have a look.
[Bug sanitizer/66452] [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Mon Jun 8 10:35:24 2015 New Revision: 224216 URL: https://gcc.gnu.org/viewcvs?rev=224216&root=gcc&view=rev Log: PR sanitizer/66452 * toplev.c (check_global_declaration): Don't warn about artificial decls. * g++.dg/ubsan/pr66452.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr66452.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c
[Bug sanitizer/66452] [6 Regression] [UBSAN] *.Lubsan_data0' defined but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66452 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug tree-optimization/66422] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-06-08
CC||hubicka at gcc dot gnu.org
Component|c |tree-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Richard Biener ---
Ok, so we peeled the loop like
run_foo ()
{
...
:
_33 = myfoo_28->buf[3];
if (_33 != 1)
goto ;
else
goto ;
:
_34 = (int) _27;
if (_34 > 4)
goto ;
else
goto ;
:
__builtin_unreachable ();
_35 = myfoo_28->buf[4];
:
# _36 = PHI <0(2), 1(3), 0(4), 1(5), 0(6), 1(7), 0(8), 1(9), 0(10), 1(11),
0(12)>
if (_36 != 0)
goto ;
else
goto ;
:
i_37 = 1;
:
# _2 = PHI <0(13), -1(14)>
return _2;
and the unreachable () remains in the CFG.
Honza - it seems that remove_exits_and_undefined_stmts inserts these
unreachable calls but fails to split the BBs.
I have a patch.
[Bug tree-optimization/66422] [5/6 Regression] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 Richard Biener changed: What|Removed |Added Known to work||4.9.2 Target Milestone|--- |5.2 Summary|-Warray-bounds false|[5/6 Regression] |positive with -O3 |-Warray-bounds false ||positive with -O3
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #5 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00547.html
[Bug tree-optimization/66423] [6 Regression] a % (1 << b) no longer gets folded to a & (1 << b) for unsigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66423 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine.
[Bug middle-end/66325] [6 Regression] ICE in gcc.c-torture/execute/930408-1.c, verify_type fails with --enable-checking=yes on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66325 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- confirmed.
[Bug fortran/66459] New: bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459 Bug ID: 66459 Summary: bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized] Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mario-baumann at web dot de Target Milestone: --- Created attachment 35716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35716&action=edit Fortran Fixed Form File Hi All, The attached file generates bogus warnings if compiled with -Wall AND -O1(or higher optimizations). > gfortran -c -Wall -O1 foo.F foo.F:14:0: W(J,I) = 0 ^ Warning: 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized] foo.F:14:0: Warning: 'w.dim[1].stride' may be used uninitialized in this function [-Wmaybe-uninitialized] > gfortran -v Using built-in specs. COLLECT_GCC=./gfortran COLLECT_LTO_WRAPPER=/Build/gcc/5.1.0/install/libexec/gcc/x86_64-apple-darwin13/5.1.0/lto-wrapper Target: x86_64-apple-darwin13 Configured with: /Source/gcc/5.1.0/configure --prefix=/Build/gcc/5.1.0/install --build=x86_64-apple-darwin13 --enable-languages=c,c++,fortran,lto --enable-cloog-backend=isl --enable-stage1-checking --enable-lto --enable-libstdcxx-time --with-system-zlib --disable-cloog-version-check --disable-nls --disable-libquadmath-support Thread model: posix gcc version 5.1.0 (GCC) NOTEs: - -O0 works fine - same behaviour with gcc-4.9.2
[Bug libstdc++/66417] std::codecvt_utf16 generates incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66417 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 11:09:17 2015 New Revision: 224217 URL: https://gcc.gnu.org/viewcvs?rev=224217&root=gcc&view=rev Log: PR libstdc++/66417 * src/c++11/codecvt.cc (write_utf16_code_point): Use adjust_byte_order for single UTF-16 units. * testsuite/22_locale/codecvt/codecvt_utf16/66417.cc: New. Added: trunk/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/66417.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/codecvt.cc
[Bug c++/66460] New: ICE using __func__ in constexpr function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66460
Bug ID: 66460
Summary: ICE using __func__ in constexpr function.
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
constexpr char f() { return *__func__; }
constexpr char c = f();
pf.cc:2:21: in constexpr expansion of ‘f()’
pf.cc:2:22: internal compiler error: Segmentation fault
constexpr char c = f();
^
0x10ab4173 crash_signal
/home/jwakely/src/gcc/gcc/toplev.c:375
0x107394bc vec_safe_reserve
/home/jwakely/src/gcc/gcc/vec.h:577
0x107394bc vec_safe_push
/home/jwakely/src/gcc/gcc/vec.h:671
0x107394bc add_local_decl(function*, tree_node*)
/home/jwakely/src/gcc/gcc/function.c:6702
0x10b4a293 remap_decls
/home/jwakely/src/gcc/gcc/tree-inline.c:648
0x10b4b70f remap_block
/home/jwakely/src/gcc/gcc/tree-inline.c:718
0x10b51c47 copy_bind_expr
/home/jwakely/src/gcc/gcc/tree-inline.c:789
0x10b51c47 copy_tree_body_r(tree_node**, int*, void*)
/home/jwakely/src/gcc/gcc/tree-inline.c:1123
0x10df0593 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
/home/jwakely/src/gcc/gcc/tree.c:11182
0x10b42ddb copy_tree_body
/home/jwakely/src/gcc/gcc/tree-inline.c:2959
0x10b548e3 copy_fn(tree_node*, tree_node*&, tree_node*&)
/home/jwakely/src/gcc/gcc/tree-inline.c:5989
0x1044f3d7 cxx_eval_call_expression
/home/jwakely/src/gcc/gcc/cp/constexpr.c:1353
0x10451567 cxx_eval_constant_expression
/home/jwakely/src/gcc/gcc/cp/constexpr.c:3074
0x1045871b cxx_eval_outermost_constant_expr
/home/jwakely/src/gcc/gcc/cp/constexpr.c:3577
0x1028326b store_init_value(tree_node*, tree_node*, vec**, int)
/home/jwakely/src/gcc/gcc/cp/typeck2.c:829
0x101cf907 check_initializer
/home/jwakely/src/gcc/gcc/cp/decl.c:6024
0x101ff50f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/jwakely/src/gcc/gcc/cp/decl.c:6636
0x1032f163 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/cp/parser.c:17320
0x103320c3 cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/cp/parser.c:11612
0x10329a67 cp_parser_block_declaration
/home/jwakely/src/gcc/gcc/cp/parser.c:11486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug libstdc++/66417] std::codecvt_utf16 generates incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66417 --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far.
[Bug middle-end/66434] cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66434
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
The issue is in IVOPTs:
#13 0x011ed370 in create_iv (base=,
step=, var=,
loop=0x76a4d620, incr_pos=0x7fffd880, after=true,
var_before=0x2523a20, var_after=0x2523a28)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-manip.c:147
147 step = force_gimple_operand (step, &stmts, true, NULL_TREE);
(gdb) l
142 step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
143 incr_op = POINTER_PLUS_EXPR;
144 }
145 /* Gimplify the step if necessary. We put the computations in front
of the
146 loop (i.e. the step should be loop invariant). */
147 step = force_gimple_operand (step, &stmts, true, NULL_TREE);
148 if (stmts)
149 gsi_insert_seq_on_edge_immediate (pe, stmts);
150
151 stmt = gimple_build_assign (va, incr_op, vb, step);
ends up trying to gimplfy
(long unsigned int) ((if (_40 > 0)
{
iftmp.23 = _14 + 1;
}
else
{
iftmp.23 = 1;
}) * pretmp_43)
but we can't put GENERIC COND_EXPR into GIMPLE via force_gimple_operand ().
At least not iff it contains possibly trapping operations.
ISTR fixing up places to avoid gobbling up trapping expressions, so I'll have
a look (it's SCEV analysis).
[Bug middle-end/66434] cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66434 --- Comment #3 from Richard Biener --- Ok, so it boils down to fold-const.c moving computations into cond ? expr : cst and thus exposing the possible trapping expressions inside the conditional (which comes from number of iteration analysis maybe-zero condition). There isn't a convenient way to disable this (and no reason to do that for GENERIC). #0 fold_build2_stat_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/fold-const.c:14279 #1 0x00c52d78 in fold_plusminus_mult_expr (loc=0, code=PLUS_EXPR, type=, arg0=, arg1=) at /space/rguenther/tramp3d/trunk/gcc/fold-const.c:7274 #2 0x00c5f5cc in fold_binary_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/fold-const.c:10086 #3 0x00c75289 in fold_build2_stat_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/fold-const.c:14279 #4 0x00c5e758 in fold_binary_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/fold-const.c:9912 #5 0x00c75289 in fold_build2_stat_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/fold-const.c:14279 #6 0x0188ed24 in chrec_fold_plus_1 (code=PLUS_EXPR, type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/tree-chrec.c:360 #7 0x0188ee34 in chrec_fold_plus ( type=, op0=, op1=) at /space/rguenther/tramp3d/trunk/gcc/tree-chrec.c:393 #8 0x0115477e in add_to_evolution_1 (loop_nb=4, chrec_before=, to_add=, at_stmt=) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:672 #9 0x01154b2e in add_to_evolution (loop_nb=4, chrec_before=, code=PLUS_EXPR, to_add=, at_stmt=) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:865 #10 0x01154f70 in follow_ssa_edge_binary (loop=0x76a4d620, at_stmt=, type=, rhs0=, code=PLUS_EXPR, rhs1=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd460, limit=2) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1008 #11 0x0115531e in follow_ssa_edge_expr (loop=0x76a4d620, at_stmt=, expr=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd460, limit=2) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1113 #12 0x01155a63 in follow_ssa_edge_inner_loop_phi ( outer_loop=0x76a4d620, loop_phi_node=0x76a5cb00, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd460, limit=2) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1340 #13 0x01155b91 in follow_ssa_edge (loop=0x76a4d620, def=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd460, limit=1) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1389 #14 0x01154d8b in follow_ssa_edge_binary (loop=0x76a4d620, at_stmt=, type=, rhs0=, code=PLUS_EXPR, rhs1=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd5d0, limit=1) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:961 #15 0x0115565b in follow_ssa_edge_in_rhs (loop=0x76a4d620, stmt=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd5d0, limit=0) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1181 #16 0x01155bb8 in follow_ssa_edge (loop=0x76a4d620, def=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd5d0, limit=0) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1396 #17 0x011557b4 in follow_ssa_edge_in_condition_phi_branch (i=0, loop=0x76a4d620, condition_phi=0x76a5c900, halting_phi=0x76a5c300, evolution_of_branch=0x7fffd5d0, init_cond=, limit=0) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1236 #18 0x01155811 in follow_ssa_edge_in_condition_phi ( loop=0x76a4d620, condition_phi=0x76a5c900, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd680, limit=0) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1264 #19 0x01155b24 in follow_ssa_edge (loop=0x76a4d620, def=, halting_phi=0x76a5c300, evolution_of_loop=0x7fffd680, limit=0) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1371 #20 0x0115603f in analyze_evolution_in_loop ( loop_phi_node=0x76a5c300, init_cond=) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1507 #21 0x011564f9 in interpret_loop_phi (loop=0x76a4d620, loop_phi_node=0x76a5c300) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evolution.c:1660 #22 0x0115784c in analyze_scalar_evolution_1 (loop=0x76a4d620, var=, res=) at /space/rguenther/tramp3d/trunk/gcc/tree-scalar-evol
[Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396
--- Comment #6 from Richard Biener ---
The issue is corrupted VOPs.
:
# .MEM_4 = VDEF <.MEM_3(D)>
iD.1808@ = 1;
# .MEM_5 = VDEF <.MEM_4>
xD.1810@ = &iD.1808@;
# .MEM_6 = VDEF <.MEM_5>
yD.1811@ = &jD.1807@;
# .MEM_7 = VDEF <.MEM_6>
fD.1806@.pD.1801 = &yD.1811@;
# .MEM_8 = VDEF <.MEM_7>
fD.1806@.qD.1802 = &xD.1810@;
# PT = { D.1806 }
p_25 = &fD.1806@ + 4;
# .MEM_28 = VDEF <.MEM_3(D)>
jD.1807@ = 4;
see how that uses the wrong VUSE.
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 --- Comment #6 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jun 8 11:53:27 2015 New Revision: 224218 URL: https://gcc.gnu.org/viewcvs?rev=224218&root=gcc&view=rev Log: Fix try_transform_to_exit_first_loop_alt 2015-06-08 Tom de Vries PR tree-optimization/66442 * gimple-iterator.h (gimple_seq_nondebug_singleton_p): Add function. * tree-parloops.c (try_transform_to_exit_first_loop_alt): Return false if the loop latch is not a singleton. Use gimple_seq_nondebug_singleton_p instead of gimple_seq_singleton_p. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-iterator.h trunk/gcc/tree-parloops.c
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
Markus Trippelsdorf changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||trippels at gcc dot gnu.org
--- Comment #6 from Markus Trippelsdorf ---
A bit more reduced:
% cat test_66214.ii
class A;
template class B {
typedef A value_type;
void m_fn1(const value_type &);
};
class A {
int m_upperBorder;
B<> m_tupelTypes;
};
% g++ -c -g test_66214.ii
test_66214.ii: In instantiation of ‘class B<>’:
test_66214.ii:8:7: required from here
test_66214.ii:2:33: error: TYPE_CANONICAL is not compatible
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jun 8 11:59:20 2015 New Revision: 224219 URL: https://gcc.gnu.org/viewcvs?rev=224219&root=gcc&view=rev Log: Fix try_transform_to_exit_first_loop_alt 2015-06-08 Tom de Vries backport from trunk: 2015-06-08 Tom de Vries PR tree-optimization/66442 * gimple-iterator.h (gimple_seq_nondebug_singleton_p): Add function. * tree-parloops.c (try_transform_to_exit_first_loop_alt): Return false if the loop latch is not a singleton. Use gimple_seq_nondebug_singleton_p instead of gimple_seq_singleton_p. Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/gimple-iterator.h branches/gomp-4_0-branch/gcc/tree-parloops.c
[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 Bug 65443 depends on bug 66442, which changed state. Bug 66442 Summary: [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from vries at gcc dot gnu.org --- patch committed to trunk and gomp-4_0-branch. marking resolved-fixed.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #9 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00553.html
[Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396 --- Comment #7 from Richard Biener --- The code in SESE doesn't deal with virtual operands correctly. In other places GRAPHITE tries to paper over this with marking all vops for renaming. But that isn't done when no code is generated, thus this breaks.
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #5 from vries at gcc dot gnu.org --- patch: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01063.html
[Bug tree-optimization/66013] Missed optimization after inlining va_list parameter, -m32 case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66013 vries at gcc dot gnu.org changed: What|Removed |Added Keywords|patch | --- Comment #6 from vries at gcc dot gnu.org --- Removing patch keyword. Discussed patch in https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00886.html .
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 --- Comment #6 from vries at gcc dot gnu.org --- stage1 ping^2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00557.html
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #10 from vries at gcc dot gnu.org --- ping ^2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00558.html
[Bug fortran/66461] New: ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 Bug ID: 66461 Summary: ICE on missing end program in fixed source Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A missing end program in a "fixed" source s.f : program p integer x(2) x = 0 if ( x(1) < 0 .or. &x(2) < 0 ) print *, x !end yields : f951: internal compiler error: free_expr0(): Bad expr type --- Whereas a missing end program in a "free" source s.f90 : program p integer x(2) x = 0 if ( x(1) < 0 .or. & x(2) < 0 ) print *, x !end yields : f951: Error: Unexpected end of file in 's.f90'
[Bug libstdc++/66441] wstring_convert not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66441 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 13:03:45 2015 New Revision: 224222 URL: https://gcc.gnu.org/viewcvs?rev=224222&root=gcc&view=rev Log: PR libstdc++/66441 * testsuite/22_locale/conversions/string/66441.cc: New. * include/bits/locale_conv.h (__do_str_codecvt): Reserve enough space in the output string for BOM and complete result. Added: trunk/libstdc++-v3/testsuite/22_locale/conversions/string/66441.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_conv.h
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 --- Comment #5 from jkratoch at gcc dot gnu.org --- Author: jkratoch Date: Mon Jun 8 13:35:51 2015 New Revision: 224223 URL: https://gcc.gnu.org/viewcvs?rev=224223&root=gcc&view=rev Log: PR other/65366 * gdbhooks.py: Import sys. (intptr): New function. Replace int(...) by intptr(...). Modified: trunk/gcc/ChangeLog trunk/gcc/gdbhooks.py
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 Jan Kratochvil changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Kratochvil --- Checked in Comment 4 fix.
[Bug target/66457] gcc generates an extra "mov ??, %edx" before "call mcount" when "-pg" is enabled in cross compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66457 --- Comment #6 from Dangyi Liu --- (In reply to Andrew Pinski from comment #4) > Yes you don't define NO_PROFILE_COUNTERS . That is the default i386-elf > target defaults to NO_PROFILE_COUNTERS not being defined. Thank you very much!!! But I don't know how to define this macro during building phase, and I can't find any useful information using Google. Could you help me ?
[Bug libstdc++/66417] std::codecvt_utf16 generates incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66417 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 13:42:46 2015 New Revision: 224224 URL: https://gcc.gnu.org/viewcvs?rev=224224&root=gcc&view=rev Log: PR libstdc++/66417 * src/c++11/codecvt.cc (write_utf16_code_point): Use adjust_byte_order for single UTF-16 units. * testsuite/22_locale/codecvt/codecvt_utf16/66417.cc: New. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/66417.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/src/c++11/codecvt.cc
[Bug libstdc++/66441] wstring_convert not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66441 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 13:42:51 2015 New Revision: 224225 URL: https://gcc.gnu.org/viewcvs?rev=224225&root=gcc&view=rev Log: PR libstdc++/66441 * testsuite/22_locale/conversions/string/66441.cc: New. * include/bits/locale_conv.h (__do_str_codecvt): Reserve enough space in the output string for BOM and complete result. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/22_locale/conversions/string/66441.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/locale_conv.h
[Bug libstdc++/66441] wstring_convert not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66441 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #4 from Jonathan Wakely --- Fixed for 5.2
[Bug libstdc++/66417] std::codecvt_utf16 generates incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66417 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #4 from Jonathan Wakely --- Fixed for 5.2, thanks for the reports.
[Bug tree-optimization/66413] [6 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66413
--- Comment #3 from Richard Biener ---
Ok, so IPA-CP propagates a constant to fn4 but this function has its parameter
unused (but by debug stmts). It looks like we have a tree sharing issue here,
as the location while initially stripped, gets substituted back in via
#0 expand_gimple_stmt_1 (stmt=)
at /space/rguenther/tramp3d/trunk/gcc/cfgexpand.c:3317
3315if (gimple_has_location (stmt) && CAN_HAVE_LOCATION_P
(rhs))
3316 SET_EXPR_LOCATION (rhs, gimple_location (stmt));
which is expansion of fn2.constprop (but the same address-expression is
used in fn4.constprop). The following fixes it for me:
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 224221)
+++ gcc/tree-inline.c (working copy)
@@ -3027,7 +3027,7 @@ insert_init_debug_bind (copy_body_data *
base_stmt = gsi_stmt (gsi);
}
- note = gimple_build_debug_bind (tracked_var, value, base_stmt);
+ note = gimple_build_debug_bind (tracked_var, unshare_expr (value),
base_stmt);
if (bb)
{
the issue is surely latent on the GCC 5 branch.
[Bug libstdc++/66327] -fsanitize=nonnull-attribute errors in stl_algobase.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66327 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 14:19:10 2015 New Revision: 224230 URL: https://gcc.gnu.org/viewcvs?rev=224230&root=gcc&view=rev Log: PR libstdc++/66354 * include/bits/stl_algobase.h (__fill_a): Check length before calling memset. PR libstdc++/66327 * include/bits/stl_algobase.h (__equal::equal): Do not call memcmp for empty ranges. (__lexicographical_compare::__lc): Likewise. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/stl_algobase.h
[Bug libstdc++/66354] [UBSAN] stl_algobase.h:708:7: runtime error: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66354 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 14:19:10 2015 New Revision: 224230 URL: https://gcc.gnu.org/viewcvs?rev=224230&root=gcc&view=rev Log: PR libstdc++/66354 * include/bits/stl_algobase.h (__fill_a): Check length before calling memset. PR libstdc++/66327 * include/bits/stl_algobase.h (__equal::equal): Do not call memcmp for empty ranges. (__lexicographical_compare::__lc): Likewise. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/stl_algobase.h
[Bug middle-end/66462] New: GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
Bug ID: 66462
Summary: GCC isinf/isnan/... builtins cause sNaN exceptions
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
The isinf, isnan, isnormal, isfinite, fpclassify and signbit builtins use FP
arithmetic to compute their result even with -fsignaling-nans (signbit only
when -ffast-math is also used). This means sNaNs cause invalid operation
exceptions which is incorrect according to the IEEE754-2008 standard.
The reason is the use of FP comparisons. Integer arithmetic avoids this, and is
typically faster, especially when using softfloat.
int snan_fail(double x)
{
return __builtin_isinf (x);
}
gcc6.0 -O2 -fsignaling-nans generates for AArch64:
snan_fail:
ldr d1, .LC7
fabsd0, d0
fcmpd0, d1 // will signal on sNaN...
csetw0, gt
ret
[Bug libstdc++/66327] -fsanitize=nonnull-attribute errors in stl_algobase.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66327 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 14:42:02 2015 New Revision: 224233 URL: https://gcc.gnu.org/viewcvs?rev=224233&root=gcc&view=rev Log: PR libstdc++/66354 * include/bits/stl_algobase.h (__fill_a): Check length before calling memset. PR libstdc++/66327 * include/bits/stl_algobase.h (__equal::equal): Do not call memcmp for empty ranges. (__lexicographical_compare::__lc): Likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/stl_algobase.h
[Bug libstdc++/66354] [UBSAN] stl_algobase.h:708:7: runtime error: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66354 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #9 from Jonathan Wakely --- Fixed for 4.9.3, 5.2 and 6.0
[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66419 --- Comment #3 from Richard Biener --- Ah, because we detect it as subchain which fails to consider gaps.
[Bug fortran/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-08 CC||mikael at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Mikael Morin --- Confirmed. Possibly related bug: PR60500 (In reply to Mario Baumann from comment #0) > - -O0 works fine This is expected, uninitializedness may only become apparent to the compiler after some optimization passes have simplified/reorganized the code.
[Bug libstdc++/66354] [UBSAN] stl_algobase.h:708:7: runtime error: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66354 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Mon Jun 8 14:42:02 2015 New Revision: 224233 URL: https://gcc.gnu.org/viewcvs?rev=224233&root=gcc&view=rev Log: PR libstdc++/66354 * include/bits/stl_algobase.h (__fill_a): Check length before calling memset. PR libstdc++/66327 * include/bits/stl_algobase.h (__equal::equal): Do not call memcmp for empty ranges. (__lexicographical_compare::__lc): Likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/stl_algobase.h
[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66419
--- Comment #2 from Richard Biener ---
The difference is that we vectorize parts of stdarg_func:
:
_57 = ap.__vr_top;
_58 = (sizetype) _39;
_59 = _57 + _58;
_60 = *_59;
MEM[(float *)&ha.20] = _60;
_64 = _58 + 16;
_65 = _57 + _64;
_66 = MEM[(float *)_65];
MEM[(float *)&ha.20 + 4B] = _66;
_70 = _58 + 32;
_71 = _57 + _70;
_72 = MEM[(float *)_71];
MEM[(float *)&ha.20 + 8B] = _72;
_76 = _58 + 48;
_77 = _57 + _76;
_78 = MEM[(float *)_77];
MEM[(float *)&ha.20 + 12B] = _78;
to
:
_57 = ap.__vr_top;
_58 = (sizetype) _39;
_59 = _57 + _58;
_60 = *_59;
_64 = _58 + 16;
_65 = _57 + _64;
_66 = MEM[(float *)_65];
_70 = _58 + 32;
_71 = _57 + _70;
_72 = MEM[(float *)_71];
_76 = _58 + 48;
_77 = _57 + _76;
vectp.40_138 = _59;
vect__60.41_125 = MEM[(float *)vectp.40_138];
_78 = MEM[(float *)_77];
vectp.43_107 = &ha.20;
MEM[(float *)vectp.43_107] = vect__60.41_125;
which looks bogus. The load permutation
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.h:98:6:
note: Load permutation 0 4 8 12
due to the gaps isn't reflected in the transform. And of course cost
considerations should prohibit the transform (but well).
C testcase that fails on x86_64 as well:
extern void abort (void);
int a[16];
int b[4];
void __attribute__((noinline))
foo (void)
{
b[0] = a[0];
b[1] = a[4];
b[2] = a[8];
b[3] = a[12];
}
int main()
{
int i;
for (i = 0; i < 16; ++i)
{
a[i] = i;
__asm__ volatile ("");
}
foo ();
if (b[0] != 0 || b[1] != 4 || b[2] != 8 || b[3] != 12)
abort ();
return 0;
}
[Bug tree-optimization/66422] [5/6 Regression] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Jun 8 14:53:19 2015 New Revision: 224235 URL: https://gcc.gnu.org/viewcvs?rev=224235&root=gcc&view=rev Log: 2015-06-08 Richard Biener PR tree-optimization/66422 * tree-ssa-loop-ivcanon.c (remove_exits_and_undefined_stmts): Split block after inserted gcc_unreachable. * gcc.dg/Warray-bounds-16.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c
[Bug bootstrap/65988] Trying to compile GCC 5.1 in my (customized) Solaris 10/x86-64 fails with GMP errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65988 --- Comment #3 from Jesus Cea --- Ping...
[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 --- Comment #1 from Wilco --- Note when this is fixed, GLIBC math/math.h should be updated to enable the isinf builtins even with -fsignaling-nans.
[Bug libstdc++/66327] -fsanitize=nonnull-attribute errors in stl_algobase.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66327 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #4 from Jonathan Wakely --- Fixed for 4.9.3, 5.2 and 6.0
[Bug bootstrap/65988] Trying to compile GCC 5.1 in my (customized) Solaris 10/x86-64 fails with GMP errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65988 --- Comment #4 from Jonathan Wakely --- You could try building without ISL.
[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 --- Comment #12 from Jonathan Wakely --- I think the patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00590.html should be equivalent, if you have time to check it that would be great.
[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66415 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Mon Jun 8 15:16:12 2015 New Revision: 224236 URL: https://gcc.gnu.org/viewcvs?rev=224236&root=gcc&view=rev Log: PR c/66415 * c-format.c (location_from_offset): Return LOC if LINE is null. * line-map.c (linemap_position_for_loc_and_offset): Remove linemap_assert_fails; reverse conditions. * gcc.dg/cpp/pr66415-1.c: New test. * gcc.dg/cpp/pr66415-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/pr66415-1.c trunk/gcc/testsuite/gcc.dg/cpp/pr66415-2.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Jan van Dijk from comment #0)
> It appears that the mere act of loading libgfortran.so changes the FPU
> exception mask. It looks as if the library contains initialization code that
> I would have expected to appear in the program's start-up code. (Indeed it
> appears to do so in line 266 of libgfortran/runtime/main.c.)
>
> The problem can be reproduced by compiling the following C program:
>
> // fpuflags
> #include
> #include
#pragma STDC FENV_ACCESS ON
> int main(int argc, char* argv[])
> {
> volatile double d=0;
fenv_t fpu;
> feenableexcept(FE_ALL_EXCEPT);
> if (argc==2)
> {
fegetenv(&fpu);
> dlopen(argv[1],RTLD_NOW);
fesetenv(&fpu);
> }
> // I expect the expression 1/d to generate an FPU exception:
> return 1/d;
> }
>
> > gcc fpuflags.c -ldl -lm
> > ./a.out
> Floating point exception
> > ./a.out /usr/lib64/libstdc++.so.6
> Floating point exception
> > ./a.out /usr/lib64/gcc/x86_64-suse-linux/4.8/libgfortran.so
> > #nothing happens
>
> After merely loading libgfortan.so, no FPU exceptions are generated anymore.
> Loading libstdc++.so does not result in such problem.
>
> This is a problem in my numerical application where libgfortran.so is loaded
> as a depency of a plugin library that is loaded at runtime.
You're loading a dynamic library that has a constructor that is
executed to set up the library's internal state. If you're loading
libraries and you want a specific FPU state, then you'll need to
save and reset the state.
--
steve
[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66415 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #5 from Aldy Hernandez ---
I don't have access to a Darwin box. Could you provide a preprocessed file so I
can try to reproduce the defined but not used problem on a cross build?
Also, what triplet?
Thanks.
On Jun 7, 2015 4:09 AM, "iains at gcc dot gnu.org"
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
>
> --- Comment #1 from Iain Sandoe ---
> Created attachment 35710
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35710&action=edit
> declare "extern int __CFConstantStringClassReference" lazily
>
> There seem to be three issues triggered by 224161
>
> 1. Debug is not initialised when the built-ins are initialised, therefore
> any
> attempt to declare a variable at that time causes the segv. (hash table is
> not
> present).
>
> * at present, *darwin* declares "extern int
> __CFConstantStringClassReference[]" at the time that the CFString built-in is
> initialised.
>
> - on the basis that it's not clear *if* such early declarations are allowed,
> I've made a patch that makes the declaration lazily (when the fist use of the
> built-in occurs).
>
> This works around the reported crash (one could also use DECL_SOURCE_LOCATION
> != BUILTINS_LOCATION as an additional test at passes.c:338, if built-ins
> *are*
> supposed to be allowed to declare variables.
>
> … however ...
>
>
>
> 2. Once (1) is fixed, bootstrap then fails with:
>
> /GCC/gcc-trunk/gcc/ipa-pure-const.c:1640:1: error:
> ‘{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)’
> defined
> but not used [-Werror=unused-function]
> pass_ipa_pure_const::
>
> A --disable-werror boostrap completes, but there are a number of constructors
> and destructors that report "declared but not used". AFAICT, it's only
> constructors/destructors.
>
> This is occurring at stage #2, and I thought maybe that the stage#1 compiler
> could have been mis-compiled by the bootstrap; however, gcc-4.9, 5.1 and
> clang
> (xcode 5.1.1) bootstraps all give the same result.
>
> … additional info …
>
> =
>
> 3. During bootstrap (and in the test suite on the --disable-werror build)
> there
> are a large number of warnings from ld64 (of course, this might be a
> limitation
> of ld64, but for the record):
>
> warning: invalid DWARF generated by the compiler: DIE 0x02f7 has multiple
> AT_location attributes in
> '/GCC/ml/gcc-trunk-xtools/x86_64-apple-darwin12/libgcc/enable-execute-stack_s.o'.
>
> warning: invalid DWARF generated by the compiler: DIE 0x0317 has multiple
> AT_location attributes in
> '/GCC/ml/gcc-trunk-xtools/x86_64-apple-darwin12/libgcc/enable-execute-stack_s.o'.
>
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug bootstrap/66252] [6 regression] bootstrap comparison failures on sparc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66252
--- Comment #6 from Eric Botcazou ---
cse.c:fold_rtx is miscompiled by the stage2 compiler, more precisely in:
if (const_arg1 != 0 && CONST_INT_P (const_arg1)
&& INTVAL (const_arg1) < 0
/* This used to test
-INTVAL (const_arg1) >= 0
But The Sun V5.0 compilers mis-compiled that test. So
instead we test for the problematic value in a more direct
manner and hope the Sun compilers get it correct. */
&& INTVAL (const_arg1) !=
((HOST_WIDE_INT) 1 << (HOST_BITS_PER_WIDE_INT - 1))
&& REG_P (folded_arg1))
{
rtx new_const = GEN_INT (-INTVAL (const_arg1));
the -INTVAL is miscompiled:
=> 0x00a94d58 <+4884>: subcc %g0, %o3, %o2
0x00a94d5c <+4888>: clr %o0
0x00a94d60 <+4892>: call 0x35044c
0x00a94d64 <+4896>: subc %g0, %o2, %o1
%o2 is wrongly clobbered by the first subtraction.
[Bug bootstrap/66252] [6 regression] bootstrap comparison failures on sparc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66252 --- Comment #7 from Eric Botcazou --- It's a known fragility of the SPARC back-end in 32-bit mode, which really wants to forbid DImode values in odd-numbered registers. The problem is that the calling conventions for 'long long' disagree, so DImode destinations can be odd-numbered registers in the end...
[Bug fortran/66245] ICE on select type with empty type spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66245 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Jun 8 15:55:16 2015 New Revision: 224237 URL: https://gcc.gnu.org/viewcvs?rev=224237&root=gcc&view=rev Log: 2015-06-08 Steven G. Kargl PR fortran/66245 * match.c (gfc_match_type_is, gfc_match_class_is): Check if the return type spec or derived type spec is validate. 2015-06-08 Steven G. Kargl PR fortran/66245 * gfortran.dg/class_is_1.f90: New test. * gfortran.dg/type_is_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/class_is_1.f90 trunk/gcc/testsuite/gfortran.dg/type_is_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239 --- Comment #6 from Maciej Andrzejewski --- Libm and other libs have been mixed. Properly compiled toolchain with libs solved the problem. Thank you all for assistance!
[Bug bootstrap/65988] Trying to compile GCC 5.1 in my (customized) Solaris 10/x86-64 fails with GMP errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65988 --- Comment #5 from Jesus Cea --- Could you possibly tell me how to do it and what the impact would be? Thanks!
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239 Maciej Andrzejewski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Maciej Andrzejewski --- Libm and other libs have been mixed. Properly compiled toolchain with libs solved the problem. Thank you all for assistance!
[Bug fortran/66245] ICE on select type with empty type spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66245 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Jun 8 16:45:56 2015 New Revision: 224238 URL: https://gcc.gnu.org/viewcvs?rev=224238&root=gcc&view=rev Log: 2015-06-08 Steven G. Kargl PR fortran/66245 * match.c (gfc_match_type_is, gfc_match_class_is): Check if the return type spec or derived type spec is validate. 2015-06-08 Steven G. Kargl PR fortran/66245 * gfortran.dg/class_is_1.f90: New test. * gfortran.dg/type_is_1.f90: Ditto. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/class_is_1.f90 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/type_is_1.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/match.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
