http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53827
--- Comment #3 from Uros Bizjak 2012-07-03 07:05:29
UTC ---
(In reply to comment #2)
> My thinko. This patchlet ought to fix it. Testing now...
I can confirm that the patch fixes all memset* runtime failures in [1].
[1] http://gcc.gnu.org/ml/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53834
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Andreas Schwab changed:
What|Removed |Added
CC||baker at usgs dot gov
--- Comment #4 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
Bug #: 53836
Summary: ICE: unexpected expression of kind template_parm_index
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
--- Comment #1 from Roger Ferrer Ibanez 2012-07-03
08:28:59 UTC ---
A similar problem happens when template-type parameters are involved.
// -- test2.cc
template
struct A { };
template
void g2()
{
const int M ( sizeof(Q) );
A a;
}
v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561
--- Comment #16 from Jonathan Wakely 2012-07-03
08:31:18 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > Patch reverted, thus in C++11 mode size() is back to O(n) but std::list can
> > interoperate with the C++98 version of it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561
--- Comment #17 from Jonathan Wakely 2012-07-03
08:34:51 UTC ---
(In reply to comment #15)
> Also, didn't this already make it into the 4.7 release? Wouldn't reverting it
> now just cause incompatibilities with 4.7 and both older and newer releas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #5 from Andreas Schwab 2012-07-03
09:46:07 UTC ---
Author: schwab
Date: Tue Jul 3 09:46:01 2012
New Revision: 189210
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189210
Log:
PR target/28896
* config/m68k/m68k.c (m68
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Andreas Schwab changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707
--- Comment #15 from Mikael Pettersson 2012-07-03
09:56:33 UTC ---
Created attachment 27734
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27734
cleaned up test case
This cleaned up version of the small C test case should be free of any
tec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53835
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53832
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.8.0
--- Comment #2 from Richard Guen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Richard Guenther changed:
What|Removed |Added
Target|arm-linux-androideabi |arm-linux-androideabi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #3 from Yuri Gribov 2012-07-03
10:45:09 UTC ---
I don't think linker can do much after gcc removes the symbol from symtab.
BTW it would help a lot if linker verified that LTO and ELF symtabs actually
match. Currently mismatches cause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #4 from Richard Guenther 2012-07-03
10:52:42 UTC ---
(In reply to comment #3)
> I don't think linker can do much after gcc removes the symbol from symtab.
I belive the contract between the linker and GCC is that GCC can introduce
new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #5 from Richard Guenther 2012-07-03
10:59:57 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > I don't think linker can do much after gcc removes the symbol from symtab.
>
> I belive the contract between the linker and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53832
--- Comment #3 from Jonathan Wakely 2012-07-03
11:02:52 UTC ---
I also saw this on x86_64-linux (gcc14 in the compile farm) ... not sure what's
going on. In all cases it was a completely clean objdir.
Will investigate further tonight.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811
Uros Bizjak changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811
--- Comment #4 from Tobias Hansen 2012-07-03
11:13:26 UTC ---
Sorry, I won't get around to compile gcc (never done that yet) and test it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53837
Bug #: 53837
Summary: Unpacking variadic template parameters in a method
parameter default value gives parse error
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
Bug #: 53838
Summary: _GLIBCXX_DEBUG and empty ostringstream
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
--- Comment #1 from Jonathan Wakely 2012-07-03
11:52:17 UTC ---
This is not a GCC bug, please report it to MacPorts not here.
At a guess I'd say you're linking to the system libstdc++.so not the one from
your mp builds, and the mp builds do not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811
--- Comment #5 from uros at gcc dot gnu.org 2012-07-03 11:58:16 UTC ---
Author: uros
Date: Tue Jul 3 11:58:12 2012
New Revision: 189218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189218
Log:
PR target/53811
* config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #6 from Yuri Gribov 2012-07-03
12:16:21 UTC ---
First of all note that we are talking about _ZN1C1fEv (not _ZN1C1gEv!) here.
I agree that linker doesn't mention it in the resolution file but I think this
happens because it's missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Richard Guenther changed:
What|Removed |Added
CC||rafael.espindola at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53820
--- Comment #4 from dave.anglin at bell dot net 2012-07-03 12:46:16 UTC ---
On 7/2/2012 11:20 AM, aoliva at gcc dot gnu.org wrote:
> This patchlet for var-tracking.c fixes the testcase. I'm now testing it on
> x86_64. John, would you be so kind a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #8 from Richard Guenther 2012-07-03
12:46:36 UTC ---
So I think GCC is wrong to optimize away C::f() from impl.cpp and your analysis
is correct. It is referenced from the vtable and we output that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #9 from Richard Guenther 2012-07-03
12:54:07 UTC ---
Or your program is invalid because you have no inline definition where you
have a use.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #10 from Yuri Gribov 2012-07-03
12:59:01 UTC ---
> if I use -fno-fat-lto-objects I get a maybe more easily to debug linker
> failure
I guess that's because in this case archive symtab doesn't reference any
symbols at all (which is a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707
--- Comment #16 from Andrew Pinski 2012-07-03
13:09:01 UTC ---
The code as written might be considered as undefined.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53812
--- Comment #3 from Jakub Jelinek 2012-07-03
13:09:22 UTC ---
Author: jakub
Date: Tue Jul 3 13:09:16 2012
New Revision: 189225
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189225
Log:
PR c++/53812
* semantics.c (finish_goto_stm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #11 from Richard Guenther 2012-07-03
13:11:59 UTC ---
(In reply to comment #10)
> > if I use -fno-fat-lto-objects I get a maybe more easily to debug linker
> > failure
>
> I guess that's because in this case archive symtab doesn't r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #12 from Richard Guenther 2012-07-03
13:17:12 UTC ---
Created attachment 27735
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27735
adjusted testcase
Certainly valid testcase w/o inline. Fails at -O0 even, added
-fno-fat-lto-ob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Richard Guenther changed:
What|Removed |Added
Known to work||4.6.3
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53839
Bug #: 53839
Summary: [4.7/4.8 Regresion] [C++11] internal compiler error:
in adjust_temp_type, at cp/semantics.c:6391
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #14 from Yuri Gribov 2012-07-03
13:31:28 UTC ---
> you need to use the LTO aware nm that gcc installs, gcc-nm. It says
My bad.
> Btw, removing the 'inline' keyword everywhere still reproduces the issue.
> That makes the testcase ce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #16 from Markus Trippelsdorf
2012-07-03 13:46:43 UTC ---
IOW with:
% cat =ar
#!/bin/sh
cmd=$1
shift
/usr/bin/ar $cmd --plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/liblto_plugin.so $*
I cannot reproduce the issue anymore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707
--- Comment #17 from Andreas Schwab 2012-07-03 14:05:06
UTC ---
When the call to find_stack_direction is inlined into itself there is no
requirement on how the two instances of here are allocated, so their addresses
have no defined relative order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
Richard Guenther changed:
What|Removed |Added
Attachment #27735|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #18 from Richard Guenther 2012-07-03
14:13:38 UTC ---
That leaves us with the testcase that eventually is invalid. The testcase
is fixed when using -fno-fat-lto-objects and gcc-ar (which is not required,
or should not be required(?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
--- Comment #3 from Jonathan Wakely 2012-07-03
14:48:38 UTC ---
Andrew, I'm not actually sure about that, see
https://trac.macports.org/ticket/22234
But in any case, it's a problem with MacPorts' GCC package not FSF's GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707
--- Comment #18 from Mikael Pettersson 2012-07-03
15:04:56 UTC ---
Right, I understood that the C test case invoked implementation-defined
behaviour, but inlining does invalidate any assumptions it might have made.
Attaching an "__attribute__((_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53840
Bug #: 53840
Summary: [C++11] DR 921. Rational Arithmetic should use
template aliases
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632
--- Comment #9 from Jonathan Wakely 2012-07-03
15:06:56 UTC ---
I don't know if anything was changed, but the speed seems OK now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #16 from Uros Bizjak 2012-07-03 15:57:34
UTC ---
Following patch fixes testcase failure for me, and also enables lto-bootstrap:
--cut here--
Index: ipa.c
===
--- ipa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53841
Bug #: 53841
Summary: [C++11] condition_variable::wait_until() fails with
high resolution clocks
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53841
--- Comment #1 from Jonathan Wakely 2012-07-03
16:05:50 UTC ---
Also, I don't think the _Clock template parameter for __wait_until_impl is
needed. That function is always passed a time_point<__clock_t, D> so _Clock is
always deduced as _Clock.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48879
eric changed:
What|Removed |Added
CC||aric999 at gmail dot com
--- Comment #7 from eric
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53841
--- Comment #2 from Jonathan Wakely 2012-07-03
16:15:38 UTC ---
(In reply to comment #1)
> Also, I don't think the _Clock template parameter for __wait_until_impl is
> needed. That function is always passed a time_point<__clock_t, D> so _Clock is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #8 from Jonathan Wakely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53840
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #19 from Yuri Gribov 2012-07-03
16:55:27 UTC ---
(In reply to comment #18)
> The testcase is fixed when using -fno-fat-lto-objects and gcc-ar
For me x64_64-linux version works if I use gcc-ar (both with and without
-fno-fat-lto-obje
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53837
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #15 from Martin Jambor 2012-07-03
17:43:35 UTC ---
Hi,
(In reply to comment #12)
> Hi,
> I discussed some of the issues today with Martin. For the array descriptor
> testcase, we really want ipa-cp to be propagate the constant array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53826
--- Comment #2 from Jason Merrill 2012-07-03
18:10:46 UTC ---
Author: jason
Date: Tue Jul 3 18:10:39 2012
New Revision: 189238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189238
Log:
PR c++/53826
* tree.c (build_zero_cst): Han
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #17 from Uros Bizjak 2012-07-03 18:17:09
UTC ---
Created attachment 27736
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27736
Patch that cures various "may be used uninitialized" errors during LTO
bootstrap
This patch is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53826
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
Uros Bizjak changed:
What|Removed |Added
Depends on||53321
--- Comment #19 from Uros Bizjak 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #20 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53842
Bug #: 53842
Summary: avr second write to volatile register gets dropped
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53840
--- Comment #2 from paolo at gcc dot gnu.org
2012-07-03 19:24:15 UTC ---
Author: paolo
Date: Tue Jul 3 19:24:07 2012
New Revision: 189239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189239
Log:
2012-07-03 Paolo Carlini
PR libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53840
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53843
Bug #: 53843
Summary: Macros following string literals don't expand in C++11
mode
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
Bug #: 53844
Summary: GCC generates suboptimal code for unused members of
classes in some cases on multiple targets.
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53843
--- Comment #1 from Joseph Garvin 2012-07-03
19:56:28 UTC ---
Forgot to mention inserting a space between "x" and bar fixes the error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
Edward Rosten changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53843
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845
Bug #: 53845
Summary: Another "error reporting routines re-entered" issue
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53843
--- Comment #3 from Joseph Garvin 2012-07-03
20:00:28 UTC ---
Sorry, I Googled for "C++11 preprocessor changes" and didn't find anything
discussing this. Do you have a link?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53843
--- Comment #4 from Andrew Pinski 2012-07-03
20:02:18 UTC ---
http://gcc.gnu.org/gcc-4.7/porting_to.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53843
--- Comment #5 from Jonathan Wakely 2012-07-03
20:07:11 UTC ---
and C.2.1 in the C++11 standard
and PR 50917 and PR 51282
and https://groups.google.com/forum/#!topic/comp.std.c++/9nD4Mb8pN1Q
(the second to last post quotes C.2.1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844
Andrew Pinski changed:
What|Removed |Added
Known to work||4.3.3
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846
Bug #: 53846
Summary: [c++11] memory exhaustion on simple recursive function
template that uses decltype
Classification: Unclassified
Product: gcc
Version: 4.7.0
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53821
--- Comment #7 from vincenzo Innocente
2012-07-03 20:39:50 UTC ---
I'm still wandering, more in general, if there is a semantic difference between
template
int Foo::bar(int i, int j) {
…
}
and
template
inline
int Foo::bar(int i, int j) {
…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53675
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53821
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #8
/gcc/4.7.0
--prefix=/afs/cern.ch/user/i/innocent/w3/gcc47slc5
--with-build-time-tools=/build/ge/new-binutils/a/slc5_amd64_gcc470/external/gcc/4.7.0-cms/bin
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.8.0 20120703 (experimental) [trunk revision 18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53821
Jason Merrill changed:
What|Removed |Added
CC|jason at redhat dot com |
--- Comment #9 from Jason Merrill 2012-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53847
vincenzo Innocente changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53814
--- Comment #1 from michaelh at gcc dot gnu.org 2012-07-03 23:29:07 UTC ---
Author: michaelh
Date: Tue Jul 3 23:29:03 2012
New Revision: 189242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189242
Log:
2012-07-03 Michael Hope
PR c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #7 from Larry Baker 2012-07-03 23:43:46 UTC
---
(In reply to comment #6)
> Fixed in 4.8.
Refer to bug 53834 (duplicate of this bug) for original report.
Changing -mcpu=5208 to -mcpu=68020 resolves only the -fstack-limit-reg= ICE
(co
-march=x86-64 -auxbase curl -version -o
/tmp/innocent/ccQfRfNv.s --output-pch= bho.gch
reading VI .tcshrc
tty
set noglob;
setenv COLUMNS '181';
setenv LINES '55';
unset noglob;
GNU C++ (GCC) version 4.8.0 20120703 (experimental) [trunk revision 189240]
(x86_64-unknown-linu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53832
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #8 from Larry Baker 2012-07-04 01:40:23 UTC
---
Andreas,
I posted my negative findings that -mcpu=68020 still causes the
-fstack-limit-symbol code path to fail. I believe the fundamental problem
there is the allocation of two differ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53849
Bug #: 53849
Summary: [4.8 Regression] ICE: in add_referenced_var_1, at
tree-dfa.c:567 with -O2 -ftree-parallelize-loops=2
-fno-tree-loop-im
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850
Bug #: 53850
Summary: [4.8 Regression] ICE: in expand_call_tm, at
trans-mem.c:2289 with -fgnu-tm -O3
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
94 matches
Mail list logo
