http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50084
--- Comment #2 from Jason Merrill 2011-08-30
21:27:39 UTC ---
Author: jason
Date: Tue Aug 30 21:27:36 2011
New Revision: 178340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178340
Log:
PR c++/50084
* cp-tree.h (cp_decl_specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50089
--- Comment #2 from Jason Merrill 2011-08-30
21:27:31 UTC ---
Author: jason
Date: Tue Aug 30 21:27:27 2011
New Revision: 178339
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178339
Log:
PR c++/50089
* semantics.c (finish_id_expre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114
--- Comment #6 from Jason Merrill 2011-08-30
21:27:23 UTC ---
Author: jason
Date: Tue Aug 30 21:27:18 2011
New Revision: 178338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178338
Log:
PR c++/50114
* decl.c (poplevel): Disable f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044
--- Comment #4 from Tobias Burnus 2011-08-30
21:33:18 UTC ---
I was thinking of using:
gfc_gsymbol *gsym;
gsym = gfc_get_gsymbol (com->name);
gcc_assert (gsym->type == GSYM_COMMON);
gfc_warning ("Named COM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50192
--- Comment #5 from Thomas Koenig 2011-08-30
21:36:53 UTC ---
Author: tkoenig
Date: Tue Aug 30 21:36:48 2011
New Revision: 178341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178341
Log:
2011-08-30 Thomas Koenig
Backport from tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50084
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50089
--- Comment #3 from Jason Merrill 2011-08-30
21:48:28 UTC ---
Author: jason
Date: Tue Aug 30 21:48:24 2011
New Revision: 178342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178342
Log:
PR c++/50089
* semantics.c (finish_id_expre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207
--- Comment #9 from Jason Merrill 2011-08-30
21:48:38 UTC ---
Author: jason
Date: Tue Aug 30 21:48:34 2011
New Revision: 178343
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178343
Log:
PR c++/50207
* class.c (finish_struct_1): C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50089
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #6 from Jason Merrill 2011-08-30
21:56:42 UTC ---
This will eventually be issue 1322,
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1322
but the issues list hasn't been updated yet. In Bloomington we assigned it
pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044
--- Comment #5 from Tobias Burnus 2011-08-30
22:09:55 UTC ---
Author: burnus
Date: Tue Aug 30 22:09:49 2011
New Revision: 178344
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178344
Log:
2011-08-30 Tobias Burnus
PR fortran/45
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244
Bug #: 50244
Summary: wcstold not available for C++0x
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244
--- Comment #2 from lcid-fire at gmx dot net 2011-08-30 23:13:07 UTC ---
Created attachment 25141
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25141
Filtered output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244
--- Comment #3 from lcid-fire at gmx dot net 2011-08-30 23:14:01 UTC ---
Created attachment 25142
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25142
Generated ii file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15606
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244
--- Comment #4 from Jonathan Wakely 2011-08-30
23:21:29 UTC ---
is that whole file really necessary?
what happens if you just #include ?
What's the simplest command that reproduces the error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15606
--- Comment #7 from Samuel Tardieu 2011-08-30 23:21:41
UTC ---
Je suis absent jusqu'au 5 septembre sans accès à mon courrier électronique.
I am on vacation until September 5 without email access.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #14 from Jonathan Schmidt-Dominé 2011-08-30
23:25:25 UTC ---
Created attachment 25143
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25143
bits/stl_vector.h patch
moved operator== and operator< inside class, because I want to ov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #15 from Jonathan Schmidt-Dominé 2011-08-30
23:30:00 UTC ---
Created attachment 25144
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25144
b
More efficient (non representative benchmark!) implementation of operator< and
operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #16 from Jonathan Schmidt-Dominé 2011-08-30
23:30:36 UTC ---
Added basic patch…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15611
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #17 from Jonathan Wakely 2011-08-30
23:34:42 UTC ---
(In reply to comment #14)
> moved operator== and operator< inside class, because I want to overload them
huh, why is that needed? it's not acceptable anyway, it needs to be a
non-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50241
--- Comment #2 from George R. Goffe 2011-08-30
23:36:49 UTC ---
Thank you for your time in looking over this bug report.
I am not building from within the source directory.
Here's the relevant part of my build script. Do you see something wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50241
--- Comment #3 from Andrew Pinski 2011-08-30
23:40:15 UTC ---
>I am not building from within the source directory.
Yes you are in the end with the lndir.
Try instead:
cd gcc
svn up
cd ..
rm -fr obj-i686-pc-linux-gnu
mkdir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15614
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #18 from Jonathan Schmidt-Dominé 2011-08-30
23:56:38 UTC ---
(In reply to comment #17)
> (In reply to comment #14)
> > moved operator== and operator< inside class, because I want to overload them
>
> huh, why is that needed? it's no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15615
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #19 from Paolo Carlini 2011-08-31
00:04:36 UTC ---
I'm wondering if processing an unsigned long at a time wouldn't be a step in
the right direction. Then, a compiler intrinsics would be the right place for
that, would naturally fit in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50245
Bug #: 50245
Summary: Compile of cross compiler for M68HC11 fails in libgcc,
"internal compiler error: Segmentation fault"
Classification: Unclassified
Product: gcc
Version: 4.5.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15798
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50245
--- Comment #1 from Don Reid 2011-08-31 00:11:58 UTC
---
Created attachment 25146
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25146
stderr from command with "-v -save-temps" added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50246
Bug #: 50246
Summary: SRA: Writes to class members are not combined
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15799
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #20 from Paolo Carlini 2011-08-31
00:26:49 UTC ---
Largely irrelevant here, but partial specialization of function templates
simply does not exist. We have been talking about adding an overload like:
template
bool
operator<(co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #21 from Jonathan Schmidt-Dominé 2011-08-31
00:30:58 UTC ---
It would indeed be nice to have such a builtin function (8, 16, 32, 64 bit
reversing), currently there is none in gcc, only bytewise reversing iirc.
Should that be put as wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #22 from Andrew Pinski 2011-08-31
00:33:52 UTC ---
Can't you do ~a < ~b ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #23 from Jonathan Schmidt-Dominé 2011-08-31
00:34:28 UTC ---
@Paolo
Okay, I am sometimes overcautious with function-templates, because I often had
a lot of errors because of partial specialisation when it was indeed necessary
(functi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #24 from Jonathan Schmidt-Dominé 2011-08-31
00:39:57 UTC ---
@Andrew
Nope:
1001 > 0001 (lexicographically)
1001 > 0001 (as little-endian)
0110 < 1110 (as little-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15800
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15840
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #25 from Paolo Carlini 2011-08-31
00:56:42 UTC ---
I think a separate Bugzilla requesting as an enhancement such intrinsics would
be certainly appropriate. I'm sure other code could exploit those.
Note, in the meanwhile we could as w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15843
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
--- Comment #5 from dave.anglin at bell dot net 2011-08-31 01:10:16 UTC ---
On 30-Aug-11, at 11:06 AM, bernds at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
>
> --- Comment #4 from Bernd Schmidt
> 2011-08-30 15:06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #11 from H.J. Lu 2011-08-31 04:21:53
UTC ---
(In reply to comment #10)
> On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:
>
> > The main issue is mixing input .ctors sections with .init_array sections
> > to generate the single
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239
eviom changed:
What|Removed |Added
Version|4.7.0 |4.5.2
--- Comment #2 from eviom 2011-08-31 05:42
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50236
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50235
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #21 from Jonathan Wakely 2011-08-30
09:12:23 UTC ---
Thanks, Marc! We can (and eventually should) fix anything in libstdc++ that
incorrectly relies on this bug. Gthreads might be a little harder, but we could
probably overload on langu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
--- Comment #2 from Paolo Carlini 2011-08-30
09:14:25 UTC ---
Good. 4_6-branch behaves the same. Do we agree that GCC is correct in rejecting
this (without ICE-ing of course)?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
--- Comment #3 from Daniel Krügler
2011-08-30 09:30:48 UTC ---
(In reply to comment #2)
> Good. 4_6-branch behaves the same. Do we agree that GCC is correct in
> rejecting
> this (without ICE-ing of course)?
I think that gcc is right rejecting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #22 from Marc Glisse 2011-08-30
09:32:24 UTC ---
(In reply to comment #21)
> I'll try your patch and see what, if anything, can be changed safely in
> libstdc++ right away.
Thanks :-)
Note that some things are painful to do right wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #2 from Daniel Krügler
2011-08-30 09:39:43 UTC ---
I believe I found a conforming usage of reinterpret_cast in constant
expressions useable in C++03:
//
struct X {
X* operator&();
};
X x[2];
const bool p = (reinter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
Paolo Carlini changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org
--- Comment #16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
--- Comment #5 from Daniel Krügler
2011-08-30 09:52:19 UTC ---
I just notice that the current exclusion of reinterpret_cast in constant
expressions would make it impossible to define addressof as a constexpr
function. C++11 currently invalidates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
Paolo Carlini changed:
What|Removed |Added
Summary|vector comparison |vector comparison
|very slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich changed:
What|Removed |Added
Attachment #25083|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #23 from Jonathan Wakely 2011-08-30
10:46:51 UTC ---
(In reply to comment #22)
> Note that some things are painful to do right with extern "C". For instance,
> the __stoa helper takes as argument a pointer to a function with a type tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
--- Comment #8 from Ilya Enkovich 2011-08-30
10:50:44 UTC ---
I attached a fixed reproducer. It is closer to the original test and has higher
registers pressure then the previous version. It has the same problem as the
first reproducer.
Reprodu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #24 from Jonathan Wakely 2011-08-30
10:49:27 UTC ---
(In reply to comment #23)
> I think you can do it with a alias-declaration in an extern "C" block:
But that might have only worked when I tested it because Clang++ doesn't
overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #25 from Marc Glisse 2011-08-30
11:28:48 UTC ---
(In reply to comment #23)
> I think you can do it with a alias-declaration in an extern "C" block:
>
> extern "C" {
> template
> using func_type = T (*)();
> }
>
> extern "C" voi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
--- Comment #2 from Bernd Schmidt 2011-08-30
11:31:34 UTC ---
Ugh, code prettyfication gone wrong. Will fix.
However, you'll probably also want to add "return" patterns to PA for
optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50163
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #26 from Jonathan Wakely 2011-08-30
12:17:47 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
>
> > We could solve it with an alternative syntax for language linkage
> > using attributes:
> >
> > void f( [[extern(C)]]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #27 from Jonathan Wakely 2011-08-30
12:19:23 UTC ---
this is DR13 btw
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13
I don't know if that's been reconsidered now we have attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231
Tobias Burnus changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #28 from Marc Glisse 2011-08-30
12:34:20 UTC ---
(In reply to comment #27)
> this is DR13 btw
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13
> I don't know if that's been reconsidered now we have attributes
Gah, I lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #22 from Christopher Yeleighton
2011-08-30 13:10:38 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > Please publish your result (just one page will do).
>
> I've deleted it now, you can see for yourself using the (ab
ls
--disable-libmudflap
Thread model: posix
gcc version 4.7.0 20110830 (experimental) [trunk revision 178287] (GCC)
A workaround would be to get rid of the __attribute__((constructor)) in lex.c
but someone should sit down and write a correct HAVE_INITFINI_ARRAY check.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45045
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044
Bug 45044 depends on bug 45045, which changed state.
Bug 45045 Summary: Named COMMON with different size: No warning with
-fwhole-file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45045
What|Old Value |New Value
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #23 from Jonathan Wakely 2011-08-30
13:25:17 UTC ---
Did you alter the Doxyfile as I described in Comment 20 here? Otherwise you're
not getting valid XHTML, and you're not getting the treeview that caused the
problem when I tested it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044
--- Comment #3 from Tobias Burnus 2011-08-30
13:26:23 UTC ---
Simple patch to print also a warning if a smaller named common block follows a
larger one.
TODO: Print the location of the other COMMON block. One can recover the line
number via DECL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #24 from Jonathan Wakely 2011-08-30
13:27:37 UTC ---
(In reply to comment #23)
> Did you alter the Doxyfile as I described in Comment 20 here?
Comment 18, rather
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50185
--- Comment #6 from hjl at gcc dot gnu.org 2011-08-30
13:28:26 UTC ---
Author: hjl
Date: Tue Aug 30 13:28:21 2011
New Revision: 178302
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178302
Log:
Rename avx2-vmovmskb-2.c to avx2-vpmovmskb-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
Richard Guenther changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org
Target Milest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
H.J. Lu changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #2 from Eric Botcazou 2011-08-30
13:50:28 UTC ---
> HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> independent of compiler.
AFAICS it doesn't, it compiles everything with the host compiler, which will
use in p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #25 from Christopher Yeleighton
2011-08-30 13:51:39 UTC ---
Well, the original documentation now shows up in Konqueror after a little
delay, so the original failure might have been due do a network problem (e.g. a
failed script downlo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #3 from H.J. Lu 2011-08-30 13:57:46
UTC ---
(In reply to comment #2)
> > HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> > independent of compiler.
>
> AFAICS it doesn't, it compiles everything with the host co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571
--- Comment #5 from Richard Guenther 2011-08-30
14:06:07 UTC ---
Author: rguenth
Date: Tue Aug 30 14:06:00 2011
New Revision: 178312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178312
Log:
2011-08-30 Richard Guenther
PR middle-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571
Richard Guenther changed:
What|Removed |Added
Known to work||4.7.0
Summary|[4.5/4.6/4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #4 from Richard Guenther 2011-08-30
14:09:08 UTC ---
Only stage2/3 binutils need to be the same and those are relevant for
feature tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #5 from H.J. Lu 2011-08-30 14:23:05
UTC ---
(In reply to comment #4)
> Only stage2/3 binutils need to be the same and those are relevant for
> feature tests.
How does stage 2 binutils fail the test?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
--- Comment #3 from dave.anglin at bell dot net 2011-08-30 14:29:10 UTC ---
On 8/30/2011 7:31 AM, bernds at gcc dot gnu.org wrote:
> However, you'll probably also want to add "return" patterns to PA for
> optimization.
>
I don't think the condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49328
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|fort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050
Tobias Burnus changed:
What|Removed |Added
Summary|[4.6/4.7 Regression]|Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #6 from Eric Botcazou 2011-08-30
15:00:54 UTC ---
> How does stage 2 binutils fail the test?
It doesn't. Let me explain:
- during stage1, the check is made with the host compiler, i.e. the base
compiler, so the old binutils are u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232
--- Comment #4 from Bernd Schmidt 2011-08-30
15:06:05 UTC ---
Surely the PA has some kind of return instruction?
Most ports define a "return" pattern with an insn condition that requires that
the epilogue is empty. In that case, jumps to the end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220
--- Comment #1 from Jason Merrill 2011-08-30
15:28:44 UTC ---
Author: jason
Date: Tue Aug 30 15:28:40 2011
New Revision: 178326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178326
Log:
PR c++/50220
* semantics.c (add_capture): C
1 - 100 of 140 matches
Mail list logo
