--- 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 #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
ble-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspac
Thread model: posix
gcc version 4.5.0 20100329 (experimental) [trunk revision 157802] (GCC)
$ ./xgcc -B. ~/ice2.i -O3 -mfpu=neon -mfloat-abi=softfp -c
/home/ryan/ice2.i: In function 'test':
/home/ryan/ice2.i:22:1: err
--- Comment #7 from jiez at gcc dot gnu dot org 2010-03-30 04:06 ---
A new patch is here:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01375.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
--- Comment #1 from ictlpeng at gmail dot com 2010-03-30 04:03 ---
Created an attachment (id=20256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20256&action=view)
Test case susan.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43589
A segmentation fault(ipa-cp.c ipcp_lattice_changed (old_lat=0x7bf46080,
new_lat=0x0)) comes up if we:
declare function Mibench > automotive_susan_e > susan.c:susan_edges() with
__attribute__((optimize(3)))
declare function Mibench > automotive_susan_e > susan.c:susan_edges_small()
with __attr
--- Comment #33 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:57
---
Closing one more time. Fixed on trunk and 4.4
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jiez at gcc dot gnu dot org 2010-03-30 03:56 ---
I'm testing a patch.
--
jiez at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:56
---
Subject: Bug 43265
Author: jvdelisle
Date: Tue Mar 30 03:56:08 2010
New Revision: 157813
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157813
Log:
2010-03-29 Jerry DeLisle
PR libfortran/4326
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:54
---
Subject: Bug 43265
Author: jvdelisle
Date: Tue Mar 30 03:54:36 2010
New Revision: 157812
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157812
Log:
2010-03-29 Jerry DeLisle
PR libfortran/4326
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:25
---
Subject: Bug 43265
Author: jvdelisle
Date: Tue Mar 30 03:25:04 2010
New Revision: 157811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157811
Log:
2010-03-29 Jerry DeLisle
PR libfortran/4326
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:22
---
Subject: Bug 43265
Author: jvdelisle
Date: Tue Mar 30 03:22:28 2010
New Revision: 157810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157810
Log:
2010-03-29 Jerry DeLisle
PR libfortran/4326
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-03-30 03:22
---
> ... and the m32l-rtems* ...
Typo, this should have been "... m32r-rtems*... "
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-03-30 03:09
---
AFAICT, this bug affects all *-rtems* targets, if not _all_ targets, i.e.
building target files uses host includes during bootstrap.
But for some reasons I don't (yet) know, it only causes a breakdown for
building
--- Comment #10 from jiez at gcc dot gnu dot org 2010-03-30 02:41 ---
(In reply to comment #9)
> (In reply to comment #4)
> > bug2-susan.i does not crash ICE on GCC SVN trunk now.
> >
>
> Do you mean bug2-susan.i does not exist on GCC 4.5?
>
I don't see it on latest GCC 4.5.
--
h
--- Comment #9 from ictlpeng at gmail dot com 2010-03-30 02:14 ---
(In reply to comment #4)
> bug2-susan.i does not crash ICE on GCC SVN trunk now.
>
Do you mean bug2-susan.i does not exist on GCC 4.5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41150
--- Comment #8 from ictlpeng at gmail dot com 2010-03-30 02:09 ---
(In reply to comment #7)
> bug2-susan.i still exists on gcc 4.4 branch head. So reopen it.
>
Yes, It was true that bug1-susan.i was a duplicate of PR 43562, we used the
same way like you suggestion 1 to fix it temporari
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-30 00:14 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from danglin at gcc dot gnu dot org 2010-03-29 23:51 ---
Subject: Bug 43458
Author: danglin
Date: Mon Mar 29 23:51:05 2010
New Revision: 157806
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157806
Log:
PR target/43458
* testsuite/26_numerics/heade
rsion 4.5.0 20100329 (experimental) [trunk revision 157802] (GCC)
$ cat ~/ice.i
typedef unsigned int _GCC_ATTR_ALIGN_u16t __attribute__((__mode__(__HI__)));
typedef _GCC_ATTR_ALIGN_u16t _Uint16t __attribute__((__aligned__(8)));
typedef _Uint16t uint16_t;
typedef __builtin_neon_uhi uint16x4_t __attrib
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-29 22:17 ---
I just was about to bootstrap with [trunk revision 157804].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-03-29 22:06 ---
Created an attachment (id=20255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20255&action=view)
Preprocessed source where the problem occurs for the first time
team.c also shows the problem, this is just the
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-03-29 22:01 ---
Created an attachment (id=20254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20254&action=view)
Preprocessed source
This is from
~/Gcc/trunk-bin/x86_64-unknown-linux-gnu/32/libgomp
the 32 bit subdirectory
--- Comment #25 from eric dot cabret at gmail dot com 2010-03-29 21:48
---
I've reported this problem to Ubuntu at this following URL :
https://bugs.launchpad.net/ubuntu/+bug/551245
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
--- Comment #1 from jason at gcc dot gnu dot org 2010-03-29 20:57 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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 #8 from pinskia at gcc dot gnu dot org 2010-03-29 20:53 ---
Yes we are inconsistent with how foundational types work with argument
dependent namelookup but it is still the same issue.
*** This bug has been marked as a duplicate of 29131 ***
--
pinskia at gcc dot gnu dot
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-29 20:53
---
*** Bug 43506 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131
--- Comment #24 from eric dot cabret at gmail dot com 2010-03-29 20:44
---
I checked on my Ubuntu 64bit Lucid Lynx system that generates bad binary :
1) binutils (2.20.1-3ubuntu1) is installed
2) binutils-gold (2.20-0ubuntu2) is NOT installed
(In reply to comment #23)
> only seen with
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 20:43 ---
This works for me with:
gcc version 4.5.0 20100326 (experimental) [trunk revision 157759] (GCC)
GNU ld (GNU Binutils for Debian) 2.18.0.20080103
GNU C Library stable release version 2.7, by Roland McGrath et al.
I
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-29 20:34 ---
__sync_fetch_and_add (&gomp_remaining_threads_count,
1UL - team->nthreads);
This should not cause a warning to happen.
Can you provide the preprocessed source?
This works
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-29 20:27 ---
*** Bug 43584 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-29 20:27 ---
*** This bug has been marked as a duplicate of 43531 ***
*** This bug has been marked as a duplicate of 43531 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 20:27 ---
I don't see why h8300.c is being built.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
On Linux/ia32, revision 157801 gave:
FAIL: gcc.dg/cpp/include6.c (test for excess errors)
FAIL: gcc.dg/raw-string-1.c (test for excess errors)
FAIL: gcc.dg/raw-string-2.c (test for excess errors)
FAIL: gcc.dg/raw-string-5.c (test for excess errors)
FAIL: gcc.dg/raw-string-6.c (test for errors, li
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 20:26 ---
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 stringstream instead.
--
pinsk
I am not seeing strstream.h file in Include directory.Instead of this i am
seeing strstream in include directory because of this my old code is giving
errors while compliation
Here are the list of files which i am able to see.
[/usr] find . -name strstream
./include/c++/3.4.6/backward/strstream
./
--- Comment #3 from tkoenig at gcc dot gnu dot org 2010-03-29 18:58 ---
... which of course works better if I get the
"Known to work" and "Known to fail" fields correct.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-03-29 18:57 ---
Trying to get this onto the regression radar..
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-03-29 18:54 ---
Created an attachment (id=20253)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20253&action=view)
config.log in the libgomp directory
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-29 18:52 ---
Cross source is
gcc (GCC) 4.5.0 20100328 (experimental) [trunk revision 157785]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43584
Looking at the failure log, this looks like the new cross-compiler is being
used to compile a native part of gcc.
make[3]: Entering directory `/users/joel/test-gcc/b-gcc1-h8300/gcc'
/users/joel/test-gcc/b-gcc1-h8300/./gcc/xgcc
-B/users/joel/test-gcc/b-gcc1-h8300/./gcc/ -nostdinc
-B/users/joel/te
Bootstrap fails with revision 157799 on trunk:
/bin/sh ./libtool --tag=CC --mode=compile /home/ig25/Gcc/trunk-bin/./gcc/xgcc
-B/home/ig25/Gcc/trunk-bin/./gcc/ -B/home/ig25/x86_64-unknown-linux-gnu/bin/
-B/home/ig25/x86_64-unknown-linux-gnu/lib/ -isystem
/home/ig25/x86_64-unknown-linux-gnu/includ
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |other
Summary|exception handling broken |[4.5 Regression
linux-gnu
Configured with: ../gcc/configure -C --enable-maintainer-mode --prefix=/opt
LDFLAGS_FOR_TARGET=-Wl,--as-needed --with-boot-ldflags=-Wl,--as-needed
--with-stage1-ldflags=-Wl,--as-needed --enable-lto --without-cloog
--without-ppl --enable-languages=c,c++,fortran,java,lto,objc,obj-c++
-
--- Comment #2 from joel at gcc dot gnu dot org 2010-03-29 18:45 ---
Could someone try this with arm-eabi/elf? That would impact the priority of
this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Summary|ICE segfault compiling
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-29 18:44 ---
Created an attachment (id=20252)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20252&action=view)
Preprocessed libgcc2.c source
Definitely compiles with 4.4.3 not with head
--
http://gcc.gnu.org/bugzilla/sho
Compiles at -O0. Fails at -O1 and higher.
$ gcc --version
gcc (GCC) 4.5.0 20100328 (experimental) [trunk revision 157785]
This should also be
/users/joel/test-gcc/b-gcc1-arm/./gcc/xgcc
-B/users/joel/test-gcc/b-gcc1-arm/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-gcc1-arm/arm-rtems4.10/newlib/ -i
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 18:28 ---
Well the testcase is really bogus without early inline turned on. It is
testing early inlining as far as I can tell.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43577
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-29 18:29 ---
Yes this testcase is testing early inlining :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-29 18:29 ---
* passes.c (init_optimization_passes): Schedule
pass_rebuild_cgraph_edges and pass_early_inline outside
of pass_all_early_optimizations. Document reason.
--
http://gcc.gnu.org/bugzilla/s
If you compile the testcase consisting of files
testsuite/gcc.dg/lto/20081115_[012].c with disabled early inlining
(-fno-early-inlining), the execution will abort.
The testcase is full of extern inline functions so probably the
correct ones get picked by early inliner but wrong ones by the IPA
inl
--- Comment #3 from cgf at gcc dot gnu dot org 2010-03-29 18:02 ---
Need to remember to restart everything that uses spamassassin after an update
to
spamassassin.
--
cgf at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from cgf at gcc dot gnu dot org 2010-03-29 18:00 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43573
Im writing to you regarding a possible bug in linear loop transfor.
The bug can be reproduce by compiling the attached c file with gcc.4.5.0
(20100204, 20100325) on x86 machine.
The compiler flags that reproduce the error are:
-O2 -fno-inline -fno-tree-ch -ftree-loop-linear
If the compiler is ru
56 matches
Mail list logo
