--- Comment #2 from redi at gcc dot gnu dot org 2010-04-28 18:23 ---
all three forms compile ok with 4.4.3 or 4.6.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mlrus at mac dot com 2010-04-28 18:20 ---
Appended status to booost bug 3944 http://svn.boost.org/trac/boost/ticket/3844
--
mlrus at mac dot com changed:
What|Removed |Added
-
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-28 18:19 ---
(In reply to comment #0)
> gcc -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE
> -mtune=niagara -mcpu=niagara -m64 -m64 -m64 -m64 -o .libs/sqlite3 shell.o
> -L/usr/lib/sparcv9 ./.libs/libsqlite3.so -lre
--- Comment #22 from ro at gcc dot gnu dot org 2010-04-28 18:13 ---
(In reply to comment #20)
> I don't think it should be closed: the installation docs for Solaris x86
> recommend to use the default binutils 2.15 and say it works fine, but that's
> not the case if you use --with-arch=c
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28
18:00 ---
Subject: Re: preprocessor fails with myassertion
> --- Comment #1 from steven at gcc dot gnu dot org 2010-04-23 22:43
> ---
> This one appears to have fallen through the cracks. Reported exactly
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28
17:51 ---
Subject: Re: ICE in gcc/config/soft-fp/divtf3.c
"gcc-tgc at jupiterrise dot com" writes:
> Program received signal SIGSEGV, Segmentation fault.
> 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac)
--- Comment #3 from navin dot kumar at gmail dot com 2010-04-28 17:43
---
Are you compiling with -std=c++0x or without? It compiles fine without the
-std=c++0x flag. The issue is when it is supplied.
Look at line 134 of include/c++/4.5.0/bits/stl_pair.h; inside a #ifdef
__GXX_EXPERIM
I've just noticed that all plugin tests are UNRESOLVED on IRIX 6.5, with the
following error:
UNRESOLVED: attribute_plugin.c compilation, -I. -I/vol/gcc/src/hg/trunk/local/g
cc/testsuite -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../gcc
-I/vol/gcc/ob
j/regression/trunk/6.5-gcc/build/gcc/testsu
--- Comment #24 from dominiq at lps dot ens dot fr 2010-04-28 17:07 ---
> Are you saying you regression hunted and this was triggered by...
> Author: bernds
> Date: Thu Apr 22 11:47:52 2010
> New Revision: 158643
No. If you read the thread, it was due to revision 158639 (see comment #6)
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-04-28
16:50 ---
Dominique,
Are you saying you regression hunted and this was triggered by...
Author: bernds
Date: Thu Apr 22 11:47:52 2010
New Revision: 158643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158
--- Comment #5 from ro at gcc dot gnu dot org 2010-04-28 16:28 ---
Fixed for 4.5.1, 4.6.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #4 from ro at gcc dot gnu dot org 2010-04-28 16:26 ---
Subject: Bug 4
Author: ro
Date: Wed Apr 28 16:26:24 2010
New Revision: 158832
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158832
Log:
PR target/4
* config/alpha/osf.h (ASM_OUTPUT_LOCAL)
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-28 16:24 ---
Subject: Bug 4
Author: ro
Date: Wed Apr 28 16:24:28 2010
New Revision: 158831
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158831
Log:
PR target/4
* config/alpha/osf5.h (ASM_OUTPUT_LOCAL
--- Comment #13 from alexey dot salmin at gmail dot com 2010-04-28 15:53
---
Sorry, but I still don't get it :( Why exactly we can't remove the second load
of "*b"?
void f(int *a, const int *restrict b) {
*a++ = *b + 1;
*a++ = *b + 1;
}
--
http://gcc.gnu.org/bugzil
--- Comment #21 from jb at gcc dot gnu dot org 2010-04-28 15:43 ---
(In reply to comment #19)
> (In reply to comment #18)
> > 3) for the same reason you can also drop the + 1 in computing the
> > allocation
> > size which is currently (ubound - lbound + 1) * 4
>
> Sorry, but isn't +1
--- Comment #20 from jv244 at cam dot ac dot uk 2010-04-28 15:20 ---
(In reply to comment #18)
>
> If that's all acceptable I will work on this soon.
>
FYI, this would fix PR38318 and PR21046
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #19 from amonakov at gcc dot gnu dot org 2010-04-28 15:15
---
(In reply to comment #18)
> 3) for the same reason you can also drop the + 1 in computing the allocation
> size which is currently (ubound - lbound + 1) * 4
Sorry, but isn't +1 needed because bounds are inclusiv
--- Comment #8 from zsojka at seznam dot cz 2010-04-28 15:12 ---
Created an attachment (id=20508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20508&action=view)
second part of reduced testcase
These testcases demonstrate what happens in cfgrtl.c, why is
cfg_layout_merge_blocks m
--- Comment #7 from zsojka at seznam dot cz 2010-04-28 15:09 ---
Created an attachment (id=20507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20507&action=view)
first part of reduced testcase
second part to follow
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-04-28 14:52
---
Updating the status on this bugreport. I am working on middle-end support
for hoisting/sinking malloc/free pairs out of loops (in case the size is
loop invariant). The Fortran FE makes this somewhat difficult.
F
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28
14:40 ---
Subject: Re: lto-elf.c fails to compile on Solaris
> --- Comment #9 from hubicka at gcc dot gnu dot org 2010-04-28 13:01
> ---
> Hmm, I am not at all sure what problem I should have with this?
Since revision 158788 (see
http://gcc.gnu.org/ml/gcc-regression/2010-04/msg00294.html)
gfortran.dg/array_constructor_11.f90 fails with '-O3 -g' with:
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/array_constructor_11.f90:6:0:
internal compiler error: in output_die, at dwarf2out.c:10649
--
--- Comment #22 from bernds at codesourcery dot com 2010-04-28 13:59
---
(In reply to comment #20)
> I have forgotten to ask my question! Could it be a similar issue to that you
> fixed for pr42220?
No, that looks completely unrelated at first glance.
--
http://gcc.gnu.org/bugzill
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC|hjl at gcc dot gnu dot org |hjl dot tools at gmail dot
|
--- Comment #8 from tbptbp at gmail dot com 2010-04-28 13:43 ---
Allow me to extend to you my most profuse praises and blessing; may all the
woman in your vicinity fall pregnant and your male progeny be granted abounding
chest hair.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #2 from davek at gcc dot gnu dot org 2010-04-28 13:38 ---
Quoting RG from the gcc list:
"[ ... ] Or you fix collect2 to do processing of archives and hand
lto1 the required information (it expects archive components
with LTO bytecode like archiv...@offset with offset being t
--- Comment #21 from dominiq at lps dot ens dot fr 2010-04-28 13:19 ---
> Two questions - are you sure you didn't reverse the _w and _f files (i.e.
> maybe
> _f is the working version and _w the failing one)?
I have double checked and I confirm that the *_f.* files are coming from th
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-04-28 13:15 ---
This is now fixed on both the trunk and the 4.5 branch.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-04-28 13:10 ---
Subject: Bug 43846
Author: jamborm
Date: Wed Apr 28 13:09:56 2010
New Revision: 158826
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158826
Log:
2010-04-28 Martin Jambor
PR tree-optimization/438
--- Comment #14 from dominiq at lps dot ens dot fr 2010-04-28 13:04 ---
Note also that the polyhedron test aermod.f90 fails with -flto or -whopr at any
level of optimization with:
ld: in /var/tmp//ccDGk6QZ.o, in section __TEXT,__text reloc 17: local
relocation for address 0x000E58F4 in
--- Comment #9 from hubicka at gcc dot gnu dot org 2010-04-28 13:01 ---
Hmm, I am not at all sure what problem I should have with this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-28 12:53 ---
Real miscompiles prevailing:
=== libstdc++ tests ===
Running target unix/-fipa-pta/
FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test
FAIL: 23_containers/bitset/cons/1.cc execu
--- Comment #13 from dominiq at lps dot ens dot fr 2010-04-28 12:20 ---
> proof-of-concept patch
Great!-) Thanks a lot.
Besides the 17 C failures, for all languages but ADA, I also see
FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link
and
FAIL: gcc.c-torture/ex
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-28 11:55 ---
I'm not sure, let's as honza.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-28 11:52 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-28 11:51 ---
Subject: Bug 43909
Author: rguenth
Date: Wed Apr 28 11:51:31 2010
New Revision: 158825
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158825
Log:
2010-04-28 Richard Guenther
PR tree-optimization/
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-28 11:51 ---
Subject: Bug 43879
Author: rguenth
Date: Wed Apr 28 11:51:31 2010
New Revision: 158825
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158825
Log:
2010-04-28 Richard Guenther
PR tree-optimization/
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-28 11:46 ---
(In reply to comment #6)
> In this diagnostic:
>
> invalid initialization of reference of type 'boost::thread&&' from expression
> of type 'boost::thread'
>
> it might be clearer if the latter type was given as 'boost
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-28 11:40 ---
N.B. I stopped testing boost trunk against gcc trunk ages ago and I don't think
anyone does it these days, which means that boost releases often don't work
with GCC versions that come out after the release, especially i
--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-28 11:35
---
Ah, thanks. Let's add DJ in CC, otherwise, as far as I'm concerned, the patch
could go also in 4_5-branch (dates fixed of course).
--
paolo dot carlini at oracle dot com changed:
What|Remove
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-28 11:28 ---
DJ Delorie is the port maintainer. The patch needs (at least) the right
copyright dates
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
--- Comment #1 from stephan dot aiche at fu-berlin dot de 2010-04-28 11:23
---
The preprocessed file is to big for bugzille but it can be downloaded here
http://page.mi.fu-berlin.de/aiche/FeatureFinder.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43922
After some recent changes to our code we observed that g++ fails with ICE when
compiled with -fopenmp. The error occurs only with the 4.3.4 compiler, 4.4.1
works.
g++-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.4-5ubuntu1
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-28 11:17 ---
In this diagnostic:
invalid initialization of reference of type 'boost::thread&&' from expression
of type 'boost::thread'
it might be clearer if the latter type was given as 'boost::thread&' so that
it's clear it is a
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-28
11:16 ---
Subject: Re: lto-elf.c fails to compile on Solaris
> --- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-23 14:34
> ---
> What's the status of this bug?
I haven't checked anything before
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-28 11:15 ---
I think this error is correct:
./boost/thread/pthread/thread_heap_alloc.hpp: In function 'T*
boost::detail::heap_new(A1&&) [with T = boost::detail::thread_data,
A1 = void (*&)()]':
./boost/thread/detail/thread.hpp:130:
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-28 10:38 ---
(In reply to comment #3)
> Subject: Re: FAIL: libgomp.fortran/reduction3.f90
>
> > Does it work without -fopenmp?
>
> Yes.
>
> Dave
Does this still fail ? Recent testresults don't show this failure in libgomp.
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-28 10:28 ---
Fixed for 4.6 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-28 10:28 ---
Subject: Bug 43880
Author: rguenth
Date: Wed Apr 28 10:28:24 2010
New Revision: 158824
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158824
Log:
2010-04-28 Richard Guenther
PR c++/43880
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-28 10:10 ---
On trunk I don't see the movne / moveq problem but the extra mov r3, #1 could
be removed. (I think one of Bernd's recent fixes to ifcvt.c fixed these
issues).
tst r1, #1
mov r3, #1
--- Comment #2 from ramana at gcc dot gnu dot org 2010-04-28 10:06 ---
* I don't see why smulbb, smultb, smulbt, smultt shouldn't be generated for
their respective cases. So, yes that's correct.
* smulwy is not supported in the backend, so that's a feature enhancement
* smlawy is again
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-28 09:55 ---
Confirmed though it isn't as simple as an "expand" time problem alone.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
When I try to build gcc-4.5 with gcc-4.5 using -march=atom it fails when
comparing stage2 and 3:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/graphite-interchange.o differs
gcc/dwarf2out.o differs
gcc/tree-c
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-28 09:23
---
_Unwind_GetIPInfo is exported since 4.2.0, the symbol should be
> objdump -T /lib/libgcc_s.so.1 | grep GetIPI
00013f30 gDF .text 0016 GCC_4.2.0 _Unwind_GetIPInfo
what binutils version are you using (w
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org
|dot org
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-28 09:16
---
May be related to PR43740 which also sees cc1 miscompilation but even with
release checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.3 4.5.0
Summary|[4.4.3/4.5.0 regression] g++|[4.4/4.5
--- Comment #19 from paolo dot carlini at oracle dot com 2010-04-28 09:14
---
Closing as invalid, then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-28 09:12
---
Dave, do you know this target? Is it a supported one? Thanks...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-28 09:09
---
Likely, something is broken in your installation, this problem cannot be
reproduced in a sane installation of 4.5.0 or mainline. Note that the std::swap
overload for std::pair takes *lvalue* references.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-28 09:07 ---
*** This bug has been marked as a duplicate of 43917 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-28 09:07 ---
*** Bug 43916 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
--- Comment #2 from carrot at google dot com 2010-04-28 09:01 ---
The expected sequence should be:
...
cmp r4, #-1
beq .L4
cmp r0, #-1
beq .L4
...
When changes the options to -march=armv5te -mthumb -Os, gcc can generate the
expected codes. Th
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:57 ---
Created an attachment (id=20505)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20505&action=view)
coarray_13.f90 test case
Depending on this fix are constraint checking for coarrays, cf. attached test
case.
--- Comment #20 from dominiq at lps dot ens dot fr 2010-04-28 08:54 ---
I have forgotten to ask my question! Could it be a similar issue to that you
fixed for pr42220?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-28 08:50 ---
> Two questions - are you sure you didn't reverse the _w and _f files (i.e.
> maybe
> _f is the working version and _w the failing one)?
I have looked at how I have generated the archive and I don't think so.
I'l
--- Comment #4 from manu at gcc dot gnu dot org 2010-04-28 08:46 ---
The output is now:
$ cc1plus pr43113.C -ftemplate-depth=10
pr43113.C:7:11: error: template instantiation depth exceeds maximum of 10 (use
-ftemplate-depth= to increase the maximum) instantiating struct
A::S>::S>::S>:
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:42 ---
Fortran 2008 FDIS (ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1826.pdf) has:
R448 type-bound-procedure-stmt
is PROCEDURE [ [ , binding-attr -list ] :: ] type-bound-proc-decl -list
or PROCEDURE (interface-na
--- Comment #27 from manu at gcc dot gnu dot org 2010-04-28 08:38 ---
The current output is:
recurse2.C:5:38: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating struct
X<-0x00018>
recurse2.C:5:38: rec
--- Comment #26 from manu at gcc dot gnu dot org 2010-04-28 08:34 ---
Subject: Bug 9335
Author: manu
Date: Wed Apr 28 08:34:01 2010
New Revision: 158823
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158823
Log:
2010-04-28 Manuel López-Ibáñez
PR c++/9335
cp/
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:30 ---
Mine. Patch works.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #1 from carrot at google dot com 2010-04-28 08:18 ---
Created an attachment (id=20504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20504&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
Compile the attached source code with options -march=armv7-a -mthumb -Os, gcc
generates following instructions for "if (start == -1 || end == -1)":
...
cmp r4, #-1
ite ne
movne r3, #0
moveq r3, #1
cmp r0, #-1
it eq
--- Comment #3 from suresh dot gumpula at amd dot com 2010-04-28 08:02
---
(In reply to comment #2)
> (In reply to comment #1)
> > Created an attachment (id=20503)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20503&action=view) [edit]
> > patch for target i586-pc-msdosdjgpp for
--- Comment #2 from suresh dot gumpula at amd dot com 2010-04-28 08:00
---
(In reply to comment #1)
> Created an attachment (id=20503)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20503&action=view) [edit]
> patch for target i586-pc-msdosdjgpp for undefined error constants
I c
--- Comment #1 from suresh dot gumpula at amd dot com 2010-04-28 07:56
---
Created an attachment (id=20503)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20503&action=view)
patch for target i586-pc-msdosdjgpp for undefined error constants
--
http://gcc.gnu.org/bugzilla/show_
The following program gives an ICE:
f951: internal compiler error: in simplify_cobound, at fortran/simplify.c:2969
integer :: a[*]
print *,a
print *,lcobound(a), ucobound(a)
end
Patch (untested):
Index: gcc/fortran/simplify.c
===
-
101 - 179 of 179 matches
Mail list logo
