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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234
--- Comment #1 from Jason Merrill 2011-08-30
15:28:35 UTC ---
Author: jason
Date: Tue Aug 30 15:28:30 2011
New Revision: 178325
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178325
Log:
PR c++/50234
* semantics.c (cxx_eval_compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220
--- Comment #2 from Jason Merrill 2011-08-30
15:29:09 UTC ---
Author: jason
Date: Tue Aug 30 15:29:04 2011
New Revision: 178328
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178328
Log:
PR c++/50220
* semantics.c (add_capture): C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234
--- Comment #2 from Jason Merrill 2011-08-30
15:28:57 UTC ---
Author: jason
Date: Tue Aug 30 15:28:55 2011
New Revision: 178327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178327
Log:
PR c++/50234
* semantics.c (cxx_eval_compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #29 from kargl at gcc dot gnu.org 2011-08-30 15:34:06 UTC ---
Author: kargl
Date: Tue Aug 30 15:34:01 2011
New Revision: 178329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178329
Log:
2011-08-30 Steven G. Kargl
PR for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238
Bug #: 50238
Summary: configure: error: GNU Fortran is not working
Classification: Unclassified
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #7 from joseph at codesourcery dot com 2011-08-30 15:40:49 UTC ---
On Tue, 30 Aug 2011, ebotcazou at gcc dot gnu.org wrote:
> The fix is to turn the check into a target check, i.e. test the target
> binutils.
> See configure.ac:1884 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #8 from H.J. Lu 2011-08-30 15:55:51
UTC ---
The main issue is mixing input .ctors sections with .init_array sections
to generate the single output .init_array section. Not all linkers support
it even if they support .init_array secti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #9 from H.J. Lu 2011-08-30 15:56:45
UTC ---
In the meantime, you can use --enable-initfini-array/--disable-initfini-array
to work around this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239
Bug #: 50239
Summary: compiled program segfault when -O0 is used to compile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #10 from joseph at codesourcery dot com 2011-08-30 16:39:39 UTC ---
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 output .ini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238
--- Comment #2 from Silvio Filipe
2011-08-30 16:49:27 UTC ---
Created attachment 25139
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25139
x86_64-unknown-linux-gnu/libgfortran/config.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238
--- Comment #3 from Silvio Filipe
2011-08-30 16:56:57 UTC ---
(In reply to comment #1)
> Most of the time it indicates that your MPFR or GMP libary is wrongly
> installed, which is not a GCC problem.
When I installed the GMP and MPFR has not gi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50240
Bug #: 50240
Summary: [4.7 Regression] ERROR: (DejaGnu) proc "^s" does not
exist
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238
--- Comment #5 from Tobias Burnus 2011-08-30
17:08:14 UTC ---
(In reply to comment #3)
> ./configure --prefix=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local
I want to add to the comments of Jakub that building GCC in-tree is not
support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227
--- Comment #12 from janus at gcc dot gnu.org 2011-08-30 17:09:22 UTC ---
(In reply to comment #11)
> And indeed it seems to fix the segfault.
... and regtests cleanly.
Unfortunately, there is one more complication: When compiling the two files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227
--- Comment #13 from Dominique d'Humieres
2011-08-30 17:24:31 UTC ---
> gfortran-4.7 -c module.f90
> gfortran-4.7 program.f90
What about
gfortran-4.7 program.f90 module.o?
AFAIK there is not "object" in the *.mod files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50240
H.J. Lu changed:
What|Removed |Added
CC||tocarip.intel at gmail dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18762
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50240
Uros Bizjak changed:
What|Removed |Added
Target||x86
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40185
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50241
Andrew Pinski changed:
What|Removed |Added
Component|classpath |libgcj
Version|unspecified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #30 from Damian Rouson 2011-08-30
18:46:42 UTC ---
Just out curiosity, what's the reason for the "real::rnd" line in the
helloworld testcase? I don't see "rnd" used anywhere.
Damian
On Tue, Aug 30, 2011 at 8:34 AM, kargl at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #25134|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #31 from Steve Kargl
2011-08-30 19:31:25 UTC ---
On Tue, Aug 30, 2011 at 06:46:42PM +, damian at rouson dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
>
> --- Comment #30 from Damian Rouson 2011-08-30
> 18:4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #8 from William J. Schmidt 2011-08-30
19:33:42 UTC ---
I built a cross-compiler on gcc10.fsffrance.org that exhibits the problem:
$ cd /home/wschmidt/src/416.gamess
$ /home/wschmidt/gcc/build/gcc-mainline-base/gcc/f951 chgpen.fppized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50089
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242
Bug #: 50242
Summary: __attribute__((naked)) is ignored on IA32 (x86)
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #12 from M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #30 from Marc Glisse 2011-08-30
20:32:57 UTC ---
(In reply to comment #29)
> New version that works with typedefs (I was forgetting extern "C" in the
> canonical type...). The patch also includes a workaround for __stoa. There
> seems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242
Andrew Pinski changed:
What|Removed |Added
Component|c++ |target
--- Comment #1 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234
--- Comment #4 from Benjamin Kosnik 2011-08-30
20:48:22 UTC ---
HA! You rule, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50243
Bug #: 50243
Summary: vtable for pure abstract class (interface) shouldn't
be emitted
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50243
--- Comment #1 from Andrew Pinski 2011-08-30
20:54:34 UTC ---
The vtable is required by the ABI IIRC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #5 from William J. Schmidt 2011-08-30
21:07:03 UTC ---
Here's the relevant gimple following 103t.copyprop5:
==
:
err2 = 0.0;
err2_lsm.820_567 = err2;
:
#
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
1 - 100 of 140 matches
Mail list logo
