--- Comment #2 from skalyan_g at yahoo dot co dot in 2010-03-30 06:01
---
(In reply to comment #1)
First off your find will only find files named exactly strstream.
And second strstream.h never existed and is not part of the C++ standard
(strstream is not either).
You should use
--- Comment #3 from skalyan_g at yahoo dot co dot in 2010-03-30 06:07
---
I belive the backward compactibilty should be exits.Also i think the old style
library's is with .h extension(strstream.h,iostream.h) and new style is
without .h extension(strstream,iostream)
I am trying
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-30 07:48 ---
Well fix the code. This code is no where near standards complaint and we are
not going to keep around this extension just for one or two people.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from fabien dot chene at gmail dot com 2010-03-30 08:22
---
is it still invalid in c++0X ?
5.3.4.15 has been revamped, and I no longer find a motif to reject such code.
I think the following code is also invalid, according to 8.5.6 (c++03) / 8.5.8
(c++0x):
struct A {
--- Comment #3 from redi at gcc dot gnu dot org 2010-03-30 09:16 ---
(In reply to comment #2)
is it still invalid in c++0X ?
Yes.
5.3.4.15 has been revamped, and I no longer find a motif to reject such code.
In C++0x the object is default-initialized, which for a class type means
--- Comment #3 from jiez at gcc dot gnu dot org 2010-03-30 09:20 ---
The patch:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01395.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43574
--- Comment #3 from mikpe at it dot uu dot se 2010-03-30 09:38 ---
Building gcc-4.5-20100325 as a cross to arm-unknown-eabi works and compiles
__mulsc3 for all three of thumb, arm, and arm + float-abi=hard. But a cross to
arm-unknown-elf fails to build because of an ICE when compiling
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-30 09:39 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-30 09:46 ---
Works for me as well. Building GCC with --as-needed is known to at least
break libjava big times (you can see that when testing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
--- Comment #24 from LpSolit at netscape dot net 2010-03-30 09:54 ---
We are very close from releasing Bugzilla 3.6:
https://bugzilla.mozilla.org/show_bug.cgi?id=554523
The plan is to release it next week. So you may as well upgrade to 3.6
directly. Note that I'm on vacation this week
--- Comment #4 from fabien dot chene at gmail dot com 2010-03-30 10:07
---
(In reply to comment #3)
(In reply to comment #2)
is it still invalid in c++0X ?
Yes.
5.3.4.15 has been revamped, and I no longer find a motif to reject such
code.
In C++0x the object is
--- Comment #5 from fabien dot chene at gmail dot com 2010-03-30 10:10
---
Nevertheless, can you confirm that it is valid C++03 ?
I mean invalid, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
--- Comment #6 from redi at gcc dot gnu dot org 2010-03-30 11:19 ---
(In reply to comment #5)
Nevertheless, can you confirm that it is valid C++03 ?
I mean invalid, sorry.
Yup :-)
It is invalid. A is a non-POD class type, so 5.3.4/15 says the new-expression
without a
--- Comment #5 from fabien dot chene at gmail dot com 2010-03-30 11:40
---
I'm working on this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-30 11:44 ---
Subject: Re: const variable requires initializer / no
explicitly declared default constructor
I'm working on this bug
Could you please assign it to yourself then?
Thanks.
--
--- Comment #7 from fabien dot chene at gmail dot com 2010-03-30 11:51
---
(In reply to comment #6)
Subject: Re: const variable requires initializer / no
explicitly declared default constructor
I'm working on this bug
Could you please assign it to yourself then?
Thanks.
I
--- Comment #8 from redi at gcc dot gnu dot org 2010-03-30 11:56 ---
you should have the option Accept bug below the comment box. I've done it
for you
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-03-30 12:35 ---
Subject: Bug 25232
Author: jsm28
Date: Tue Mar 30 12:35:08 2010
New Revision: 157819
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157819
Log:
PR other/25232
* libgcc-std.ver (GCC_4.5.0):
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-03-30 12:36 ---
Fixed for 4.5.0.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-30 13:09
---
Subject: Bug 43553
Author: rguenth
Date: Tue Mar 30 13:08:52 2010
New Revision: 157821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157821
Log:
2010-03-30 Jack Howarth howa...@bromo.med.uc.edu
--- Comment #28 from mikpe at it dot uu dot se 2010-03-30 13:21 ---
I've looked at the amount of .ARM.exidx entry merging being done and its
consequences for the various unwinders in gcc. Currently only table entries
with immediate (inlined) data are merged, and for that all of gcc
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-30 13:46 ---
Not primary or secondary target.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-30 13:47 ---
Still unconfirmed, leaving at P3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43559
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-30 13:55 ---
CCing ARM maintainer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
--- Comment #29 from pbrook at gcc dot gnu dot org 2010-03-30 14:04 ---
Wouldn't it be better to just remove _Unwind_GetRegionStart?
This function is not part of the ARM EABI, and removing it would expose any
(already broken) users at compile time.
--
--- Comment #22 from dodji at gcc dot gnu dot org 2010-03-30 14:06 ---
I'll be looking into this.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from corsepiu at gcc dot gnu dot org 2010-03-30 14:11
---
(In reply to comment #5)
Not primary or secondary target.
Well, then redefine your priorities - AFAICT, this bug affects cross building
gcc for all targets - This isn't a regression, this is a show stopper!
--
--- Comment #9 from fabien dot chene at gmail dot com 2010-03-30 14:11
---
(In reply to comment #8)
you should have the option Accept bug below the comment box.
I've done it for you
I've just seen it since you did it for me (thanks), but I still can't do it by
myself for other
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-30 14:21 ---
It doesn't warn for me. Please provide -v output of the command that warns
for team.i or parallel.i.
tmp /abuild/rguenther/trunk-g/gcc/cc1 -quiet -o /dev/null -Wall -O2 parallel.i
-m32 -g -march=i486
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-30 14:35 ---
I only see -I../libdecnumber, not libcpp. And that's a host include dir
which looks ok as we are building h8300.o, an object for the host.
In fact what looks broken is
-isystem
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-30 14:36
---
Doesn't this belong in the linker as a relaxation? This would solve the reloc
problem in the process.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
--- Comment #5 from mikpe at it dot uu dot se 2010-03-30 14:42 ---
It's caused or exposed by r157476:
2010-03-16 Jakub Jelinek ja...@redhat.com
PR debug/43051
PR debug/43092
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
--- Comment #6 from mikpe at it dot uu dot se 2010-03-30 14:48 ---
(In reply to comment #5)
It's caused or exposed by r157476:
2010-03-16 Jakub Jelinek ja...@redhat.com
PR debug/43051
PR debug/43092
Actually this caused a different ICE earlier in libgcc2.c
--- Comment #30 from mikpe at it dot uu dot se 2010-03-30 15:09 ---
(In reply to comment #29)
Wouldn't it be better to just remove _Unwind_GetRegionStart?
This function is not part of the ARM EABI, and removing it would expose any
(already broken) users at compile time.
No.
First
--- Comment #9 from tkoenig at gcc dot gnu dot org 2010-03-30 15:10 ---
Created an attachment (id=20257)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20257action=view)
Output obtained from adding '-v to the 32/libgomp Makefile
Here's the output of make, just after having added -v
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-30 15:16
---
Err,
cc1: error: unrecognized command line option -fsave-temps
but - still works for me. How did you configure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-30 15:32 ---
Looks like an arm backend bug:
(insn/f 624 6 625 2 /users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c:1827
(set (mem:XF (pre_dec:XF (reg/f:SI 13 sp)) [0 S12 A32])
(reg:XF 23 f7)) 390 {*movxf_fpa}
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-30 15:34 ---
Created an attachment (id=20258)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20258action=view)
gcc45-pr43580.patch
Untested fix. Can somebody please test it?
--
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-30 15:47 ---
Created an attachment (id=20259)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20259action=view)
gcc45-pr43557.patch
This is a --combine mode bug, the type definitely shouldn't be incomplete just
because it has
: (reconfigured)
../trunk/configure --prefix=/home/ig25 --enable-languages=all,ada
--with-mpc=/usr/local
Thread model: posix
gcc version 4.5.0 20100330 (experimental) (GCC
--- Comment #12 from tkoenig at gcc dot gnu dot org 2010-03-30 15:54
---
Please forget the second half of my previous comment
(I copied / pasted the wrong part). Here's the actual
output, probably not very useful:
i...@linux-fd1f:~/Gcc/trunk-bin gcc/cc1 -quiet -o /dev/null -O2 -Wall
-model=initial-exec'
'-mtune=i686' '-Werror' '-v'
/abuild/rguenther/trunk-g/gcc/cc1 -fpreprocessed team.i -quiet -dumpbase
team.i -m32 -march=i486 -mtune=i686 -auxbase-strip /dev/null -g -O2 -Wall
-Werror -version -ftls-model=initial-exec -o /dev/null
GNU C (GCC) version 4.5.0 20100330 (experimental
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-03-30 16:01
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mikpe at it dot uu dot se 2010-03-30 16:04 ---
(In reply to comment #8)
Created an attachment (id=20258)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20258action=view) [edit]
gcc45-pr43580.patch
Untested fix. Can somebody please test it?
Worked for me.
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-03-30 16:09
---
(In reply to comment #7)
At least please say how you configured gcc.
We build one-tree-style build with newlib symlinked into gcc's sourcetree.
Configuration from a sparc-rtems4.11-gcc:
#
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-30 16:13 ---
I can't reproduce this iether.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
--- Comment #9 from joel at gcc dot gnu dot org 2010-03-30 16:22 ---
Maybe I am misreading the command invoked in Ralf's original report but it is
using xgcc which is the cross gcc:
make[5]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/gcc'
--- Comment #10 from joel at gcc dot gnu dot org 2010-03-30 16:29 ---
I encountered this issue while doing builds to run gcc tests. Newlib is
symlinked into gcc. binutils was built and installed separately. My configure
command is pretty simple.
--- Comment #9 from rwild at gcc dot gnu dot org 2010-03-30 16:39 ---
(In reply to comment #2)
Works when linking in comm.o main.o order.
FWIW one can construct test cases where neither order works, e.g.,
cat main.c \EOF
extern int i;
int j;
int main(void)
{
i = 0;
return i;
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-30 16:46 ---
Yes, this is a bug. The call to same_type_p in more_specialized_fn is wrong
because the two template parms have different indices.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from fabien dot chene at gmail dot com 2010-03-30 16:47
---
reduced testcase for this one:
struct A {};
void f()
{
A const a;
}
I misspoke, let's keep the original testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
--- Comment #6 from dominiq at lps dot ens dot fr 2010-03-30 16:48 ---
I do not get any ICE with the different 4.5 versions I have tried (oldest is
r156618). Could someone check that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
--- Comment #11 from corsepiu at gcc dot gnu dot org 2010-03-30 16:50
---
(In reply to comment #9)
Maybe I am misreading the command invoked in Ralf's original report but it is
using xgcc which is the cross gcc:
No, you haven't - It's likely a better analysis of the same issue
I
--- Comment #14 from spop at gcc dot gnu dot org 2010-03-30 16:57 ---
Subject: Bug 43464
Author: spop
Date: Tue Mar 30 16:56:49 2010
New Revision: 157828
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157828
Log:
Fix PR43464: copyprop should maintain loop close phi nodes with
--- Comment #12 from joel at gcc dot gnu dot org 2010-03-30 16:58 ---
Created an attachment (id=20260)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20260action=view)
generated gcc/Makefile
This is the gcc/Makefile generated for my h8300-rtems4.10 build. h8300.o is
supposed to go
--- Comment #3 from rwild at gcc dot gnu dot org 2010-03-30 16:58 ---
Bug also happens with
$ g++ -v
Using built-in specs.
COLLECT_GCC=/opt/bin/g++
COLLECT_LTO_WRAPPER=/opt/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
--- Comment #10 from ghazi at gcc dot gnu dot org 2010-03-30 17:11 ---
Still happens on 4.5 trunk.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #7 from burnus at gcc dot gnu dot org 2010-03-30 17:12 ---
Hmm, currently, I cannot reproduce it - not even with valgrind; I tried:
gfortran 4.1, 4.2, 4.3, 4.4, 4.5 - and various older trunk versions
(2008-12-18, 2008-12-05,2009-01-05, 2009-02-05, 2009-05-05, 2009-08-05) -
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-30 17:13 ---
... . I guess that we could tag every line for errors but this would need a
bigger change to error.c than I am prepared to embark on.
I understand that! Although there is no emergency to clean up the error
--- Comment #19 from ghazi at gcc dot gnu dot org 2010-03-30 17:16 ---
gcc.dg/pr30957-1.c still XFAILs on x86_64-unknown-linux-gnu
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ghazi at gcc dot gnu dot org 2010-03-30 17:17 ---
Reconfirm
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Last
/ --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20100330 (experimental) (GCC)
ward.f90:79:0: internal compiler error: in gfc_traverse_expr, at
fortran/expr.c:3604
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html
--- Comment #1 from ohl at physik dot uni-wuerzburg dot de 2010-03-30
17:21 ---
Created an attachment (id=20261)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20261action=view)
program that triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
--- Comment #20 from ghazi at gcc dot gnu dot org 2010-03-30 17:22 ---
Still have gcc.dg/pr34668-1.c failing on mainline (with checking enabled).
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dominiq at lps dot ens dot fr 2010-03-30 17:24 ---
I get the ICE with 4.4.2 (intel/ppc), 4.3.4, and 4.2.4 (ppc), but not on
trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
--- Comment #16 from ghazi at gcc dot gnu dot org 2010-03-30 17:25 ---
PASSes on 4.5 trunk, but still XFAILs on 4.4 branch. Since it's a 4.4
regression, should the patch be backported to 4.4 ?
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from tkoenig at gcc dot gnu dot org 2010-03-30 17:30
---
This was caused by a local modification on my tree.
Sorry for the noise :-(
Closing as invalid.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2010-03-30 17:58 ---
confirmed.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-30 18:29 ---
Reduced test:
module ward_lib
implicit none
type omega_procedures
procedure(number_particles_out), nopass, pointer :: number_particles_out
= NULL()
procedure(number_flavor_states), nopass, pointer ::
cat small.f90
interface assignment (=)
interface pseudo_scalar
pure function double_tensor2odd (x, t2) result (xt2)
gfortran small.f90
small.f90:2.25:
interface pseudo_scalar
1
Error: Unexpected INTERFACE statement in INTERFACE block at (1)
f951: internal
--- Comment #5 from jason at gcc dot gnu dot org 2010-03-30 19:40 ---
Subject: Bug 43559
Author: jason
Date: Tue Mar 30 19:39:48 2010
New Revision: 157831
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157831
Log:
PR c++/43559
* pt.c (more_specialized_fn): Don't
--- Comment #6 from jason at gcc dot gnu dot org 2010-03-30 19:47 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-30 19:55 ---
Further reduced test that does not give an ICE, but several errors:
[macbook] f90/bug% cat pr43591_red_1.f90
module ward_lib
implicit none
type omega_procedures
procedure(number_particles_out), nopass,
--- Comment #6 from spop at gcc dot gnu dot org 2010-03-30 19:58 ---
Subject: Bug 43430
Author: spop
Date: Tue Mar 30 19:58:35 2010
New Revision: 157833
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157833
Log:
Replace type != type comparisons with types_compatible_p.
Flushing e.g. sp on each call is completely unnecessary:
for (r = 0; r FIRST_PSEUDO_REGISTER; r++)
-if (TEST_HARD_REG_BIT (call_used_reg_set, r))
+if (TEST_HARD_REG_BIT (regs_invalidated_by_call, r))
var_regno_delete (set, r);
--
Summary: Var-tracking unnecessarily
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-30 20:00 ---
Confirmed:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001000674c8 in parse_spec (st=ST_INTERFACE) at
--- Comment #10 from ramana at gcc dot gnu dot org 2010-03-30 20:09 ---
This would be arm-elf only because arm-eabi configurations don't touch the FPA
which is why this didn't show up earlier. My last trawl of this looked for
PRE_DEC and BLKmode - didn't expect an XFmode for this.
--
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-30 20:17 ---
Subject: Bug 43593
Author: jakub
Date: Tue Mar 30 20:16:52 2010
New Revision: 157834
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157834
Log:
PR debug/43593
* var-tracking.c
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-30 20:18 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-30 20:29 ---
So this cannot be a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-30 21:01 ---
Subject: Bug 42977
Author: jakub
Date: Tue Mar 30 21:00:47 2010
New Revision: 157837
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157837
Log:
PR debug/42977
* cselib.c (n_useless_values):
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-30 21:01 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-30 21:19 ---
Subject: Bug 41786
Author: jason
Date: Tue Mar 30 21:19:23 2010
New Revision: 157838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157838
Log:
PR c++/41185
PR c++/41786
* parser.c
--- Comment #9 from jason at gcc dot gnu dot org 2010-03-30 21:19 ---
Subject: Bug 41185
Author: jason
Date: Tue Mar 30 21:19:23 2010
New Revision: 157838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157838
Log:
PR c++/41185
PR c++/41786
* parser.c
--- Comment #5 from jason at gcc dot gnu dot org 2010-03-30 21:21 ---
Subject: Bug 41786
Author: jason
Date: Tue Mar 30 21:20:58 2010
New Revision: 157839
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157839
Log:
PR c++/41185
PR c++/41786
* parser.c
--- Comment #10 from jason at gcc dot gnu dot org 2010-03-30 21:21 ---
Subject: Bug 41185
Author: jason
Date: Tue Mar 30 21:20:58 2010
New Revision: 157839
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157839
Log:
PR c++/41185
PR c++/41786
* parser.c
--- Comment #6 from jason at gcc dot gnu dot org 2010-03-30 21:22 ---
Fixed for 4.4.4 and 4.5.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jason at gcc dot gnu dot org 2010-03-30 21:23 ---
Fixed for 4.4.4 and 4.5.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from manuel dot montezelo at gmail dot com 2010-03-30 22:30
---
For the record, the last build worked fine (same upstream package, same gcc
version):
https://buildd.debian.org/fetch.cgi?pkg=openscenegraph;ver=2.8.2-2;arch=mips;stamp=1265665688
--
--- Comment #3 from jason at gcc dot gnu dot org 2010-03-30 22:34 ---
Subject: Bug 43076
Author: jason
Date: Tue Mar 30 22:34:02 2010
New Revision: 157842
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157842
Log:
PR c++/43076
* pt.c (push_template_decl_real):
--- Comment #11 from joel at gcc dot gnu dot org 2010-03-30 23:05 ---
Patch worked for me targeting arm-rtems4.10 on the same gcc checkout.
Please apply it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
--- Comment #25 from dberlin at gcc dot gnu dot org 2010-03-30 23:18
---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
Note: I have no urge or time to upgrade gcc's bugzilla anymore.
If ya'll want to work on it, i'm happy to give you all the info i have
and get you shell
--- Comment #4 from wilson at gcc dot gnu dot org 2010-03-30 23:58 ---
I've confirmed that Vlad's -fsched-pressure patch is the problem, and done a
bit more analysis to see why.
The testcase has approximately 20,000 movdi_internal insns, 6000 movsi_internal
insns, and 10,000
//#include cstdio
struct values
{
static const int one = 1;
};
struct counter
{
int n;
counter() : n(0) {}
counter
operator,(int const) { n++; return *this; }
};
int
main()
{
values vals;
counter cntr;
cntr, vals.one;
//std::printf(%d\n, cntr.n);
return 0;
}
g++
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-31 00:14 ---
Not a bug, see PR 42101.
*** This bug has been marked as a duplicate of 42101 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-31 00:14
---
*** Bug 43594 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jiez at gcc dot gnu dot org 2010-03-31 01:46 ---
A new patch:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01440.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43574
1 - 100 of 114 matches
Mail list logo
