--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 06:56 ---
Works just fine here. Are you sure you have updated also to the latest
fortran/openmp.c and rebuilt f951?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43826
--- Comment #25 from jason at gcc dot gnu dot org 2010-04-21 06:06 ---
Subject: Bug 9335
Author: jason
Date: Wed Apr 21 06:06:27 2010
New Revision: 158586
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158586
Log:
PR c++/9335
gcc/cp:
* init.c (constant_value_1):
--- Comment #7 from pault at gcc dot gnu dot org 2010-04-21 05:37 ---
Not only does it regtest but I had a few minutes to commit it in your name, as
obvious! Thanks for the fix, Janus, and thanks for the report, Salvatore.
Paul
--
pault at gcc dot gnu dot org changed:
W
--- Comment #6 from pault at gcc dot gnu dot org 2010-04-21 05:35 ---
Subject: Bug 43492
Author: pault
Date: Wed Apr 21 05:35:04 2010
New Revision: 158585
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158585
Log:
2010-04-21 Janus Weil
PR fortran/43492
* reso
--- Comment #9 from wilson at gcc dot gnu dot org 2010-04-21 05:31 ---
Fixed on mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot
|dot org
--- Comment #8 from wilson at gcc dot gnu dot org 2010-04-21 05:29 ---
Subject: Bug 43520
Author: wilson
Date: Wed Apr 21 05:29:11 2010
New Revision: 158584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158584
Log:
PR rtl-optimization/43520
* ira-lives.c (ira_implicitly_set_ins
--- Comment #8 from pault at gcc dot gnu dot org 2010-04-21 04:53 ---
I'll do this one next - assigning to self.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from pault at gcc dot gnu dot org 2010-04-21 04:27 ---
Fixed on trunk - will do 4.5 next week.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
Take this code snippet from x264:
h->mc.mc_luma( pix , 64, m->p_fref, m->i_stride[0], omx, omy-1, bw, bh,
&m->weight[0] );
h->mc.mc_luma( pix+16, 64, m->p_fref, m->i_stride[0], omx, omy+1, bw, bh,
&m->weight[0] );
h->mc.mc_luma( pix+32, 64, m->p_fref, m->i_stride[0], omx-1, omy, bw, bh,
&m->weig
--- Comment #12 from paolo dot carlini at oracle dot com 2010-04-21 03:36
---
Many thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #11 from davek at gcc dot gnu dot org 2010-04-21 02:17 ---
(In reply to comment #10)
> Dave, can I assign this to you?
>
Probably not now I beat you to it! Will take me a day or three to get round
to.
--
davek at gcc dot gnu dot org changed:
What|Remove
--- Comment #11 from lucier at math dot purdue dot edu 2010-04-21 01:17
---
Thank you for your way to build a 64-bit gcc, it has now worked for me using
Apple's gcc-4.0.1 as you say, so I'll close this bug as WORKSFORME.
Brad
--
lucier at math dot purdue dot edu changed:
--- Comment #16 from justinmattock at gmail dot com 2010-04-21 01:12
---
ugh... sysvinit rebuilt(just to see), makes no difference still getting stuck
during boot. libselinux breaks as well with the build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
--- Comment #1 from kargl at gcc dot gnu dot org 2010-04-21 01:11 ---
Created an attachment (id=20451)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20451&action=view)
dejagnu log file
It looks like lines 31-34 are not triggering errors.
--
http://gcc.gnu.org/bugzilla/show_bu
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for excess errors)
--
Summary: [libgomp] sharing-2..f90 has too many excess errors
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: li
--- Comment #8 from paolo dot carlini at oracle dot com 2010-04-21 00:33
---
Note: if the *only* way to change the behevior for the best requires using
enable_if on the user-level member functions (as, if I remember correctly,
pioneered by Howard at Metrowerks quite a few years ago), we
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-04-21 00:29 ---
(In reply to comment #0)
> When compiling the source with "-Wall -O", gcc gives the following warning:
>
> % gcc -c -Wall -O gcc_test.c
> gcc_test.c: In function ?functionLeon?:
> gcc_test.c:11: warning: ?reference?
--- Comment #8 from davidxl at gcc dot gnu dot org 2010-04-21 00:27 ---
(In reply to comment #2)
> Note this is not fully a regression but really a progression.
> What is happening now is only partial optimizations is happen before the
> warning to happen.
>
> >I was unable to reduce t
--- Comment #1 from paolo dot carlini at oracle dot com 2010-04-21 00:24
---
This new feature of C++0x has been pioneered by GCC, used for the
implementation of the special modes of the C++ library (eg, debug-mode, then
parallel-mode, etc). I'm not sure how much we can tighten the warni
--- Comment #6 from tglek at mozilla dot com 2010-04-21 00:19 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> > > executable and leave libraries alone?
> > >
> >
> > I'
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-21 00:17 ---
(In reply to comment #4)
> (In reply to comment #3)
> > I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> > executable and leave libraries alone?
> >
>
> I'm not sure what you mean.
>
Fed
--- Comment #4 from tglek at mozilla dot com 2010-04-21 00:15 ---
(In reply to comment #3)
> I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> executable and leave libraries alone?
>
I'm not sure what you mean.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-21 00:14 ---
I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
executable and leave libraries alone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
--- Comment #2 from tglek at mozilla dot com 2010-04-21 00:05 ---
(In reply to comment #1)
> Do you have a small testcase?
>
I wish. A minimal testcase works, but mozilla doesn't. Any suggestions on how
to reduce this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-21 00:04 ---
Do you have a small testcase?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from davidxl at gcc dot gnu dot org 2010-04-20 23:55
---
(In reply to comment #2)
> (In reply to comment #1)
> > check() can return 1 on the first call and 0 on the second and if *argv is
> > NULL
> > then then "bug" will be used uninitialized.
>
> right, but this does
Building Mozilla with pgo results in a binary that can't even start to generate
profiling data. Turns out that even CXX="g++ --coverage" and CC="gcc
--coverage" resulting a binary that segfaults on start.
The crash looks like
#0 0x740807c1 in strlen () from /lib/libc.so.6
#1 0x7fff
--- Comment #27 from mikpe at it dot uu dot se 2010-04-20 23:34 ---
(In reply to comment #22)
> Subject: Bug 43572
>
> Author: rguenth
> Date: Fri Apr 16 13:21:38 2010
> New Revision: 158418
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158418
> Log:
> 2010-04-16 Richard G
--- Comment #16 from jason at gcc dot gnu dot org 2010-04-20 23:10 ---
I agree that it's similar to signed integer overflow. One significant
difference is that this issue doesn't affect C.
One strange thing here is that the VRP optimization only happens when the enum
variable is conver
--- Comment #5 from patrick at motec dot com dot au 2010-04-20 23:01
---
Running
powerpc-eabispe-objdump -t `powerpc-eabispe-gcc --print-libgcc-file-name` |grep
_save
shows no symbols so I assume something in the build process has gone wrong.
Do you need me to attach my libgcc.a or a
--- Comment #5 from fabien dot chene at gmail dot com 2010-04-20 22:50
---
patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01199.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43719
--- Comment #12 from fabien dot chene at gmail dot com 2010-04-20 22:49
---
updated patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01148.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
--- Comment #5 from fabien dot chene at gmail dot com 2010-04-20 22:47
---
patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01269.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-20
22:28 ---
Subject: Re: [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal
compiler error)
> Can you bisect the few commits that happened inbetween? Like reverting
> the fixes for PRs 43679 and/or 43661,
--- Comment #15 from mark at codesourcery dot com 2010-04-20 22:18 ---
Subject: Re: [DR 1022] G++ is too aggressive in optimizing
away bounds checking with enums
jason at gcc dot gnu dot org wrote:
> Certainly optimizing away bounds checking is good when it is provably
> redundant, b
--- Comment #14 from jason at gcc dot gnu dot org 2010-04-20 22:02 ---
Certainly optimizing away bounds checking is good when it is provably
redundant, but that clearly doesn't apply to this case. That said, I'll go
ahead and add the option.
--
http://gcc.gnu.org/bugzilla/show_bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43800
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-20 21:56 ---
Here is a preliminary patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 158513)
+++ gcc/fortran/resolve.c (working
Inline namespace definitions are a feature proposed under C++0x. The feature
is not part of the C++98/03 standards. Code that uses it under -std=c++98
-Wall -Wextra -pedantic should get at least a warning.
berg...@etna:~/gcc/BUGS/> cat t.cpp
inline namespace A { }
berg...@etna:~/gcc/BUGS/> g++
--- Comment #10 from paolo dot carlini at oracle dot com 2010-04-20 21:26
---
Dave, can I assign this to you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-20 20:51 ---
Further reduced test case:
module base_mod
type :: base_mat
contains
procedure :: transp1 => base_transp1
generic :: transp => transp1
end type base_mat
contains
subroutine base_transp1(a)
--- Comment #11 from kargl at gcc dot gnu dot org 2010-04-20 20:44 ---
I have a patch that prevents the ICE on the invalid code in comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
--- Comment #13 from mmitchel at gcc dot gnu dot org 2010-04-20 20:43
---
I think this optimization is valuable in some cases, so I think this is a
question of defaults, rather than of behavior per se. While it may be useful
for some security-related applications not to eliminate the c
--- Comment #2 from kargl at gcc dot gnu dot org 2010-04-20 20:40 ---
-flto-compression-level=0 or 9 has no affect on the
ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
--- Comment #1 from kargl at gcc dot gnu dot org 2010-04-20 20:08 ---
Created an attachment (id=20450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20450&action=view)
Compile log of link failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
--- Comment #7 from jyasskin at gmail dot com 2010-04-20 20:04 ---
Patch request acknowledged. :) My plan if I do get around to writing it is to
use enable_if> since that's the rule
[lib.sequence.reqmts]p9 asks for.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
Executing on host:
/usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran
-B/usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../ -O2 -fwhopr -c -o
f_lto_20091015-1_0.o
/usr/home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/lto/20091015-1_0.f
(timeout = 300)
PASS: gfortran.dg/lto/20091015-1
--- Comment #4 from dodji at gcc dot gnu dot org 2010-04-20 19:40 ---
Fixed in trunk (4.6)
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #11 from dodji at gcc dot gnu dot org 2010-04-20 19:40 ---
Fixed in trunk (4.6) and 4.5.1.
--- Comment #12 from dodji at gcc dot gnu dot org 2010-04-20 19:40 ---
Subject: Bug 43704
Author: dodji
Date: Tue Apr 20 19:40:11 2010
New Revision: 158572
URL: http://gcc.
--- Comment #11 from dodji at gcc dot gnu dot org 2010-04-20 19:40 ---
Fixed in trunk (4.6) and 4.5.1.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dodji at gcc dot gnu dot org 2010-04-20 19:24 ---
Subject: Bug 43704
Author: dodji
Date: Tue Apr 20 19:23:45 2010
New Revision: 158571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158571
Log:
Fix PR c++/43800
gcc/cp/ChangeLog:
PR c++/43800
--- Comment #3 from dodji at gcc dot gnu dot org 2010-04-20 19:24 ---
Subject: Bug 43800
Author: dodji
Date: Tue Apr 20 19:23:45 2010
New Revision: 158571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158571
Log:
Fix PR c++/43800
gcc/cp/ChangeLog:
PR c++/43800
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-20 19:17 ---
> Thanks for the heads up on this - I had completely forgotten this PR.
I was suspecting something like that;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
--- Comment #11 from rlerallut at free dot fr 2010-04-20 19:09 ---
I don't think auto_ptr is special and I, as a mere user, would appreciate you
didn't hide *helpful* warnings from anywhere (but I do also appreciate your
efforts in limiting spurious warnings !).
I have the option of usi
--- Comment #26 from pault at gcc dot gnu dot org 2010-04-20 19:07 ---
Subject: Bug 43227
Author: pault
Date: Tue Apr 20 19:07:14 2010
New Revision: 158570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158570
Log:
2010-04-20 Paul Thomas
PR fortran/43227
* re
--- Comment #5 from pault at gcc dot gnu dot org 2010-04-20 19:07 ---
Subject: Bug 43266
Author: pault
Date: Tue Apr 20 19:07:14 2010
New Revision: 158570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158570
Log:
2010-04-20 Paul Thomas
PR fortran/43227
* res
--- Comment #10 from paolo dot carlini at oracle dot com 2010-04-20 18:59
---
Nah, the pragma must stay, we have it everywhere, consistently. And I really do
not understand why auto_ptr is *so* special to need more warnings to be spilled
vs *all* the rest of the library in order to be u
--- Comment #6 from pault at gcc dot gnu dot org 2010-04-20 18:57 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Technically this PR, fixed on trunk but not on fortran-dev, is now a
> > [fortran-dev Regression]. Could it be marked that way?
>
> Yes.
>
Janus and Dominique,
--- Comment #9 from chris at bubblescope dot net 2010-04-20 18:53 ---
I don't think it's a front-end issue. '#pragma GCC system_header' is
specifically designed to stop warnings in headers. However, it stops 'good'
warnings as well as 'bad' warnings. 'system_header' could be extended to
--- Comment #8 from rlerallut at free dot fr 2010-04-20 18:41 ---
@Chris Jefferson : indeed, if I roll my own "auto_ptr" locally, I get the
proper warning, as well as if I use -Wsystem-headers (didn't know that one).
@Paolo Carlini : I'm using the default standard mode for gcc 4.4, so
--- Comment #7 from paolo dot carlini at oracle dot com 2010-04-20 18:36
---
Maybe I should clarify my earlier message: at this time in the life of
auto_ptr, it seems quite unlikely to me that we'll non-trivially change the
implementation only because a warning is not emitted anymore. I
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-04-20 18:36 ---
Created an attachment (id=20449)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20449&action=view)
Work-in-progress patch
This is a patch that fixes the uderlying problem and also adds verification
that same_co
--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-20 18:30
---
To me it looks like a front-end issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org
|dot org
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-20 18:22 ---
sure, it's deprecated in C++0x mode, but it's a pretty bad regression that it
no longer warns in C++03 mode
Chris is right, -Wsystem-headers restores the warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4382
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-04-20 18:10 ---
*** Bug 43822 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-20 18:10 ---
*** This bug has been marked as a duplicate of 43704 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-20 18:01 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #10 from kargl at gcc dot gnu dot org 2010-04-20 18:01 ---
The submitted testcase is invalid. See R729.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-20 17:53 ---
yawn valid testcase here ftp://ftp.berlios.de/pub/cp2k/cp2k.tar.gz
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
--- Comment #2 from mr dot chr dot schmidt at online dot de 2010-04-20
17:34 ---
Created an attachment (id=20448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20448&action=view)
g++ -v / g++ test.cc output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43822
--- Comment #1 from mr dot chr dot schmidt at online dot de 2010-04-20
17:32 ---
Created an attachment (id=20447)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20447&action=view)
Preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43822
The attached code causes gcc-4.5 to segfault. gcc-4.4.1 accepts the code.
I have absolutely no idea what is actually causing the segfault, as the very
same instantiation does not segfault in another context.
--
Summary: template instantiation causes gcc to segfault
Product:
--- Comment #4 from chris at bubblescope dot net 2010-04-20 17:18 ---
Yes, in C++0x mode, we should just add a deprication warning for auto_ptr full
stop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--- Comment #3 from paolo dot carlini at oracle dot com 2010-04-20 17:17
---
And frankly note that anything related to auto_ptr is very unlikely to change,
given the deprecation status, unless it's something like the code doesn't
compile anymore.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from chris at bubblescope dot net 2010-04-20 17:10 ---
I think this is connected to the "suppress warning is the standard library"
pragma starting to actually work.
--
chris at bubblescope dot net changed:
What|Removed |Added
---
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-20 17:06 ---
Created an attachment (id=20446)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20446&action=view)
comparison between asm files without an with -feliminate-dwarf2-dups
the main difference seems to be moving the f
This is probably another dsymutil bug... but, just in case...
int main (int ac, char *av[])
{
int a ;
return a + 1;
}
===
$ ./gcc/xgcc -B gcc ../trivial.c -g
$ ./gcc/xgcc -B gcc ../trivial.c -g -feliminate-dwarf2-dups
warning: no debug symbols in executable (-arch i386)
--
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-20 16:59 ---
one problem is that it's not trivial to determine if a type "qualifies as an
input iterator" because a non-iterator type could provide private members which
perform some of the operations supported by an iterator (e.g.
--- Comment #5 from oberlaender at fzi dot de 2010-04-20 16:51 ---
I don't think it's the memory, I've got 4 GB at my disposal (32-Bit system with
PAE kernel), and it doesn't seem to take up much memory:
$ uname -a
Linux delorean 2.6.31-20-generic-pae #58-Ubuntu SMP Fri Mar 12 06:25:51
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-20 16:50 ---
patches welcome :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
--- Comment #5 from pinskia at gmail dot com 2010-04-20 16:38 ---
Subject: Re: Bootstrapping GCC 4.5.0 fails with "cannot compute suffix of
object files: cannot compile"
Sent from my iPhone
On Apr 20, 2010, at 8:42 AM, "florin at iucha dot net"
wrote:
>
>
> --- Comment #2 from
Sent from my iPhone
On Apr 20, 2010, at 8:42 AM, "florin at iucha dot net" > wrote:
--- Comment #2 from florin at iucha dot net 2010-04-20 15:42
---
The 'missing' library is in fact present:
Yes it is present but that directory is not looked at during the
runtime, use eith
--- Comment #4 from jyasskin at gmail dot com 2010-04-20 16:34 ---
It seems like a QoI issue until the C++ issue is resolved, since the expected
behavior is also allowed by the standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-20 16:27 ---
works for me with 4.4.2 and higher - could you be running out of memory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-20 16:21 ---
Could be a front-end bug, but probably something in the library
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
The following code used to trigger a warning with gcc 4.2 and 4.3 but passes
silently with 4.4 and 4.5:
=
#include
struct S;
int main()
{
std::auto_ptr p( (S*) 1234 );
}
=
This code triggers a segfault but when the poin
--- Comment #3 from paolo dot carlini at oracle dot com 2010-04-20 16:10
---
The issue has been discussed a little bit in Pittsburgh and frankly people
(besides Matt) didn't show a huge interest. I think it's well possible that
will not be resolved in time for C++1x (unless, as usual, o
--- Comment #4 from florin at iucha dot net 2010-04-20 15:54 ---
I will do that - but I was expecting that passing in the paths is sufficient.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43819
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-20 15:45 ---
You need to adjust your LD_LIBRARY_PATH so the library is picked up at runtime.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from florin at iucha dot net 2010-04-20 15:42 ---
The 'missing' library is in fact present:
$ ls -l /usr/local.296/lib/
total 4260
-rw-r--r--1 root root 1726470 Apr 20 15:00 libelf.a
lrwxrwxrwx1 root root 16 Apr 20 15:00 libelf.so ->
libelf.
--- Comment #1 from florin at iucha dot net 2010-04-20 15:41 ---
Created an attachment (id=20445)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20445&action=view)
libgcc config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43819
I'm trying to build GCC 4.5.0 on RedHat 7.3, using the included gcc compiler
version "2.96". I have built and installed the dependencies (mpc-0.8.1,
mpfr-2.4.2, gmp-5.0.1) into /usr/local.296 and I tried to bootstrap gcc with
the following command line:
/tmp/gcc-4.5.0/configure --prefix=/usr/loca
--- Comment #8 from jakub at gcc dot gnu dot org 2010-04-20 15:38 ---
Subject: Bug 43706
Author: jakub
Date: Tue Apr 20 15:37:51 2010
New Revision: 158565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158565
Log:
PR libgomp/43706
* config/linux/affinity.c (gomp_
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-20 15:37 ---
Subject: Bug 43569
Author: jakub
Date: Tue Apr 20 15:36:45 2010
New Revision: 158564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158564
Log:
PR libgomp/43569
* sections.c (gomp_sections_init
--- Comment #3 from oberlaender at fzi dot de 2010-04-20 15:29 ---
The file bugtest.ii compiles successfully in gcc-4.3.4 (unfortunately I can't
go back to 4.3 though).
$ g++-4.3 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubun
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-04-20 14:49 ---
The problem here is that we have a call graph node with !DECL_COMDAT
(node->decl) in a same_comdat_group linked list. Thus it is kept alive
but looked at as if it should have been dead long time ago.
It seems th
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-04-20 14:32
---
Backported the fix for the $summary. WONTFIX for the cfgexpand slowness.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-04-20 14:32
---
Subject: Bug 38584
Author: rguenth
Date: Tue Apr 20 14:31:47 2010
New Revision: 158562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158562
Log:
2010-04-20 Richard Guenther
Backport from mainl
1 - 100 of 196 matches
Mail list logo
