[Bug target/59046] New: [4.8.x REGRESSION] corei7: L1 + L2 cache size not correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59046 Bug ID: 59046 Summary: [4.8.x REGRESSION] corei7: L1 + L2 cache size not correct Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gnu.org at marc dot ngoe.de Issuing the following command gives incorrect cache sizes with gcc 4.8.1: gcc -march=native -E -v - /dev/null 21 | grep c1 17.05.2013 gcc-4.7.3 /usr/libexec/gcc/i686-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=corei7 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -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=4096 -mtune=corei7 20 # 06.11.2013 gcc-4.8.1-r1 /usr/libexec/gcc/i686-pc-linux-gnu/4.8.1/cc1 -E -quiet -v - -march=corei7 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -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 -mno-xsave -mno-xsaveopt --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 -mtune=corei7 According to a comment in #57657 this should have been fixed in May 15th, but the 4.8.1 release dated May 31 still has the bug. Is this fixed in 4.8.2 or re-introduced?
[Bug tree-optimization/58955] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58955 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 8 08:44:02 2013 New Revision: 204561 URL: http://gcc.gnu.org/viewcvs?rev=204561root=gccview=rev Log: 2013-11-08 Richard Biener rguent...@suse.de PR tree-optimization/59038 PR tree-optimization/58955 * tree-loop-distribution.c (pg_add_dependence_edges): Revert previous change. Handle known dependences correctly. * gcc.dg/torture/pr59038.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59038.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/59038] [4.9 Regression] r204398 causes 186.crafty init.c to be miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 8 08:44:02 2013 New Revision: 204561 URL: http://gcc.gnu.org/viewcvs?rev=204561root=gccview=rev Log: 2013-11-08 Richard Biener rguent...@suse.de PR tree-optimization/59038 PR tree-optimization/58955 * tree-loop-distribution.c (pg_add_dependence_edges): Revert previous change. Handle known dependences correctly. * gcc.dg/torture/pr59038.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59038.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/59038] [4.9 Regression] r204398 causes 186.crafty init.c to be miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to H.J. Lu from comment #15) (In reply to Eric Botcazou from comment #14) This is good to hear. What is each field? I assume that the first 3 fields are frame address, resume address and stack address. Are the same for all targets? What are the maximum number of fields? Everything is in the manual I think, otherwise certainly in the sources. I couldn't find anything in GCC manual. See tm.texi / md.texi.
[Bug tree-optimization/59047] New: wrong code for bitfields at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047
Bug ID: 59047
Summary: wrong code for bitfields at -O3 on x86_64-linux-gnu
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following testcase on x86_64-linux-gnu at
-O3 (in both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--enable-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131108 (experimental) [trunk revision 204560] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
1
$ gcc-4.8.2 -O3 small.c; a.out
1
$
$ gcc-trunk -O3 small.c; a.out
0
$
--
int printf (const char *, ...);
struct
{
int f0;
int f1:1;
int f2:2;
} a = {0, 0, 1};
int b, c, *d, e, f;
int
fn1 ()
{
for (; b 1; ++b)
{
for (e = 0; e 1; e = 1)
{
int **g = d;
*g = c;
}
*d = 0;
f = a.f1;
if (f)
return 0;
}
return 0;
}
int
main ()
{
fn1 ();
printf (%d\n, b);
return 0;
}
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-08 CC|decaluwe.t at gmail dot com| Summary|Internal compiler error |[4.8/4.9 Regression] |triggers when accessing a |Internal compiler error |typedef in a specialized|triggers when accessing a |member class|typedef in a specialized ||member class Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- The code may be invalid however.
[Bug tree-optimization/59047] [4.9 Regression] wrong code for bitfields at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.8.2 Keywords||wrong-code Last reconfirmed||2013-11-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code for bitfields at |[4.9 Regression] wrong code |-O3 on x86_64-linux-gnu |for bitfields at -O3 on ||x86_64-linux-gnu Target Milestone|--- |4.9.0 Known to fail||4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #16) I couldn't find anything in GCC manual. See tm.texi / md.texi. This is the only thing I found: -- Macro: DONT_USE_BUILTIN_SETJMP Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme should use the 'setjmp'/'longjmp' functions from the C library instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. It doesn't say they can't be used in the same function, the size of the jump buffer, nor what each field in the jump buffer is used for.
[Bug target/59046] [4.8.x REGRESSION] corei7: L1 + L2 cache size not correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59046 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657#c3
[Bug target/59046] [4.8.x REGRESSION] corei7: L1 + L2 cache size not correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59046 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Marc Burkhardt from comment #0) According to a comment in #57657 this should have been fixed in May 15th, The comment says it was INTRODUCED on May 15.
[Bug tree-optimization/59047] [4.9 Regression] wrong code for bitfields at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Triggered by predictive commoning fix. Mine.
[Bug middle-end/48110] __attribute__ ((optimize(...))) version of -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Indeed, not sure why we even support 3 or s, but fast would certainly alias with -fast ;)
[Bug tree-optimization/59038] [4.9 Regression] r204398 causes 186.crafty init.c to be miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 59045 has been marked as a duplicate of this bug. ***
[Bug testsuite/59043] [4.9 Regression] FAIL: (gcc|++).dg/pubtypes* scan-assembler long.*Length of Public Type Names Info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59043 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59045] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59045 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Already fixed. *** This bug has been marked as a duplicate of bug 59038 ***
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
I couldn't find anything in GCC manual.
There are a few documented hooks, but this looks quite light indeed, so the
sources are probably the best references, i.e. builtins.c and except.c:
/* __builtin_longjmp is passed a pointer to an array of five words (not
all will be used on all machines). It operates similarly to the C
library function of the same name, but is more efficient. Much of
the code below is copied from the handling of non-local gotos. */
static void
expand_builtin_longjmp (rtx buf_addr, rtx value)
{
rtx fp, lab, stack, insn, last;
enum machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
void
init_eh (void)
{
[...]
#ifdef DONT_USE_BUILTIN_SETJMP
#ifdef JMP_BUF_SIZE
tmp = size_int (JMP_BUF_SIZE - 1);
#else
/* Should be large enough for most systems, if it is not,
JMP_BUF_SIZE should be defined with the proper value. It will
also tend to be larger than necessary for most systems, a more
optimal port will define JMP_BUF_SIZE. */
tmp = size_int (FIRST_PSEUDO_REGISTER + 2 - 1);
#endif
#else
/* builtin_setjmp takes a pointer to 5 words. */
tmp = size_int (5 * BITS_PER_WORD / POINTER_SIZE - 1);
#endif
tmp = build_index_type (tmp);
tmp = build_array_type (ptr_type_node, tmp);
f_jbuf = build_decl (BUILTINS_LOCATION,
FIELD_DECL, get_identifier (__jbuf), tmp);
#ifdef DONT_USE_BUILTIN_SETJMP
/* We don't know what the alignment requirements of the
runtime's jmp_buf has. Overestimate. */
DECL_ALIGN (f_jbuf) = BIGGEST_ALIGNMENT;
DECL_USER_ALIGN (f_jbuf) = 1;
#endif
[Bug c/57258] unused variable warning is emitted for volatile variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #2 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Is there a practical reason why the user would not want to remove such a variable? We can't think of any.
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED CC|gcc-bugs at gcc dot gnu.org| Resolution|--- |FIXED Target Milestone|--- |4.6.0 --- Comment #29 from Paolo Carlini paolo.carlini at oracle dot com --- Thus fixed for 4.6.0, right?
[Bug c++/59048] New: std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
Bug ID: 59048
Summary: std::string operator== between std::string and const
char* creates unecessary temporary object
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luca.stoppa at bbh dot com
Template functions
bool operator==( const char*, const std::string ) and
bool operator==( const std::string, const char* )
creates unecessary temporary std::string object. I'm using mainly GCC 4.4.7,
but I have tested GCC 4.8.3 and the behavior is exactly the same.
Look at this simple example:
1) here we call operator==(std::string, const char*):
size_t f(const std::string str)
{
size_t result = 0;
size_t len = str.size();
for (size_t i=0; ilen; ++i)
if (str == ST)
result += i;
return result;
}
2) here we call operator==(const char*, const std::string)
size_t h(const std::string str)
{
size_t result = 0;
size_t len = str.size();
for (size_t i=0; ilen; ++i)
if (ST == str)
result += i;
return result;
}
3) here a basic const char* version
size_t ii(const char *str)
{
size_t result = 0;
size_t len = strlen(str);
for (size_t i=0; ilen; ++i)
if (0 == strcmp(str,ST))
result += i;
return result;
}
4) here a mixed version: std::string compared with strcmp().
size_t g(const std::string str)
{
size_t result = 0;
size_t len = str.size();
for (size_t i=0; ilen; ++i)
if (0 == strcmp(str.c_str(),ST))
result += i;
return result;
}
This is the main I used to test these functions:
int main(int argc, char **argv )
{
long how_many_times=atol( argv[1] );
std::string events[]={ CASH, EQ, FI, FT, FWD, OP, ST };
size_t result=0;
for (size_t i=0; ihow_many_times; ++i)
for (size_t j=0; jelements(events); ++j)
result += f(events[j]);
std::cout result std::endl;
return 0;
}
Few things to notice: running time ./a.out
f() will produce:
bash-4.1$ time ./a.out 1000
1000
real0m4.222s
g() will produce:
bash-4.1$ time ./a.out 1000
1000
real0m1.036s
h() will produce:
bash-4.1$ time ./a.out 1000
1000
real0m4.223s
ii() (if we change in main() std::string events[]={...} into const char*
events[]={...}) will produce:
bash-4.1$ time ./a.out 1000
1000
real0m1.266s
if I remove the call to strlen() will be basically 0seconds.
Which is the problem?
The problem here is that: why f()/h() are taking basically 4times more then
g()? The only different is how we compare strings. It seems like that f() and
h() are creating a temporary std::string object. Shouldn't we have the same
performance? It seems like the compare() method of the char_traitchar could
be better implemented.
As a final notice: I have compiled all examples with g++ -O3 (Linux 64 and
MacOS Snow Lion).
[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Always considering trap-if as ending a BB appears to be a bit of a rathole. Every time I squash one issue, another raises its head. A little unexpected I'd say, what kind of issues does that introduce? I did find that combine.c already has some bits to recognize when it does something that may muck up the CFG and tries to compensate, it just doesn't hadle the situation around trap-if. I'm going to see if I can proof of concept a fix in that code. Of course this is a pass specific fix, but as I look deeper, more memories keep coming back -- we've had special code in cse.c to deal with similar situations, so maybe adding another case for combine isn't that bad after all. See existing examples in split_all_insns and lra.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-08 Component|c++ |libstdc++ Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- 4.4.7 has been unmaintained for years. Please provide a proper testcase, not several incomplete snippets that force people to recreate your tests.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Luca Stoppa from comment #0) Template functions bool operator==( const char*, const std::string ) and bool operator==( const std::string, const char* ) creates unecessary temporary std::string object. Where? It seems like that f() and h() are creating a temporary std::string object. If you look at the code or use a debugger you can see there is no temporary created, so you'll need to explain why you think that.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #3 from Luca Stoppa luca.stoppa at bbh dot com --- Created attachment 31181 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31181action=edit testcase g++ -O3 mapping.cpp time ./a.out 1000 f time ./a.out 1000 g time ./a.out 1000 h time ./a.out 1000 i will execute the 4 different paths in the code.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Indeed, I had a look to f and the correct operator== and compare are called, no temporaries. By the way, type_traitschar uses memcmp not strcmp.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #5 from Luca Stoppa luca.stoppa at bbh dot com ---
Thanks a lot,
so if memcmp() is called, how can the difference in performance be explained?
In short:
std::string s=something;
if (s == something) { ... }
and
if (0 == strcmp(s.c_str(),something)) { ... }
? Probably I'm doing something wrong, or my testcase is invalid?
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- An important detail is that the compare functions aren't inline, and are exported for basic_stringchar. Thus, for a fair comparison, the strcmp should be in an attribute noinline helper (to be 100% correct, should be a memcmp). I'm pretty sure this is all there is to it.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- The only major difference I see is that in the operator== case you make a call to a PIC function in libstdc++.so, whereas strcmp can be inlined. There's no temporary created though.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Right, it's also PIC.
[Bug rtl-optimization/58934] [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org --- I have re-submitted my patch in which this bug is fixed, you can find it at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00598.html I have verified the patch bootstraps on i686-linux (reported by Jakub in the mailing list), ppc64-linux (some problem reported by David in comment #8) and ia64-linux (no problem reported but anyway), however I could not try the same on Sparc or Solaris (even though failure was reported by Rainer in comment #1) because I do not have access to either of them (oh how I wish that sparcs on the compile farm came back). Similarly, I have verified that the original reported failure on cris-elf cross-compiler goes away, as does the problem on sh-none-elf cross (the one from comment #4). However, even without the fix I was not able to reproduce the failure on arm reported in comment #6. If anyone is willing to test the patch on any platform but especially on those which I could not, I'd be very grateful. Thanks.
[Bug tree-optimization/59047] [4.9 Regression] wrong code for bitfields at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 8 12:49:10 2013 New Revision: 204566 URL: http://gcc.gnu.org/viewcvs?rev=204566root=gccview=rev Log: 2013-11-08 Richard Biener rguent...@suse.de PR tree-optimization/59047 * tree-predcom.c (ref_at_iteration): Handle bitfield accesses properly. * gcc.dg/torture/pr59047.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59047.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-predcom.c
[Bug tree-optimization/59047] [4.9 Regression] wrong code for bitfields at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58653] [4.7/4.8 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653 Bug 58653 depends on bug 59047, which changed state. Bug 59047 Summary: [4.9 Regression] wrong code for bitfields at -O3 on x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/57258] unused variable warning is emitted for volatile variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Me neither.
[Bug middle-end/59049] New: Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 Bug ID: 59049 Summary: Two VOIDmode constant in comparison passed to cstoresi4 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org For gcc.c-torture/execute/builtins/strlen-2.c compilation, -O1, with target arc-elf, I see an ICE in config/arc/arc.c:gen_compare_reg, as it has been passed a comparison for two VOIDmode constants: (ne:SI (const_int 3 [0x3]) (const_int 3 [0x3])) We should not generate such comparisons. [amylaar@rowan gcc]$ ./cc1 -fpreprocessed strlen-2.i -quiet -dumpbase strlen-2.c -auxbase strlen-2 -O1 -w -version -fno-diagnostics-show-caret -fdiagnostics-color=never -fno-tree-loop-distribute-patterns -o strlen-2.s GNU C (GCC) version 4.9.0 20131024 (experimental) (arc-elf) compiled by GNU C version 4.8.1 20130603 (Red Hat 4.8.1-1), GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20131024 (experimental) (arc-elf) compiled by GNU C version 4.8.1 20130603 (Red Hat 4.8.1-1), GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: a28c59382a8f5b3c721a450c1591fc5d /home/amylaar/synopsys/synopsys-gcc-mainline/unisrc-4.8/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-2.c: In function ‘main_test’: /home/amylaar/synopsys/synopsys-gcc-mainline/unisrc-4.8/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-2.c:25:1: internal compiler error: in gen_compare_reg, at config/arc/arc.c:1430 0x899316f gen_compare_reg(rtx_def*, machine_mode) ../../gcc/gcc/config/arc/arc.c:1430 0x89cfa80 gen_cstoresi4(rtx_def*, rtx_def*, rtx_def*, rtx_def*) ../../gcc/gcc/config/arc/arc.md:3208 0x85c8a6d insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const ../../gcc/gcc/recog.h:286 0x85c83b9 maybe_gen_insn(insn_code, unsigned int, expand_operand*) ../../gcc/gcc/optabs.c:8217 0x85c8604 maybe_expand_insn(insn_code, unsigned int, expand_operand*) ../../gcc/gcc/optabs.c:8243 0x83942ef emit_cstore ../../gcc/gcc/expmed.c:5121 0x8394a85 emit_store_flag_1 ../../gcc/gcc/expmed.c:5362 0x8394b7c emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) ../../gcc/gcc/expmed.c:5405 0x83959ec emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) ../../gcc/gcc/expmed.c:5727 0x83ba5dd do_store_flag ../../gcc/gcc/expr.c:10832 0x83b1fb5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:8787 0x83b9191 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/gcc/expr.c:10444 0x83ad831 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/gcc/expr.c:7796 0x83b3ab6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/gcc/expr.c:9253 0x83ad831 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/gcc/expr.c:7796 0x831e807 expand_normal ../../gcc/gcc/expr.h:450 0x8320856 do_jump(tree_node*, rtx_def*, rtx_def*, int) ../../gcc/gcc/dojump.c:608 0x831fa22 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*, int) ../../gcc/gcc/dojump.c:364 0x831e918 jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int) ../../gcc/gcc/dojump.c:114 0x82af4bd expand_gimple_cond ../../gcc/gcc/cfgexpand.c:2030 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. emit_cstore has generated this comparison. I propose to use copy_to_mode_reg in this case to preserve the information about the mode. I see that for the testcase, the unnecessary instructions are removed in the ce1 pass.
[Bug tree-optimization/59050] New: [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
Bug ID: 59050
Summary: [4.9 Regression] ICE: tree check: expected
integer_cst, have nop_expr in tree_int_cst_lt, at
tree.c:7083
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 tsan % cat test.ii
struct {
int trace[6];
} a;
void fn1() {
for (int i; i; i++) {
a.trace[i] = a.trace[-i];
a.trace[-i] = 0;
}
}
markus@x4 tsan % /var/tmp/gcc_build_dir/./gcc/xgcc
-B/var/tmp/gcc_build_dir/./gcc -O3 test.ii
test.ii:3:3: warning: anonymous type with no linkage used to declare variable
‘anonymous struct a’ with linkage [enabled by default]
} a;
^
test.ii: In function ‘void fn1()’:
test.ii:4:6: internal compiler error: tree check: expected integer_cst, have
nop_expr in tree_int_cst_lt, at tree.c:7083
void fn1() {
^
0xd1c3f4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9477
0xd1e354 tree_check
../../gcc/gcc/tree.h:2914
0xd1e354 tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/gcc/tree.c:7083
0xd1e390 tree_int_cst_compare(tree_node const*, tree_node const*)
../../gcc/gcc/tree.c:7093
0x100228c comp_dr_addr_with_seg_len_pair
../../gcc/gcc/tree-vect-data-refs.c:2672
0x100af25 vecdr_addr_with_seg_len_pair_t, va_heap, vl_embed::qsort(int
(*)(void const*, void const*))
../../gcc/gcc/vec.h:941
0x100af25 vecdr_addr_with_seg_len_pair_t, va_heap, vl_ptr::qsort(int (*)(void
const*, void const*))
../../gcc/gcc/vec.h:1620
0x100af25 vect_prune_runtime_alias_test_list(_loop_vec_info*)
../../gcc/gcc/tree-vect-data-refs.c:2845
0xce76f2 vect_analyze_loop_2
../../gcc/gcc/tree-vect-loop.c:1716
0xce76f2 vect_analyze_loop(loop*)
../../gcc/gcc/tree-vect-loop.c:1807
0xcfdaff vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:360
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug debug/59051] New: DW_tag_restrict_type not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59051 Bug ID: 59051 Summary: DW_tag_restrict_type not used Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org GCC should use DW_tag_restrict_type in debug info when describing the types of restrict-qualified pointers.
[Bug tree-optimization/59050] [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050 octoploid at yandex dot com changed: What|Removed |Added CC||congh at google dot com --- Comment #1 from octoploid at yandex dot com --- Started with r204538.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #9 from Luca Stoppa luca.stoppa at bbh dot com --- Created attachment 31182 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31182action=edit not inlined memcmp used.
[Bug target/57680] [META-BUG][target]deregister_frame_fn is set to invalid address in cygming-crtbegin.c:__gcc_deregister_frame due to unknown reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 Jean-Pierre Flori jpflori at gmail dot com changed: What|Removed |Added CC||jpflori at gmail dot com --- Comment #3 from Jean-Pierre Flori jpflori at gmail dot com --- This looks like the problem reported here: * http://cygwin.com/ml/cygwin/2013-08/msg00201.html * http://cygwin.com/ml/cygwin/2013-07/msg00528.html Note that an explanation and a fix are also provided there. This also affects 4.7.3.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #10 from Luca Stoppa luca.stoppa at bbh dot com ---
Hi,
honestly I don't know what PIC means, but I did like you suggested. I have
added a wrapper to memcmp() that is not inlined.
__attribute__((noinline)) int memcmp_not_inlined
(const char *s1, const char *s2, size_t bytes) { return memcmp(s1,s2,bytes); }
Basically I got exactly the same results.
[Bug tree-optimization/59050] [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-08 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Also a few gfortran testcases fail that way after the patch.
[Bug target/58423] [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58423 --- Comment #4 from clyon at gcc dot gnu.org --- Author: clyon Date: Fri Nov 8 14:22:10 2013 New Revision: 204570 URL: http://gcc.gnu.org/viewcvs?rev=204570root=gccview=rev Log: gcc/ 2013-11-05 Zhenqiang Chen zhenqiang.c...@linaro.org Backport from trunk r203267, r203603 and r204247. 2013-10-08 Zhenqiang Chen zhenqiang.c...@linaro.org PR target/58423 * config/arm/arm.c (arm_emit_ldrd_pop): Attach RTX_FRAME_RELATED_P on INSN. 2013-10-15 Matthew Gretton-Dann matthew.gretton-d...@arm.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/t-aprofile: New file. * config.gcc: Handle --with-multilib-list option. 2013-10-31 Zhenqiang Chen zhenqiang.c...@linaro.org * lower-subreg.c (resolve_simple_move): Copy REG_INC note. gcc/testsuite/ 2013-11-05 Zhenqiang Chen zhenqiang.c...@linaro.org Backport from trunk r204247. 2013-10-31 Zhenqiang Chen zhenqiang.c...@linaro.org * gcc.target/arm/lp1243022.c: New test. Added: branches/linaro/gcc-4_8-branch/gcc/config/arm/t-aprofile branches/linaro/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/lp1243022.c Modified: branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_8-branch/gcc/config.gcc branches/linaro/gcc-4_8-branch/gcc/config/arm/arm.c branches/linaro/gcc-4_8-branch/gcc/lower-subreg.c branches/linaro/gcc-4_8-branch/gcc/testsuite/ChangeLog.linaro
[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Marc Glisse from comment #4) Martin, do you have an opinion on the testcase in comment 3? We get: _2 = t_1(D)-first; _4 = MEM[(const struct type *)t_1(D)]._vptr.A; _5 = *_4; OBJ_TYPE_REF(_5;_2-0) (_2); [tail call] Assuming that first is a non-artificial (as in DECL_ARTIFICIAL) field, we should be able to devirtualize this but as you have already noticed, our current type-based middle-end intraprocedural devirtualization machinery only works on automatic variables, but this example shows another interesting situation. Thanks for the testcase, I will try to make it work after I cleanup the the code to better interoperate with Honza's recent devirtualization work.
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #2 from Tom De Caluwé decaluwe.t at gmail dot com --- As far as I can verify partial specializations are only allowed at namespace scope so you're right. However gcc never used to complain about such constructs. In any case, an internal compiler error is never desired behaviour, hence the bug report.
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Frame 12 shows that at the tree level, one of the comparison operands is an initialized variable. (gdb) frame 12 #12 0x083bd9fa in expand_expr_real_1 (exp=ne_expr 0xb7b55b28, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:10444 10444 return expand_expr_real_2 (ops, target, tmode, modifier); (gdb) call debug_tree(exp) ne_expr 0xb7b55b28 type boolean_type 0xb7abd5a0 _Bool public unsigned QI size integer_cst 0xb7aaa258 constant 8 unit size integer_cst 0xb7aaa26c constant 1 align 8 symtab 0 alias set -1 canonical type 0xb7abd5a0 precision 1 min integer_cst 0xb7aaa438 0 max integer_cst 0xb7aaa460 1 arg 0 ssa_name 0xb7b0ac58 type integer_type 0xb7abd480 long unsigned int public unsigned SI size integer_cst 0xb7aaa140 constant 32 unit size integer_cst 0xb7aaa154 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb7abd480 precision 32 min integer_cst 0xb7aaa3c0 0 max integer_cst 0xb7aaa3ac 4294967295 context translation_unit_decl 0xb7ac3dec D.1415 pointer_to_this pointer_type 0xb7ac44e0 visited var var_decl 0xb7b4db24 D.1483def_stmt _10 = 3; version 10 arg 1 integer_cst 0xb7b3ce4c type integer_type 0xb7abd480 long unsigned int constant 3 /home/amylaar/synopsys/synopsys-gcc-mainline/unisrc-4.8/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-2.c:29:6
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Yes. It's all about prioritizing, an ICE on invalid isn't the same as an ICE on valid, even if it's a regression.
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
--- Comment #4 from Tom De Caluwé decaluwe.t at gmail dot com ---
However the following code seems to be valid but results in the same ICE:
/* bug.cpp --- */
namespace N {
template class T
class C {
private:
template T a, T b
struct Implementation {};
public:
typedef typename Implementation0, 0::Typedef Type;
};
template class T
template T b
struct CT::Implementation0, b { typedef void Typedef; };
}
template class N::Cunsigned;
/* */
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Frankly, I'm not sure either, current clang rejects it the same way, for example. In any case, in Bugzilla we have got at least 2/3 on valid Bugs triggering that gcc_assert, hopefully will be fixed all together.
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org,
||steven at gcc dot gnu.org
--- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org ---
The regression shows up at r204194 :
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=204194
The 104t.copyprop6 looks indeed more cumbersome for r204194 than for r204193:
--- ../204193/strlen-2.i.104t.copyprop6 2013-11-08 16:03:58.272739028 +
+++ ./strlen-2.i.104t.copyprop6 2013-11-08 16:04:18.355773658 +
@@ -27,11 +27,15 @@
main_test ()
{
+ char[4] * iftmp.2_1;
+ const char * iftmp.6_2;
const char * iftmp.12_3;
long unsigned int g.3_7;
long unsigned int g.5_8;
+ long unsigned int _10;
long unsigned int h.7_11;
long unsigned int h.9_12;
+ long unsigned int _14;
long unsigned int i.10_15;
long unsigned int i.11_16;
long unsigned int j.13_19;
@@ -44,24 +48,31 @@
long unsigned int _28;
long unsigned int k.14_29;
long unsigned int l.20_33;
+ _Bool _34;
+ _Bool _35;
+ _Bool _36;
+ _Bool _37;
+ _Bool _38;
+ _Bool _39;
bb 2:
g.3_7 = g;
g.5_8 = g.3_7 + 1;
g = g.5_8;
- if (g.5_8 != 1)
+ if (g.3_7 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
- abort ();
bb 4:
- h.7_11 = h;
- h.9_12 = h.7_11 + 1;
- h = h.9_12;
- if (h.9_12 != 1)
+ # iftmp.2_1 = PHI foo(3), bar(2)
+ _10 = strlen (iftmp.2_1);
+ _34 = g.5_8 != 1;
+ _35 = _10 != 3;
+ _36 = _35 | _34;
+ if (_36 != 0)
goto bb 5;
else
goto bb 6;
@@ -70,68 +81,93 @@
abort ();
bb 6:
+ h.7_11 = h;
+ h.9_12 = h.7_11 + 1;
+ h = h.9_12;
+ if (h.7_11 != 0)
+goto bb 7;
+ else
+goto bb 8;
+
+ bb 7:
+
+ bb 8:
+ # iftmp.6_2 = PHI MEM[(void *)xfoo + 1B](7), bar(6)
+ _14 = strlen (iftmp.6_2);
+ _37 = h.9_12 != 1;
+ _38 = _14 != 3;
+ _39 = _38 | _37;
+ if (_39 != 0)
+goto bb 9;
+ else
+goto bb 10;
+
+ bb 9:
+ abort ();
+
+ bb 10:
i.10_15 = i;
i.11_16 = i.10_15 + 1;
i = i.11_16;
if (i.11_16 != 1)
-goto bb 7;
+goto bb 11;
else
-goto bb 8;
+goto bb 12;
- bb 7:
+ bb 11:
abort ();
- bb 8:
+ bb 12:
inside_main = 0;
j.13_19 = j;
if (j.13_19 != 0)
-goto bb 9;
+goto bb 13;
else
-goto bb 10;
+goto bb 14;
- bb 9:
+ bb 13:
k.14_20 = k;
k.16_21 = k.14_20 + 1;
k = k.16_21;
iftmp.12_23 = foo + k.14_20;
- goto bb 11;
+ goto bb 15;
- bb 10:
+ bb 14:
k.14_24 = k;
k.18_25 = k.14_24 + 1;
k = k.18_25;
iftmp.12_27 = bar + k.14_24;
- bb 11:
- # iftmp.12_3 = PHI iftmp.12_23(9), iftmp.12_27(10)
+ bb 15:
+ # iftmp.12_3 = PHI iftmp.12_23(13), iftmp.12_27(14)
_28 = strlen (iftmp.12_3);
if (_28 != 3)
-goto bb 13;
+goto bb 17;
else
-goto bb 12;
+goto bb 16;
- bb 12:
+ bb 16:
k.14_29 = k;
if (k.14_29 != 1)
-goto bb 13;
+goto bb 17;
else
-goto bb 14;
+goto bb 18;
- bb 13:
+ bb 17:
abort ();
- bb 14:
+ bb 18:
foo ();
l.20_33 = l;
if (l.20_33 != 1)
-goto bb 15;
+goto bb 19;
else
-goto bb 16;
+goto bb 20;
- bb 15:
+ bb 19:
abort ();
- bb 16:
+ bb 20:
return;
}
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Current llvm trunk is broken at the moment on darwin, but using a build from Oct 29th, I have no issues with the failing test case under clang... % /sw/opt/llvm-3.4/bin/clang -O1 -fsanitize=address -fno-builtin-memset -g -fdiagnostics-color=never -O0 -m64 global-overflow-1.c % ./a.out = ==81836==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000103d991ea at pc 0x103d98b76 bp 0x7fff5be686d0 sp 0x7fff5be686c8 READ of size 1 at 0x000103d991ea thread T0 ==81836==WARNING: Trying to symbolize code, but external symbolizer is not initialized! #0 0x103d98b75 (/Users/howarth/./a.out+0x11b75) #1 0x7fff8a4237e0 (/usr/lib/system/libdyld.dylib+0x27e0) #2 0x0 0x000103d991ea is located 54 bytes to the left of global variable 'main.ZZZ' from 'global-overflow-1.c' (0x103d99220) of size 10 0x000103d991ea is located 0 bytes to the right of global variable 'main.YYY' from 'global-overflow-1.c' (0x103d991e0) of size 10 SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x1000207b31e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b31f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3210: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 0x1000207b3220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =0x1000207b3230: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9 0x1000207b3240: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 0x1000207b3250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3280: 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 ASan internal: fe ==81836==ABORTING
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Jack Howarth from comment #4) This was a test of recent clang's -fsanitize=address on x86_64-apple-darwin12.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #19 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Eric Botcazou from comment #18) I couldn't find anything in GCC manual. There are a few documented hooks, but this looks quite light indeed, so the sources are probably the best references, i.e. builtins.c and except.c: Would it be OK to submit it a patch to document __builtin_longjmp/__builtin_setjmp based on their sources?
[Bug middle-end/59049] Two VOIDmode constant in comparison passed to cstoresi4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Making emit_store_flag return 0 in the case of const-const comparison gives simpler rtl generation: (insn 14 13 15 (set (reg:QI 175) (const_int 1 [0x1])) .../strlen-2.c:29 -1 (nil)) (insn 15 14 16 (set (reg:QI 175) (const_int 0 [0])) .../strlen-2.c:29 -1 (nil)) (code_label 16 15 0 8 [0 uses])
[Bug c++/59052] New: Partial specialization of template with dependent non-type template argument not correctly resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052
Bug ID: 59052
Summary: Partial specialization of template with dependent
non-type template argument not correctly resolved
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: decaluwe.t at gmail dot com
Created attachment 31183
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31183action=edit
The preprocessed code
This bug seems to be related to bug 59044
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044).
The following code when compiled with 'g++ spec.cpp' is rejected by gcc 4.8.1:
/* spec.cpp */
namespace N {
template class T
struct C {
template class U, T t
struct Implementation {};
};
template class T
template T t
struct CT::Implementationvoid, t {
static void method() {}
};
}
int main() {
N::Cint::Implementationvoid, 0::method();
}
/* */
The bug is only triggered when the second template argument is a non-type
template argument dependent on the template argument of the enclosing class
template. The error message produced by g++ 4.8.1 (as found in the g++-4.8
package in the Ubuntu 13.10 repo, see below for build information):
spec.cpp: In function ‘int main()’:
spec.cpp:18:5: error: ‘method’ is not a member of
‘N::Cint::Implementationvoid, 0’
N::Cint::Implementationvoid, 0::method();
^
This bug is still present in the gcc-snapshot package. However the code
compiles fine in g++ 4.7.3 (as found in the g++-4.7 package).
Additional information:
GCC version: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8)
System type: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu8' --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 --disable-werror --with-arch-32=i686
--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
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #6 from Tom De Caluwé decaluwe.t at gmail dot com --- I reported a related bug with valid code which does not trigger this ICE (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052). Also LLVM bug 16519 (http://llvm.org/bugs/show_bug.cgi?id=16519) might be related to the errors triggered by clang when compiling the example code above. The example code provided in bug 59052 does compile with clang.
[Bug other/59053] New: cilkplus branch compiler loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053 Bug ID: 59053 Summary: cilkplus branch compiler loops Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: john.forrest at fastercoin dot com Created attachment 31184 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31184action=edit preprocessed file from 25 line function using sort from cilkpub When compiling a small C++ function with latest cilkplus branch the compiler loops (well killed after an hour). Tried on 4.8 and get an internal compiler error which may be a clue. .ii file attached = 4.9 gcc -v and output = Build Specs - latest svn update of 4.9 cilkplus -- john@fasterCoin2:~/cbcstable/2.8/s3/source/oct1413/pg$ /j/mycilk6/bin/g++ -v Using built-in specs. COLLECT_GCC=/j/mycilk6/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../cilk6/configure --prefix=/j/mycilk6 --libexecdir=/usr/lib --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib CFLAGS='-fPIC -I/j/mycilk4/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include/ -march=x86-64' LD=/usr/bin/ld LDFLAGS='-L/usr/lib/x86_64-linux-gnu -L/usr/local/lib/ -lz -lpthread -lrt' CXXFLAGS='-I/j/mycilk4/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include -I/j/mycilk4/include/c++/4.8.0/x86_64-unknown-linux-gnu -I/j/mycilk4/include/c++/4.8.0/' : (reconfigured) ../cilk6/configure --prefix=/j/mycilk6 --libexecdir=/usr/lib --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib CFLAGS='-fPIC -I/usr/include -I/j/cilk6/libstdc++-v3/include -march=x86-64' LD=/usr/bin/ld : (reconfigured) ../cilk6/configure --prefix=/j/mycilk6 --libexecdir=/usr/lib --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-bootstrap --with-system-zlib CFLAGS='-fPIC -I/usr/include -I/j/cilk6/libstdc++-v3/include -march=x86-64' LD=/usr/bin/ld --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 4.9.0 20130520 (experimental) (GCC) -- Command line /j/mycilk6/bin/g++ -Wall -O0 -fcilkplus misc_cpp.ii --- Output - none With old 4.8 version In file included from ../misc_cpp.cpp:6:0: /j/cilkpub/include/cilkpub/sort.h: In function ‘void cilkpub::internal::repack_and_subsort(RandomAccessIterator, RandomAccessIterator, size_t, ValueType*, const size_t (*)[32], Compare) [with RandomAccessIterator = CoinPairint, int*; ValueType = CoinPairint, int; Compare = CoinFirstLess_2int, int; size_t = long unsigned int]’: /j/cilkpub/include/cilkpub/sort.h:433:14: internal compiler error: Segmentation fault void repack_and_subsort( RandomAccessIterator xs, ^ Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Would it be OK to submit it a patch to document __builtin_longjmp/__builtin_setjmp based on their sources? I think that we would need to issue an error if both are in the same function.
[Bug other/59053] cilkplus branch compiler loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-11-08
CC||bviyer at gmail dot com
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
The bug is in
while (ii_tree)
{
if (TREE_CODE (ii_tree) == ARRAY_NOTATION_REF)
{
current_rank++;
ii_tree = ARRAY_NOTATION_ARRAY (ii_tree);
}
else if (TREE_CODE (ii_tree) == ARRAY_REF)
ii_tree = TREE_OPERAND (ii_tree, 0);
else if (TREE_CODE (ii_tree) == PARM_DECL
|| TREE_CODE (ii_tree) == VAR_DECL)
break;
}
When TREE_CODE (ii_tree) != ARRAY_NOTATION_REF:
indirect_ref 0x706b0f80
type array_type 0x706327e0
type integer_type 0x709b6930 size_t readonly public unsigned
type_6 DI
size integer_cst 0x718b5140 constant 64
unit size integer_cst 0x718b5160 constant 8
align 64 symtab 0 alias set -1 canonical type 0x70f9bbd0
precision 64 min integer_cst 0x718b5580 0 max integer_cst 0x718b5560
18446744073709551615
pointer_to_this pointer_type 0x70a28000
type_6 BLK
size integer_cst 0x70b21800 constant 2048
unit size integer_cst 0x70b217e0 constant 256
align 64 symtab 0 alias set -1 canonical type 0x70632690
domain integer_type 0x70f2b150 type integer_type 0x718b60a8
sizetype
type_6 DI size integer_cst 0x718b5140 64 unit size
integer_cst 0x718b5160 8
align 64 symtab 0 alias set -1 canonical type 0x70f2b150
precision 64 min integer_cst 0x718b5180 0 max integer_cst 0x70ed1d60
31
pointer_to_this pointer_type 0x70632d20
readonly
arg 0 pointer_plus_expr 0x706b6078
type pointer_type 0x70632d20 type array_type 0x706327e0
unsigned type_6 DI size integer_cst 0x718b5140 64 unit size
integer_cst 0x718b5160 8
align 64 symtab 0 alias set -1 canonical type 0x70632b28
arg 0 parm_decl 0x7067dc00 tally type pointer_type
0x70632d20
used unsigned DI file /j/cilkpub/include/cilkpub/sort.h line 437
col 71 size integer_cst 0x718b5140 64 unit size integer_cst
0x718b5160 8
align 64 context function_decl 0x7067ca00 repack_and_subsort
arg-type pointer_type 0x70632d20 chain parm_decl
0x7067dc80 comp
arg 1 nop_expr 0x706b0f60 type integer_type 0x718b60a8
sizetype
arg 0 mult_expr 0x706b6050 type integer_type 0x718e3dc8
size_t
arg 0 var_decl 0x706a7688 i
arg 1 integer_cst 0x706b0de0 constant 256
/j/cilkpub/include/cilkpub/sort.h:456:42
/j/cilkpub/include/cilkpub/sort.h:456:42
it turns into an infinite loop.
[Bug tree-optimization/58508] [Missed-Optimization] Redundant vector load of actual loop invariant in loop body.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508 --- Comment #8 from congh at gcc dot gnu.org --- Author: congh Date: Fri Nov 8 18:44:46 2013 New Revision: 204590 URL: http://gcc.gnu.org/viewcvs?rev=204590root=gccview=rev Log: 2013-11-08 Cong Hou co...@google.com PR tree-optimization/58508 * gcc.dg/vect/pr58508.c: Update. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr58508.c
[Bug c++/58963] Does C++ need flag_complex_method = 2?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58963 --- Comment #1 from Cong Hou congh at google dot com --- Any comment on this topic? thanks, Cong
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #21 from Andreas Schwab sch...@linux-m68k.org --- It's only an error if they use the same jmpbuf.
[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 --- Comment #11 from Marc Glisse glisse at gcc dot gnu.org --- memcmp is pure and gcc manages to pull it out of the loop (see the file created by -fdump-tree-optimized). It is funny that -fno-builtin-strcmp makes the code more than 2 times faster (the main difference I can see is using repz cmpsb instead of a call to the libc function strcmp).
[Bug tree-optimization/56717] Enhance Dot-product pattern recognition to avoid mult widening.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56717 Cong Hou congh at google dot com changed: What|Removed |Added CC||congh at google dot com --- Comment #1 from Cong Hou congh at google dot com --- The way ICC uses is not related to dot-product. It just finds out a smart way to implement widen-mult (s16 to s32) using PMADDWD. I will try to make a patch on this issue. thanks, Cong
[Bug target/57680] [META-BUG][target]deregister_frame_fn is set to invalid address in cygming-crtbegin.c:__gcc_deregister_frame due to unknown reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 --- Comment #4 from gee jojelino at gmail dot com --- I think gcc backend for x86 that doesn't support weak attribute needed to supress weak attribute on variables as long as gas/16011 is not fixed.
[Bug target/59054] New: Powerpc -O0 -mcpu=power7 generates sub-optimal code to load 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054 Bug ID: 59054 Summary: Powerpc -O0 -mcpu=power7 generates sub-optimal code to load 0 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org After the changes in early October went in, if you use -O0, and compile code to load up 0, the compiler decides to generate the 0 in a VSX register, store it on the stack, and then reload it to a GPR, rather than doing a load immediate of 0.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #22 from bviyer at gcc dot gnu.org --- Author: bviyer Date: Fri Nov 8 19:52:27 2013 New Revision: 204592 URL: http://gcc.gnu.org/viewcvs?rev=204592root=gccview=rev Log: +2013-11-08 Balaji V. Iyer balaji.v.i...@intel.com + + PR c/59039 + * runtime/cilk_fiber-unix.cpp: Fixed a crash in run() function + when optimization is turned on. + Modified: trunk/libcilkrts/ChangeLog trunk/libcilkrts/runtime/cilk_fiber-unix.cpp
[Bug target/59054] Powerpc -O0 -mcpu=power7 generates sub-optimal code to load 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 31185 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31185action=edit Sample file to show the problem.
[Bug target/59054] Powerpc -O0 -mcpu=power7 generates sub-optimal code to load 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-08 Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #2) I think at least something like this for this specific bug, but the whole file needs auditing: Not only that file, but stl_algobase.h too, we compile this without complaint and then do a memmove() on atomic objects! std::atomicint a[1]; std::atomicint b[1]; std::uninitialized_copy(a,a+1, b);
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- And this, which is more obviously wrong: std::atomicint a[1]; std::atomicint b[1]; std::copy(a,a+1, b);
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- At some point we replaced a weak (not using front-end intrinsics) version of is_pod with __is_trivial, in algos uninitialized. At that time was safe, ins't anymore in 4.9. In principle we could minimally go back to std::is_pod. Or add to __is_trivial the required additional constraints on copy move operations. Which seems much better.
[Bug objc/59055] New: gcc.texinfo warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055 Bug ID: 59055 Summary: gcc.texinfo warnings Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com I got if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --no-split -I . -I /export/gnu/import/git/gcc/gcc/doc \ -I /export/gnu/import/git/gcc/gcc/doc/include -o doc/gcc.info /export/gnu/import/git/gcc/gcc/doc/gcc.texi; \ fi /export/gnu/import/git/gcc/gcc/doc/invoke.texi:1097: warning: node next `Overall Options' in menu `C Dialect Options' and in sectioning `Invoking G++' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:1097: warning: node up `Overall Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:1563: warning: node prev `C Dialect Options' in menu `Overall Options' and in sectioning `Invoking G++' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:1563: warning: node up `C Dialect Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:1982: warning: node up `C++ Dialect Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:2804: warning: node up `Objective-C and Objective-C++ Dialect Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:3036: warning: node up `Language Independent Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:3162: warning: node up `Warning Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:5050: warning: node up `Debugging Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:6637: warning: node up `Optimize Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:9897: warning: node up `Preprocessor Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:9950: warning: node up `Assembler Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:9973: warning: node up `Link Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:10255: warning: node up `Directory Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:10408: warning: node up `Spec Files' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/invoke.texi:10985: warning: node up `Target Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ /export/gnu/import/git/gcc/gcc/doc/extend.texi:7845: warning: node next `Pointer Bounds Checker builtins' in menu `Cilk Plus Builtins' and in sectioning `Other Builtins' differ /export/gnu/import/git/gcc/gcc/doc/extend.texi:8015: warning: node next `Other Builtins' in menu `Target Builtins' and in sectioning `Cilk Plus Builtins' differ /export/gnu/import/git/gcc/gcc/doc/extend.texi:8015: warning: node prev `Other Builtins' in menu `Cilk Plus Builtins' and in sectioning `Pointer Bounds Checker builtins' differ /export/gnu/import/git/gcc/gcc/doc/extend.texi:9139: warning: node next `Cilk Plus Builtins' in menu `Other Builtins' and in sectioning `Target Builtins' differ /export/gnu/import/git/gcc/gcc/doc/extend.texi:9139: warning: node prev `Cilk Plus Builtins' in menu `Pointer Bounds Checker builtins' and in sectioning `Other Builtins' differ /export/gnu/import/git/gcc/gcc/doc/extend.texi:9165: warning: node prev `Target Builtins' in menu `Other Builtins' and in sectioning `Cilk Plus Builtins' differ /export/gnu/import/git/gcc/gcc/doc/trouble.texi:5: warning: node next `Trouble' in menu `Service' and in sectioning `Bugs' differ /export/gnu/import/git/gcc/gcc/doc/trouble.texi:5: warning: node prev `Trouble' in menu `Bug Reporting' and in sectioning `Gcov' differ /export/gnu/import/git/gcc/gcc/doc/trouble.texi:5: warning: node up `Trouble' in menu `Bugs' and in sectioning `Top' differ /export/gnu/import/git/gcc/gcc/doc/service.texi:5: warning: node prev `Service' in menu `Trouble' and in sectioning `Bugs' differ /export/gnu/import/git/gcc/gcc/doc/service.texi:5: warning: node up `Service' in menu `Bugs' and in sectioning `Top' differ
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, it's not too hard to fix properly, so I'm working on that.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31186 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31186action=edit A patch to document __builtin_setjmp/__builtin_longjmp Does it look OK?
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks!
[Bug other/59053] cilkplus branch compiler loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053 --- Comment #2 from John Forrest john.forrest at fastercoin dot com --- Thanks for your very fast response. Glad it was easy to reproduce. John Forrest
[Bug other/59055] gcc.texinfo warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Fri Nov 8 22:16:59 2013 New Revision: 204604 URL: http://gcc.gnu.org/viewcvs?rev=204604root=gccview=rev Log: Move Cilk Plus Builtins node before Other Builtins node PR other/59055 * doc/extend.texi: Move Cilk Plus Builtins node before Other Builtins node. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c++/59056] New: enable_if turns a non-ambiguous template into an ambiguous one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
Bug ID: 59056
Summary: enable_if turns a non-ambiguous template into an
ambiguous one
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: walter.mascarenhas at gmail dot com
Created attachment 31187
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31187action=edit
a simple code illustrating the bug
The attached file shows that by turning a specialization of
template class A, class Enable = void
struct Foo {};
like this one (which works just fine)
template class A
struct FooA, void{};
into
template class A
struct FooA, std::enable_if typename always_trueA() ::type {};
we can get ambigouities, even when typename always_trueA() ::type
always resolves to void.
For more details, look at the attachement
[Bug c++/59056] enable_if turns a non-ambiguous template into an ambiguous one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Needs an analysis, but I doubt this is a bug, all the up to date compilers I have handy (eg, clang, icc) reject it the same way.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org --- Reduced test case: module args_mod interface iargc module procedure iargc_8 end interface contains integer(8) function iargc_8() integer(4) iargc iargc_8=iargc() end function end module (The getarg parts are not relevant for the bug.)
[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #5) Always considering trap-if as ending a BB appears to be a bit of a rathole. Every time I squash one issue, another raises its head. Heh, I'm surprised that trap-if is not already a control flow insn. Clearly it can alter control flow. Likewise for a conditional no-return call. Anyway, there are lots of places in the compiler where a transformation results in a CFG cleanup of some sort. Before this trap-if case, my favorite was in lower-subreg.c, where splitting a trapping load into multiple trapping loads -- fun!
[Bug tree-optimization/56717] Enhance Dot-product pattern recognition to avoid mult widening.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56717
--- Comment #2 from Cong Hou congh at google dot com ---
I examined the GCC generated code, and found the main problem is that the load
of 'scale' (rhs operand of ) to an xmm register is in the loop body, which
could be moved outside.
This happened during rtl-reload pass. For the following code, the load to scale
is still outside of the loop body.
void foo(short* a, short scale, int n) {
int i;
for (i=0; in; i++)
a[i] = a[i] scale;
}
But for your code here, it is not. I suspect there may exist some issue in that
pass.
By the way, from my test it turns out that using PMADDWD is no faster than the
way used by GCC now.
[Bug bootstrap/59057] New: bootstrap comparison failure with -frecord-gcc-switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59057 Bug ID: 59057 Summary: bootstrap comparison failure with -frecord-gcc-switches Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dirtyepic at gentoo dot org We have a bug report about comparison failures bootstrapping with -frecord-gcc-switches. The cause is -gtoggle appearing in .GCC.command.line of the stage2 obj files but not in stage3. Should .GCC.command.line be considered a comment and stripped when comparing?
[Bug tree-optimization/59058] New: wrong code at -O3 on x86_64-linux-gnu (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
Bug ID: 59058
Summary: wrong code at -O3 on x86_64-linux-gnu (affecting gcc
4.6 to trunk)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.6, 4.7, and 4.8) miscompiles the following
code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes.
It also affects gcc 4.6 and 4.7 at -O2, older versions of gcc, and on other
platforms.
For trunk and 4.8 (but not for 4.6 and 4.7 though), -fno-tree-vectorize makes
the bug go away.
Interestingly also, both the current clang and icc fail on this testcase too.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--enable-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131108 (experimental) [trunk revision 204593] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
-1
$ gcc-trunk -O3 small.c; a.out
7
$ gcc-4.8.2 -O3 small.c; a.out
7
$ gcc-4.7.3 -O3 small.c; a.out
131071
$ gcc-4.7.3 -O2 small.c; a.out
131071
$ gcc-4.6.4 -O3 small.c; a.out
131071
$ gcc-4.6.4 -O2 small.c; a.out
131071
$
$ gcc-trunk -O3 -fno-tree-vectorize small.c; a.out
-1
$ gcc-4.8.2 -O3 -fno-tree-vectorize small.c; a.out
-1
$ gcc-4.7.3 -O3 -fno-tree-vectorize small.c; a.out
131071
$ gcc-4.6.4 -O3 -fno-tree-vectorize small.c; a.out
131071
$
$ clang-trunk -O3 small.c; a.out
0
$ icc -O3 small.c; a.out
1
$
--
int printf (const char *, ...);
int a, c, d;
short b = -1;
void
foo ()
{
b++;
}
void
bar ()
{
l1:
foo ();
d = -3;
for (a = 0; a -3; a = d)
c |= b;
if (b)
goto l1;
}
int
main ()
{
b++;
l2:
if (b)
goto l2;
bar ();
printf (%d\n, c);
return 0;
}
[Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640 --- Comment #12 from Jeffrey A. Law law at redhat dot com --- Oleg, I just worked through an independent problem that I saw locally that probably explains your SH issue as well. I expect to have a fix in the trunk shortly. I'll let you know so you can test it.
[Bug middle-end/59059] New: [4.9 Regression] internal compiler error: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:6931
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59059 Bug ID: 59059 Summary: [4.9 Regression] internal compiler error: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:6931 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch A recent regression, likely introduced between r204496 and r204556 cat bug.f90 SUBROUTINE collocate_core_default(grid,lp,cmax,coef_xyz,pol_z,gridbounds) INTEGER, PARAMETER :: wp=8 INTEGER :: cmax,lp REAL(wp) :: coef_xyz(((lp+1)*(lp+2)*(lp+3))/6) REAL(wp) :: pol_z(1:2,0:lp,-cmax:0) INTEGER :: gridbounds(2,3) REAL(wp) :: grid(gridbounds(1,1):gridbounds(2,1), gridbounds(1,2):gridbounds(2,2), gridbounds(1,3):gridbounds(2,3)) INTEGER :: coef_xy(2,(lp+1)*(lp+2)/2), s04 DO kg=kgmin,0 DO lzp=0,lp DO lyp=0,lp-lzp DO lxp=0,lp-lzp-lyp lxyz=lxyz+1 ; lxy=lxy+1 coef_xy(1,lxy)=coef_xy(1,lxy)+coef_xyz(lxyz)*pol_z(1,lzp,kg) coef_xy(2,lxy)=coef_xy(2,lxy)+coef_xyz(lxyz)*pol_z(2,lzp,kg) ENDDO grid(i,j2,k2) = grid(i,j2,k2) + s04 END DO END DO END DO END SUBROUTINE collocate_core_default gfortran -O3 bug.f90 bug.f90: In function ‘collocate_core_default’: bug.f90:1:0: internal compiler error: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:6931 SUBROUTINE collocate_core_default(grid,lp,cmax,coef_xyz,pol_z,gridbounds) ^ 0xc248f4 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9144 0xc27f02 tree_check ../../gcc/gcc/tree.h:2914 0xc27f02 tree_int_cst_lt(tree_node const*, tree_node const*) ../../gcc/gcc/tree.c:6931 0xc27f28 tree_int_cst_compare(tree_node const*, tree_node const*) ../../gcc/gcc/tree.c:6941 0xf695ac comp_dr_addr_with_seg_len_pair ../../gcc/gcc/tree-vect-data-refs.c:2672 0xf695ac comp_dr_addr_with_seg_len_pair ../../gcc/gcc/tree-vect-data-refs.c:2645 0xf70ac8 vecdr_addr_with_seg_len_pair_t, va_heap, vl_embed::qsort(int (*)(void const*, void const*)) ../../gcc/gcc/vec.h:941 0xf70ac8 vecdr_addr_with_seg_len_pair_t, va_heap, vl_ptr::qsort(int (*)(void const*, void const*)) ../../gcc/gcc/vec.h:1620 0xf70ac8 vect_prune_runtime_alias_test_list(_loop_vec_info*) ../../gcc/gcc/tree-vect-data-refs.c:2845 0xbf1b67 vect_analyze_loop_2 ../../gcc/gcc/tree-vect-loop.c:1716 0xbf1b67 vect_analyze_loop(loop*) ../../gcc/gcc/tree-vect-loop.c:1807 0xc05173 vectorize_loops() ../../gcc/gcc/tree-vectorizer.c:360 Please submit a full bug report,
[Bug fortran/59060] New: Accepts invalid ? Missing component data value for component D1 of TYPE(T2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060 Bug ID: 59060 Summary: Accepts invalid ? Missing component data value for component D1 of TYPE(T2) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Testcase: MODULE M1 TYPE T1 INTEGER, PRIVATE :: I=0 END TYPE T1 TYPE T2 TYPE(T1) :: D1 END TYPE T2 TYPE(T2), PARAMETER :: D2=T2() END MODULE M1 gfortran and pgi compile this, while intel, cray and g95 give an error message along the lines: ftn-1767 crayftn: ERROR M1, File = bug.f90, Line = 8, Column = 28 Missing component data value for component D1 of TYPE(T2). Given that T1 has a default initialization, I'm not 100% sure that the bug is on the gfortran side, however, if I comment out the 'initializer' for D2, gfortran generates an error, even though all structure components have a value (so at least, gfortran is not very consistent).
[Bug fortran/59060] Accepts invalid ? Missing component data value for component D1 of TYPE(T2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Or is this a F2003 feature already in gfortran and not in other compilers? I do see now (after moving the private attribute away) gfortran -c -std=f95 bug.f90 bug.f90:8.27: TYPE(T2), PARAMETER :: D2=T2() 1 Error: Fortran 2003: Structure constructor with missing optional arguments at (1)
