[Bug c/57647] New: lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 Bug ID: 57647 Summary: lvalue required as increment operand Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vijunag at gmail dot com I recently upgraded my gcc compiler from 3.4.X to 4.7.2 for my project. Consider the following expression char *foo = bar; ((unsigned long*)foo)++ While gcc 3.4.X was more forgiving of this issue, 4.7.2 barfs out an error lvalue required as increment operand. I did notice in gcc documentation that cast as l-value has been removed. C and Objective-C The -Wstrict-aliasing=2 option has been added. This warning catches all unsafe cases, but it may also give a warning for some cases that are safe. The cast-as-lvalue, conditional-expression-as-lvalue and compound-expression-as-lvalue extensions, which were deprecated in 3.3.4 and 3.4, have been removed. The -fwritable-strings option, which was deprecated in 3.4, has been removed. #pragma pack() semantics have been brought closer to those used by other compilers. This also applies to C++. Taking the address of a variable with register storage is invalid in C. GCC now issues an error instead of a warning. Arrays of incomplete element type are invalid in C. GCC now issues an error for such arrays. Declarations such as extern struct s x[]; (where struct s has not been defined) can be moved after the definition of struct s. Function parameters declared as arrays of incomplete type can instead be declared as pointers. So the natural fix and equivalent legitimate expression for the same would ((unsigned long *)foo++), however with -Wall gcc again warns about unused-value. While gcc accepts the expression ((unsigned long*)foo++), the expression has become useless when -Wall -Werror is turned on since it throws -Werror=unused-value. Either the expression should completely be removed or GCC should stop warning about such expressions.
[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org --- (In reply to Vladimir Makarov from comment #2) Thanks! Btw. the Ada and Java bootstraps started failing with enabling LRA for S/390 (also without --with-arch=...). I'll wait for a patch for this PR before having a closer look. Perhaps the fails are related?!
[Bug libitm/57643] libitm.c/reentrant.c hangs on POWER8 with HTM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643 torvald at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-19 CC||torvald at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |torvald at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
While 4.7 issues warning: value computed is not used, 4.8 and 4.9 do not for
int
main ()
{
char bar = 4;
char *foo = bar;
(unsigned long *)foo++;
return 0;
}
For 4.7, you can just add cast to void
(void) (unsigned long *)foo++;
to silence the warning.
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647
--- Comment #2 from vijay Nag vijunag at gmail dot com ---
(In reply to Marek Polacek from comment #1)
While 4.7 issues warning: value computed is not used, 4.8 and 4.9 do not for
int
main ()
{
char bar = 4;
char *foo = bar;
(unsigned long *)foo++;
return 0;
}
For 4.7, you can just add cast to void
(void) (unsigned long *)foo++;
to silence the warning.
Does it work only for int or any type ?
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- It should work for any type, but, why don't you do only foo++;, i.e. drop the cast? In that case there shouldn't be value computed is not used warning.
[Bug target/57648] New: Illegal use ARM Cortex M3 instruction LDMIA causes UserFault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57648
Bug ID: 57648
Summary: Illegal use ARM Cortex M3 instruction LDMIA causes
UserFault
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: v.van.beveren at nikhef dot nl
Created attachment 30322
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30322action=edit
Test-case generating UserFault
When copying a struct into another struct, GCC's ARM back-end generates code in
which the LDMIA instruction is used. This instruction expects word-aligned
addresses. However, in some cases this is not true, causing a UserFault.
See this function:
TestStruct target;
void copyStruct(TestStruct * toCopy)
{
target = *toCopy; // illegal instruction is generated here.
}
Causes this code to be generated:
05d8 copyStruct:
5d8:b082 subsp, #8
5da:9001 strr0, [sp, #4]
5dc:4b03 ldrr3, [pc, #12]; (5ec copyStruct+0x14)
5de:9a01 ldrr2, [sp, #4]
5e0:ca07 ldmiar2, {r0, r1, r2} ; UserFault if (r2 0x3)
!= 0
5e2:e883 0007 stmia.wr3, {r0, r1, r2}
5e6:b002 addsp, #8
5e8:4770 bxlr
5ea:bf00 nop
5ec:25ec .word0x25ec
Its not said in so-many words in the ARM description, but I believe that r2 at
line 0x5e0 should be word aligned. I have verified with a debugger that this is
the line which causes the UserFault.
See:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABCAEDD.html
Complete test-case attached. Note that I used an Energy Micro Cortex M3
processor. You may need to modify it for your specific MCU. In this scenario it
does not matter what optimization one enables, however, I first noticed the
issue when compiling with -Os, which caused packing and non-word aligned
structures.
[Bug target/57648] Illegal use ARM Cortex M3 instruction LDMIA causes UserFault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57648 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code | Target|ARM Cortex M3 | Host|Windows 7 x64 | Known to fail|4.6.3, 4.7.2| Build|4.7.2 | --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- What options did you configure GCC with? What options are you using to compile the source with? I think this is note in the changes page is what you need to read in this case: On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or ARMv7-M, the new option -munaligned-access is active by default, which for some sources generates code that accesses memory on unaligned addresses. This requires the kernel of those systems to enable such accesses (controlled by CP15 register c1, refer to ARM documentation). Alternatively, or for compatibility with kernels where unaligned accesses are not supported, all code has to be compiled with -mno-unaligned-access. Upstream Linux kernel releases have automatically and unconditionally supported unaligned accesses as emitted by GCC due to this option being active since version 2.6.28.
[Bug c++/57644] [C++1y] Cannot bind bitfield to lvalue reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Looks related to PR 57573
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 --- Comment #4 from vijay Nag vijunag at gmail dot com --- (In reply to Marek Polacek from comment #3) It should work for any type, but, why don't you do only foo++;, i.e. drop the cast? In that case there shouldn't be value computed is not used warning. Pointer Arithmetic. I want to advance the pointer by sizeof(unsigned long) but not by sizeof(char).
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- ((unsigned long*)foo)++ and ((unsigned long *)foo++) are not equivalent expressions. The former is the same as foo = (char *)((unsigned long*)foo + 1), the latter is foo += sizeof(*foo) (and the cast has no effect).
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 --- Comment #6 from vijay Nag vijunag at gmail dot com --- (In reply to Andreas Schwab from comment #5) ((unsigned long*)foo)++ and ((unsigned long *)foo++) are not equivalent expressions. The former is the same as foo = (char *)((unsigned long*)foo + 1), the latter is foo += sizeof(*foo) (and the cast has no effect). ((unsigned long*)foo)++ is no longer a valid C expression for the cast evaluates it to be an R-value rather than L-value
[Bug c++/57646] bogus warning about uninitialized ‘saved_stack.1’ with gotos and VLAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57646 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Actually PR44613 is most likely the same issue.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#type error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 --- Comment #7 from vijay Nag vijunag at gmail dot com --- (In reply to vijay Nag from comment #6) (In reply to Andreas Schwab from comment #5) ((unsigned long*)foo)++ and ((unsigned long *)foo++) are not equivalent expressions. The former is the same as foo = (char *)((unsigned long*)foo + 1), the latter is foo += sizeof(*foo) (and the cast has no effect). ((unsigned long*)foo)++ is no longer a valid C expression for the cast evaluates it to be an R-value rather than L-value. Why is the second expression evaluating as foo += sizeof(*foo) ? ()(parentheses) comes before ++(postfix) although they both have the same precedence but associativity is from left to right.
[Bug c/57647] lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 --- Comment #8 from Andreas Schwab sch...@linux-m68k.org --- Postfix operators bind stronger than cast operators. If you need help on the C language then bugzilla is not the right place.
[Bug c++/56544] documentation for __cplusplus is out of date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56544 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed mainline and 4.8.2.
[Bug c++/57645] [4.8/4.9 Regression] Explicitly-declared destructor with no exception specification is always noexcept(true)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-19
Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle
dot com
Summary|Explicitly-declared |[4.8/4.9 Regression]
|destructor with no |Explicitly-declared
|exception specification is |destructor with no
|always noexcept(true) |exception specification is
||always noexcept(true)
Ever confirmed|0 |1
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Humpf, this regressed with PR50043. Apparently something is going wrong with
the way we are implementing 12.4/3, because this is still fine:
struct Thrower
{
~Thrower() noexcept(false) { throw 1; }
};
struct Explicit
{
// ~Explicit() {}
Thrower t;
};
[Bug middle-end/57649] New: [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649
Bug ID: 57649
Summary: [4.7 Regression] ICE in set_is_used
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: matz at gcc dot gnu.org
void bar (const char *);
void
foo ()
{
static const char *s = __PRETTY_FUNCTION__;
struct T { T () { bar (s); } } t;
}
ICEs at -O2 starting with r179618 on 4.7 branch, went away with r187719 for
4.8+.
Similarly C -O2:
void bar (const char *);
void
foo (void)
{
static const char *s = __PRETTY_FUNCTION__;
auto void baz (void) { bar (s); }
baz ();
}
The problem is that the s variable isn't referenced in foo during
*referenced_vars pass, is referenced in another function (nested or local class
method), but at that point the DECL_INITIAL of the var isn't marked, and later
on when the nested/local class method is inlined nothing marks the
DECL_INITIAL.
Perhaps the inliner should somewhere go through all gimple_referenced_vars of
the callee and for each TREE_STATIC var with DECL_CONTEXT of the caller just
call add_referenced_var?
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-19 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- We have this patchlet in our 4.7 tree: --- a/gcc/tree-dfa.c +++ b/gcc/tree-dfa.c @@ -590,10 +590,13 @@ add_referenced_var (tree var) /* Scan DECL_INITIAL for pointer variables as they may contain address arithmetic referencing the address of other variables. As we are only interested in directly referenced -globals or referenced locals restrict this to initializers -than can refer to local variables. */ +globals or referenced locals, restrict this to initializers +than can refer to local variables. But we need to do it for +initializers of global variables declared in parent functions +lest these variables aren't referenced anywhere else. */ if (DECL_INITIAL (var) - DECL_CONTEXT (var) == current_function_decl) + (DECL_CONTEXT (var) == current_function_decl + || (!DECL_FILE_SCOPE_P (var) is_global_var (var walk_tree (DECL_INITIAL (var), find_vars_r, NULL, 0); return true; * tree-dfa.c (add_referenced_var): Find variables referenced in the initializers of global variables declared in parent functions.
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Actually, it ICEs even without inlining, so guess the issue is just that we have a local static var that is referenced by some other function (thus used) and we don't mark its DECL_INITIAL as referenced.
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Other testcases without __PRETTY_FUNCTION__:
void bar (const char *);
void
foo (void)
{
static const char r[] = abc;
static const char *s = t;
auto void baz (void) { bar (s); }
baz ();
}
void bar (const char *);
void
foo ()
{
static const char r[] = abc;
static const char *s = r;
struct T { T () { bar (s); } } t;
}
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- How about backporting r187719? I don't remember whether there are any dependencies here, but ... it seems it's the first patch in the series to cleanup all this stuff.
[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Andi also reported success.
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Isn't it going to cause problems if we fold some accesses to the static var using the expressions in the initializer, we'd end up with not having the vars referenced? If backporting anything, my preference would be to actually backport just the tree-ssa-live.c change and not the tree-dfa.c change. Or Eric's patch.
[Bug middle-end/57649] [4.7 Regression] ICE in set_is_used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57649 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) Isn't it going to cause problems if we fold some accesses to the static var using the expressions in the initializer, we'd end up with not having the vars referenced? Well - we are carefully trying to add them at the point we fold ... If backporting anything, my preference would be to actually backport just the tree-ssa-live.c change and not the tree-dfa.c change. Or Eric's patch. Backporting just the tree-ssa-live.c change also works for me.
[Bug tree-optimization/57650] New: Suboptimal code after TRUTH_AND_EXPR is changed into BIT_AND_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57650
Bug ID: 57650
Summary: Suboptimal code after TRUTH_AND_EXPR is changed into
BIT_AND_EXPR
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
On:
int baz (int);
int
foo (char *x, int y, int z)
{
if (y z x)
return baz (1);
if (x)
baz (2);
return 0;
}
int
bar (char *x, int y, int z)
{
if (x y z)
return baz (1);
if (x)
baz (2);
return 0;
}
one of the functions (depending on reassoc decission to keep or swap the
BIT_AND_EXPR arguments) ends up with really bad generated code, will do
testq %rdi, %rdi
setne %al
...
compare y with z, jump based on that, then test %al (separately in both
branches). Would be much better if tree optimizers could figure out that if
one of the BIT_AND_EXPR operands is also used as condition for a conditional
jump nearby, that it perhaps could jump thread this (essentially generate the
same code as
if (x)
{
if (y z)
return bar (1);
bar (2);
}
would).
[Bug driver/57651] New: [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 Bug ID: 57651 Summary: [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org $ gcc-ar-4.8 -h gcc-ar-4.8: Cannot find plugin 'liblto_plugin.so' the plugin is *not* installed with x permission flags (which seems to be the standard for shared libraries). You did change the code to use find_a_file which searches only for files with the x bit set. Work around is to install the plugin with the x bits set, or use some helper function which doesn't look for the x bits. I assume that wasn't catched, because the plugin then was found in another location? gcc.c has a static find_a_file function which does allows to specify the permission flags you want to search for.
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- now, working around the permission bit, I get: $ gcc-ar-4.8 gcc-ar-4.8: Cannot find binary 'ar' so it only searches ar in the given paths, not on the path of the file system (/usr/bin in this case)
[Bug tree-optimization/40766] this fortran program is too slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW Component|fortran |tree-optimization --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr --- On a Intel(R) Xeon(R) CPU E5640 @ 2.67GHz under Linux version 2.6.43.8-1.fc15.x86_64 (mockbu...@x86-02.phx2.fedoraproject.org) (gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) ) #1 SMP Mon Jun 4 20:33:44 UTC 2012, the timing for the test in comment #0 compiled with gfortran 4.6.3 is [delta] test/fortran$ time a.out 4.28173363E+09 1441.326u 0.035s 24:04.84 99.7%0+0k 0+0io 0pf+0w Note that a real(8) version gives [delta] test/fortran$ time a.out 696899672.37568963 184.465u 0.067s 3:05.04 99.7%0+0k 400+0io 3pf+0w without optimization, 696899672.37569129 131.957u 0.104s 2:12.39 99.7%0+0k 0+0io 0pf+0w with -O3 and 696899672.37550783 136.051u 0.066s 2:16.43 99.7%0+0k 0+0io 0pf+0w with -O3 -ffast-math. I don't have access to more recent fedora and/or gcc versions, so I don't know if the miserable performances of some linux transcendental floats have been finally fixed or not (the accuracy argument is ridiculous: what is the point to get the 23rd bit exact when you cat get more than 50 for 10 time less?). On this count this PR should be fixed as INVALID. However, I have found a strange behavior with optimization when repeating the test on a 2.5Ghz Core2Duo under x86_64-apple-darwin10: -O0 76.1s -O0 -ftree-ter 62.5s -O1103.0s -O2112.9s -O3112.9s -Ofast 115.2s Can someone explain what's going on?
[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Given Richard's comments and no testcase, I'm in doubt if this PR is meaningful?! Any new opinion about this PR? or should we close it as WONTFIX. NOTE: I'ld like very much that the -no-protect-parens be removed from -Ofast!-(
[Bug fortran/54797] Gnu Fortran compiler does not recognize module file it created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any progress on this PR? or should it be closed at WORKSFORME?
[Bug tree-optimization/57584] [4.9 Regression] ice: SSA corruption: Unable to coalesce ssa_names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57584 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |4.9.0 Summary|ice: SSA corruption: Unable |[4.9 Regression] ice: SSA |to coalesce ssa_names |corruption: Unable to ||coalesce ssa_names --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It's the vectorizer, thus fails at -O -ftree-vectorize already.
[Bug driver/57652] New: [4.7/4.8/4.9 Regression] collect2 does not clean up temporary files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57652
Bug ID: 57652
Summary: [4.7/4.8/4.9 Regression] collect2 does not clean up
temporary files
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
The 2011-05-19 change to convert collect2 to use the common diagnostics
infrastructure broke collect2's handling of temporary files. The original
error reporting routines reported the error message and, IMPORTANTLY, called
collect_exit(). collect_exit() removes temporary files through multiple
invocations of maybe_unlink().
The change to invoke fatal_error() in GCC's diagnostics.c directly terminates
without cleaning up the temporary files. This leaves at least 5 temporary files
in /tmp for each link step that results in an error message. When using GNU
configure to probe system features, this creates numerous temporary files.
For example,
$ cat foo.c
int main () {}
$ gcc foo.c -lnonexistent
collect2: fatal error: library libnonexistent not found
compilation terminated.
$ ls /tmp/cc*
/tmp/cc0IcxVL.c /tmp/ccKwuh03.x /tmp/ccqMJsFn.le
/tmp/cc2taIMJ.ld /tmp/cceKTq5n.o
[Bug driver/57652] [4.7/4.8/4.9 Regression] collect2 does not clean up temporary files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57652 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.6.3 Keywords||error-recovery Last reconfirmed||2013-06-19 CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |4.9.0 Known to fail||4.7.0, 4.7.1, 4.7.2, 4.7.3, ||4.8.0, 4.8.1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug middle-end/57653] New: filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Bug ID: 57653 Summary: filename information discarded when using -imacros Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: allan at archlinux dot org When compiling with the -imacros flag, the file name information is lost in error messages and backtraces. e.g. gcc-4.8 -imacros i.h test.c command-line: In function ‘main’: command-line:5:1: error: expected ‘;’ before ‘}’ token The problem commit is: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6adc88f8
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 --- Comment #2 from Meador Inge meadori at codesourcery dot com --- Since Jakub posted a patch for the PATH problem [1] and it seems that the permission issue might be a non-issue [2] is there anything else let for this bug? [1] http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01122.html [2] http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01113.html
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- please lets fix it in gcc. I fixed it in gcc.c last year, and this behaviour is now re-introduced, so it is a regression. shared libraries work without the x bit set too, so lets just recognize these too.
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 --- Comment #4 from Meador Inge meadori at codesourcery dot com --- OK, I will look into it.
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 meadori at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-19 CC||meadori at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |meadori at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #184 from Jan Hubicka hubicka at gcc dot gnu.org --- New profiles after Richard's changes to remove pointer maps from straming in. Stream in: samples %app name symbol name 3659912.3464 lto1 inflate_fast 27382 9.2371 lto1 streamer_read_uhwi(lto_input_block*) 19282 6.5047 lto1 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) 15807 5.3324 lto1 compare_tree_sccs_1(tree_node*, tree_node*, tree_node***) 11385 3.8407 libc-2.11.1.so msort_with_tmp 9054 3.0543 libc-2.11.1.so memcpy 8701 2.9352 lto1 htab_find_slot_with_hash 8506 2.8694 lto1 lto_input_tree(lto_input_block*, data_in*) 8405 2.8354 lto1 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) 8055 2.7173 lto1 ht_lookup_with_hash(ht*, unsigned char const*, unsigned long, unsigned int, ht_lookup_option) 6436 2.1711 lto1 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*) 6287 2.1209 lto1 adler32 5891 1.9873 lto1 streamer_get_pickled_tree(lto_input_block*, data_in*) Stream out: samples %app name symbol name 1988514.6837 lto1 DFS_write_tree(output_block*, sccs*, tree_node*, bool, bool) 1928514.2407 lto1 linemap_lookup(line_maps*, unsigned int) 1619211.9567 lto1 streamer_write_uhwi_stream(lto_output_stream*, unsigned long) 1592611.7603 lto1 pointer_map_insert(pointer_map_t*, void const*) 10285 7.5948 lto1 pointer_map_contains(pointer_map_t const*, void const*) 7324 5.4083 lto1 streamer_tree_cache_lookup(streamer_tree_cache_d*, tree_node*, unsigned int*) 5897 4.3545 lto1 streamer_pack_tree_bitfields(output_block*, bitpack_d*, tree_node*) 5374 3.9683 lto1 lto_output_tree(output_block*, tree_node*, bool, bool) 4896 3.6154 lto1 streamer_tree_cache_insert_1(streamer_tree_cache_d*, tree_node*, unsigned int, unsigned int*, bool) 3285 2.4258 libc-2.11.1.so memset 2669 1.9709 lto1 streamer_write_tree_body(output_block*, tree_node*, bool) 2520 1.8608 libc-2.11.1.so memcpy 2383 1.7597 lto1 streamer_tree_cache_add_to_node_array(streamer_tree_cache_d*, unsigned int, tree_node*, unsigned int) linemap_lookup is easy target, obviously. Execution times (seconds) phase setup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1399 kB ( 0%) ggc phase opt and generate : 69.29 (14%) usr 0.82 ( 3%) sys 70.62 (13%) wall 270269 kB (11%) ggc phase stream in : 224.95 (44%) usr 6.23 (22%) sys 236.02 (43%) wall 2174294 kB (89%) ggc phase stream out: 213.26 (42%) usr 21.35 (75%) sys 236.87 (44%) wall 7157 kB ( 0%) ggc garbage collection : 9.92 ( 2%) usr 0.00 ( 0%) sys 9.99 ( 2%) wall 0 kB ( 0%) ggc callgraph optimization : 1.36 ( 0%) usr 0.00 ( 0%) sys 1.34 ( 0%) wall 32 kB ( 0%) ggc ipa cp : 7.65 ( 2%) usr 0.32 ( 1%) sys 8.01 ( 1%) wall 418436 kB (17%) ggc ipa inlining heuristics : 38.83 ( 8%) usr 0.83 ( 3%) sys 39.99 ( 7%) wall 1352530 kB (55%) ggc ipa lto gimple in : 0.39 ( 0%) usr 0.05 ( 0%) sys 0.53 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple out : 16.46 ( 3%) usr 1.39 ( 5%) sys 17.93 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl in : 158.55 (31%) usr 3.99 (14%) sys 166.99 (31%) wall 2583106 kB (105%) ggc ipa lto decl out: 191.10 (38%) usr 11.48 (40%) sys 203.47 (37%) wall 0 kB ( 0%) ggc ipa lto cgraph I/O : 7.07 ( 1%) usr 1.17 ( 4%) sys 8.27 ( 2%) wall 2134131 kB (87%) ggc ipa lto decl merge : 29.94 ( 6%) usr 0.01 ( 0%) sys 30.06 ( 6%) wall 8270 kB ( 0%) ggc ipa lto cgraph merge: 12.02 ( 2%) usr 0.04 ( 0%) sys 12.13 ( 2%) wall 142240 kB ( 6%) ggc whopr wpa : 7.30 ( 1%) usr 0.03 ( 0%) sys 7.39 ( 1%) wall 7160 kB ( 0%) ggc whopr wpa I/O : 1.40 ( 0%) usr 8.46 (30%) sys 11.14 ( 2%) wall 0 kB ( 0%) ggc whopr partitioning : 2.33 ( 0%) usr 0.01 ( 0%) sys 2.36 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 5.44 ( 1%) usr 0.04 ( 0%) sys 5.53 ( 1%) wall 0 kB ( 0%) ggc ipa profile : 1.26 ( 0%) usr 0.04 ( 0%) sys 1.32 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 5.87 ( 1%) usr 0.13 ( 0%) sys 6.03 ( 1%) wall 0 kB ( 0%) ggc inline parameters : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 meadori at gcc dot gnu.org changed: What|Removed |Added Assignee|meadori at gcc dot gnu.org |doko at gcc dot gnu.org --- Comment #5 from meadori at gcc dot gnu.org --- Matthias, I see where you already have a proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01134.html Assigning to you.
[Bug c++/57654] New: [c++11][constexpr] static class member reference-to-a-reference will not compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57654
Bug ID: 57654
Summary: [c++11][constexpr] static class member
reference-to-a-reference will not compile
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pebbles at riseup dot net
This simple example fails to compile with g++ development sources.
===
int i;
constexpr int iref = i;
constexpr int irefref = iref;
// works
class A {
static constexpr int irefref = iref;
// ^
// error: field initializer is not constant
};
This is similar but not the same as bug 50298 .
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-19 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- This seems to be ELF or libelf limitation. The .o produced is corrupt apparently because we produce too many function sections. The second largest ltrans unit is over 2, so perhaps elf is limited to 32000 sections?
[Bug driver/57652] [4.7/4.8/4.9 Regression] collect2 does not clean up temporary files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57652
--- Comment #2 from David Edelsohn dje at gcc dot gnu.org ---
Prototype patch to use atexit.
PR driver/57652
* collect2.c (collect_atexit): New.
(collect_exit): Directly call exit.
(main): Register collect_atexit with atexit.
Index: collect2.c
===
--- collect2.c (revision 200203)
+++ collect2.c (working copy)
@@ -367,7 +367,7 @@
/* Delete tempfiles and exit function. */
void
-collect_exit (int status)
+collect_atexit (void)
{
if (c_file != 0 c_file[0])
maybe_unlink (c_file);
@@ -395,12 +395,13 @@
maybe_unlink (lderrout);
}
- if (status != 0 output_file != 0 output_file[0])
-maybe_unlink (output_file);
-
if (response_file)
maybe_unlink (response_file);
+}
+void
+collect_exit (int status)
+{
exit (status);
}
@@ -970,6 +971,9 @@
signal (SIGCHLD, SIG_DFL);
#endif
+ if (atexit (collect_atexit) != 0)
+fatal_error (atexit failed);
+
/* Unlock the stdio streams. */
unlock_std_streams ();
[Bug driver/57651] [4.8 / 4.9 Regression] gcc-ar and gcc-nm don't find the lto plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57651 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 19 17:37:36 2013 New Revision: 200209 URL: http://gcc.gnu.org/viewcvs?rev=200209root=gccview=rev Log: PR driver/57651 * gcc-ar.c (main): If not CROSS_DIRECTORY_STRUCTURE, look for PERSONALITY in $PATH derived prefixes. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc-ar.c Author: jakub Date: Wed Jun 19 17:39:20 2013 New Revision: 200210 URL: http://gcc.gnu.org/viewcvs?rev=200210root=gccview=rev Log: PR driver/57651 * gcc-ar.c (main): If not CROSS_DIRECTORY_STRUCTURE, look for PERSONALITY in $PATH derived prefixes. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/gcc-ar.c
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #9 from Ian Lance Taylor ian at airs dot com --- It looks like simple_object_elf_write_ehdr in libiberty/simple-object-elf.c does not correctly handle the case of writing an ELF object with more than 65,280 sections. That may be the problem here.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #10 from Ian Lance Taylor ian at airs dot com --- Created attachment 30323 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30323action=edit Possible patch Can you see if this patch fixes the problem?
[Bug c/45784] gcc OpenMP - error: invalid controlling predicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45784 --- Comment #2 from Geir Johansen geir at cray dot com --- Fails in GCC 4.8.0: $ gcc --version gcc (GCC) 4.8.0 20130322 (Cray Inc.) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -c -fopenmp -std=c99 ISU3417.c ISU3417.c: In function 'vla_test': ISU3417.c:24:25: error: invalid controlling predicate for (ptr = vla; ptr vla + sizeof(vla)/sizeof(vla[0]); ^ $
[Bug libgomp/33720] A negative value in OpenMP clause num_threads is not detected at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720 --- Comment #6 from Geir Johansen geir at cray dot com --- Fails in GCC 4.8.0: $ gcc --version gcc (GCC) 4.8.0 20130322 (Cray Inc.) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -o x -fopenmp bug2883.c -lm $ ./x pi 3.1416 n_thread -7 libgomp: Out of memory allocating 481036337712 bytes $
[Bug libgomp/33720] A negative value in OpenMP clause num_threads is not detected at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- I still believe it is not needed to slow down the runtime library with checks for invalid programs. Negative num_threads is undefined behavior, just don't do it.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, self contained way to reproduce the bug:
evans:/tmp/:[1]# cat t.c
#include stdio.h
main()
{
int i;
printf (int main(){}\n);
for (i=0;i7;i++)
printf (__attribute__ ((used, externally_visible)) int
tti%i(){}\n,
i);
}
evans:/tmp/:[1]# gcc t.c
evans:/tmp/:[1]# ./a.out tt.c
evans:/tmp/:[1]# /abuild/jh/trunk-install/bin/gcc -O2 -flto tt.c --param
lto-partitions=1
takes a while. I am testing the patch.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Just use preprocessor rather than proglet to generate the testcase ;).
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
meadori at gcc dot gnu.org changed:
What|Removed |Added
CC||meadori at gcc dot gnu.org
--- Comment #10 from meadori at gcc dot gnu.org ---
I just bumped into this again while looking through some XFAILS.
I think Andreas' analysis is correct, but I am not sure how to
fix the problem.
Note that for ARM that the test passes for '-mfloat-abi=hard'.
For `arm-none-eabi-gcc -O -Wuninitialized` we get:
original
{
C f;
C f;
IMAGPART_EXPR f = 0.0;
return f;
}
gimple
==
foo ()
{
float D.4063;
C f;
; NOTE: The partial store was promoted to a total store which
; introduces the 'REALPART_EXPR f' bit.
D.4063 = REALPART_EXPR f;
f = COMPLEX_EXPR D.4063, 0.0;
retval = f;
return retval;
}
cplxlower1
==
foo ()
{
float f$real;
C f;
bb 2:
f$real_2 = f$real_6(D);
f_3 = COMPLEX_EXPR f$real_2, 0.0;
REALPART_EXPR retval = f$real_2;
IMAGPART_EXPR retval = 0.0;
return retval;
}
dce2
foo ()
{
float f$real;
C f;
bb 2:
; NOTE: Warning about unused variable on next statement, which is
; associated with the 'C f;' declaration because the statements
; below as introduced by cplxlower1 don't have any location info.
REALPART_EXPR retval = f$real_6(D);
IMAGPART_EXPR retval = 0.0;
return retval;
}
For `arm-none-eabi-gcc -O -Wuninitialized -mfloat-abi=hard` things are very
similar until we get to complex lowering:
gimple
==
foo ()
{
float D.4062;
C D.4063;
C f;
; NOTE: The partial store was promoted to a total store which
; introduces the 'REALPART_EXPR f' bit.
D.4062 = REALPART_EXPR f;
f = COMPLEX_EXPR D.4062, 0.0;
D.4063 = f;
return D.4063;
}
cplxlower1
==
foo ()
{
float f$real;
C f;
bb 2:
f$real_2 = f$real_5(D);
f_3 = COMPLEX_EXPR f$real_2, 0.0;
return f_3;
}
dce2
foo ()
{
float f$real;
C f;
bb 2:
; NOTE: Warning about unused variable on next statement,
; which is associated with the '__imag__ f = 0;' line.
f_3 = COMPLEX_EXPR f$real_5(D), 0.0;
return f_3;
}
[Bug libgomp/33720] A negative value in OpenMP clause num_threads is not detected at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) I still believe it is not needed to slow down the runtime library with checks for invalid programs. Negative num_threads is undefined behavior, just don't do it. Perhaps the check could be added with the new -fsanitize=undefined?
[Bug target/57655] New: [4.8/4.9 Regression] ICE: in create_pre_exit, at mode-switching.c:418 with -mno-fp-ret-in-387 -mvzeroupper -mxop and __builtin_ilogbl()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57655 Bug ID: 57655 Summary: [4.8/4.9 Regression] ICE: in create_pre_exit, at mode-switching.c:418 with -mno-fp-ret-in-387 -mvzeroupper -mxop and __builtin_ilogbl() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 30324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30324action=edit reduced testcase Compiler output: $ gcc -mno-fp-ret-in-387 -mvzeroupper -mxop testcase.c testcase.c: In function 'foo': testcase.c:5:1: internal compiler error: in create_pre_exit, at mode-switching.c:418 } ^ 0x1178ceb create_pre_exit /mnt/svn/gcc-trunk/gcc/mode-switching.c:404 0x1178ceb optimize_mode_switching /mnt/svn/gcc-trunk/gcc/mode-switching.c:493 0x1178ceb rest_of_handle_mode_switching /mnt/svn/gcc-trunk/gcc/mode-switching.c:779 0xc97d17 rest_of_handle_insert_vzeroupper /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:2599 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. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-200176-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-200176-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.9.0 20130618 (experimental) (GCC) Tested revisions: r200211 - ICE 4.8 r198018 - ICE 4.7 r198018 - OK
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to meadori from comment #10)
I just bumped into this again while looking through some XFAILS.
I think Andreas' analysis is correct, but I am not sure how to
fix the problem.
This explanation would be clearer if you used the option -lineno (or -all) when
dumping.
Ideally, the warning should be given in return f. Perhaps there is a way to
adjust the locations?
I guess that for:
4 typedef _Complex float C;
5 C foo()
6 {
7C f;
8__imag__ f = 0; /* { dg-warning is used unconditional } */
__real__ f = 0;
9return f;
10 }
there is no warning, no?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org Component|middle-end |c --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Can you provide a complete testcase? Thanks.
[Bug c++/57646] bogus warning about uninitialized ‘saved_stack.1’ with gotos and VLAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57646 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I think it is exactly the same. *** This bug has been marked as a duplicate of bug 44613 ***
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||b.r.longbons at gmail dot com --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 57646 has been marked as a duplicate of this bug. ***
[Bug target/57655] [4.8/4.9 Regression] ICE: in create_pre_exit, at mode-switching.c:418 with -mno-fp-ret-in-387 -mvzeroupper -mxop and __builtin_ilogbl()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57655 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-19 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- --cut here-- Index: i386.c === --- i386.c (revision 200211) +++ i386.c (working copy) @@ -6498,7 +6498,7 @@ construct_container (enum machine_mode mode, enum /* Likewise, error if the ABI requires us to return values in the x87 registers and the user specified -mno-80387. */ - if (!TARGET_80387 in_return) + if (!TARGET_FLOAT_RETURNS_IN_80387 in_return) for (i = 0; i n; i++) if (regclass[i] == X86_64_X87_CLASS || regclass[i] == X86_64_X87UP_CLASS --cut here--
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #2 from Allan McRae allan at archlinux dot org ---
# echo int main() { return } foo.c
# touch foo.h
# gcc -imacros foo.h foo.c
command-line: In function ‘main’:
command-line:1:21: error: expected expression before ‘}’ token
[Bug tree-optimization/57656] New: Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656
Bug ID: 57656
Summary: Wrong constant folding
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
GCC 4.8.2 for i686 miscompiles the following code.
$ cat error.c
int main (void)
{
int a = -1;
int b = 2147483647;
int c = 2;
int t = 1 - ((a - b) / c); // t = 1 - ( -2147483648 / 2 )
if (t != 1073741825) { __builtin_abort(); }
return 0;
}
$ i686-pc-linux-gnu-gcc-4.8.2 error.c -O2
$ ./a.out
Aborted (core dumped)
There was no problem with an x86_64 target.
$ i686-pc-linux-gnu-gcc-4.8.2 -v
Using built-in specs.
COLLECT_GCC=i686-pc-linux-gnu-gcc-4.8.2
COLLECT_LTO_WRAPPER=/usr/local/i686-tools/gcc-4.8.2/libexec/gcc/i686-pc-linux-gnu/4.8.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/hassy/gcc/configure
--prefix=/usr/local/i686-tools/gcc-4.8.2/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib --disable-nls
--enable-languages=c
Thread model: posix
gcc version 4.8.2 20130607 (prerelease) (GCC)
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Allan McRae from comment #2)
# echo int main() { return } foo.c
# touch foo.h
# gcc -imacros foo.h foo.c
command-line: In function ‘main’:
command-line:1:21: error: expected expression before ‘}’ token
I cannot reproduce this with r198545, so it seems fixed in mainline. Could you
test with that?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I mean in GCC 4.9.0 (trunk), (that revision is the latest I have built).
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #5 from Allan McRae allan at archlinux dot org --- I still get this with r200224 # gcc-4.9 -v Using built-in specs. COLLECT_GCC=gcc-4.9 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-git/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share/gcc-4.9 --with-bugurl='http://aur.archlinux.org/packages.php?ID=16045' --enable-languages=c,c++,lto --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release --program-suffix=-4.9 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.9.0 20130619 (experimental) (GCC) Built with CFLAGS=-march=x86-64 -mtune=generic -O2 -fstack-protector --param=ssp-buffer-size=4 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro
[Bug c/57657] New: [regression from 4.7] Reports incorrect cache sizes on corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657 Bug ID: 57657 Summary: [regression from 4.7] Reports incorrect cache sizes on corei7 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thomas.br...@virtuell-zuhause.de I have a Intel(R) Core(TM) i7-3930K CPU @ 3.20GH CPU and I'm on debian unstable. The bottom line is that gcc-4.8 reports incorrect cache sizes compared to gcc-4.7. #gcc-4.8 -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-3) Calling #gcc-4.8 -### -E -march=native /usr/include/stdlib.h 21 | grep cache-size gives /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -E -quiet -imultilib . -imultiarch x86_64-linux-gnu /usr/include/stdlib.h -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 -mtune=corei7-avx Whereas #cat /proc/cpuinfo | grep -E (cache size|cache_alignment) | tail -n 2 says cache size : 12288 KB cache_alignment : 64 Using an older version of gcc #gcc-4.7 --version gcc-4.7 (Debian 4.7.3-5) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE I get what I expect #gcc-4.7 -### -E -march=native /usr/include/stdlib.h 21 | grep cache-size /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -imultilib . -imultiarch x86_64-linux-gnu /usr/include/stdlib.h -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=corei7-avx Thanks for reading Thomas PS: Output of cpuid eax ineax ebx ecx edx 000d 756e6547 6c65746e 49656e69 0001 000206d7 03200800 1fbee3bf bfebfbff 0002 76035a01 00f0b2ff 00ca 0003 0004 0005 0040 0040 0003 00021120 0006 0077 0002 0009 0007 0008 0009 0001 000a 07300403 0603 000b 002c 0003 000c 000d 8000 8008 8001 0001 2c100800 8002 20202020 49202020 6c65746e 20295228 8003 65726f43 294d5428 2d376920 30333933 8004 5043204b 20402055 30322e33 007a4847 8005 8006 01006040 8007 0100 8008 302e Vendor ID: GenuineIntel; CPUID level 13 Intel-specific functions: Version 000206d7: Type 0 - Original OEM Family 6 - Pentium Pro Model 13 - Stepping 7 Reserved 8 Extended brand string:Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz CLFLUSH instruction cache line size: 8 Initial APIC ID: 3 Hyper threading siblings: 32 Feature flags bfebfbff: FPUFloating Point Unit VMEVirtual 8086 Mode
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org --- progret needs a fraction of brain capacity than the preprocessor generator and I doubt it would be faster :))) anyway I seem to be still getting error with the patch evans:/tmp/:[0]# /abuild/jh/trunk-install/bin/gcc -O2 -flto tt.c --param lto-partitions=1 lto1: error: ELF section name out of range (null):0: confused by earlier errors, bailing out lto-wrapper: /abuild/jh/trunk-install/bin/gcc returned 1 exit status /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug target/57648] Illegal use ARM Cortex M3 instruction LDMIA causes UserFault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57648 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- static uint8_t source[sizeof(TestStruct) + 4] __attribute__((aligned(4))); ... // create a half-word aligned structure (fails!) TestStruct * sourcePtrFail = (TestStruct *) (source[2]); This has undefined behaviour. Your TestStruct defintion is required (by the ABI) to have word alignment.
[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408 --- Comment #4 from superbem at gmail dot com --- Thanks for further testing it. Isn't this confirmed yet? How to do. I've stumbled across this issue several times, and I'm very admired that I'm the only one.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #6 from Allan McRae allan at archlinux dot org --- I have also confirmed this issue on Fedora rawhide. gcc 4.8.1 20130603 (Red Hat 4.8.1-1)
[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255 Carlos O'Donell carlos at redhat dot com changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #7 from Carlos O'Donell carlos at redhat dot com --- (In reply to Krisztian Kocsis from comment #6) I currently know that glibc uses it but don't know who else use it. In my projects I always use constructor/destructor attributes because with them I can control the exection order. Internally glibc uses attribute used to mark any special .init_array sections as used. It is only in our configure check and some tests that we don't use the used attribute (bug in glibc). Building the library with -fwhole-program has never been tested and likely won't succeed without a lot of additional work.
