[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org --- x86/x86-64 now have their own fenv.c file that defines the FE_* macros itself and so is immune to that issue. I was hoping that generally the macros would be defined to correspond to the appropriate bits in the relevant status register and so the hook could be OS-independent. That's a reasonable assumption and, to answer my own question, Solaris defines the same FE_* macros as Linux on x86. The hitch on the SPARC is that you have 2 sets of flags in the FP status register, the FSR_accrued_exception field and the FSR_current_exception field; Solaris defines the FE_* macros according to the latter and Linux according to the former (so you need a shift to convert between the 2 sets of macros). Hopefully the other OSes use one of these two settings. They are symmetric as regards which bits are set (would be indicated by fetestexcept as being set) after feupdateenv. They are not symmetric with regard to which are raised in the sense of having trap handlers called - feupdateenv should cause traps (where enabled in the saved environment) for any exceptions that were set at the time feupdateenv was called, but not for any that were only set in the saved environment but not in the environment active when feupdateenv was called. OK, that's what I was more or less suspecting, thanks for confirming. In any case, c11-atomic-exec-5.c does not test anything relating to enabled traps, although the feholdexcept code sequence from the target hook is intended to disable traps and the feupdateenv sequence should then restore the previous state of which traps were enabled.) The question is: does the UPDATE part of the hook really need to cause traps as the feupdateenv routine, or could it only set the appropriate bits?
[Bug tree-optimization/59374] [4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59374 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |ASSIGNED Known to work||4.7.3 Keywords||wrong-code Last reconfirmed||2013-12-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|-ftree-slp-vectorize breaks |[4.8/4.9 Regression] |unique_ptr's move |-ftree-slp-vectorize breaks |constructor |unique_ptr's move ||constructor Target Milestone|--- |4.8.3 Known to fail||4.8.0, 4.8.2, 4.9.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. I will have a look.
[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |4.9.0
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.8.3 Summary|Performance regression in |[4.8/4.9 Regression] |GCC 4.8 and later versions. |Performance regression in ||GCC 4.8 and later versions. --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The IVOPTs dump looks different on x86_64, it looks like 4.7 was able to do a better job here. Can you provide a runnable testcase so we can see if x86_64 regressed in speed as well?
[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Hopefully the other OSes use one of these two settings. At least FreeBSD uses the Linux setting.
[Bug middle-end/59134] [4.7/4.8/4.9 regression] infinite loop between store_fixed_bit_field and store_split_bit_field with STRICT_ALIGNMENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59134 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-e500| Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-03 CC||ebotcazou at gcc dot gnu.org Summary|Infinite loop between |[4.7/4.8/4.9 regression] |store_fixed_bit_field and |infinite loop between |store_split_bit_field with |store_fixed_bit_field and |STRICT_ALIGNMENT|store_split_bit_field with ||STRICT_ALIGNMENT Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed as a regression by Michael.
[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31361 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31361action=edit Proposed patch Dmitry, does this look fine?
[Bug middle-end/59134] [4.7/4.8/4.9 regression] infinite loop between store_fixed_bit_field and store_split_bit_field with STRICT_ALIGNMENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59134 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug middle-end/59134] [4.7/4.8/4.9 regression] infinite loop between store_fixed_bit_field and store_split_bit_field with STRICT_ALIGNMENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59134
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
typedef struct {
char pad;
int arr[0];
} __attribute__((packed)) str;
str *
foo (int* src)
{
str *s = __builtin_malloc (sizeof (str) + sizeof (int));
s-arr[0] = 0x12345678;
return s;
}
as said elsewhere - IMHO the mode on op0 should not be that of the
base object (QImode) but that of the access (SImode).
[Bug tree-optimization/59374] [4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59374 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- bar = myalloc (); [return slot optimization] bb 3: _22 = MEM[(struct Bar * const )bar + 8]; MEM[(struct Bar * )bar + 8] = 0B; MEM[(struct Foo * )foo + 8] = _22; _23 = MEM[(const struct BarDelete *)bar].D.39226.alloc_; MEM[(struct deleter_type *)foo] = _23; _7 = std::operator std::char_traitschar (cout, p ); is vectorized to bar = myalloc (); [return slot optimization] bb 3: _22 = MEM[(struct Bar * const )bar + 8]; MEM[(struct Bar * )bar + 8] = 0B; vectp.87_1 = MEM[(const struct BarDelete *)bar].D.39226.alloc_; vect__23.88_36 = MEM[(const struct BarDelete *)vectp.87_1]; _23 = MEM[(const struct BarDelete *)bar].D.39226.alloc_; vectp.90_37 = foo; MEM[(struct deleter_type *)vectp.90_37] = vect__23.88_36; _7 = std::operator std::char_traitschar (cout, p ); obvious violating a WAR dependency. I'm sure it was me who broke this.
[Bug tree-optimization/59374] [4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59374
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Testcase:
extern void abort (void);
static struct X { void *a; void *b; } a, b;
void __attribute__((noinline)) foo (void)
{
void *tem = a.b;
a.b = (void *)0;
b.b = tem;
b.a = a.a;
}
int main()
{
a.b = a;
foo ();
if (b.b != a)
abort ();
return 0;
}
[Bug c/59351] ICE on empty compound literal with -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Dec 3 11:57:31 2013 New Revision: 205627 URL: http://gcc.gnu.org/viewcvs?rev=205627root=gccview=rev Log: PR c/59351 c/ * c-decl.c (build_compound_literal): Allow compound literals with empty initial value. testsuite/ * gcc.dg/pr59351.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr59351.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56344] ICE for program with very large structs returned by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56344 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Dec 3 12:11:36 2013 New Revision: 205628 URL: http://gcc.gnu.org/viewcvs?rev=205628root=gccview=rev Log: PR middle-end/56344 * calls.c (expand_call): Disallow passing huge arguments by value. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c
[Bug target/59376] New: -mmemcpy-strategy= and -mmemset-strategy= are undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59376 Bug ID: 59376 Summary: -mmemcpy-strategy= and -mmemset-strategy= are undocumented Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: davidxl at google dot com r201645 added -mmemcpy-strategy= and -mmemset-strategy=. But there is no documentation.
[Bug libstdc++/59373] Table 92 is unreadable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-03 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Your URL is wrong, it would have been helpful to say it's in the docs for basic_filebuf::open
[Bug libstdc++/59373] Table 92 is unreadable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- You can also look in the source, where the table is formatted correctly.
[Bug middle-end/56344] ICE for program with very large structs returned by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56344 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2013-12-3
CC||olegendo at gcc dot gnu.org
--- Comment #5 from chrbr at gcc dot gnu.org ---
seems a wrong T-bit optimization.
we have
.L3:
tstr1,r1
bt
replaced by
.L3:
bf.L4
although the r1 value can have defs reached from several path.
This has been fixed by Oleg in the 4.9 with a new cflow pass. In 4.8 I think
it's best to just disable it as unsafe, The following workaround is enough to
to fix the problem:
Index: sh.md
===
--- sh.md (revision 205585)
+++ sh.md (working copy)
@@ -8380,7 +8380,7 @@ label:
{
return output_branch (sh_eval_treg_value (operands[1]), insn, operands);
}
- 1
+ 0
[(set (pc) (if_then_else (eq (reg:SI T_REG) (match_dup 2))
(label_ref (match_dup 0))
(pc)))]
do you agree Oleg ?
[Bug c/59351] ICE on empty compound literal with -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Dec 3 12:52:39 2013 New Revision: 205629 URL: http://gcc.gnu.org/viewcvs?rev=205629root=gccview=rev Log: PR c/59351 c/ * c-decl.c (build_compound_literal): Allow compound literals with empty initial value. testsuite/ * gcc.dg/pr59351.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr59351.c Modified: branches/gcc-4_8-branch/gcc/c/ChangeLog branches/gcc-4_8-branch/gcc/c/c-decl.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #22 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Dec 3 12:56:32 2013 New Revision: 205630 URL: http://gcc.gnu.org/viewcvs?rev=205630root=gccview=rev Log: Adjust destination address after gen_strset gcc/ PR target/59363 * config/i386/i386.c (emit_memset): Adjust destination address after gen_strset. (expand_setmem_epilogue): Likewise. gcc/testsuite/ PR target/59363 * gcc.target/i386/pr59363.c: New file. Added: trunk/gcc/testsuite/gcc.target/i386/pr59363.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/59373] Table 92 is unreadable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-12/msg00073.html
[Bug tree-optimization/59374] [4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59374 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31362 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31362action=edit patch Patch I am testing.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Markus Trippelsdorf octoploid at yandex dot com --- Fixed. Thanks.
[Bug c/59351] ICE on empty compound literal with -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Dec 3 13:52:12 2013 New Revision: 205632 URL: http://gcc.gnu.org/viewcvs?rev=205632root=gccview=rev Log: Backport from mainline 2013-12-03 Marek Polacek pola...@redhat.com PR c/59351 * c-decl.c (build_compound_literal): Allow compound literals with empty initial value. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr59351.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/c-decl.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c/59351] ICE on empty compound literal with -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59355] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fno-devirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59355 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-03 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31363 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31363action=edit gcc49-pr59355.patch Untested fix.
[Bug c/59367] Syntax error with #pragma message before else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-03 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, both cc1/cc1plus. Goes back at least to 4.6.
[Bug gcov-profile/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added Summary|[4.9 Regression]|[4.9 Regression] |profiledbootstrap |profiledbootstrap |miscompiles gcc during |miscompiles gcc during |stagefeedback |stagefeedback ||--with-tune=amdfam10 --- Comment #1 from Markus Trippelsdorf octoploid at yandex dot com --- The following is enough to reproduce the issue: % ../gcc/configure --with-tune=amdfam10 --enable-checking=release --disable-werror --disable-multilib --enable-languages=c,c++ --with-build-config=bootstrap-lto bootstrap-O3 % make profiledbootstrap Maybe it is another target problem?
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 gcc-bugzilla-f5d8 at theblacksun dot eu changed: What|Removed |Added Known to work||4.7.3 --- Comment #6 from gcc-bugzilla-f5d8 at theblacksun dot eu --- I tested your patch and it fixes the problem for me. Thanks for the quick feedback. Meanwhile I tested gcc 4.7.3. I cannot reproduce the miscompilation there.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- It turned out that proposed fix does not help trunk compilers since now another huge routine is inlined firstly (read_input) and for perdida we got the following message: This has been seen before and supposed to be fixed: see pr48636, comment #37. Note that passing --param large-function-growth=130 will restore performance. As does --param max-inline-insns-auto=94. I assume that additional heuristics must be designed to inline once called functions which are called inside inner loop. Well, it was supposed to have been found. What did break it?
[Bug c/58943] [4.7/4.8/4.9 Regression] wrong calculation of indirect structure member arithmetic via function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- If anything, this would be a C FE request for a change like PR45437 that made into the C++ FE. The question is if we want to do this only for flag_isoc11, or also older. Handling it during gimplification or later is impossible, because the difference between x[0] |= x[0] | f (); and x[0] = x[0] | f (); is already lost there.
[Bug c++/59231] [4.8/4.9 Regression] gcc misses [-Werror=sign-compare] when inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- This has changed in r187542 and from what I can see, the change was completely intentional.
[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Yes, the patch works. Thanks.
[Bug tree-optimization/59377] New: VRP produces bogus warning with -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59377
Bug ID: 59377
Summary: VRP produces bogus warning with -Warray-bounds
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dnovillo at gcc dot gnu.org
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Using trunk and 4.8.x, this code produces a bogus -Warray-bounds warning:
typedef decltype(sizeof(void*)) size_t;
size_t strlen(const char *);
int memcmp (const void *, const void *, size_t);
struct StringPiece
{
const char *ptr_;
size_t size_;
StringPiece ();
StringPiece (const char *p1):ptr_ (p1), size_(strlen(p1)) { }
const char *data () { return ptr_; }
size_t length() { return size_; }
};
void operator== (StringPiece, StringPiece p2)
{
const char *a = p2.data (), *b = a;
if (p2.length() 8) {
b += 8;
memcmp (a, b, 1);
}
}
void
UtilsSplitQuotedStrings ()
{
StringPiece c;
c == ;
}
$ trunk/bld/bin/g++ -std=c++11 -c -Warray-bounds -O2 a.cc
a.cc: In function ‘void UtilsSplitQuotedStrings()’:
a.cc:22:23: warning: array subscript is above array bounds [-Warray-bounds]
memcmp (a, b, 1);
$ ^
The warning disappears with -fno-tree-vrp:
$ trunk/bld/bin/g++ -std=c++11 -c -Warray-bounds -O2 a.cc -fno-tree-vrp
$
I've seen some similar looking bug reports, but none seemed related with VRP.
[Bug tree-optimization/59377] VRP produces bogus warning with -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59377 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/7233326
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #7 from Yuri Rumyantsev ysrumyan at gmail dot com --- I saw that on old compiler sources (dated by 20130911) with my patch 'perdida' was inlined without any additional inline parameters (using -flto) but now it does not inlined since another large function read_input is inlined before it and we reach max growth limit. So I assume that an order of call graph walking is different now. It means that we really need another heuristics to distinguish really cold and hot calls, e.g. we can use edge-count for sorting inline candidates.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Tue Dec 3 16:01:13 2013
New Revision: 205639
URL: http://gcc.gnu.org/viewcvs?rev=205639root=gccview=rev
Log:
PR sanitizer/59063
* lib/asan-dg.exp: Don't add anything to flags if libsanitizer
has not been found.
* lib/ubsan-dg.exp: Likewise. Append to flags also
-B${gccpath}/libsanitizer/.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/asan-dg.exp
trunk/gcc/testsuite/lib/ubsan-dg.exp
[Bug c++/59231] [4.8/4.9 Regression] gcc misses [-Werror=sign-compare] when inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
This has changed in r187542 and from what I can see, the change was
completely intentional.
Interestingly, the same was done recently in Clang:
http://llvm.org/bugs/show_bug.cgi?id=8682
That commit also killed warnings for non-dependant types within templates:
unsigned int z;
signed int w;
templateclass X, class Y
bool equals( X x, Y y )
{
return (z == w);
}
(It would be nice to edit the log of that commit to fix the PR number, which
should be 11856).
[Bug c++/59268] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr in a virtual function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59268 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- ICE started with r172790, the first ICE supposedly fixed by PR55944.
[Bug c++/59268] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr in a virtual function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59268 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-03 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31364 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31364action=edit gcc49-pr59268.patch Untested fix.
[Bug tree-optimization/59058] [4.7/4.8/4.9 Regression] 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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- So, is this fully fixed now on the trunk?
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 --- Comment #2 from Steve Ellcey sje at gcc dot gnu.org --- Created attachment 31365 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31365action=edit runnnable performance test case Here is a runnable test case. You may need to increase the loop counts depending on the speed of your machine. On the MIPS system I used a 4.7.3 GCC took 36.127 seconds and a 4.8.1 GCC took 38.435 seconds (Little endian, -O2, static linking).
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 Paul Smith psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #4 from Paul Smith psmith at gnu dot org --- See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a repro case for C++ inline functions on x86_64 (very latest GCC and GDB releases).
[Bug debug/47471] [4.7/4.8/4.9 Regression] stdarg functions extraneous too-early prologue end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471 Paul Smith psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #11 from Paul Smith psmith at gnu dot org --- See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a repro case for C++ inline functions on x86_64 (very latest GCC 4.8.2 and GDB 7.6.1 releases).
[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 Paul Smith psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #4 from Paul Smith psmith at gnu dot org --- See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a repro case for C++ inline functions on x86_64 (very latest GCC 4.8.2 and GDB 7.6.1 releases).
[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 3 Dec 2013, ebotcazou at gcc dot gnu.org wrote: In any case, c11-atomic-exec-5.c does not test anything relating to enabled traps, although the feholdexcept code sequence from the target hook is intended to disable traps and the feupdateenv sequence should then restore the previous state of which traps were enabled.) The question is: does the UPDATE part of the hook really need to cause traps as the feupdateenv routine, or could it only set the appropriate bits? Properly it should cause traps if those are enabled (although enabling traps is outside the scope of ISO C, and my guess is that when TS 18661-5 provides C bindings for IEEE 754-2008 alternate exception handling, they will be a lot more complicated than simply enabling / disabling traps, and won't be implemented in GCC / glibc any time soon). The issue of trapping for exact underflow is deliberately ignored (I raised it in http://www.open-std.org/jtc1/sc22/wg14/13103 for consideration for TS 18661-5).
[Bug c/58943] [4.7/4.8/4.9 Regression] wrong calculation of indirect structure member arithmetic via function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- I think it should be fixed for all C standard versions, not just C11 (that is, the front end should produce something like (save (rhs), save (lhs) = save (lhs) op save (rhs)) to get the right order of evaluation). As it's reported for at least 4.6 onwards and earlier versions didn't claim any C11 support and only C11 defined things sufficiently precisely for this to be a bug, I don't see this as a regression.
[Bug ipa/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-12/msg00252.htm ||l Component|tree-optimization |ipa --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- Thanks I have posted the updated patch (which checks for gimple_register_type rather than non-BLKmode) to the mailing list for review: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00252.html Computing, storing and re-using the types would certainly be too invasive a change for stage 3. Moreover, it would basically mean passing the PARM_DECL types as types of actual arguments and I am not even sure that it is correct, the back-end should probably see the actual arguments as exactly what they are in the callers.
[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Properly it should cause traps if those are enabled (although enabling traps is outside the scope of ISO C, and my guess is that when TS 18661-5 provides C bindings for IEEE 754-2008 alternate exception handling, they will be a lot more complicated than simply enabling / disabling traps, and won't be implemented in GCC / glibc any time soon). OK, I'll go for the call to __atomic_feraiseexcept like on x86 then, and I'll define a macro on Solaris to do the required shifting. Thanks again.
[Bug target/59376] -mmemcpy-strategy= and -mmemset-strategy= are undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59376 davidxl xinliangli at gmail dot com changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #1 from davidxl xinliangli at gmail dot com --- Where should it be documented (they are documented in doc/invoke.texi already)?
[Bug target/59376] -mmemcpy-strategy= and -mmemset-strategy= are undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59376 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Never mind.
[Bug c/59367] Syntax error with #pragma message before else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- I think #pragma are being considered a statement which is why you are getting a parse error. I almost want to say they are statements based on what I have read (though I don't have any explicit references to the standard currently).
[Bug tree-optimization/59377] VRP produces bogus warning with -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59377 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-03 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I think this is an invalid testcase. GCC does not know what this strlen/memcmp does. If we add extern C around strlen and memcmp, GCC does not warn. I think you over reduced the original testcase.
[Bug tree-optimization/59377] VRP produces bogus warning with -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59377 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) I think this is an invalid testcase. GCC does not know what this strlen/memcmp does. If we add extern C around strlen and memcmp, GCC does not warn. Does not warn as GCC is able to optimize away the strlen (and even the memcmp too).
[Bug c/59367] Syntax error with #pragma message before else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- All preprocessing directives are deleted at the end of phase 4.
[Bug rtl-optimization/59020] [4.9 Regression] internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:933
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020 --- Comment #5 from wmi at gcc dot gnu.org --- Author: wmi Date: Tue Dec 3 18:35:24 2013 New Revision: 205644 URL: http://gcc.gnu.org/viewcvs?rev=205644root=gccview=rev Log: 2013-12-03 Wei Mi w...@google.com PR rtl-optimization/59020 * sched-deps.c (try_group_insn): Move it from haifa-sched.c to here. (sched_analyze_insn): Call try_group_insn. (sched_analyze): Cleanup SCHED_GROUP_P before start the analysis. * haifa-sched.c (try_group_insn): Moved to sched-deps.c. (group_insns_for_macro_fusion): Removed. (sched_init): Remove calling group_insns_for_macro_fusion. 2013-12-03 Wei Mi w...@google.com PR rtl-optimization/59020 * testsuite/gcc.dg/pr59020.c: New. * testsuite/gcc.dg/macro-fusion-1.c: New. * testsuite/gcc.dg/macro-fusion-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/macro-fusion-1.c trunk/gcc/testsuite/gcc.dg/macro-fusion-2.c trunk/gcc/testsuite/gcc.dg/pr59020.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59058] [4.7/4.8/4.9 Regression] 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 --- Comment #12 from rguenther at suse dot de rguenther at suse dot de --- jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- So, is this fully fixed now on the trunk? No, it's not fixed. Richard.
[Bug target/57363] IBM long double: adding NaN and number raises inexact exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org --- Fixed. http://gcc.gnu.org/ml/gcc-cvs/2013-12/msg00087.html
[Bug rtl-optimization/58726] [4.7/4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58726
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Testcase suitable for gcc.c-torture/execute/:
int a, c;
union { int f1; int f2 : 1; } b;
short
foo (short p)
{
return p 0 ? p : a;
}
int
main ()
{
if (sizeof (short) * __CHAR_BIT__ != 16
|| sizeof (int) * __CHAR_BIT__ != 32)
return 0;
b.f1 = 56374;
unsigned short d;
int e = b.f2;
d = e == 0 ? b.f1 : 0;
c = foo (d);
if (c != (short) 56374)
__builtin_abort ();
return 0;
}
This seems to be a bug in the combiner, during combination of:
(gdb) p debug_rtx (i3)
(insn 22 21 23 2 (parallel [
(set (reg:CCGOC 17 flags)
(compare:CCGOC (and:HI (reg/v:HI 83 [ d ])
(const_int -9162 [0xdc36]))
(const_int 0 [0])))
(set (reg:HI 85 [ D.1789 ])
(and:HI (reg/v:HI 83 [ d ])
(const_int -9162 [0xdc36])))
]) pr58726.c:7 395 {*andhi_2}
(expr_list:REG_DEAD (reg/v:HI 83 [ d ])
(nil)))
(gdb) p debug_rtx (i2)
(insn 55 54 56 2 (parallel [
(set (subreg:SI (reg/v:HI 83 [ d ]) 0)
(if_then_else:SI (ltu:SI (reg:CC 17 flags)
(const_int 0 [0]))
(const_int -1 [0x])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
]) pr58726.c:19 925 {*x86_movsicc_0_m1}
(expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(gdb) p debug_rtx (i1)
(insn 54 15 55 2 (set (reg:CC 17 flags)
(compare:CC (reg:QI 98 [ D.1788 ])
(const_int 1 [0x1]))) pr58726.c:19 5 {*cmpqi_1}
(expr_list:REG_DEAD (reg:QI 98 [ D.1788 ])
(nil)))
The problem is that reg:HI 83 is substed multiple twice (with unique_copy == 0)
and apparently force_to_mode seems to destructively modify the expression,
which is shared, around line 8533. On the second occurrence it is first
force_to_mode'd with mask 0xdc36, and on the first occurrence later on
simplify_comparison performs:
11187 /* If this is a sign bit comparison and we can do arithmetic in
11188 MODE, say that we will only be needing the sign bit of OP0. */
11189 if (sign_bit_comparison_p HWI_COMPUTABLE_MODE_P (mode))
11190op0 = force_to_mode (op0, mode,
11191 (unsigned HOST_WIDE_INT) 1
11192 (GET_MODE_PRECISION (mode) - 1),
11193 0);
with mask 0x8000, which destructively modifies also the second occurrence.
So the question is, do we have to copy_rtx always just in case, or should some
routines (e.g. force_to_mode) be documented as not modifying the argument in
place? I guess this issue can be fixed easily just by changing those two
SUBSTs at the end of force_to_mode in IF_THEN_ELSE handling (and there is
another one for ROTATE{,RT}), but the question is if we don't have tons of
similar latent issues. The changes in place were done using SUBST, so if we
undo_all, they are properly reverted, the problem is when they aren't reverted,
as in this case.
[Bug rtl-optimization/58726] [4.7/4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58726 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31366 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31366action=edit gcc49-pr58726.patch Untested patch that does that, fixes the testcase.
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-* CC||hubicka at ucw dot cz Component|gcov-profile|target --- Comment #2 from Markus Trippelsdorf octoploid at yandex dot com --- Started with r203937.
[Bug c++/59378] New: Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 Bug ID: 59378 Summary: Internal compiler error when using __builtin_shuffle in a template function Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bcmpinc at hotmail dot com The g++ compiler crashes on an internal error when instantiating a template function or class that uses the gcc vector extensions and __builtin_shuffle(). See attachment. The error message when instantiating a template function: test.cpp:4:23: internal compiler error: in make_decl_rtl, at varasm.c:1140 The error message when instantiating a template class: test2.cpp:5:17: internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 --- Comment #1 from Bauke Conijn bcmpinc at hotmail dot com --- Created attachment 31368 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31368action=edit Testcase 1
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 --- Comment #2 from Bauke Conijn bcmpinc at hotmail dot com --- Created attachment 31369 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31369action=edit Testcase 2
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 Bauke Conijn bcmpinc at hotmail dot com changed: What|Removed |Added Attachment #31367|0 |1 is obsolete|| --- Comment #3 from Bauke Conijn bcmpinc at hotmail dot com --- Created attachment 31370 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31370action=edit Verbose compiler output for testcase 1 Generated using: g++ -v -save-temps -std=c++11 test.cpp 2 save-temps
[Bug target/59379] New: gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 Bug ID: 59379 Summary: gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: areg.melikadamyan at gmail dot com On Linux/x86-64, when GCC revision 205645 configured with --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go --prefix=/usr/local --enable-gnu-indirect-function --disable-werror --with-build-config=bootstrap-lto --with-fpmath=sse --with-arch=corei7 --with-cpu=slm is bootstrapped with make profiledbootstrap, gomp_init_num_threads is compiled into an infinite loop: (gdb) next 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) 90 gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size); (gdb) 106if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp)) (gdb) Stage3 GCC is miscompiled.
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #3 from Markus Trippelsdorf octoploid at yandex dot com --- Switching off misaligned_move_string_pro_epilogues for AMD fixes the issue: diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def index 4c13c3a0ec69..af58b3e1f77e 100644 --- a/gcc/config/i386/x86-tune.def +++ b/gcc/config/i386/x86-tune.def @@ -264,7 +264,7 @@ DEF_TUNE (X86_TUNE_SINGLE_STRINGOP, single_stringop, m_386 | m_P4_NOCONA) FIXME: This may actualy be a win on more targets than listed here. */ DEF_TUNE (X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES, misaligned_move_string_pro_epilogues, - m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_GENERIC) + m_386 | m_486 | m_CORE_ALL | m_GENERIC) /* X86_TUNE_USE_SAHF: Controls use of SAHF. */ DEF_TUNE (X86_TUNE_USE_SAHF, use_sa
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-03
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |4.8.3
Ever confirmed|0 |1
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Confirmed. With trunk and checking enabled:
i.C: In instantiation of ‘void traverse(v4si) [with int C = 0; v4si =
__vector(4) int]’:
i.C:6:31: required from here
i.C:4:23: internal compiler error: in tsubst_copy, at cp/pt.c:12863
v4si new_bounds = __builtin_shuffle(bounds,v4si{0,1,2,3});
^
0x6309f8 tsubst_copy
/home/marek/src/gcc/gcc/cp/pt.c:12863
0x63d373 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:15072
0x63d28d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:15057
0x636b52 tsubst_expr
/home/marek/src/gcc/gcc/cp/pt.c:13777
0x6334e0 tsubst_expr
/home/marek/src/gcc/gcc/cp/pt.c:13299
0x633f2a tsubst_expr
/home/marek/src/gcc/gcc/cp/pt.c:13396
0x652266 instantiate_decl(tree_node*, int, bool)
/home/marek/src/gcc/gcc/cp/pt.c:19643
0x652c4f instantiate_pending_templates(int)
/home/marek/src/gcc/gcc/cp/pt.c:19755
0x6a8d17 cp_write_global_declarations()
/home/marek/src/gcc/gcc/cp/decl2.c:4131
[Bug c/53424] dynamic array expressions get wrong sizeof() if pointers to const are involved and the pointers are changed (const is misapplied to the whole expression)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53424 --- Comment #4 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Created attachment 31371 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31371action=edit Patch to tree_invariant_p_1 I tried restricting tree_invariant_p_1 as in the attached patch, but while this fixes the bug it causes regressions FAIL: gnat.dg/vect1.adb scan-tree-dump-times vect vectorized 1 loops 15 and similar for vect2.adb through vect6.adb. It seems Ada vectorization is somehow relying on certain trees being treated as invariant when similar C trees aren't invariant; I'd hoped that it wouldn't matter much because the GIMPLE optimizers should eliminate any unnecessary temporaries.
[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf octoploid at yandex dot com --- Maybe a dup of Bug59003?
[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Symptom is msgfmt never stops: 30751 pts/0t 43:26 msgfmt -o de.mo /export/gnu/import/git/gcc/libstdc++- 30752 pts/0R 64:42 msgfmt -o fr.mo /export/gnu/import/git/gcc/libstdc++- (gdb) info shared FromTo Syms Read Shared Object Library 0x003039808780 0x003039832a98 Yes (*) /lib64/libgettextsrc-0.18.2.so 0x00303941aad0 0x00303948179c Yes (*) /lib64/libgettextlib-0.18.2.so 0x00303e408d10 0x00303e426ea8 Yes (*) /lib64/libcroco-0.6.so.3 0x00303901a260 0x0030390af89c Yes (*) /lib64/libglib-2.0.so.0 0x003cf6606d50 0x003cf6620164 Yes (*) /lib64/libncurses.so.5 0x003cf4a0ce40 0x003cf4a188d8 Yes (*) /lib64/libtinfo.so.5 0x003cf4610160 0x003cf4643ad0 Yes (*) /lib64/libunistring.so.0 0x003cdda1f410 0x003cddb6269f Yes (*) /lib64/libc.so.6 0x7f570fecc380 0x7f570fed9467 Yes /export/build/gnu/gcc-lto-fdo/build-x86_64-linux/x86_64-unknown-linux-gnu/libgomp/.libs/libgomp.so.1 0x003cdde05790 0x003cdde103b1 Yes (*) /lib64/libpthread.so.0 0x003ce2a2e870 0x003ce2b15060 Yes (*) /lib64/libxml2.so.2 0x003cde200ed0 0x003cde2019ce Yes (*) /lib64/libdl.so.2 0x003cdd600ae0 0x003cdd61ac5a Yes (*) /lib64/ld-linux-x86-64.so.2 0x003cdea02170 0x003cdea0e5f0 Yes (*) /lib64/libz.so.1 0x003ce1602f30 0x003ce16187a0 Yes (*) /lib64/liblzma.so.5 0x003cde6054b0 0x003cde66fbb6 Yes (*) /lib64/libm.so.6 (*): Shared library is missing debugging information. (gdb)
[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Markus Trippelsdorf from comment #1) Maybe a dup of Bug59003? Maybe.
[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- Thanks for reporting. I'll have a look at this.
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to chrbr from comment #5)
This has been fixed by Oleg in the 4.9 with a new cflow pass. In 4.8 I think
it's best to just disable it as unsafe, The following workaround is enough
to to fix the problem:
Index: sh.md
===
--- sh.md (revision 205585)
+++ sh.md (working copy)
@@ -8380,7 +8380,7 @@ label:
{
return output_branch (sh_eval_treg_value (operands[1]), insn, operands);
}
- 1
+ 0
[(set (pc) (if_then_else (eq (reg:SI T_REG) (match_dup 2))
(label_ref (match_dup 0))
(pc)))]
do you agree Oleg ?
This has been mentioned in PR 51244 already, I think.
It should not be necessary to disable the T bit optimization completely, only
the cases where there are multiple non-fallthrough basic blocks (i.e. where
there's a label in between).
Something like the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244#c64 should do.
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- I wonder whether the following could be the right thing to do. --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -12823,6 +12823,9 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl) in response to the saved STMT_IS_FULL_EXPR_P setting. */ gcc_unreachable (); +case SAVE_EXPR: + return tsubst_copy (TREE_OPERAND (t, 0), args, complain, in_decl); + case OFFSET_REF: r = build2 (code, tsubst (TREE_TYPE (t), args, complain, in_decl),
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #4 from Jan Hubicka hubicka at ucw dot cz --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #3 from Markus Trippelsdorf octoploid at yandex dot com --- Switching off misaligned_move_string_pro_epilogues for AMD fixes the issue: We need to figure out why it causes problem for AMD and not for generic/core. I will try to reproduce the ICE... Honza
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #27 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #26) A: The specific intrinsic procedure itself retains the elemental property (so a reference using its own name can be elemental), but the dummy procedure or procedure pointer associated with it is not elemental and so cannot be used to reference the specific intrinsic procedure elementally. Thus, the following code is invalid: interface elemental real function x(y) ! Valid external procedure real, intent(in) :: y end function x end interface ! pointer :: x ! comment aside: this proc-ptr would violate C1218 intrinsic :: sin call foo(sin) contains subroutine foo(z) procedure(x) :: z ! INVALID per C1218 ! procedure(sin) :: z! Valid - but not elemental ... print *, z([1.,2.,3.]) ! ... hence this invalid too for procedure(sin)::z end subroutine foo end See also: 12.5.2.9 Actual arguments associated with dummy procedure entities [...] If the interface of a dummy procedure is explicit, its characteristics as a procedure (12.3.1) shall be the same as those of its effective argument, except that a pure effective argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which cannot be elemental). [The parenthesis is a consequence of C1218, see comment 26 for the quote.] Thus: * I think we need a check for elemental as dummy argument and reject it * For the patch (comment 18), I wonder whether whether one should leave out the elemental assignment and just do the pure assignment.
[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317
Vladimir Makarov vmakarov at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #1 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Robert Suchanek from comment #0)
The LRA generates the following piece of RTL that fails at check_rtl():
(insn 265 54 267 2 (set (reg:SI 8 $8 [339])
(const:SI (unspec:SI [
(const_int 0 [0])
] UNSPEC_GP))) ia64-1_testcase.c:49 295 {*movsi_mips16}
(nil))
This does not satisfy the operand’s constrains in movmode_mips16 pattern.
The ICE appears to be triggered because of ALL_REGS assigned to new pseudos
generated and the pseudo data gets expanded but I do not know how to fix it
without breaking PR59133 again.
I believe it has been solved by one of the latest patches. The pseudos with
ALL_REGS are really generated but their class is changed lately.
It would be nice, Robert, if you check this and close the PR.
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 Maciej W. Rozycki ma...@linux-mips.org changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #3 from Maciej W. Rozycki ma...@linux-mips.org --- Caused by: r193882 | rguenth | 2012-11-28 09:27:10 + (Wed, 28 Nov 2012) | 19 lines 2012-11-28 Richard Biener rguent...@suse.de PR c/35634 * gimple.h (gimplify_self_mod_expr): Declare. * gimplify.c (gimplify_self_mod_expr): Export. Take a different type for performing the arithmetic in. (gimplify_expr): Adjust. * tree-vect-loop-manip.c (vect_can_advance_ivs_p): Strip sign conversions we can re-apply after adjusting the IV. c-family/ * c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions here and use a type with proper overflow behavior for types that would need to be promoted for the arithmetic. * gcc.dg/torture/pr35634.c: New testcase. * g++.dg/torture/pr35634.C: Likewise. * gcc.dg/vect/pr18536.c: Mark worker function noinline.
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Maciej W. Rozycki from comment #3) Caused by: Well that corrects how i++ is done.
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- No, that doesn't work for the second testcase...
[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31372action=edit A testcase The outputs from stage 2 and stage 3 cc1 are different: [hjl@gnu-mic-2 pr59379]$ make /export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/ -ftls-model=initial-exec -fPIC -O2 -S test.c /export/build/gnu/gcc-lto-fdo/build-x86_64-linux/prev-gcc/xgcc -B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/prev-gcc/ -ftls-model=initial-exec -fPIC -O2 -S -o good.s test.c diff -up test.s good.s --- test.s2013-12-03 16:38:50.413067359 -0800 +++ good.s2013-12-03 16:38:50.473066316 -0800 @@ -27,7 +27,7 @@ gomp_init_num_threads: movq%rdi, gomp_cpuset_size(%rip) callgomp_malloc@PLT .p2align 4,,15 -.L24: +.L27: movq%rax, gomp_cpusetp(%rip) movq%rax, %rbx .L2: @@ -40,9 +40,9 @@ gomp_init_num_threads: xorl%eax, %eax callpthread_getaffinity_np@PLT testl%eax, %eax -je.L27 +je.L30 cmpl$22, %eax -jne.L25 +jne.L28 movqgomp_cpuset_size(%rip), %rsi cmpq$127, %rsi ja.L10 @@ -64,8 +64,8 @@ gomp_init_num_threads: movqgomp_cpusetp(%rip), %rdi callrealloc@PLT testq%rax, %rax -jne.L24 -.L25: +jne.L27 +.L28: movqgomp_global_icv@GOTPCREL(%rip), %rbx .L4: movqgomp_cpusetp(%rip), %rdi @@ -88,7 +88,7 @@ gomp_init_num_threads: ret .p2align 4,,7 .p2align 3 -.L27: +.L30: .cfi_restore_state movqgomp_cpusetp(%rip), %rsi movqgomp_cpuset_size(%rip), %rdi @@ -98,35 +98,31 @@ gomp_init_num_threads: testq%rax, %rax movq%rax, (%rbx) je.L4 -movqgomp_cpuset_size(%rip), %rdi -movq%rdi, gomp_get_cpuset_size(%rip) -salq$3, %rdi +movqgomp_cpuset_size(%rip), %rsi +movq%rsi, gomp_get_cpuset_size(%rip) +salq$3, %rsi je.L14 -movq%rdi, %r8 -movq%rdi, %rsi -movqgomp_cpusetp(%rip), %r9 -negq%r8 -salq$32, %r8 -jmp.L6 +movqgomp_cpusetp(%rip), %rdi +movq%rsi, %rdx +jmp.L8 .p2align 4,,7 .p2align 3 -.L8: -testq%rdx, %rdx -je.L5 .L7: -movq%rcx, %rsi +testq%rcx, %rcx +je.L5 .L6: -leaq-1(%rsi), %rcx -leaq(%rcx,%r8), %rdx -cmpq%rdx, %rdi -jbe.L7 +movq%rcx, %rdx +.L8: +leaq-1(%rdx), %rcx +cmpq%rcx, %rsi +jbe.L6 movq%rcx, %rax shrq$6, %rax -movq(%r9,%rax,8), %rax +movq(%rdi,%rax,8), %rax shrq%cl, %rax andl$1, %eax -je.L8 -leaq63(%rsi), %rax +je.L7 +leaq63(%rdx), %rax shrq$6, %rax salq$3, %rax .L5: make: *** [all] Error 1
[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-04 Ever confirmed|0 |1 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- The difference starts in ivopts pass: diff -upr good/test.c.120t.ivopts bad/test.c.120t.ivopts --- good/test.c.120t.ivopts2013-12-03 16:46:21.995210047 -0800 +++ bad/test.c.120t.ivopts2013-12-03 16:46:34.847986232 -0800 @@ -13,6 +13,7 @@ gomp_init_num_threads () long unsigned int _13; long unsigned int gomp_cpuset_size.2_14; void * gomp_cpusetp.3_17; + long unsigned int _19; long unsigned int gomp_cpuset_size.1_20; int _22; long unsigned int gomp_cpuset_size.1_25; @@ -39,6 +40,7 @@ gomp_init_num_threads () struct cpu_set_t * prephitmp_89; struct cpu_set_t * prephitmp_90; long unsigned int pretmp_91; + long unsigned int _92; long unsigned int pretmp_93; long unsigned int pretmp_95; long unsigned int prephitmp_96; @@ -93,7 +95,9 @@ gomp_init_num_threads () bb 8: # i_76 = PHI i_48(12), i_47(7) i_48 = i_76 + 18446744073709551615; - if (i_47 i_48) + _92 = i_47 * 18446744069414584320; + i_94 = i_48 + _92; + if (i_47 i_94) goto bb 9; else goto bb 11; @@ -118,7 +122,9 @@ gomp_init_num_threads () goto bb 13; bb 11: - if (i_48 != 0) + _19 = i_47 * 18446744069414584320; + i_69 = _19 + i_48; + if (i_69 != 0) goto bb 12; else goto bb 13;
[Bug ipa/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 --- Comment #8 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Martin Jambor from comment #7) Thanks I have posted the updated patch (which checks for gimple_register_type rather than non-BLKmode) FWIW, it is possible to have a BLKmode struct passed in a register. The compat testcases have a number of those. Not sure if it's possible to craft a testcase that also triggers this ipa path. Computing, storing and re-using the types would certainly be too invasive a change for stage 3. Moreover, it would basically mean passing the PARM_DECL types as types of actual arguments and I am not even sure that it is correct, the back-end should probably see the actual arguments as exactly what they are in the callers. The idea of a function is that there can be multiple callers, using different actual arguments, thus you shoud pick one formal argument type for each argument, and stick with it for all callers and the callee. The formal argument type determines how the argument is passed. Now, I understand that with ipa, you will often have only a single caller, and the compiler can change the types with consideration of the passed actual arguments to fit various optimization purposes, but it still has to pick one list of formal parameters types for each specialized callee, and stick to this list at the corresponding call site(s).
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 --- Comment #5 from Maciej W. Rozycki ma...@linux-mips.org --- (In reply to Andrew Pinski from comment #4) Well that corrects how i++ is done. Old MIPS assembly code produced was AFAICT correct. The loop termination condition was expressed as: bne$3,$6,$L3 that represented (i != c) rather than (i c), but we start `i' from 0 and increment by one at a time, so both expressions are equivalent in this context. Here I believe the following C language standard clause applies[1]: Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type. so for both operands the expression is supposed to use the unsigned short type, that is 16-bit on the MIPS target. There are no 16-bit ALU operations defined in the MIPS architecture though, so at the assembly (and therefore machine-level) level both `c' and `i' were sign-extended to 32-bits: andi$5,$5,0x seh$6,$5 and: seh$3,$3 respectively (of course ANDI is redundant here, there's no need to zero-extend before sign-extending, SEH does not require it), before the BNE comparison quoted above was made. That correctly mimicked 16-bit operations required by the language here (of course zero-extension of both `c' and `i' would do as well). Now after the change `c' is zero-extended only (no sign-extension afterwards): andi$5,$5,0x while `i' is still sign-extended: seh$3,$3 Then the loop termination condition is expressed as: slt$6,$3,$5 bne$6,$0,$L3 instead. Notice the SLT instruction, that accurately represents the (i c) termination condition, however using *signed* arithmetic. Which means that for `c' equal e.g. to 32768 the loop will never terminate. I believe this is not what the clause of the C language standard quoted above implies. For unsigned arithmetic SLTU would have to be used instead. So it looks to me like the performance regression merely happens to be a visible sign of a bigger correctness problem. Have I missed anything? [1] Programming languages -- C, ISO/IEC 9899:1999(E), Section 6.3.1.8 Usual arithmetic conversions.
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Maciej W. Rozycki from comment #5) (In reply to Andrew Pinski from comment #4) Well that corrects how i++ is done. Old MIPS assembly code produced was AFAICT correct. The loop termination condition was expressed as: Correctly representative in the gimple IR rather than in the final assembly.
[Bug c++/59378] Internal compiler error when using __builtin_shuffle in a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- Created attachment 31373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31373action=edit Untested rough patch This ugliness makes the vec_perm_expr more similar to the other build_x_* functions. Just a quick thing, may be wrong.
[Bug c++/59380] New: libstdc++.a: could not read symbols: Bad value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380
Bug ID: 59380
Summary: libstdc++.a: could not read symbols: Bad value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cnstar9988 at gmail dot com
libstdc++.a: could not read symbols: Bad value
gcc 4.8.2
foo.cc=
#include iostream
void foo() { std::cout 42 std::endl; }
g++ -pthread -fPIC -o foo.so -shared foo.cc
[root@hpblade01 ~]# g++ -pthread -fPIC -o foo.so -shared foo.cc
/usr/bin/ld:
/opt/gcc-4.8.2/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libstdc++.a(ios_init.o):
relocation R_X86_64_32 against `__pthread_key_create' can not be used when
making a shared object; recompile with -fPIC
/opt/gcc-4.8.2/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libstdc++.a:
could not read symbols: Bad value
collect2: error: ld returned 1 exit status
===
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.8.2/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../src/configure --prefix=/opt/gcc-4.8.2
--enable-languages=c,c++ --with-pic --disable-shared --enable-threads=posix
--enable-checking=release --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --disable-nls
--with-cpu=generic --disable-multilib --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug c++/59380] libstdc++.a: could not read symbols: Bad value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380 littlestar cnstar9988 at gmail dot com changed: What|Removed |Added Version|unknown |4.8.2 --- Comment #1 from littlestar cnstar9988 at gmail dot com --- works well on gcc 4.6.4 fails on gcc 4.8.2 CentOS 6.2 X86_64
[Bug c++/59380] libstdc++.a: could not read symbols: Bad value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59380 --- Comment #2 from littlestar cnstar9988 at gmail dot com --- similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638
[Bug c++/59381] New: Internal compiler error in get_expr_operands, in tree-ssa-operands.c:1035
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59381 Bug ID: 59381 Summary: Internal compiler error in get_expr_operands, in tree-ssa-operands.c:1035 Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hindmost.one at gmail dot com The bug is caused by line `g++ clock-test.c++ -pthread -o clock-test -save-temps` It says (russian locale, sorry) clock-test.c++: In lambda function: clock-test.c++:16:1: внутренняя ошибка компилятора: в get_expr_operands, в tree-ssa-operands.c:1035 Отправьте подробное сообщение об ошибке с препроцессированным исходным кодом. Смотрите инструкции в file:///usr/share/doc/gcc-4.7/README.Bugs. Preprocessed source stored into /tmp/ccoyPRmF.out file, please attach this to your bugreport. uname -a: Linux phoenix-GA-970A-UD3 3.5.0-43-generic #66-Ubuntu SMP Wed Oct 23 17:33:43 UTC 2013 i686 athlon i686 GNU/Linux g++ -v: Inner specs are used. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper Target arch: i686-linux-gnu Conf params: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Threading model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
[Bug c++/59381] Internal compiler error in get_expr_operands, in tree-ssa-operands.c:1035
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59381 --- Comment #1 from Heimdell hindmost.one at gmail dot com --- Created attachment 31374 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31374action=edit The (compressed) file, produced by compiler.
[Bug c++/59381] Internal compiler error in get_expr_operands, in tree-ssa-operands.c:1035
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59381 --- Comment #2 from Heimdell hindmost.one at gmail dot com --- Created attachment 31375 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31375action=edit Project sources
