[Bug tree-optimization/61437] [4.10 Regression] wrong code on x86_64-linux-gnu when compile separately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61437 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Jun 11 07:35:36 2014 New Revision: 211436 URL: http://gcc.gnu.org/viewcvs?rev=211436&root=gcc&view=rev Log: 2014-06-11 Richard Biener PR middle-end/61437 Revert 2014-06-04 Richard Biener * tree.h (may_be_aliased): Trust TREE_ADDRESSABLE from TREE_PUBLIC and DECL_EXTERNAL decls. * gcc.dg/torture/20140610-1.c: New testcase. * gcc.dg/torture/20140610-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/20140610-1.c trunk/gcc/testsuite/gcc.dg/torture/20140610-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug tree-optimization/61437] [4.10 Regression] wrong code on x86_64-linux-gnu when compile separately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61437 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed by reversion.
[Bug ipa/61462] [4.10 Regression] ICE in ipa-prop.c:2562 caused by missing edge gimple call stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61462 Richard Biener changed: What|Removed |Added Component|middle-end |ipa Target Milestone|--- |4.10.0 Summary|ICE in ipa-prop.c:2562 |[4.10 Regression] ICE in |caused by missing edge |ipa-prop.c:2562 caused by |gimple call stmt|missing edge gimple call ||stmt
[Bug target/61467] -m16/.code16gcc invalid code for passing parameters on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61467 --- Comment #1 from 1zeeky at gmail dot com --- Created attachment 32918 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32918&action=edit linker script
[Bug target/61467] New: -m16/.code16gcc invalid code for passing parameters on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61467 Bug ID: 61467 Summary: -m16/.code16gcc invalid code for passing parameters on stack Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: 1zeeky at gmail dot com Created attachment 32917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32917&action=edit test-case -m16/.code16gcc seem to produce invalid code due to (I think) using pushl (4 bytes) instead of pushw (2 bytes). It was my understanding that .code16gcc produces binaries that can execute in real-mode and for gcc 4.8 this worked due to preferring mov $VAL,(%esp) to push $VAL when passing parameters. I've attached a test-case illustrating the problem. It produces a x86 bootable binary image that can be booted with qemu for example, or just examine the objdump. The Makefile and linker-script will follow. The code uses .code16gcc in favor of -m16 so you can easily test with gcc 4.8 if desired, but using -m16 instead makes no difference.
[Bug target/61467] -m16/.code16gcc invalid code for passing parameters on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61467 --- Comment #2 from 1zeeky at gmail dot com --- Created attachment 32919 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32919&action=edit Makefile make init16.elf generates an ELF-file that can be examined with objdump -mi8086. make floppy.img generates a bootable floppy-disk image. make qemu starts qemu and boots the image.
[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52252 --- Comment #6 from Kirill Yukhin --- Author: kyukhin Date: Wed Jun 11 08:37:53 2014 New Revision: 211439 URL: http://gcc.gnu.org/viewcvs?rev=211439&root=gcc&view=rev Log: gcc/ * tree-vect-data-refs.c (vect_grouped_store_supported): New check for stores group of length 3. (vect_permute_store_chain): New permutations for stores group of length 3. * tree-vect-stmts.c (vect_model_store_cost): Change cost of vec_perm_shuffle for the new permutations. gcc/testsuite/ PR tree-optimization/52252 * gcc.dg/vect/pr52252-st.c: Test on stores group of size 3. Added: trunk/gcc/testsuite/gcc.dg/vect/pr52252-st.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c
[Bug middle-end/61456] [4.9 Regression] Bogus "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456 --- Comment #11 from Richard Biener --- Author: rguenth Date: Wed Jun 11 09:29:11 2014 New Revision: 211442 URL: http://gcc.gnu.org/viewcvs?rev=211442&root=gcc&view=rev Log: 2014-06-11 Richard Biener PR middle-end/61456 * tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p): Do not use the main variant for the type comparison. * g++.dg/opt/pr61456.C: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/opt/pr61456.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-alias.c
[Bug middle-end/61456] [4.9 Regression] Bogus "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed.
[Bug middle-end/54364] Tail call jumps not threaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54364 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Steven Bosscher --- http://gcc.gnu.org/r191462
[Bug c/61469] New: language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 Bug ID: 61469 Summary: language feature: Support for enum underlying type Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nick87720z at gmail dot com Just like some other features (inline functions, const, bool), ability to specify data type for enumeration should be useful, since enumeration is just a restriction for possible values. Unlike C++, where type is specified as "enum class type ...", i propose following forms: - enum(type) ... - type enum ...
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #1 from Jonathan Wakely ---
(In reply to nick87720z from comment #0)
> Unlike C++, where type is specified as "enum class type ..."
That's not how C++ does it, the correct syntax is:
enum foo_type : int { foo, bar, baz };
[Bug tree-optimization/61306] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306 --- Comment #6 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Wed Jun 11 10:04:33 2014 New Revision: 211444 URL: http://gcc.gnu.org/viewcvs?rev=211444&root=gcc&view=rev Log: 2014-06-11 Thomas Preud'homme gcc/ PR tree-optimization/61306 * tree-ssa-math-opts.c (struct symbolic_number): Store type of expression instead of its size. (do_shift_rotate): Adapt to change in struct symbolic_number. Return false to prevent optimization when the result is unpredictable due to arithmetic right shift of signed type with highest byte is set. (verify_symbolic_number_p): Adapt to change in struct symbolic_number. (init_symbolic_number): Likewise. (find_bswap_or_nop_1): Likewise. Return NULL to prevent optimization when the result is unpredictable due to sign extension. gcc/testsuite/ * gcc.c-torture/execute/pr61306-1.c: New test. * gcc.c-torture/execute/pr61306-2.c: Likewise. * gcc.c-torture/execute/pr61306-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr61306-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr61306-2.c trunk/gcc/testsuite/gcc.c-torture/execute/pr61306-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug c++/61457] Inaccurately refusing non-ODR usage of type with no linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61457 --- Comment #1 from Paolo Carlini --- At the moment I can't find the Bug # but we certainly have other issues opened about C++11 ODR. We should probably link all together in a meta-bug.
[Bug tree-optimization/61306] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61306 thopre01 at gcc dot gnu.org changed: What|Removed |Added Known to work|4.9.0 |4.10.0 Known to fail||4.8.3, 4.9.0 --- Comment #7 from thopre01 at gcc dot gnu.org --- Although the number of code impacted is bigger since the recent improvement to bswap pass to support memory source, this bug is actually quite old. I'm thus updating the known to work/fail versions accordingly
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #2 from nick87720z at gmail dot com --- Didn't know about this form. What i mentioned, i found othere: http://en.wikipedia.org/wiki/Enumerated_type#C.2B.2B
[Bug c++/34049] Parentheses-enclosed expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34049 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| Known to fail|| --- Comment #2 from Paolo Carlini --- This is fixed for 4.9.0. I'm adding the testcase and closing the bug.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #3 from Jonathan Wakely --- You're confusing two separate things, that's a "scoped enumeration" which is orthogonal to defining a fixed underlying type for an enumeration.
[Bug c++/34049] Parentheses-enclosed expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34049 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini --- Done.
[Bug c++/34049] Parentheses-enclosed expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34049 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jun 11 10:24:55 2014 New Revision: 211445 URL: http://gcc.gnu.org/viewcvs?rev=211445&root=gcc&view=rev Log: 2014-06-11 Paolo Carlini PR c++/34049 * g++.dg/parse/pr34049.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/pr34049.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/61470] New: ill-formed friend declaration(s) with default-arguments not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61470
Bug ID: 61470
Summary: ill-formed friend declaration(s) with
default-arguments not caught
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32920&action=edit
testcase.cpp
struct A {
friend void f(int=0); // (A), ill-formed, [dcl.fct.default]p4
friend void g(int=0){}; // ( ), legal
};
void g(int); // (B), ill-formed, [dcl.fct.default]p4
int main () { }
-
(A) and (B) are violating the following sentence from [dcl.fct.default]p4:
> If a friend declaration specifies a default argument expression, that
> declaration shall be a definition and shall be the only declaration of
> the function or function template in the translation unit.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- But those other features (inline functions, const, bool) are specified by standard. What is the use case? If you want to save space, there's __attribute__ ((__packed__)) or -fshort-enums (use with caution). We should be very careful with adding such extensions.
[Bug c++/61471] New: redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471
Bug ID: 61471
Summary: redeclaration of default-argument in function template
declaration not caught
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32921&action=edit
testcase.cpp
template void f(int=3);
template void f(int=3); // ill-formed
int main () { }
`gcc` inaccurately accepts the above snippet, which is violating the following
[dcl.fct.default]p4:
> A default argument shall not be redefined b a later declaration
> (not even to the same value).
By making `f` a non-template the violating is caught, and appropriate
diagnostics are shown.
[Bug c++/52180] [DR 1227] [C++11] need to remember whether a return type was specified early or late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52180 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #1 from Paolo Carlini --- We took care of this: 2014-05-31 Paolo Carlini DR 1227 PR c++/57543
[Bug c++/61471] redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471 --- Comment #1 from Filip Roséen --- Created attachment 32922 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32922&action=edit testcase-real.cpp The previously attached `testcase.cpp` contains a code snippet for a related, but different, bug. See the newly attached testcase.cpp for contents matching the code in the original post.
[Bug c++/61472] New: added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472
Bug ID: 61472
Summary: added default-argument in later declaration of
function template not caught
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32923&action=edit
testcase.cpp
template void f(int);
template void f(int=3);
int main () { }
-
`gcc` inaccurately accepts the above snippet, which is violating the following
sentence from [dcl.fct.default]p4:
> For non-template functions, default arguments can be added in later
> declarations of a function in the same scope.
-
[Bug c++/61472] added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472 --- Comment #1 from Jonathan Wakely --- (Please set the version field to make it clear you're not reporting bugs against GCC 4.4 or something ancient and unmaintained) This is very likely to be the same issue as PR 61471
[Bug c++/61472] added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472 --- Comment #2 from Filip Roséen --- Sorry Jonathan, I completely forgot, I'll add the version to this (and those other newly posted bug reports where it is missing).
[Bug c++/61472] added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-11 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Thanks - I can confirm they're present in the current trunk, but for at least one of them I thought it looked like something that was fixed recently and might only be a problem for old versions (I was wrong, it's still a problem).
[Bug c++/61471] redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-11 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- We diagnose this if the function template is instantiated. I'm not sure if we're required to diagnose it for uninstantiated templates.
[Bug tree-optimization/61452] [4.8/4.9/4.10 Regression] hang at -O1 and -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Jun 11 11:17:21 2014 New Revision: 211450 URL: http://gcc.gnu.org/viewcvs?rev=211450&root=gcc&view=rev Log: 2014-06-11 Richard Biener PR tree-optimization/61452 * tree-ssa-sccvn.c (visit_phi): Remove pointless setting of expr and has_constants in case we found a leader. (simplify_binary_expression): Always valueize operands first. (simplify_unary_expression): Likewise. * gcc.dg/torture/pr61452.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61452.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug c++/61472] added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472 --- Comment #4 from Jonathan Wakely --- As with PR 61471 we diagnose this if the template is instantiated
[Bug tree-optimization/61452] [4.8/4.9/4.10 Regression] hang at -O1 and -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jun 11 11:18:14 2014 New Revision: 211451 URL: http://gcc.gnu.org/viewcvs?rev=211451&root=gcc&view=rev Log: 2014-06-11 Richard Biener PR tree-optimization/61452 * tree-ssa-sccvn.c (visit_phi): Remove pointless setting of expr and has_constants in case we found a leader. (simplify_binary_expression): Always valueize operands first. (simplify_unary_expression): Likewise. * gcc.dg/torture/pr61452.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61452.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/61452] [4.8 Regression] hang at -O1 and -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452 Richard Biener changed: What|Removed |Added Known to work||4.10.0, 4.9.1 Summary|[4.8/4.9/4.10 Regression] |[4.8 Regression] hang at |hang at -O1 and -Os on |-O1 and -Os on |x86_64-linux-gnu|x86_64-linux-gnu Known to fail||4.8.3, 4.9.0 --- Comment #5 from Richard Biener --- Fixed on trunk/4.9 sofar.
[Bug c++/61471] redeclaration of default-argument in function template declaration not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61471 --- Comment #3 from Jonathan Wakely --- Oops, I messed up my test - we don't diagnose this even at instantiation
[Bug c++/61472] added default-argument in later declaration of function template not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61472 --- Comment #5 from Jonathan Wakely --- I messed up my test for this too - we only diagnose it if you try to use the default argument, so it seems to be ignored on the redeclaration.
[Bug c++/61470] ill-formed friend declaration(s) with default-arguments not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61470 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- EDG accepts this too. Clang rejects both ill-formed declarations.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #5 from nick87720z at gmail dot com --- I remember case, when bigger size, than from int, was needed - it was 64-bit integer, used as flag container. Program, using it, is not my. When i decided to reimplement it as enum, author explained me problem. As for standard, there are still things not in standard - GCC extensions (such as computed labels, for which i even exactly know possible use case - some kind of bridges to seemlessly skip certain checks, which are useless after decision is done all, with one or two exceptions) and this one, imho, is good candidate for implementation; personally i don't care very much about other compilers, thus don't fear of such proposals :].
[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59093 --- Comment #6 from Matt Thompson --- Has there been any work/success on this bug? It's still affecting our ability to compile this code with gfortran.
[Bug c/61473] register sized memmove not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473 --- Comment #1 from Julian Taylor --- I am using glibc 2.19-0ubuntu6 from the ubuntu 14.04 trusty repository
[Bug c/61473] New: register sized memmove not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473
Bug ID: 61473
Summary: register sized memmove not inlined
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
in this example file compiled with gcc-4.10 -O3 inlines the memcpy, but not the
memmove:
#include
void a(int *a, int *b)
{
memcpy(a, b, sizeof(*a));
}
void b(int *a, int *b)
{
memmove(a, b, sizeof(*a));
}
at least on x86 the integer can be stored in fully in a register and saved back
to arbitrary aligned memory, so it should not matter if the two address overlap
and gcc should be able to replace it with a much faster inline memcpy.
Currently gcc only inlines the memmove for 1 byte types.
I am using a recent svn copy of gcc:
$ gcc-4.10 --version
gcc (GCC) 4.10.0 20140605 (experimental)
[Bug preprocessor/61474] New: ICE (segfault) in preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61474 Bug ID: 61474 Summary: ICE (segfault) in preprocessor Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen on any version back to 4.4 $ cat a.c #include "b.h" #include "c.h" $ cat b.h # 1 "c.h" 1 $ gcc -E a.c # 1 "a.c" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "a.c" # 1 "b.h" 1 # 1 "c.h" 1 # 1 "b.h" 2 In file included from a.c:1:0: b.h:1:0: internal compiler error: Segmentation fault # 1 "c.h" 1 ^ Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x00d990a8 in ?? () (gdb) bt #0 0x00d990a8 in ?? () #1 0x00d997e8 in ?? () #2 0x00d9a3ab in _cpp_stack_file () #3 0x00d9a844 in _cpp_stack_include () #4 0x00d92666 in ?? () #5 0x00d931e8 in _cpp_handle_directive () #6 0x00d9fa1d in _cpp_lex_token () #7 0x00da42d0 in ?? () #8 0x005d5af8 in preprocess_file(cpp_reader*) () #9 0x005d4591 in c_common_init() () #10 0x0057faee in c_objc_common_init() () #11 0x008b4fe7 in toplev_main(int, char**) () #12 0x769e8ec5 in __libc_start_main (main=0x5526e0 , argc=12, argv=0x7fffe5e8, init=, fini=, rtld_fini=, stack_end=0x7fffe5d8) at libc-start.c:287 #13 0x00552915 in _start ()
[Bug sanitizer/61475] New: Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475
Bug ID: 61475
Summary: Building Firefox with ASan is broken in the packaging
step
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gk at torproject dot org
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
As mentioned in bug 61408 building Firefox 24 (and probably later Firefox
versions as well) with ASan is broken on GCC trunk. The build crashes in the
packaging step as follows:
Executing
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -a
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -f
/home/gk/asan/mozilla-esr24/toolkit/mozapps/installer/precompile_cache.js -e
precompile_startupcache("resource://gre/");
=
==22303==ERROR: AddressSanitizer: unknown-crash on address 0x2ad2d31bd3c0 at pc
0x2ad2d1803362 bp 0x7fff8f6149c0 sp 0x7fff8f6149b8
READ of size 16 at 0x2ad2d31bd3c0 thread T0
#0 0x2ad2d1803361 in nsIDHashKey ../../dist/include/nsHashKeys.h:375
#1 0x2ad2d1803361 in nsBaseHashtableET
../../dist/include/nsBaseHashtable.h:408
#2 0x2ad2d1803361 in nsTHashtable >::s_InitEntry(PLDHashTable*, PLDHashEntryHdr*, void const*)
../../dist/include/nsTHashtable.h:472
#3 0x2ad2d179ad39 in PL_DHashTableOperate
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/xpcom/build/pldhash.cpp:630
#4 0x2ad2d1805d75 in nsTHashtable >::PutEntry(nsID const&, mozilla::fallible_t const&)
../../dist/include/nsTHashtable.h:184
#5 0x2ad2d1805d75 in nsTHashtable >::PutEntry(nsID const&) ../../dist/include/nsTHashtable.h:170
#6 0x2ad2d1805d75 in nsBaseHashtable::Put(nsID const&, nsFactoryEntry* const&, mozilla::fallible_t
const&) ../../dist/include/nsBaseHashtable.h:147
#7 0x2ad2d1805d75 in nsBaseHashtable::Put(nsID const&, nsFactoryEntry* const&)
../../dist/include/nsBaseHashtable.h:141
#8 0x2ad2d1806065 in
nsComponentManagerImpl::RegisterCIDEntryLocked(mozilla::Module::CIDEntry
const*, nsComponentManagerImpl::KnownModule*)
/home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:502
#9 0x2ad2d1809d35 in nsComponentManagerImpl::RegisterModule(mozilla::Module
const*, mozilla::FileLocation*)
/home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:453
#10 0x2ad2d180aba2 in nsComponentManagerImpl::Init()
/home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:389
#11 0x2ad2d17a1fb0 in NS_InitXPCOM2
/home/gk/asan/mozilla-esr24/xpcom/build/nsXPComInit.cpp:467
#12 0x406d4b in main
/home/gk/asan/mozilla-esr24/js/xpconnect/shell/xpcshell.cpp:1566
#13 0x2ad2d59b6c8c in __libc_start_main (/lib/libc.so.6+0x1ec8c)
#14 0x407ea0
(/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell+0x407ea0)
0x2ad2d31bd3c0 is located 0 bytes inside of global variable
'kComponentManagerCID' from
'/home/gk/asan/mozilla-esr24/xpcom/build/nsXPComInit.cpp' (0x2ad2d31bd3c0) of
size 16
SUMMARY: AddressSanitizer: unknown-crash ../../dist/include/nsHashKeys.h:375
nsIDHashKey
Shadow bytes around the buggy address:
0x055ada62fa20: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa30: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa40: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa50: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa60: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
=>0x055ada62fa70: 00 00 f9 f9 f9 f9 f9 f9[00]00 f9 f9 f9 f9 f9 f9
0x055ada62fa80: 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9
0x055ada62fa90: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00
0x055ada62faa0: 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
0x055ada62fab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x055ada62fac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
ASan internal: fe
==22303==ABORTING
This happened on a machine running Ubuntu Precise.
After a lot of fiddling I got Firefox (+ASan) compiled and packaged with
LLVM/Clang trunk on the same Ubuntu Precise machine without problems.
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #1 from Kostya Serebryany --- Please 1. try building with -static-libasan 2. provide full reproduction steps
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #9 from Georg Koppen --- (In reply to Georg Koppen from comment #8) > Not sure about the problem in comment 3 yet which is > probably better tracked in a different bug. I'll open one as soon as my > build machine is not occupied anymore with bisecting the things related to > the crash mentioned in the description. This is now bug 61475. Let's see what happens when I compile Firefox 24 on Lucid with LLVM/Clang trunk...
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #2 from Yury Gribov --- Perhaps dup of bug 61422?
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #3 from Georg Koppen --- (In reply to Kostya Serebryany from comment #1) > Please > 1. try building with -static-libasan I'll do that once I am done with investigating bug 61408. > 2. provide full reproduction steps 1) Take an Ubuntu Precise. 2) Compile GCC (I used the trunk from June 4 as the current has an ICE when compiling Firefox which I need to report as well). I compiled it with --prefix=/path/to/my/dir --disable-multilib --enable-languages=c,c++. 3) Grab the latest Firefox ESR 24 source code (https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-esr/source/firefox-24.6.0esr.source.tar.bz2). 4) Extract it and change into mozilla-esr24. 5) Save the attached mozconfig as .mozconfig in mozille-esr24. 6) Adjust your path to point to your freshly compiled GCC and point LD_LIBRARY_PATH to your GCC-dir/lib64 (assuming you are compiling on a 64bit system). 7) Run |make -j4 -f client.mk build|. 8) After successful compilation package Firefox with |make -C obj* package INNER_MAKE_PACKAGE=true|. 9) It crashes as mentioned in the description.
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #4 from Georg Koppen --- Created attachment 32924 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32924&action=edit .mozconfig for building Firefox ESR 24 with ASan
[Bug c/61476] New: GCC is not aware of glibc extensions for format strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61476
Bug ID: 61476
Summary: GCC is not aware of glibc extensions for format
strings
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Is this something which can and should be addressed, or should be closed as
won't fix?
$ cat foo.c
#include
#include
int main()
{
fprintf(stderr, "error %d: %m\n", errno, errno);
return 0;
}
$ gcc -Wall foo.c
foo.c: In function 'main':
foo.c:6:2: warning: too many arguments for format [-Wformat-extra-args]
fprintf(stderr, "error %d: %m\n", errno, errno);
^
fprintf(3):
m (Glibc extension.) Print output of strerror(errno). No argu‐
ment is required.
[Bug c/61476] GCC is not aware of glibc extensions for format strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61476 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- As documented, %m doesn't consume an argument.
[Bug c++/61343] [C++11] Missing default initialization for class with default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61343 --- Comment #4 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Wed Jun 11 13:45:00 2014 New Revision: 211466 URL: http://gcc.gnu.org/viewcvs?rev=211466&root=gcc&view=rev Log: Backport r211386 from gcc-4_9 (r211284 from trunk). Google ref b/15250505. 2014-06-04 Jason Merrill PR c++/61343 * decl.c (check_initializer): Maybe clear DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. Added: branches/google/gcc-4_8/gcc/testsuite/g++.dg/tls/thread_local9.C Modified: branches/google/gcc-4_8/gcc/cp/decl.c
[Bug libgcc/61477] New: ICE [4.10 regression?] at regcprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61477
Bug ID: 61477
Summary: ICE [4.10 regression?] at regcprop.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
On MAC OS X at least, I was not able to compile gcc-4.10 due to the following
problem (svn rev 211463):
{{{
/usr/local/packages/gcc-4.10.0_trunk/build/./gcc/xgcc
-B/usr/local/packages/gcc-4.10.0_trunk/build/./gcc/
-B/usr/local/x86_64-apple-darwin11.4.2/bin/
-B/usr/local/x86_64-apple-darwin11.4.2/lib/ -isystem
/usr/local/x86_64-apple-darwin11.4.2/include -isystem
/usr/local/x86_64-apple-darwin11.4.2/sys-include-g -O2 -m32 -O2 -g -O2
-DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -pipe -fno-common -I. -I. -I../../.././gcc
-I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc
-I../../../../libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _fixunssfdi.o
-MT _fixunssfdi.o -MD -MP -MF _fixunssfdi.dep -DL_fixunssfdi -c
../../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS \
-DLIBGCC2_UNITS_PER_WORD=4
../../../../libgcc/libgcc2.c: In function ‘__fixunssfdi’:
../../../../libgcc/libgcc2.c:1492:1: error: insn does not satisfy its
constraints:
}
^
(insn 60 13 14 2 (set (reg:DI 0 ax)
(reg:DI 21 xmm0)) ../../../../libgcc/libgcc2.c:1444 89
{*movdi_internal}
(expr_list:REG_UNUSED (reg:DI 0 ax)
(nil)))
../../../../libgcc/libgcc2.c:1492:1: internal compiler error: in
copyprop_hardreg_forward_1, at regcprop.c:776
libbacktrace could not find executable to open
Please submit a full bug report,
}}}
[Bug libgcc/61477] ICE [4.10 regression?] at regcprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61477 --- Comment #1 from Jürgen Reuter --- Created attachment 32925 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32925&action=edit config.log
[Bug target/61062] vzip and vuzp execution tests fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062 --- Comment #6 from christophe.lyon at st dot com --- It looks OK now, thanks.
[Bug libgcc/61477] ICE [4.10 regression?] at regcprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61477 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-11 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- This is a duplicate of pr61446. A working patch has been committed at https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00775.html but nobody cared to review it!-(
[Bug c++/19200] Friend declaration misinterpreted as constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19200 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jun 11 15:16:45 2014 New Revision: 211467 URL: http://gcc.gnu.org/viewcvs?rev=211467&root=gcc&view=rev Log: /cp 2014-06-11 Paolo Carlini PR c++/19200 * parser.c (cp_parser_declarator): Add bool parameter. (cp_parser_direct_declarator): Likewise, use it. (cp_parser_member_declaration): Pass friend_p to cp_parser_declarator. (cp_parser_condition, cp_parser_explicit_instantiation, cp_parser_init_declarator, cp_parser_type_id_1, cp_parser_parameter_declaration, cp_parser_exception_declaration, cp_parser_cache_defarg, cp_parser_objc_class_ivars, cp_parser_objc_struct_declaration, cp_parser_omp_for_loop_init): Adjust. * decl.c (grokdeclarator): Fix handling of friend declared in namespace scope (g++.dg/parse/friend10.C). /testsuite 2014-06-11 Paolo Carlini PR c++/19200 * g++.dg/parse/friend9.C: New. * g++.dg/parse/friend10.C: Likewise. * g++.dg/parse/friend7.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/parse/friend10.C trunk/gcc/testsuite/g++.dg/parse/friend9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/friend7.C
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 --- Comment #5 from Dominique d'Humieres --- This pr has been exposed by revision r211321 and breaks bootstrap on all targets configured for Core* (including darwin which is configured by default for Core2, see pr61477).
[Bug c++/61478] New: wrong handling of variable scopes inside for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61478
Bug ID: 61478
Summary: wrong handling of variable scopes inside for loop
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mkrasowski at gmail dot com
Hi,
the following fails to compile (as expected):
void foo()
{
for(int i = 0; i < 10; i++) {
double i = 11;
}
}
int main() {
foo();
return 0;
}
with the following error:
gcc1.cc: In function 'void foo()':
gcc1.cc:6:16: error: redeclaration of 'double i'
double i = 11;
^
gcc1.cc:5:13: note: 'int i' previously declared here
for(int i = 0; i < 10; i++) {
However adding internal loop caused the above to compile i.e.
void foo()
{
for(int i = 0; i < 10; i++) {
for(int i = 0; i < 10; i++) {
int j = 2 * i;
}
double i = 11;
}
}
compiles with no warnings (if compiled with -Wall it will generate warning
about unused variables).
g++ 4.9.0 on x32_64 linux (latest arch linux), i.e.
% g++ --version
g++ (GCC) 4.9.0 20140604 (prerelease)
Regards,
marcin
[Bug c++/61478] wrong handling of variable scopes inside for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61478 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-11 Ever confirmed|0 |1
[Bug target/61423] Incorrect conversion from unsigned int to floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Shouldn't this patch be reverted until REE is fixed?
[Bug c++/19200] Friend declaration misinterpreted as constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19200 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #5 from Paolo Carlini --- Fixed for 4.10.0.
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #3 from H.J. Lu --- Comments for DATA_ALIGNMENT One use of this macro is to increase alignment of medium-size data to make it all fit in fewer cache lines. Another is to cause character arrays to be word-aligned so that `strcpy' calls that copy constants to character arrays can be done inline. was added by https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=ed45e834f305d1f2709bf200a13d5beebc2fcfee to improve x86 FP performance, which might be partially copied from CONSTANT_ALIGNMENT: https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=f7d6703c5d83fc9fb06246d6eb49e9b61098045c
[Bug target/61479] New: wrong code gen with fstack-protector-all for variadic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61479
Bug ID: 61479
Summary: wrong code gen with fstack-protector-all for variadic
function
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rmansfield at qnx dot com
Target: i686-unknown-linux-gnu
The following code that is specifically targeted at x86 (not intended to be
portable) and assumes that the variable arguments will follow the i386 ABI and
be on the stack. This works without stack protection, but with
-fstack-protector-all.gcc generates loads edi and esi from uninitialized stack.
#include
int
my_func(int a, int b, int c, int d, int e)
{
return a + b + c + d + e;
}
int __attribute__((noinline))
my_varg(int a, ...)
{
int*data = &a;
struct {
intx1;
intx2;
} x;
printf("%x %x %x %x\n", a, data[0], data[1], data[2]);
x.x1 = data[1] * 10;
x.x2 = data[2] * 20;
return my_func(a, data[0], data[1], data[2], (int)&x);
}
int
main()
{
intp;
return my_varg(10, 1, &p);
}
Generated with -O2 -fstack-protector-all
movl60(%esp), %ebx # a, a
movl32(%esp), %esi # MEM[(int *)&a + 8B], D.1941
movl28(%esp), %edi # MEM[(int *)&a + 4B], D.1941
movl%gs:20, %eax#, tmp98
movl%eax, 40(%esp) # tmp98, D.1942
xorl%eax, %eax # tmp98
movl%ebx, 24(%esp) # a, a
pushl %esi# D.1941
.cfi_def_cfa_offset 64
pushl %edi# D.1941
.cfi_def_cfa_offset 68
pushl %ebx# a
.cfi_def_cfa_offset 72
pushl %ebx# a
.cfi_def_cfa_offset 76
pushl $.LC1 #
.cfi_def_cfa_offset 80
callprintf #
The loads should have been:
movl68(%esp), %esi # MEM[(int *)&a + 8B], D.1941
movl64(%esp), %edi # MEM[(int *)&a + 4B], D.1941
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Bill Sacks changed: What|Removed |Added CC||sacks at ucar dot edu --- Comment #4 from Bill Sacks --- Created attachment 32926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32926&action=edit another test case demonstrating this behavior For what it's worth, I'm attaching another test case that demonstrates what seems to be the same bug. There are two subroutines, one in which the argument is declared as a 'type' and one as a 'class'. The subroutine that uses the 'type' dummy variable produces the correct output: 21 22 23 whereas the one that uses the 'class' dummy variable produces the wrong output: 21 0 0 I have confirmed this buggy behavior in gfortran 4.7.3, 4.8.2, 4.8.3 and 4.9.0.
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439
--- Comment #10 from Gary Funck ---
The following test case when compiled against a recent trunk revision (211365
2014-06-08) generates a warning, as intended by the patch described in comment
8.
int a, x;
int
main ()
{
switch (!x)
{
case 0:
a = 1;
break;
case 1:
a = 2;
break;
}
return 0;
}
s.c: In function ‘main’:
s.c:8:11: warning: switch condition has boolean value [-Wswitch-bool]
switch (!x)
^
However, -Wno-switch-bool does *not* suppress the warning.
Looking at gcc/c-family/c.opt, it has an Init(1) clause but no Var() clause.
It seems that if an Init() clause is present that a Var() clause must also be
present for this option to work as expected.
This patch fixes the issue.
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 211365)
+++ gcc/c-family/c.opt (working copy)
@@ -539,7 +539,7 @@ C ObjC C++ ObjC++ Var(warn_switch_enum)
Warn about all enumerated switches missing a specific case
Wswitch-bool
-C ObjC C++ ObjC++ Warning Init(1)
+C ObjC C++ ObjC++ Var(warn_switch_bool) Warning Init(1)
Warn about switches with boolean controlling expression
Wmissing-format-attribute
However, I'm not so certain that this option should be enabled by default, for
a few reasons:
1) The test case above shows the use of a boolean value used in the case
expression where both alternatives (0 and 1) are accounted for and no other
(overflow) cases are mentioned. Adding a cast to (int) will not clarify the
code at all and in fact then leaves apparent cases unaccounted for, which might
arguably lead to a warning to that effect on some compilers (present or
future).
2) If the compiler performed control flow analysis and range analysis to
determine that some cases are not accounted for or that some cases are
out-of-range, then enabling by default would seem appropriate. In the test
case above (in my opinion) no warning should be issued because both cases are
accounted for.
3) Perhaps this option should only be enabled explicitly or by -Wall. For
example, -Wswitch is enabled by -Wall.
Wswitch
C ObjC C++ ObjC++ Var(warn_switch) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall
)
Warn about enumerated switches, with no default, missing a case
[Bug target/61479] wrong code gen with fstack-protector-all for variadic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61479 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This code is not just non-portable but it is undefined in c as you accessing outside of the bounds of the "array" of a.
[Bug c++/60265] [C++11] using-declaration of enumerator fails if fully qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60265 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jun 11 17:28:14 2014 New Revision: 211479 URL: http://gcc.gnu.org/viewcvs?rev=211479&root=gcc&view=rev Log: /cp 2014-06-11 Paolo Carlini PR c++/60265 * parser.c (cp_parser_using_declaration): Handle unscoped enums. * name-lookup.c (validate_nonmember_using_decl): Adjust error message. /testsuite 2014-06-11 Paolo Carlini PR c++/60265 * g++.dg/cpp0x/using-enum-1.C: New. * g++.dg/cpp0x/using-enum-2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/using-enum-1.C trunk/gcc/testsuite/g++.dg/cpp0x/using-enum-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60265] [C++11] using-declaration of enumerator fails if fully qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60265 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #2 from Paolo Carlini --- Fixed for 4.10.0.
[Bug other/61480] New: GCC options processing: Init() requires Var() for 'no-' to work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61480 Bug ID: 61480 Summary: GCC options processing: Init() requires Var() for 'no-' to work as expected Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: jsm28 at gcc dot gnu.org, nenad at intrepid dot com While researching an issue related to Bug 60439, I noticed that the specification for the -Wswitch-bool option quietly ignored -Wno-switch-bool. This was fixed by adding a Var() clause. Index: gcc/c-family/c.opt === --- gcc/c-family/c.opt (revision 211365) +++ gcc/c-family/c.opt (working copy) @@ -539,7 +539,7 @@ C ObjC C++ ObjC++ Var(warn_switch_enum) Warn about all enumerated switches missing a specific case Wswitch-bool -C ObjC C++ ObjC++ Warning Init(1) +C ObjC C++ ObjC++ Var(warn_switch_bool) Warning Init(1) Warn about switches with boolean controlling expression The internal document describing the format of the c.opt file didn't appear to mention this requirement. If there is such a requirement for things to work as expected, perhaps the tool that processes the options specification file should issue an error when Init() is present, but Var() is not?
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439 Marek Polacek changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Target Milestone|--- |4.10.0 --- Comment #11 from Marek Polacek --- Ah, sorry about that. I wonder where the Var(warn_switch_bool) disappeared. In the particular testcase you posted I agree we shouldn't warn, but I think we should warn in case there is the default label. I have no problem with moving the warning to -Wall. I'll prepare a patch tomorrow.
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439 --- Comment #12 from Gary Funck --- I submitted Bug #61480 documenting the interaction between Var() and Init(). The test case that I posted is abstracted from actual code. As far as which switches should be default and/or enabled by -Wall, that question probably needs further review.
[Bug c++/60402] [Core/1395] const overload with variadics declared ambiguous according to standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60402 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2014-06-11 Summary|const overload with |[Core/1395] const overload |variadics declared |with variadics declared |ambiguous according to |ambiguous according to |standard (may be related to |standard |bug 58156) | Ever confirmed|0 |1
[Bug c++/53725] Prototype does not match error if the definition of the ctor is separated from its declaration and attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 --- Comment #2 from Paolo Carlini --- Related to PR49377
[Bug target/61479] wrong code gen with fstack-protector-all for variadic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61479 --- Comment #2 from Ryan Mansfield --- Right, thanks for pointing this out. Sorry for the noise.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #10 from Georg Koppen ---
Okay. LLVM/Clang trunk does not cope with the packaging step either. Sending
the crash through asan_symbolize.py gives:
Executing
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -a
/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -f
/home/gk/asan/mozilla-esr24/toolkit/mozapps/installer/precompile_cache.js -e
precompile_startupcache("resource://gre/");
ASAN:SIGSEGV
=
==4017==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x sp 0x2b9955a94738 bp 0x2b9955a947f0 T2)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
Thread T2 created by T0 here:
BFD: Dwarf Error: found dwarf version '4', this reader only handles version 2
and 3 information.
#0 0x48aa4f in pthread_create ??:0
BFD: Dwarf Error: found dwarf version '4', this reader only handles version 2
and 3 information.
#1 0x2b994b0d4d4e in _PR_CreateThread
/home/gk/asan/mozilla-esr24/nsprpub/pr/src/pthreads/ptthread.c:0
BFD: Dwarf Error: found dwarf version '0', this reader only handles version 2
and 3 information.
#2 0x2b994b0d48b7 in PR_CreateThread ??:0
==4017==ABORTING
I am trying to work around that problem until somebody has a good idea on what
is going on/how to debug that further.
[Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #8 from Bernd Edlinger ---
> expmed.c.214r.reload:
>
> ;; Function long unsigned int choose_multiplier(long unsigned int, int, int,
> long unsigned int*, int*, int*) (_Z17choose_multipliermiiPmPiS0_,
> funcdef_no=1085, decl_uid=47659, symbol_order=801)
>
> ...
> 557: r13:DI=0x7ff78
> REG_EQUIV 0x7ff78
> ...
> 547: debug this => debug_implicit_ptr
> 548: debug D#64 => debug_implicit_ptr
> 549: debug D#37 => D#64
> 550: debug this => D#37
> 551: debug len => optimized away
> 552: debug D#65 => debug_implicit_ptr
> 553: debug D#39 => D#65
> 554: debug this => D#39
> 555: debug high => [sp:DI+0x80038]
> 556: debug res => 0
> 560: NOTE_INSN_DELETED
> 1334: NOTE_INSN_DELETED
> 1367: ax:DI=[sp:DI+r13:DI+0xc0]
>
OK. This is actually not reachable.
Only if wi::divmod_internal would return 0, which it does not.
But in this case get_len() would return 0, and then
generic_wide_int ::uhigh () const
{
return this->get_val ()[this->get_len () - 1];
}
would access exactly SP+32GB.
So this is actually one more case, where it would be incorrect
and potentially dangerous for rtx_addr_can_trap_p_1 to return 0.
The crash in -fdump-rtl-all-slim is actually a different bug,
PR61461 which has most likely nothing to do with this issue.
[Bug c++/38260] vector_size attribute vs specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38260 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- Putting a break point in determine_specialization reveals that the attribute on the return type gets lost, and post parser the code is essentially equivalent to: template< class T > T Abs(T); template<> float Abs(__vector(4) float); which of course cannot work. Indeed, for obvious reasons, both: #define vf4 __attribute__((vector_size(16) )) float template< class T > T Abs(); template<> vf4 Abs(); and #define vf4 __attribute__((vector_size(16) )) float template< class T > void Abs(T); template<> void Abs(vf4); are accepted.
[Bug target/61423] Incorrect conversion from unsigned int to floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Either way will cause a failure. This is #1 on my hit list after the regex problem that's affecting mysql.
[Bug c++/61382] parameter pack expansion unexpected order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382 --- Comment #7 from Johannes Steinmetz --- (In reply to Jason Merrill from comment #6) > Fixed on trunk for now. Ohh great. Thank You!
[Bug ipa/61186] ./g++.dg/ipa/pr52939.C & valgrind & pointer_set_insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61186 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-11 Component|c++ |ipa Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00985.html
[Bug c++/38260] vector_size attribute vs specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38260
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-06-11
CC|paolo.carlini at oracle dot com|
Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle
dot com
Ever confirmed|0 |1
--- Comment #6 from Paolo Carlini ---
With the below, the attributes are applied to the bare float return type
*before* the specialization is checked, and the testcase finally is accepted.
But I didn't regression test anything, and at the moment I have no idea if
there are other unwanted effects of anticipating cplus_decl_attributes.
Index: decl.c
===
--- decl.c(revision 211478)
+++ decl.c(working copy)
@@ -7786,6 +7786,12 @@ grokfndecl (tree ctype,
&& !processing_template_decl)
deduce_noexcept_on_destructor (decl);
+ if (attrlist)
+{
+ cplus_decl_attributes (&decl, *attrlist, 0);
+ *attrlist = NULL_TREE;
+}
+
decl = check_explicit_specialization (orig_declarator, decl,
template_count,
2 * funcdef_flag +
@@ -7796,12 +7802,6 @@ grokfndecl (tree ctype,
if (DECL_STATIC_FUNCTION_P (decl))
check_static_quals (decl, quals);
- if (attrlist)
-{
- cplus_decl_attributes (&decl, *attrlist, 0);
- *attrlist = NULL_TREE;
-}
-
/* Check main's type after attributes have been applied. */
if (ctype == NULL_TREE && DECL_MAIN_P (decl))
{
[Bug target/61300] powerpc64le miscompile with K&R-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 --- Comment #9 from Alan Modra --- Author: amodra Date: Wed Jun 11 23:49:49 2014 New Revision: 211482 URL: http://gcc.gnu.org/viewcvs?rev=211482&root=gcc&view=rev Log: PR target/61300 * doc/tm.texi.in (INCOMING_REG_PARM_STACK_SPACE): Document. * doc/tm.texi: Regenerate. * function.c (INCOMING_REG_PARM_STACK_SPACE): Provide default. Use throughout in place of REG_PARM_STACK_SPACE. * config/rs6000/rs6000.c (rs6000_reg_parm_stack_space): Add "incoming" param. Pass to rs6000_function_parms_need_stack. (rs6000_function_parms_need_stack): Add "incoming" param, ignore prototype_p when incoming. Use function decl when incoming to handle K&R style functions. * config/rs6000/rs6000.h (REG_PARM_STACK_SPACE): Adjust. (INCOMING_REG_PARM_STACK_SPACE): Define. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-protos.h branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_9-branch/gcc/doc/tm.texi branches/gcc-4_9-branch/gcc/doc/tm.texi.in branches/gcc-4_9-branch/gcc/function.c
[Bug target/61300] powerpc64le miscompile with K&R-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 --- Comment #10 from Alan Modra --- Author: amodra Date: Wed Jun 11 23:50:16 2014 New Revision: 211483 URL: http://gcc.gnu.org/viewcvs?rev=211483&root=gcc&view=rev Log: PR target/61300 * doc/tm.texi.in (INCOMING_REG_PARM_STACK_SPACE): Document. * doc/tm.texi: Regenerate. * function.c (INCOMING_REG_PARM_STACK_SPACE): Provide default. Use throughout in place of REG_PARM_STACK_SPACE. * config/rs6000/rs6000.c (rs6000_reg_parm_stack_space): Add "incoming" param. Pass to rs6000_function_parms_need_stack. (rs6000_function_parms_need_stack): Add "incoming" param, ignore prototype_p when incoming. Use function decl when incoming to handle K&R style functions. * config/rs6000/rs6000.h (REG_PARM_STACK_SPACE): Adjust. (INCOMING_REG_PARM_STACK_SPACE): Define. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-protos.h branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_8-branch/gcc/doc/tm.texi branches/gcc-4_8-branch/gcc/doc/tm.texi.in branches/gcc-4_8-branch/gcc/function.c
[Bug target/61300] powerpc64le miscompile with K&R-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Alan Modra --- Fixed
[Bug c++/19200] Friend declaration misinterpreted as constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19200 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jun 12 01:29:42 2014 New Revision: 211488 URL: http://gcc.gnu.org/viewcvs?rev=211488&root=gcc&view=rev Log: /cp 2014-06-11 Paolo Carlini PR c++/19200 * parser.c (cp_parser_init_declarator): Actually pass friend_p to cp_parser_declarator. /testsuite 2014-06-11 Paolo Carlini PR c++/19200 * g++.dg/parse/friend11.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/friend11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/61481] New: Poor optimization of simple small-sized matrix routines with constant data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61481
Bug ID: 61481
Summary: Poor optimization of simple small-sized matrix
routines with constant data
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cas43 at cs dot stanford.edu
Created attachment 32927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32927&action=edit
Output of the
The following function does some simple matrix operations. All of the data is
constant, and N is small. The function optimizes to a return statement for N=1
and N=2. For N=3, optimization is incomplete after tree optimizations but
benifits significantly from later optimizations. For N=4, the final result is
not good.
template
int foo()
{
int x[N*N],y[N*N],z[N*N];
for(int i=0;i();
template int foo<2>();
template int foo<3>();
template int foo<4>();
Compiled with: g++ test.cpp -c -S -O3
The full test.s file is attached, but the most immediate bits are summarized
below.
=== Asm produced for foo<1>(); ===
movl $2, %eax
ret
=== Asm produced for foo<2>(); ===
movl $4, %eax
ret
=== Asm produced for foo<3>(); ===
subq $32, %rsp
.cfi_def_cfa_offset 40
movl $6, %eax
addq $32, %rsp
.cfi_def_cfa_offset 8
ret
=== Asm produced for foo<4>(); ===
subq $96, %rsp
.cfi_def_cfa_offset 104
xorl %eax, %eax
movl $8, %ecx
leaq -104(%rsp), %rdx
pxor %xmm7, %xmm7
pxor %xmm10, %xmm10
movq %rdx, %rdi
rep; stosq
movl $1, -104(%rsp)
movl $1, -84(%rsp)
movl $1, -64(%rsp)
movl $1, -44(%rsp)
movdqa %xmm7, %xmm11
shufps $136, %xmm7, %xmm11
movdqa -104(%rsp), %xmm0
shufps $221, %xmm7, %xmm7
movdqa -88(%rsp), %xmm3
... lots and lots of SSE instructions ...
movdqa %xmm2, %xmm0
punpckhdq %xmm5, %xmm2
punpckldq %xmm5, %xmm0
movaps %xmm6, -120(%rsp)
movl -120(%rsp), %eax
addl 44(%rsp), %eax
movaps %xmm0, 56(%rsp)
movaps %xmm2, 72(%rsp)
addl 64(%rsp), %eax
addl 84(%rsp), %eax
addq $96, %rsp
.cfi_def_cfa_offset 8
ret
[Bug tree-optimization/61481] Poor optimization of simple small-sized matrix routines with constant data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61481 --- Comment #1 from Craig Schroeder --- The compiler used in the above compilation was: Using built-in specs. COLLECT_GCC=/home/craig/new-gcc/i-trunk/bin/g++ COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../s-trunk/configure --prefix=/home/craig/new-gcc/i-trunk Thread model: posix gcc version 4.10.0 20140602 (experimental) (GCC)
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #35 from thopre01 at gcc dot gnu.org --- Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try again a bootstrap without any of the patch you applied locally? I would like to see if this bug is a duplicate of PR61306 as supposed by Richard.
