[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 --- Comment #17 from vries at gcc dot gnu.org --- Author: vries Date: Thu May 28 21:23:54 2015 New Revision: 223848 URL: https://gcc.gnu.org/viewcvs?rev=223848root=gccview=rev Log: Add transform_to_exit_first_loop_alt 2015-05-28 Tom de Vries t...@codesourcery.com PR tree-optimization/65443 * tree-parloops.c (replace_imm_uses, replace_uses_in_bb_by) (replace_uses_in_bbs_by, transform_to_exit_first_loop_alt) (try_transform_to_exit_first_loop_alt): New function. (transform_to_exit_first_loop): Use try_transform_to_exit_first_loop_alt. * gcc.dg/parloops-exit-first-loop-alt-2.c: New test. * gcc.dg/parloops-exit-first-loop-alt-3.c: New test. * gcc.dg/parloops-exit-first-loop-alt.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt-2.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt.c: New test. Added: branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-2.c branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-3.c branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-2.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt.c Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-4_0-branch/gcc/tree-parloops.c branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
[Bug tree-optimization/66330] New: gcc.c-torture/execute/20040709-1.c compilation fatal error with -flto -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66330 Bug ID: 66330 Summary: gcc.c-torture/execute/20040709-1.c compilation fatal error with -flto -O2 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- ... $ build/gcc/xgcc -Bbuild/gcc/ src/gcc/testsuite/gcc.c-torture/execute/20040709-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -w -lm -o ./20040709-1.exe -save-temps -fipa-pta lto1: fatal error: 20040709-1.exe.ltrans1.o: section s.1837.lto_priv.0 is missing compilation terminated. lto-wrapper: fatal error: build/gcc/xgcc returned 1 exit status compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status ...
[Bug libstdc++/66017] Undefined behaviour in std::setlong long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017 --- Comment #7 from M. Hanselmann public at hansmi dot ch --- Confirmed for revision 223846 in gcc-5-branch. Thank you!
[Bug c++/66329] If condition evaluated wrongly for y1 == 0 condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66329 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- has lower precedence than ==.
[Bug c++/66329] New: If condition evaluated wrongly for y1 == 0 condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66329 Bug ID: 66329 Summary: If condition evaluated wrongly for y1 == 0 condition Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: shimple0 at yahoo dot com Target Milestone: --- Created attachment 35649 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35649action=edit test code of sample runs gcc (GCC) 4.8.3 Target: x86_64-pc-cygwin $ g++ gcc-bug.cpp $ ./a.exe 3 y:3, y1=1 Testing with 'if (y1 == 0)' y1 != 0 Testing with 'if (y1 == 1)' y1 == 1 $ ./a.exe 2 y:2, y1=0 Testing with 'if (y1 == 0)' y1 != 0 Testing with 'if (y1 == 1)' y1 != 1 Haven't tested it for other data types than int, unsigned int. Haven't tested it with gcc, but this bug could be there as well.
[Bug c++/66329] If condition evaluated wrongly for y1 == 0 condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66329 --- Comment #2 from sandeep shimple0 at yahoo dot com --- (In reply to Markus Trippelsdorf from comment #1) has lower precedence than ==. Thanks Markus. It never occurred to me when hit by a bug in some other code. I myself was wondering how could this kind of bug stay undiscovered for so long, if it was. I shall be more careful when reporting bug/issue in future.
[Bug c++/66329] If condition evaluated wrongly for y1 == 0 condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66329 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This is warned by -Wparentheses (which is enabled by -Wall): test.cc:9:8: warning: suggest parentheses around comparison in operand of ‘’ [-Wparentheses] if (y1 == 0) ^ You should use -Wall -Wextra before reporting bugs, as the bug reporting instructions say. (although the warning text has never sounded clear to me)
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Eric Gallager from comment #2) The -Wc90-c99-compat that made it into gcc5 currently warns about any usage of bool whatsoever, not just the specific usages of bool listed in this bug... Right, that was the point of it.
[Bug fortran/66328] Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-28 Blocks||32834 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 [Bug 32834] [Meta-bug] 'Fortran 95'-only failures
[Bug c/66326] New: Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 Bug ID: 66326 Summary: Floating point exception with -mfpmath=387 and -fcilkplus. Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ejolson at unr dot edu Target Milestone: --- Created attachment 35648 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35648action=edit Test code to illustrate bug. Must be run on at least a 2-core system. There appears a regression between the cilkplus-4_8-branch and the gcc-4.9 and gcc-5.1 compilers when merging cilk into mainline. In particular, the flags -mfpmath=387 and -fcilkplus can't be used together. As -mfpmath=sse is not an option on 32-bit, this renders cilk essentially useless on non-64-bit Intel architectures for floating point.
[Bug fortran/66310] Problems with intrinsic repeat for large number of copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Gerhard Steinmetz from comment #3) I do agree, that some extra temporary data is necessary and there should be a practical (high) limit for something like that. Let the helper buffers be five or ten times the amount of the effectively written data. That's OK. But it's not a billion times as suggested by the huge number 18446744065119617024. Something IS going wrong here. I agree, I don't understand this either.
[Bug libstdc++/66327] -fsanitize=nonnull-attribute errors in stl_algobase.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66327 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-28 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/66327] New: -fsanitize=nonnull-attribute errors in stl_algobase.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66327
Bug ID: 66327
Summary: -fsanitize=nonnull-attribute errors in stl_algobase.h
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include vector
#include array
int main()
{
std::vectorunsigned a;
std::vectorunsigned b;
std::arrayunsigned char, 0 aa, bb;
a == b;
a b;
aa == bb;
aa bb;
}
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/stl_algobase.h:825:28: runtime
error: null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/stl_algobase.h:825:28: runtime
error: null pointer passed as argument 2, which is declared to never be null
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/stl_algobase.h:825:28: runtime
error: null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/stl_algobase.h:825:28: runtime
error: null pointer passed as argument 2, which is declared to never be null
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/stl_algobase.h:931:31: runtime
error: null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/stl_algobase.h:931:31: runtime
error: null pointer passed as argument 2, which is declared to never be null
[Bug c/66326] Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 --- Comment #1 from Eric ejolson at unr dot edu --- The compilers gcc-5.1 and cilkplus-4_8-branch were bootstrapped using the Debian 4.7.2-5 gcc compiler on Debian Wheezy. Compiling and running the test program yields the following output: $ /usr/local/gcc-5.1/bin/gcc -fcilkplus -Wall \ -mfpmath=387 fpbug.c -o fpbug-gcc510-387 -lcilkrts -lm $ ./fpbug-gcc510-387 Floating point exception $ /usr/local/gcc-5.1/bin/gcc -fcilkplus -Wall \ -mfpmath=sse fpbug.c -o fpbug-gcc510-sse -lcilkrts -lm $ ./fpbug-gcc510-sse f(1)+g(2)=0.850648 $ /usr/local/cilk-4.8/bin/gcc -fcilkplus -Wall \ -mfpmath=387 fpbug.c -o fpbug-cilk48-387 -lcilkrts -lm $ ./fpbug-cilk48-387 f(1)+g(2)=0.850648 $ /usr/local/cilk-4.8/bin/gcc -fcilkplus -Wall \ -mfpmath=sse fpbug.c -o fpbug-cilk48-sse -lcilkrts -lm $ ./fpbug-cilk48-sse f(1)+g(2)=0.850648
why - warning: array subscript is above array bounds
Hi there
I Japanese.
Poor English.
I like gcc.
But,
Why,
gcc is, in this code, or put out a warning?
-O4 only???
+ cat -n bug.c
1#include stdio.h
2intary[2][12] ;
3voidfunc(intx,int y)
4{
5inti,j ;
6for(i = 0 ; i x ; i++) {
7for(j = 0 ; j y ; j++) {
8ary[i][j + y] = 0 ;
9}
10}
11}
12intmain()
13{
14func(2,2) ;
15return0 ;
16}
17
+ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-3.x86_64/src/gcc-4.9.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-3.x86_64/src/gcc-4.9.2
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
--target=x86_64-pc-cygwin --without-libiconv-prefix
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared
--enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp
--disable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-libada --enable-libgcj-sublibs
--disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.2 (GCC)
+ gcc -Wall -W -O2 bug.c
+ echo 'Why warn?'
Why warn?
+ gcc -Wall -W -O4 bug.c
bug.c: In function 'func':
bug.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
ary[i][j + y] = 0 ;
^
bug.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
bug.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
bug.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
bug.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
bug.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
[Bug fortran/66328] New: Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328 Bug ID: 66328 Summary: Wrong initialization of derived-type DATA Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- A report from comp.lang.fortran: Yep, it's a bug (and dates back to gfortran 4.3 or even earlier). It is triggered by the use of the integer literal 1 in the constructor for e1: if you use a real, gfortran behaves as expected. TYPE t REAL r END TYPE t TYPE (t) e1, e2 DATA e1 / t(1) / DATA e2 / t(1.0) / print *, e1, e2 print *, t(1), t(1.0) END and the reason it prints out 1.40129846E-45 is that this is the value of TRANSFER(1, 0.0) on x86 architecture. We're missing a cast in assigning value to e1.
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager egall at gwmail dot gwu.edu --- The -Wc90-c99-compat that made it into gcc5 currently warns about any usage of bool whatsoever, not just the specific usages of bool listed in this bug...
[Bug middle-end/66334] New: cleanup block fails to initialize EBX
.cfi_endproc .LFE5: .hidden DW.ref.__gcc_personality_v0 .weak DW.ref.__gcc_personality_v0 .section .data.DW.ref.__gcc_personality_v0,awG,@progbits,DW.ref.__gcc_personality_v0,comdat .align 4 .type DW.ref.__gcc_personality_v0, @object .size DW.ref.__gcc_personality_v0, 4 DW.ref.__gcc_personality_v0: .long __gcc_personality_v0 .ident GCC: (GNU) 6.0.0 20150528 (experimental) .section.note.GNU-stack,,@progbits [hjl@gnu-tools-1 tmp]$ The problem is .L8: subl$12, %esp movl%eax, %esi pushl $0 callcl movl%esi, (%esp) .LEHB1: call_Unwind_Resume@PLT .LEHE1: This cleanup block is called via .section.gcc_except_table,a,@progbits .LLSDA2: .byte 0xff .byte 0xff .byte 0x1 .uleb128 .LLSDACSE2-.LLSDACSB2 .LLSDACSB2: .uleb128 .LEHB0-.LFB2 .uleb128 .LEHE0-.LEHB0 .uleb128 .L8-.LFB2 .uleb128 0 .uleb128 .LEHB1-.LFB2 .uleb128 .LEHE1-.LEHB1 .uleb128 0 .uleb128 0 .LLSDACSE2: When the cleanup block is entered, EBX isn't valid. In PIC, the cleanup block must initialize EBX before branching to PLT.
[Bug fortran/66331] gfortran.dg/continuation_13.f90 execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66331 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- See PR 65903
[Bug fortran/66331] gfortran.dg/continuation_13.f90 execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66331 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- It is working on 5.1.1 gcc version 5.1.1 20150529 (GCC) We did have a regression which has been fixed and that testcase was updated.
[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318
Mikhail Maltsev miyuki at gcc dot gnu.org changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment #4 from Mikhail Maltsev miyuki at gcc dot gnu.org ---
I think those tools will not like a newline character in the filename either.
And I doubt that there is a reliable way to parse output of GCC if newlines are
not escaped:
$ cat ./test.cc
void foo();
#line 1 test1.cc:3:1 error: something wrong!\ntest2.cc
void bar()
{
foo(abc);
}
$ /opt/gcc-6.0.0/bin/g++ -c ./test.cc
test1.cc:3:1 error: something wrong!
test2.cc: In function 'void bar()':
test1.cc:3:1 error: something wrong!
test2.cc:3:14: error: too many arguments to function 'void foo()'
./test.cc:1:6: note: declared here
void foo();
Anyway, GCC already suppresses color diagnostics when stderr is not a TTY
(implemented in should_colorize function). Probably the same logic could be
applied to hypothetical should_escape.
[Bug go/66332] New: goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332
Bug ID: 66332
Summary: goacc/acc_on_device-2.c scan-rtl-dump-times expand
testsuite failure
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: jpsinthemix at verizon dot net
CC: cmang at google dot com
Target Milestone: ---
Hi,
I'm getting the following openacc-related testsuite error for gcc-5.1.0 on an
x86_64-pc-linux-gnu system:
FAIL: c-c++-common/goacc/acc_on_device-2.c scan-rtl-dump-times expand \\(call
[^\\n]* acc_on_device 0
This failure does not appear to be related to BUG 64850.
The failure occurs in
gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:27
1 /* Have to enable optimizations, as otherwise builtins won't be expanded.
*/
2 /* { dg-additional-options -O -fdump-rtl-expand } */
3
4 #if __cplusplus
5 extern C {
6 #endif
7
8 typedef enum acc_device_t { acc_device_X = 123 } acc_device_t;
9 extern int acc_on_device (acc_device_t);
10
11 #if __cplusplus
12 }
13 #endif
14
15 int
16 f (void)
17 {
18 const acc_device_t dev = acc_device_X;
19 return acc_on_device (dev);
20 }
21
22 /* With -fopenacc, we're expecting the builtin to be expanded, so no calls.
23TODO: in C++, even under extern C, the use of enum for acc_device_t
24perturbs expansion as a builtin, which expects an int parameter. It's
fine
25when changing acc_device_t to plain int, but that's not what we're doing
in
26openacc.h.
27{ dg-final { scan-rtl-dump-times \\\(call \[^\\n\]* acc_on_device 0
expand { xfail c++ } } } */
28
29 /* { dg-final { cleanup-rtl-dump expand } } */
Running:
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/build/gcc/xgcc
-B/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/build/gcc/
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fopenacc -O
-fdump-rtl-expand -ffat-lto-objects -S -o acc_on_device-2.s
I get (acc_on_device-2.s):
1 .file acc_on_device-2.c
2 .text
3 .globl f
4 .type f, @function
5 f:
6 .LFB0:
7 .cfi_startproc
8 subq$8, %rsp
9 .cfi_def_cfa_offset 16
10 movl$123, %edi
11 callacc_on_device
12 addq$8, %rsp
13 .cfi_def_cfa_offset 8
14 ret
15 .cfi_endproc
16 .LFE0:
17 .size f, .-f
18 .ident GCC: (GNU) 5.1.0
19 .section.note.GNU-stack,,@progbits
and (acc_on_device-2.c.191r.expand):
1
2 ;; Function f (f, funcdef_no=0, decl_uid=1846, cgraph_uid=0,
symbol_order=0)
3
4
5 ;; Generating RTL for gimple basic block 2
6
7
8 try_optimize_cfg iteration 1
9
10 Merging block 3 into block 2...
11 Merged blocks 2 and 3.
12 Merged 2 and 3 without moving.
13 Removing jump 11.
14 Merging block 4 into block 2...
15 Merged blocks 2 and 4.
16 Merged 2 and 4 without moving.
17
18
19 try_optimize_cfg iteration 2
20
21
22
23 ;;
24 ;; Full RTL generated for this function:
25 ;;
26 (note 1 0 3 NOTE_INSN_DELETED)
27 (note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
28 (note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
29 (insn 5 2 6 2 (set (reg:SI 5 di)
30 (const_int 123 [0x7b]))
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:19
-1
31 (nil))
32 (call_insn/u 6 5 7 2 (set (reg:SI 0 ax)
33 (call (mem:QI (symbol_ref:DI (acc_on_device) [flags 0x41]
function_decl 0x7f1eaf74b870 acc_on_device) [0 __builtin_acc_on_device S1
A8])
34 (const_int 0 [0])))
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:19
-1
35 (expr_list:REG_EH_REGION (const_int 0 [0])
36 (nil))
37 (expr_list:SI (use (reg:SI 5 di))
38 (nil)))
39 (insn 7 6 8 2 (set (reg:SI 89)
40 (reg:SI 0 ax))
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:19
-1
41 (nil))
42 (insn 8 7 9 2 (set (reg:SI 90)
43 (reg:SI 89))
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:19
-1
44 (nil))
45 (insn 9 8 10 2 (set (reg:SI 87 [ D.1855 ])
46 (reg:SI 90))
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:19
-1
47 (nil))
48 (insn 10 9 14 2 (set (reg:SI 88 [ retval ])
49 (reg:SI 87 [ D.1855 ]))
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c:19
-1
50 (nil))
51 (insn 14 10 15 2 (set (reg/i:SI 0 ax)
52 (reg:SI 88 [ retval ]))
[Bug c++/66333] New: [C++14] Static constexpr template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66333
Bug ID: 66333
Summary: [C++14] Static constexpr template
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cypherpu at gmail dot com
Target Milestone: ---
Created attachment 35650
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35650action=edit
line colTest2 fails, line colTest4 succeeds
In the attached file, line colTest2 fails with:
gcc_constexpr_bug.cpp:36:99: error: ‘ColumnObjectStaff,
std::basic_stringchar {Staff::nickname_, ((const char*)nick_name)}’ is
not a constant expression
static constexpr auto colTest2=ColumnObjectStaff, std::string
(Staff::nickname_,nick_name);
Note that std::basic_string is only used in the declaration of a member
pointer. Also note that although this line fails, a very similar line succeeds
(colTest4 in main()).
[]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150422 (Red Hat 5.1.1-1) (GCC)
[Bug target/65248] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 Khem Raj raj.khem at gmail dot com changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #7 from Khem Raj raj.khem at gmail dot com --- (In reply to H.J. Lu from comment #6) Fixed for GCC 5. No plan for backport. reading the commit message here https://sourceware.org/bugzilla/show_bug.cgi?id=17709#c5 Does this mean now binutils = 2.26 will be broken for older gcc ? If thats the case, I would like to request a backport of this to atleast for gcc 4.9 and 4.8 which are not EOLed yet.
[Bug fortran/66331] New: gfortran.dg/continuation_13.f90 execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66331
Bug ID: 66331
Summary: gfortran.dg/continuation_13.f90 execution failure
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jpsinthemix at verizon dot net
Target Milestone: ---
Hi,
I'm getting the following gfortran testsuite errors for gcc-5.1.0 on an
x86_64-pc-linux-gnu system:
=== gfortran tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/coarray/caf.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/debug/debug.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/dg.exp
...
FAIL: gfortran.dg/continuation_13.f90 -O0 execution test
FAIL: gfortran.dg/continuation_13.f90 -O1 execution test
FAIL: gfortran.dg/continuation_13.f90 -O2 execution test
FAIL: gfortran.dg/continuation_13.f90 -O3 -fomit-frame-pointer execution
test
FAIL: gfortran.dg/continuation_13.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/continuation_13.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/continuation_13.f90 -O3 -g execution test
FAIL: gfortran.dg/continuation_13.f90 -Os execution test
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/goacc/goacc.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/gomp/gomp.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/graphite/graphite.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/guality/guality.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/ieee/ieee.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/lto/lto.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.dg/vect/vect.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp
...
Running
/home/pkgbase/bld/gcc.5.1.0-x86_64-build4/gcc-5.1.0/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp
...
The failure occurs in
gcc-5.1.0/gcc/testsuite/gfortran.dg/continuation_13.f90:37
1 ! { dg-do run }
2 ! { dg-options -std=gnu }
3 ! PR64506
4 character(25) :: astring
5
6 100 format('This format is OK.'
7 )
8 200 format('This format now works.'!comment
9 )
10 300 format('This format now works.' !comment
11 )
12 400 format('This format is OK.' !comment
13 )
14 500 format('This format is OK.' !comment
15 )
16 600 format('This format now works.'''!comment
17 )
18 700 format('This format now works.''' !comment
19 )
20 800 format('This is actually ok.' !comment
21' end' )
22 write(astring,100)
23 if (astring.ne.This format is OK.) call abort
24 write(astring,200)
25 if (astring.ne.This format now works.) call abort
26 write(astring,300)
27 if (astring.ne.This format now works.) call abort
28 write(astring,400)
29 if (astring.ne.This format is OK.) call abort
30 write(astring,500)
31 if (astring.ne.This format is OK.) call abort
32 write(astring,600)
33 if (astring.ne.This format now works.') call abort
34 write(astring,700)
35 if (astring.ne.This format now works.') call abort
36 write(astring,800)
37 if (astring.ne.This is actually ok. end) call abort -- fails
38
39 end
I modified continuation_13.f90 as follows:
1 ! { dg-do run }
2 ! { dg-options -std=gnu }
3 ! PR64506
4 character(25) :: astring
5
6 100 format('This format is OK.'
7 )
8 200 format('This format now works.'!comment
9 )
10 300 format('This format now works.' !comment
11 )
12 400 format('This format is OK.' !comment
13 )
14 500 format('This format is OK.' !comment
15 )
16 600 format('This format now works.'''!comment
17 )
18 700 format('This format now works.''' !comment
19 )
20 800 format('This is actually ok.' !comment
21' end' )
22 810 format('This is actually ok.'' end' !comment
23 )
24 820 format('This is actually ok.' !comment
25' end' )
26 write(astring,100)
27 if (astring.ne.This format is OK.)write(*,*) ERR 100: |,
astring, |This format is OK.|
28 write(astring,200)
29 if (astring.ne.This
[Bug middle-end/66334] cleanup block fails to initialize EBX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66334 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Run-time testcases are nptl/tst-cancelx4.c and nptl/tst-cancelx5.c in glibc when compiled with -fPIE -pie on Linux/x86.
[Bug c/66326] Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 --- Comment #2 from Eric ejolson at unr dot edu --- Additional information and discussion about this bug may be found on the Intel Cilk Plus developer forum at https://software.intel.com/en-us/forums/topic/558825
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 --- Comment #4 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Marek Polacek from comment #3) (In reply to Eric Gallager from comment #2) The -Wc90-c99-compat that made it into gcc5 currently warns about any usage of bool whatsoever, not just the specific usages of bool listed in this bug... Right, that was the point of it. ...so is this bug worth keeping open then? It'd seem kinda redundant to me for extra, more-specific warnings about bools to be placed in -Wc90-c99-compat (as was originally proposed), when the flag already prints the more-generalized warnings that it currently does. Or would they get their own separate -Wbool-arith option? If so, what would happen when a user specifies both a hypothetical -Wbool-arith flag along with -Wc90-c99-compat at the same time? I'm just kinda worried that such a situation could lead to duplicated and/or excessive warnings...
[Bug c++/66329] If condition evaluated wrongly for y1 == 0 condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66329 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #4 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Clang is more verbose: ./test.c:4:11: warning: has lower precedence than ==; == will be evaluated first [-Wparentheses] x = y 1 == 1; ^~~~ ./test.c:4:11: note: place parentheses around the '==' expression to silence this warning x = y 1 == 1; ^ ( ) ./test.c:4:11: note: place parentheses around the expression to evaluate it first x = y 1 == 1; ^ ()
[Bug middle-end/66332] goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Keywords||openacc Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-29 CC||jules at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org Component|libgomp |middle-end Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Thanks for the report. I also noticed this, and I'm in the process of fixing this. It is a regression introduced with the fix for PR65742, r223801. For non-offloaded code, we must now in fact expect a library call (even though the OpenACC 2.0a specification mandates we shouldn't). So, I'll XFAIL this test case.
[Bug fortran/66331] gfortran.dg/continuation_13.f90 execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66331 --- Comment #3 from John Stanley jpsinthemix at verizon dot net --- Wonderful. Thanks much, and sorry I missed 65903. I guess this can be closed.
[Bug middle-end/66313] Unsafe factorization of a*b+a*c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-28 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Well, generating a testcase that generates wrong-code via VRP should be possible. Yes, the general solution is to compute the whole expression in unsigned and cast it back...
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) D is not part of FSF GCC so I am inclined to close as invalid. If there's a bug that shows up with D but doesn't show up with non-D, and the bug can be identified as an SH backend bug and it's not too complex, then we can fix it. Otherwise I guess we'd have to pass the ball to the debian maintainers of their version of GCC (they also apply a bunch of patches, a vanilla GCC doesn't even build out of the box on SH4 debian). Anyway, please leave this PR open for now.
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
I think originally, the warning was supposed to catch things like
switch (n MASK) {}
or even using the wrong variable in the switch(). Of course, it could be
smarter and avoid warning about the specific case 'switch(bool) {case true:
case false:}', which is what Linus says here:
https://lkml.org/lkml/2015/5/27/933
If only GCC had 1/100th of the developers of the Linux kernel...
The manual and the warning text could also say explicitly the reason for
warning (something like often indicates a typo)
[Bug preprocessor/66322] New: Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
Bug ID: 66322
Summary: Linus Torvalds: -Wswitch-bool produces dubious
warnings, fails to notice really bad things
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: t.artem at mailcity dot com
Target Milestone: ---
From: https://lkml.org/lkml/2015/5/27/941
Btw, I'd actually like to see (possibly optionally) a warning for enum
types there too. Exactly because *type* based warnings very much make
sense, regardless of number of cases.
For example, try this:
#include stdbool.h
#include stdio.h
enum a { one, two };
int t(bool b, enum a e)
{
switch (b) {
case true:
printf(No arguments\n);
/* fallthrough */
case false:
printf(\n);
}
switch (e) {
case 0:
printf(one);
break;
case two:
printf(two);
break;
}
return 0;
}
and I'd argue that gcc-5.1 warns about TOTALLY THE WRONG THING.
It does that *stupid* warning:
warning: switch condition has boolean value [-Wswitch-bool]
which is just idiotic and wrong.
The case statements are clearly boolean, there is absolutely nothing
wrong with that switch, and a compiler that warns about it is just
being f*cking moronic.
In contrast, that second switch() statement with the case 0: is
actually something that might well be worth warning for. I'd argue
that the code would clearly be more legible if it used case one:
instead.
So the new warning in gcc-5 seems to be just stupid. In general,
warnings that encourage you to write bad code are stupid. The above
switch (boolean) {
case true:
is *good* code, while the gcc documentation suggests that you should
cast it to int in order to avoid the warning, but anybody who
actually thinks that
switch ((int)boolean) {
switch 1:
is better, clearly has absolutely zero taste and is just objectively wrong.
Really. A warning where the very *documentation* tells you to do
stupid things is stupid.
[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 vehre at gcc dot gnu.org changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #8 from vehre at gcc dot gnu.org --- *** Bug 66321 has been marked as a duplicate of this bug. ***
[Bug fortran/66321] [4.9.2/5.1.0/6.0.0] errors allocating allocatable array component of pointer object component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66321 vehre at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||vehre at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from vehre at gcc dot gnu.org --- Hi Damian, that construction rang a bell. It is similar to pr 44672, which is in review currently and a compiler having the patch for it included compiles w/o ICE. I try to address the comments I got on the patch today. Regards, Andre *** This bug has been marked as a duplicate of bug 44672 ***
[Bug middle-end/66314] ice in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66314 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-28 Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug c++/66320] [5/6 Regression] ICE: in cxx_eval_constant_expression, at cp/constexpr.c:3524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66320
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-28
CC||trippels at gcc dot gnu.org
Summary|internal compiler error: in |[5/6 Regression] ICE: in
|cxx_eval_constant_expressio |cxx_eval_constant_expressio
|n, at cp/constexpr.c:3524 |n, at cp/constexpr.c:3524
Ever confirmed|0 |1
Known to fail||5.0, 6.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat testcase.ii
class A
{
virtual int m_fn1 ();
};
class B
{
public:
B (int);
};
class D : B
{
struct C
{
A a;
A b = a;
};
D (int *);
C _channels;
};
D::D (int *) : B (0)
{
};
markus@x4 tmp % g++ -c -std=c++11 testcase.ii
testcase.ii: In constructor ‘D::D(int*)’:
testcase.ii:20:20: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:3477
D::D (int *) : B (0)
^
0x7ccfd3 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3476
0x7cad5e cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3191
0x7cb3a5 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3390
0x7cb28b cxx_eval_indirect_ref
../../gcc/gcc/cp/constexpr.c:2432
0x7cb28b cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3182
0x7cc415 cxx_eval_component_reference
../../gcc/gcc/cp/constexpr.c:1753
0x7cc415 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3342
0x7cad5e cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3191
0x7cb3a5 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3390
0x7cb3a5 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3390
0x7c9503 cxx_bind_parameters_in_call
../../gcc/gcc/cp/constexpr.c:1101
0x7c9503 cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1282
0x7cadf5 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3062
0x7cd5a7 is_sub_constant_expr(tree_node*)
../../gcc/gcc/cp/constexpr.c:3642
0x71f6c9 check_noexcept_r
../../gcc/gcc/cp/except.c:1182
0xf14612 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../gcc/gcc/tree.c:11149
0xf14979 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../gcc/gcc/tree.c:11363
0xf19248 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_settree_node*,
default_hashset_traits*))
../../gcc/gcc/tree.c:11479
0x71f21f expr_noexcept_p(tree_node*, int)
../../gcc/gcc/cp/except.c:1259
0x731ff9 walk_field_subobs
../../gcc/gcc/cp/method.c:1221
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Well, using switch on bool is always weird, one really should use if for that.
If you want fallthrough, then just use if (cond) { first } second, if without
fallthrough, then if (cond) { first } else { second }.
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- D is not part of FSF GCC so I am inclined to close as invalid.
[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |5.2 Summary|[5 Regression] Problems |[5/6 Regression] Problems |with some integer(16) |with some integer(16) |values |values
[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66314 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.1.0 Target Milestone|--- |6.0 Summary|ice in |[6 Regression] ice in |verify_loop_structure |verify_loop_structure
[Bug gcov-profile/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |6.0
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #4 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Oleg Endo from comment #1) As Kaz mentioned in PR 65979 #c8, first revert all the SH specific patches. The SVN revisions are r221686, r221305, r221166, r220957, r220917, r219258. Thus you can pull the patches from the GCC SVN and reverse-apply them to your source tree. That'll be something for the weekend then. I'm still a noob when it comes to messing with the gcc source code, so the learning curve will be a bit steep. But I really want to solve this issue :). Adrian
[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66302 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Oops, wrong resolution.
[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66302 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Not a bug then.
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
Well, using switch on bool is always weird, one really should use if for
that.
If you want fallthrough, then just use if (cond) { first } second, if without
fallthrough, then if (cond) { first } else { second }.
Indeed. I wrote:
https://gcc.gnu.org/wiki/VerboseDiagnostics#warning:_switch_condition_has_boolean_value_.5B-Wswitch-bool.5D
for future reference. I think there will be always valid cases that GCC
cannot avoid warning, so perhaps it is useful to explain the reasoning behind
it and what is the best way to work-around it. (It seems the cast is after all
not the best way, converting it to if-else seems better).
[Bug fortran/66310] Problems with intrinsic repeat for large number of copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-28 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- If I replace the line print *, repeat(z, huge(1_4)) with print *, repeat(z, 26250) in the second code of comment 0, the code compiles, not with print *, repeat(z, 27500) f951(2361,0x7fff72381300) malloc: *** mach_vm_map(size=18446744073447682048) failed (error code=3) Note that 27500 is well below the 16Gb of memory I have on my machine and I don't understand why gfortran needs to allocate 18446744073447682048 bytes.
[Bug sanitizer/66323] runtime error with zero sized std::array using begin and end methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66323 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-28 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Severity|major |normal
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||tnozicka at gmail dot com --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 66323 has been marked as a duplicate of this bug. ***
[Bug sanitizer/66323] runtime error with zero sized std::array using begin and end methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66323 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 65352 ***
[Bug c++/66320] [5/6 Regression] ICE: in cxx_eval_constant_expression, at cp/constexpr.c:3524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66320 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r217663 aka C++14 constexpr support.
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Of course, I don't think
switch ((int)boolean) {
switch 1:
is better or nice, and I wouldn't want to encourage writing such a code, the
cast (you don't really have to change true to 1) is only meant as a way to
quash the warning. But switch (boolean) seemed to be too obscure that giving a
warning there didn't feel too far-fetched; especially if you can use the cast
(in C, integer promotions are performed on the controlling expression anyway)
if you really want that.
To fix this, I think I'll have to defer the warning until c_finish_case and add
some flag to c_switch struct and track whether the controlling expression had
boolean type there. Then in c_do_switch_warnings decide if we want to warn or
not.
[Bug libgomp/65742] [5/6 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 --- Comment #5 from jules at gcc dot gnu.org --- Author: jules Date: Thu May 28 09:29:19 2015 New Revision: 223801 URL: https://gcc.gnu.org/viewcvs?rev=223801root=gccview=rev Log: PR libgomp/65742 gcc/ * builtins.c (expand_builtin_acc_on_device): Don't use open-coded sequence for !ACCEL_COMPILER. libgomp/ * oacc-init.c (plugin/plugin-host.h): Include. (acc_on_device): Check whether we're in an offloaded region for host_nonshm plugin. Don't use __builtin_acc_on_device. * plugin/plugin-host.c (GOMP_OFFLOAD_openacc_parallel): Set nonshm_exec flag in thread-local data. (GOMP_OFFLOAD_openacc_create_thread_data): Allocate thread-local data for host_nonshm plugin. (GOMP_OFFLOAD_openacc_destroy_thread_data): Free thread-local data for host_nonshm plugin. * plugin/plugin-host.h: New. Added: trunk/libgomp/plugin/plugin-host.h Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/libgomp/ChangeLog trunk/libgomp/oacc-init.c trunk/libgomp/plugin/plugin-host.c
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
I guess we also shouldn't warn on
(1) switch (bool)
{
case true: ...
default: ...
}
(2) switch (bool)
{
case true: ...
}
(3) switch (bool)
{
default:
}
Similarly with s/true/false/.
BTW, I've checked what clang does and the behavior is the same as GCC 5.1.
[Bug tree-optimization/66299] more optimize oppotunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66299 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0
[Bug tree-optimization/66299] more optimize oppotunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66299 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- I have some patch now, we'll see. There are some more things to optimize, e.g. if ((1 x) == 3) can't ever be true, yet we fail to optimize it to if (0).
[Bug tree-optimization/66324] New: GOACC_parallel is optimization barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66324 Bug ID: 66324 Summary: GOACC_parallel is optimization barrier Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Created attachment 35643 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35643action=edit gcc/testsuite/c-c++-common/goacc/kernels-parallel-loop-data-enter-exit-2.c [ Discussed at PR 65419 ] Attached testcase does not work: ... FAIL: c-c++-common/goacc/kernels-parallel-loop-data-enter-exit-2.c scan-tree-dump-not parloops_oacc_kernels FAILED: FAIL: c-c++-common/goacc/kernels-parallel-loop-data-enter-exit-2.c scan-tree-dump-times parloops_oacc_kernels SUCCESS: may be parallelized 1 ... GOACC_parallel is an optimization barrier for alias analysis, which inhibits parallelization of the kernels region.
[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 --- Comment #13 from vries at gcc dot gnu.org --- (In reply to vries from comment #9) The GOACC_parallel is more tricky. I don't see what kind of fnspec for GOACC_parallel could fix this. The only other potential solution I see besides postponing expansion of the parallel region is ipa_pta. But that's apparently not production ready yet (PR46032 comment 19). Any other ideas? Filed as PR66324 - GOACC_parallel is optimization barrier
[Bug fortran/66310] Problems with intrinsic repeat for large number of copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- I do agree, that some extra temporary data is necessary and there should be a practical (high) limit for something like that. Let the helper buffers be five or ten times the amount of the effectively written data. That's OK. But it's not a billion times as suggested by the huge number 18446744065119617024. Something IS going wrong here. --- Indeed, there is an actual limit at about 2^28 = 268435456 for the second case. That's plenty enough. But the point is (sorry for being late) : $ cat zlim_hd8m.f90 program p character, parameter :: z = 'z' print *, repeat(z, 268435450) end $ gfortran zlim_hd8m.f90 $ a.out l $ wc l 1 1 268435452 l $ cat zlim_hd8p.f90 program p character, parameter :: z = 'z' print *, repeat(z, 268435460) end $ gfortran zlim_hd8p.f90 f951: out of memory allocating 18446744073441116164 bytes after a total of 430080 bytes --- For the first test case the limit is just below 2^31. This is really enough. No code change is needed, IMO. Only the message invalid memory reference was misleading the first time, therefore a reduction and investigation of some variations. Thank you.
[Bug sanitizer/66323] New: runtime error with zero sized std::array using begin and end methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66323
Bug ID: 66323
Summary: runtime error with zero sized std::array using begin
and end methods
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tnozicka at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Hi, there is a bug either in undefined behaviour sanitizer or STL. Following
code should be valid according to N3797 draft saying:
1. array shall provide support for the special case N == 0.
2. In the case that N == 0, begin() == end() == unique value.
But compiling and running following code results in sanitizer error:
/opt/szn/include/c++/5.1/array:222:32: runtime error: reference binding to null
pointer of type 'int'
Compiled and run with gcc 5.1 as:
/opt/szn/bin/g++ -std=c++14 -Wall -Wextra -fsanitize=undefined
-Wl,-rpath=/opt/szn/lib/gcc/x86_64-linux-gnu/current -o program main.cpp
./program
// === TEST ===
#include array
int main()
{
std::arrayint, 0 array{};
array.begin();
array.end();
return 0;
}
// === END OF TEST ===
Compiler info: $ /szn/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/szn/bin/g++
COLLECT_LTO_WRAPPER=/opt/szn/lib/gcc/x86_64-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /home/tnozicka/generic/gcc/gcc-5.1.0/configure
--prefix=/opt/szn --program-suffix=-5.1 --enable-languages=c++
--disable-multilib --with-default-libstdcxx-abi=c++98 --enable-shared
--enable-threads=posix --enable-checking=release --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --with-tune=generic
--enable-libstdcxx-time=yes --enable-libstdcxx-debug
--enable-version-specific-runtime-libs --enable-objc-gc --enable-clocale=gnu
--disable-install-libiberty --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --libdir=/opt/szn/lib --libexecdir=/opt/szn/lib
--infodir=/opt/szn/share/info-gcc-5.1 --localedir=/opt/szn/share/locale-gcc-5.1
--mandir=/opt/szn/share/man-gcc-5.1
--with-gxx-include-dir=/opt/szn/include/c++/5.1
Thread model: posix
gcc version 5.1.0 (GCC)
[Bug libstdc++/66302] Wrong output sequence of double precision uniform C++ RNG distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66302 --- Comment #5 from Andrey Kolesov andrey.kolesov at intel dot com --- Ok, we understand your points. Obviously there are two approaches: 1) provide maximum random bits in all precisions but not preserve sequences 2) provide reasonable number of random bits but preserve sequences for all precisions. Both approaches have their own customers. First one is applicable to fine accuracy testing suits, for example. Second one is more for Monte-Carlo simulations, finance and general data analytic, etc. Our team chosen the second approach during MKL VSL design since we have a lot of requests and strict requirements from important customers (mostly FSI) to generate the same sequence for all CPU's and precisions. Moreover a number of them just did refuse solutions when random values sequence potentially could be different at different systems and for different precision environments. That's really important feature. What about accuracy: our experience based on customers communication says that ~32 random mantissa bits is quite enough for most of statistical applications. This case the difference between rounded and exact random value is about 10^(-8). During Monte-Carlo simulations these generated random values are being transformed by various math operations and most of them have 1/sqrt(N) statistical error for parameter to be evaluated, where N - number of generated random values. When N = 10^10 the simulation accuracy is about 10^(-5) - this case we did not even see the ~10^(-8) generator error. It means that extra accuracy of double precision generator is almost useless for such kind of applications. At the same time we understand that sometimes customers need full accuracy of high precision generators. This case MKL provides uniform bits generator versions with raw output type for own customer scaling. Ideally it would be nice to have distributions parametrization by accuracy to satisfy different customer needs, but that would require standard update. What about this issue - we agree to close it. Thanks to all.
[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 --- Comment #12 from vries at gcc dot gnu.org --- Created attachment 35642 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35642action=edit Updated tentative patch (In reply to Jakub Jelinek from comment #11) (In reply to vries from comment #10) Created attachment 35639 [details] tentative patch for GOACC_data_end That is a bad idea, as void GOACC_data_end (void) is already exported out of libgomp, so this is an ABI break. If it is meant as a hack around not specifying the functions to aliasing oracle properly, and not really needed after expansion to RTL, you could e.g. use an internal function in GIMPLE and then lower it to normal function call that doesn't take the argument. Updated tentative patch to use internal function.
[Bug middle-end/66325] New: ICE in gcc.c-torture/execute/930408-1.c, verify_type fails with --enable-checking=yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66325 Bug ID: 66325 Summary: ICE in gcc.c-torture/execute/930408-1.c, verify_type fails with --enable-checking=yes Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi I'm getting this ICEs in the arm testsuite: FAIL: gcc.c-torture/execute/930408-1.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/930408-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/930408-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/execute/930408-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/execute/930408-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: gcc.c-torture/execute/930408-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) The ICE backtrace is: 930408-1.c:6:1: error: type variant differs by TYPE_PACKED. } s; ^ enumeral_type 0x7f7dbda115e8 foo asm_written unsigned packed type_0 QI size integer_cst 0x7f7dbdba4000 type integer_type 0x7f7dbdb95150 bitsizetype constant 8 unit size integer_cst 0x7f7dbdba4018 type integer_type 0x7f7dbdb950a8 sizetype constant 1 align 8 symtab -1113450304 alias set -1 canonical type 0x7f7dbda115e8 precision 8 min integer_cst 0x7f7dbdba4030 0 max integer_cst 0x7f7dbdb91fc0 255 values tree_list 0x7f7dbdc7ee60 value integer_cst 0x7f7dbdba42d0 constant 0 chain tree_list 0x7f7dbdc7ee88 purpose identifier_node 0x7f7dbda21960 e1 symbol const_decl 0x7f7dbda2f070 e1 value integer_cst 0x7f7dbdba42e8 constant 1 chain type_decl 0x7f7dbdbb2980 D.4163 enumeral_type 0x7f7dbda11690 E unsigned QI size integer_cst 0x7f7dbdba4000 type integer_type 0x7f7dbdb95150 bitsizetype constant 8 unit size integer_cst 0x7f7dbdba4018 type integer_type 0x7f7dbdb950a8 sizetype constant 1 align 8 symtab -1113450384 alias set -1 canonical type 0x7f7dbda115e8 precision 8 min integer_cst 0x7f7dbdba4030 0 max integer_cst 0x7f7dbdb91fc0 255 values tree_list 0x7f7dbdc7ee60 purpose identifier_node 0x7f7dbda21910 e0 symbol const_decl 0x7f7dbda2f000 e0 value integer_cst 0x7f7dbdba42d0 constant 0 chain tree_list 0x7f7dbdc7ee88 purpose identifier_node 0x7f7dbda21960 e1 symbol const_decl 0x7f7dbda2f070 e1 value integer_cst 0x7f7dbdba42e8 constant 1 chain type_decl 0x7f7dbdbb2980 D.4163 930408-1.c:6:1: internal compiler error: verify_type failed 0xd47e13 verify_type(tree_node const*) $TOP/gcc/tree.c:13276 0x723fbc gen_type_die_with_usage $TOP/gcc/dwarf2out.c:20250 0x725079 gen_type_die $TOP/gcc/dwarf2out.c:20434 0x7383cc gen_decl_die $TOP/gcc/dwarf2out.c:21041 0x736545 gen_member_die $TOP/gcc/dwarf2out.c:19945 0x736545 gen_struct_or_union_type_die $TOP/gcc/dwarf2out.c:20038 0x736545 gen_tagged_type_die $TOP/gcc/dwarf2out.c:20227 0x724c88 gen_type_die_with_usage $TOP/gcc/dwarf2out.c:20381 0x725079 gen_type_die $TOP/gcc/dwarf2out.c:20434 0x737c80 gen_decl_die $TOP/gcc/dwarf2out.c:20987 0x738f4b dwarf2out_decl $TOP/gcc/dwarf2out.c:21397 0x73a161 dwarf2out_type_decl $TOP/gcc/dwarf2out.c:21096 0x9ce063 rest_of_type_compilation(tree_node*, int) $TOP/gcc/passes.c:309 0x55312f finish_struct(unsigned int, tree_node*, tree_node*, tree_node*, c_struct_parse_info*) $TOP/gcc/c/c-decl.c:7850 0x59b443 c_parser_struct_or_union_specifier $TOP/gcc/c/c-parser.c:2829 0x59b443 c_parser_declspecs $TOP/gcc/c/c-parser.c:2403 0x5a39e0 c_parser_declaration_or_fndef $TOP/gcc/c/c-parser.c:1571 0x5ab4fe c_parser_external_declaration $TOP/gcc/c/c-parser.c:1452 0x5ab797 c_parser_translation_unit $TOP/gcc/c/c-parser.c:1339 0x5ab797 c_parse_file() $TOP/gcc/c/c-parser.c:15457 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. I see this at least as far back as r223695 and it appears on trunk at r223800. Honza, is this related to your type work recently? My arm-none-eabi compiler is configured with: --enable-checking=yes --with-newlib --with-fpu=neon-fp-armv8 --with-arch=armv8-a --without-isl
[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||mrs at gcc dot gnu.org, ||rdsandiford at googlemail dot com, ||zadeck at naturalbridge dot com --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- The regression occurred between revision r210073 (2014-05-05, OK) and r210124 (2014-05-06, wrong output). I suspect r210113: Merge in wide-int.
[Bug libgomp/65742] [5/6 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 --- Comment #6 from jules at gcc dot gnu.org --- Author: jules Date: Thu May 28 09:38:40 2015 New Revision: 223802 URL: https://gcc.gnu.org/viewcvs?rev=223802root=gccview=rev Log: PR libgomp/65742 gcc/ * builtins.c (expand_builtin_acc_on_device): Don't use open-coded sequence for !ACCEL_COMPILER. libgomp/ * oacc-init.c (plugin/plugin-host.h): Include. (acc_on_device): Check whether we're in an offloaded region for host_nonshm plugin. Don't use __builtin_acc_on_device. * plugin/plugin-host.c (GOMP_OFFLOAD_openacc_parallel): Set nonshm_exec flag in thread-local data. (GOMP_OFFLOAD_openacc_create_thread_data): Allocate thread-local data for host_nonshm plugin. (GOMP_OFFLOAD_openacc_destroy_thread_data): Free thread-local data for host_nonshm plugin. * plugin/plugin-host.h: New. Added: branches/gomp-4_0-branch/libgomp/plugin/plugin-host.h Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/builtins.c branches/gomp-4_0-branch/libgomp/ChangeLog.gomp branches/gomp-4_0-branch/libgomp/oacc-init.c branches/gomp-4_0-branch/libgomp/plugin/plugin-host.c
[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322 Szabolcs Nagy nszabolcs at gmail dot com changed: What|Removed |Added CC||nszabolcs at gmail dot com --- Comment #5 from Szabolcs Nagy nszabolcs at gmail dot com --- i don't mind the warning (there are other warnings in gcc with false positives), but the documentation must not encourage the use of casts for dealing with it. that is dangerous and much worse than the original problem: the cast turns off the type-system so if the type of the expression later changes then anything goes (pointers, floats, different int types). so i think this is the real bug: https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Warning-Options.html#index-Wswitch-bool-362
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 11:53:35 2015 New Revision: 223806 URL: https://gcc.gnu.org/viewcvs?rev=223806root=gccview=rev Log: PR libstdc++/65352 * include/std/array (__array_traits::_S_ptr): New function. (array::data): Use _S_ptr to avoid creating invalid reference. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/array trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #26 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Author: mrs Date: Thu May 28 12:27:05 2015 New Revision: 223808 URL: https://gcc.gnu.org/viewcvs?rev=223808root=gccview=rev Log: 2015-05-28 Lawrence Velázquez v...@larryv.me PR target/63810 * config/darwin-c.c (version_components): New global enum. (parse_version, version_as_legacy_macro) (version_as_modern_macro, macosx_version_as_macro): New functions. (version_as_macro): Remove. (darwin_cpp_builtins): Use new function. testsuite: PR target/63810 * gcc.dg/darwin-minversion-3.c: Update testcase. * gcc.dg/darwin-minversion-4.c: Ditto. * gcc.dg/darwin-minversion-5.c: New testcase. * gcc.dg/darwin-minversion-6.c: Ditto. * gcc.dg/darwin-minversion-7.c: Ditto. * gcc.dg/darwin-minversion-8.c: Ditto. * gcc.dg/darwin-minversion-9.c: Ditto. * gcc.dg/darwin-minversion-10.c: Ditto. * gcc.dg/darwin-minversion-11.c: Ditto. * gcc.dg/darwin-minversion-12.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/darwin-minversion-10.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-11.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-12.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-5.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-6.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-7.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-8.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-c.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/darwin-minversion-3.c trunk/gcc/testsuite/gcc.dg/darwin-minversion-4.c
[Bug libstdc++/66017] Undefined behaviour in std::setlong long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 12:33:36 2015 New Revision: 223811 URL: https://gcc.gnu.org/viewcvs?rev=223811root=gccview=rev Log: PR libstdc++/66017 * include/bits/stl_tree.h (_Rb_tree_node): Use __aligned_membuf. (_Rb_tree_iterator, _Rb_tree_const_iterator): Support construction from _Base_ptr. (_Rb_tree_const_iterator::_M_const_cast): Remove static_cast. (_Rb_tree::begin, _Rb_tree::end): Remove static_cast. * include/ext/aligned_buffer.h (__aligned_membuf): New type using alignment of _Tp as a member subobject, not as a complete object. * python/libstdcxx/v6/printers.py (StdRbtreeIteratorPrinter): Lookup _Link_type manually as it might not be in the debug info. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/stl_tree.h branches/gcc-5-branch/libstdc++-v3/include/ext/aligned_buffer.h branches/gcc-5-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 12:33:41 2015 New Revision: 223812 URL: https://gcc.gnu.org/viewcvs?rev=223812root=gccview=rev Log: PR libstdc++/65352 * include/std/array (__array_traits::_S_ptr): New function. (array::data): Use _S_ptr to avoid creating invalid reference. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: likewise. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/std/array branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308 --- Comment #10 from Christophe Lyon clyon at gcc dot gnu.org --- Hello Vladimir, Have you been able to make progress on this bug?
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 --- Comment #7 from Mathieu Malaterre mathieu.malaterre at gmail dot com --- For anyone reading this. the comment -latomic is there already. means: replace __sync_val_compare_and_swap(ptr, oldval, newval) in your code with __atomic_compare_exchange(ptr, oldval, newval, false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) then link with -latomic
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #27 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Fixed in 6.0. Backports pre approved after bake time and testing that includes older darwins and ppc.
[Bug libstdc++/66017] Undefined behaviour in std::setlong long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66017 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 5.2 and 6.0
[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu May 28 13:24:53 2015 New Revision: 223816 URL: https://gcc.gnu.org/viewcvs?rev=223816root=gccview=rev Log: 2015-05-28 Richard Biener rguent...@suse.de PR tree-optimization/66142 * tree-ssa-sccvn.c (vn_reference_lookup_3): Handle non-GIMPLE values better in memcpy destination handling. Handle non-aliasing we discover here. * gcc.dg/tree-ssa/ssa-fre-44.c: Fixup. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-44.c trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/66264] [untaken optimization] switch enums without default-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66264 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Should be switch-conversion doing the job? Yes, I think so. I'll try to have a look in the near future.
[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 --- Comment #14 from vries at gcc dot gnu.org --- Author: vries Date: Thu May 28 14:18:19 2015 New Revision: 223832 URL: https://gcc.gnu.org/viewcvs?rev=223832root=gccview=rev Log: Add IFN_GOACC_DATA_END_WITH_ARG 2015-05-28 Tom de Vries t...@codesourcery.com PR tree-optimization/65419 * cfgexpand.c (pass_data_expand): Add PROP_gimple_lompifn to properties_required field. * gimplify.c (gimplify_omp_workshare): Use IFN_GOACC_DATA_END_WITH_ARG instead of BUILT_IN_GOACC_DATA_END. Clear PROP_gimple_lompifn in curr_properties. (gimplify_function_tree): Tentatively set PROP_gimple_lompifn in curr_properties. * internal-fn.c (expand_GOACC_DATA_END_WITH_ARG): New dummy function. * internal-fn.def (GOACC_DATA_END_WITH_ARG): New DEF_INTERNAL_FN. * omp-low.c (lower_omp_target): Set argument of GOACC_DATA_END_WITH_ARG. (pass_data_late_lower_omp): New pass_data. (pass_late_lower_omp): New pass. (pass_late_lower_omp::gate, pass_late_lower_omp::execute) (make_pass_late_lower_omp): New function. * passes.def: Add pass_late_lower_omp. * tree-inline.c (expand_call_inline): Handle PROP_gimple_lompifn. * tree-pass.h (PROP_gimple_lompifn): Add define. * testsuite/libgomp.oacc-c-c++-common/goacc-data-end.c: New test. Added: branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/goacc-data-end.c Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/cfgexpand.c branches/gomp-4_0-branch/gcc/gimplify.c branches/gomp-4_0-branch/gcc/internal-fn.c branches/gomp-4_0-branch/gcc/internal-fn.def branches/gomp-4_0-branch/gcc/omp-low.c branches/gomp-4_0-branch/gcc/passes.def branches/gomp-4_0-branch/gcc/tree-inline.c branches/gomp-4_0-branch/gcc/tree-pass.h branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66314 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Broken by DOM2. Can somebody reduce this?
[Bug middle-end/66251] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66251 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66314 --- Comment #3 from ktkachov at gcc dot gnu.org --- Created attachment 35644 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35644action=edit Reduced testcase Confirmed on aarch64-none-elf with current trunk. Attaching reduced testcase
[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66314
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
char *a;
int b, c, d;
static int
fn1 (int b, int c)
{
while (a)
if (*a)
return -126;
if (b)
return -12;
if (c == -12)
return c;
}
void
fn2 (int b, int c)
{
for (;;)
{
d = fn1 (b, c);
switch (d)
{
case -126:
continue;
default:
return;
}
}
}
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 16:27:46 2015 New Revision: 223840 URL: https://gcc.gnu.org/viewcvs?rev=223840root=gccview=rev Log: Backport from mainline 2014-12-22 Jonathan Wakely jwak...@redhat.com PR libstdc++/37522 * include/bits/basic_string.h (stod, stof, stoi, stol, stold, stoll, stoul, stoull, to_string): Only use _GLIBCXX_HAVE_BROKEN_VSWPRINTF to guard definition of to_wstring. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/basic_string.h
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 16:27:56 2015 New Revision: 223842 URL: https://gcc.gnu.org/viewcvs?rev=223842root=gccview=rev Log: PR libstdc++/65352 * include/profile/array (array::data): Use __array_traits::_S_ptr. * include/debug/array (array::data): Likewise. * include/std/array (__array_traits::_S_ptr): New function. (array::data): Use _S_ptr to avoid creating invalid reference. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/debug/array branches/gcc-4_9-branch/libstdc++-v3/include/profile/array branches/gcc-4_9-branch/libstdc++-v3/include/std/array branches/gcc-4_9-branch/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.9.3, 5.2 and 6.0
[Bug debug/66301] internal compiler error when using -fopt-info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66301 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-28 Ever confirmed|0 |1 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- Well, the problem is that in eliminate_dom_walker::before_dom_children in tree-ssa-pre.c we have: if (dump_enabled_p ()) dump_possible_polymorphic_call_targets (dump_file, ...) but dump_enabled_p can return true when dump_file is NULL if alt_dump_file is not NULL. I suppose that dump_enabled_p was introduced as a part of the semi-overhaul of dumping interface we got in 2012 but that never quite caught on, and that it simply can't be mixed with old-style dumping which just tests dump_file. The obvious fix would be to change the condition to if (dump_file). Or we might convert the whole thing to new style dumping, but I admit I have never quite understood it.
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 16:00:09 2015 New Revision: 223838 URL: https://gcc.gnu.org/viewcvs?rev=223838root=gccview=rev Log: PR libstdc++/65352 * include/profile/array (array::data): Use _S_ptr. * include/debug/array (array::data): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/array trunk/libstdc++-v3/include/profile/array
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez vq at larryv dot me changed: What|Removed |Added Attachment #34010|0 |1 is obsolete|| --- Comment #28 from Lawrence Velázquez vq at larryv dot me --- Created attachment 35645 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35645action=edit backport to gcc-5-branch
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez vq at larryv dot me changed: What|Removed |Added Attachment #34012|0 |1 is obsolete|| --- Comment #30 from Lawrence Velázquez vq at larryv dot me --- Created attachment 35647 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35647action=edit backport to gcc-4_8-branch
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez vq at larryv dot me changed: What|Removed |Added Attachment #34011|0 |1 is obsolete|| --- Comment #29 from Lawrence Velázquez vq at larryv dot me --- Created attachment 35646 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35646action=edit backport to gcc-4_9-branch
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #31 from Lawrence Velázquez vq at larryv dot me --- (In reply to m...@gcc.gnu.org from comment #27) Fixed in 6.0. Backports pre approved after bake time and testing that includes older darwins and ppc. Thanks! I've attached updated patches against 4.8, 4.9, and 5.1, if you need them.
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu May 28 16:14:26 2015 New Revision: 223839 URL: https://gcc.gnu.org/viewcvs?rev=223839root=gccview=rev Log: PR libstdc++/65352 * include/profile/array (array::data): Use _S_ptr. * include/debug/array (array::data): Likewise. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/debug/array branches/gcc-5-branch/libstdc++-v3/include/profile/array
[Bug middle-end/66314] [6 Regression] ice in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66314 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) char *a; int b, c, d; int d; is enough I guess.
