--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-02 07:44 ---
Do you still see this failure ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29685
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-02 07:43 ---
Do you still see these failures ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27999
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-02 07:41 ---
Do you still get this failure with 4.2.0 or 4.3.0 ?
Arno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25819
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-02 07:37 ---
I do not see this failure on your 4.2.0 runs,
so assuming this is now fixed.
Please reopen if not.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-02 07:36 ---
I do not see this failure on your 4.2.0 runs, nor on ia64 results,
so assuming this is now fixed.
Please reopen if not.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed
--- Comment #20 from pinskia at gcc dot gnu dot org 2007-05-02 07:20
---
*** Bug 31783 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 07:20 ---
*** This bug has been marked as a duplicate of 20681 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-02 07:17 ---
Use contrib/gcc_update to update the sources, this touches the generated files
so you don't have to worry about this issue. The toplevel configure in 4.2.0
is generated by autoconf 2.13, this has already changed in
--- Comment #2 from pva at gentoo dot org 2007-05-02 06:56 ---
libtool bug was discussed earlier:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460
But this bug is not about libtool. Libtool just expose problem, although it
should hide but that is another bug.
I may wish to have librar
--- Comment #3 from truedfx at gentoo dot org 2007-05-02 05:58 ---
Thanks for the link. I don't see how GAS could be fixed, though. How would the
assembler tell the difference between $0 the constant and $0 the identifier?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
--- Comment #5 from rob1weld at aol dot com 2007-05-02 05:08 ---
Thanks Andreas,
The annoying un-quoted second occurance of the languages is now fixed.
Somehow AutoConf decided that it was going to rebuild ./configure .
I renamed my current configure and then did a new SVN to get the
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-02 04:57
---
backtrace is uggly, repeats the following for a long long time
#3554 0x0043c63e in mio_expr (ep=)
at ../../gcc43/gcc/fortran/module.c:2133
#3555 0x0043c779 in mio_expr (ep=0xef2f60)
at ../
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31467
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-02 04:19
---
I attached a patch to pr31251, can someone try that and see what effect it has
on this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-02 04:13
---
Created an attachment (id=13470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13470&action=view)
Possible patch for this problem
The double error comes from trying to match_type_spec for a variable
declara
gcc 4.1.2 and gcc 4.1.1 shows the following bogus warning message.
[EMAIL PROTECTED] ~/tests] arm-rtems-gcc -Os -Wall -S test.cpp
test.cpp: In member function 'int attr::create(int)':
test.cpp:17: warning: control reaches end of non-void function
the minimal testcase:
class attr
{
attr() {}
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 03:34 ---
Most likely someone has a gcc_assert which has side effects.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-02 03:33 ---
> unless $ also becomes an invalid identifier in C.
Well read:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Dollar-Signs.html
it is can be but does not have to be.
This works for me targetting spu-elf and powerpc64
--- Comment #1 from truedfx at gentoo dot org 2007-05-02 03:21 ---
Sorry, forgot to mention, I'm using gcc 4.1.2 with binutils 2.17, and I also
tried gcc 3.3.6 with binutils 2.16.1, which behaves the same for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
Hi,
This code compiles fine with gcc:
void a$() {}
int main() { a$(); }
This generates invalid assembly code:
void $() {}
int main() { $(); }
To gas, an initial $ is not allowed in an identifier, but to gcc, it is, so gcc
can't simply copy the function name to the assembly output, unless $ als
if you --disable-checking when you build, you get additional fortran
regressions. This is true on the current trunk and has most likely been true
for at least two weeks.
FAIL: gfortran.dg/repeat_2.f90 -O0 execution test
FAIL: gfortran.dg/repeat_2.f90 -O1 execution test
FAIL: gfortran.dg/rep
--- Comment #12 from crowl at google dot com 2007-05-02 02:24 ---
(In reply to comment #10)
> I am not convinced that the code in Comment #8 is valid.
>
> Although the operand of sizeof is not in fact evaluated, it seems odd to
> permit an operand which cannot, even in principle, be eva
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-02 01:47 ---
Also I think this was caused by PR 31338.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 01:46 ---
> bug.cc:5: error: could not convert '0' to 'int __complex__'
Actually it should be able to convert that and I think this is the same reason
why we are rejecting PR 30209.
--
pinskia at gcc dot gnu dot org chang
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-05-02 01:46 ---
I just happen to have a patch which fixes this.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-05-02 00:54 ---
You would add a translation unit that says
int i;
or similar. It's not "main::i", it's "::i", because of [basic.link] paragraph
7:
When a block scope declaration of an entity with linkage is not found to refer
to
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
The following invalid code snippet triggers an ICE on mainline:
===
bool foo();
void bar()
{
__builtin_expect(foo(), 1) ? 0i : 0;
}
===
bug.cc: In function 'void bar()':
bug.cc:5: error: could not convert '0' to 'i
--- Comment #4 from malitzke at metronets dot com 2007-05-02 00:20 ---
I accept that there is something wrong on my side. Be it "forward" or
"backward".
However, there are some things that I still do not understand.
Cmake was compiled several times with different bootstrapped gcc-4.2.0
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31777
--- Comment #1 from pcarlini at suse dot de 2007-05-01 23:57 ---
Gosh you are right, will fix it asap. Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2007-05-01 23:41 ---
(In reply to comment #2)
> That is called forwards compatibility...
The name depends on the point of view ;) No, seriusly, thanks about the name, I
always get this one wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-01 23:39 ---
(In reply to comment #1)
> Obviously, you are linking a binary compiled with 4.2.0 to a 4.1.2 library.
> That kind of "backward" compatibility is not provided and never was in the
> past.
That is called forwards com
--- Comment #1 from pcarlini at suse dot de 2007-05-01 23:36 ---
Obviously, you are linking a binary compiled with 4.2.0 to a 4.1.2 library.
That kind of "backward" compatibility is not provided and never was in the
past.
--
pcarlini at suse dot de changed:
What|Remov
One more potential conspiracy item against gcc-4.2.0.
The following three items were obtained on three different machines sporting
late gcc-4.2.0
versions. (less than one week old)
cmake: relocation error: cmake: symbol _ZNSo9_M_insertEPKci, version
GLIBCXX_3.4.9 not defined in file libstdc++.so
genattrtab.c has
struct insn_def
{
struct insn_def *next;/* Next insn in chain. */
rtx def; /* The DEFINE_... */
int insn_code;/* Instruction number. */
int insn_index; /* Expression numer in file, for errors. */
int lineno;
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-01 23:02 ---
To tree-data-ref.c:add_multivariate_self_dist, we get with
c_2 = {{0, +, 30}_1, +, 1}_2
but
ddr->loop_nest contains only loops 2 and 3.
x_1 is then set to 2, which is outside of the bounds of the dist_v
array.
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-01 22:57 ---
It looks like the same cause but different symptom. The configure
check for strsignal for darwin doesn't seem to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
--- Comment #2 from schnetter at aei dot mpg dot de 2007-05-01 22:37
---
I configured with the options
~/src/gcc/configure --prefix=$HOME/gcc --with-gmp=/opt/local
--with-mpfr=/opt/local
(outside the source tree).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
in revision 83355 of libstdc++-v3/include/ext/pool_allocator.h the efficient
thread support code for GLIBCXX_FORCE_NEW was broken by changing the test
(_S_force_new>0) to (_S_force_new==1). now there is a race condition.
--
Summary: GLIBCXX_FORCE_NEW doesn't always work in pool_alloca
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-05-01 22:24 ---
I am checking this; so far it looks like some memory corruption.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31762
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 22:03 ---
How did you configure?
This is most likely the same as reported in
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00033.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
The current svn repository does not bootstrap on my machine.
$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 124341
Node Kind: directory
Schedule: normal
Last Changed Author: dwarak
L
--- Comment #1 from sje at cup dot hp dot com 2007-05-01 21:22 ---
This does not look like a GCC bug, you just need to link in the YACC library on
the link line. The lex library (-ll) has calls to the yacc library (-ly) and
so that library needs to be linked in.
--
sje at cup dot hp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 21:03 ---
I think this is really a libtool bug passing -nostdlib to g++, there is no
reason why it should be doing that anyways.
Also --as-needed is a binutils option, since the pthreads library is not needed
by the main prog
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-01 20:44 ---
How do you define main"::"i? That is, how'd you make the testcase work from a
second translation unit if it would fail now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
--- Comment #5 from ian at gcc dot gnu dot org 2007-05-01 20:23 ---
Subject: Bug 31739
Author: ian
Date: Tue May 1 20:23:47 2007
New Revision: 124338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124338
Log:
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_m
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-05-01 19:56 ---
This testcase is the same principle, but might use a different code path in the
compiler:
extern "C" void abort();
extern int *p;
int main()
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
return
In [basic.link] paragraph 6, there's an example that shows that (unlike in C)
it is permissible to define an object 'static' in a namespace scope and then
have another object which is 'extern', and reference both in the same
translation unit.
The compiler optimises that example so that there's no
I have problems linking executable with C++ library with --as-needed ld flag
while linking with gcc succeeds. During investigation I found inconsistency in
gcc and g++ calls concerning --as-needed. First I will show you what I do next
I'll summarize what is this bug about:
* What I do:
First I com
t;
PR middle-end/31740
* gcc.c-torture/compile/20070501-1.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20070501-1.c
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31740
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-01 19:26 ---
Yes this was fixed after:
2007-05-01 Ian Lance Taylor <[EMAIL PROTECTED]>
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static functio
--- Comment #3 from bangerth at dealii dot org 2007-05-01 19:16 ---
(In reply to comment #2)
> Ok, thanks. The other compiler we use here at work uses the i suffix to mean
> integer, just like l/L for long.
This is definitely non-standard. The 'i' suffix is for the imaginary part of
co
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-01 19:15 ---
Reduced testcase:
typedef signed int signed16 __attribute__ ((__mode__ (__HI__)));
typedef unsigned int unsigned16 __attribute__ ((__mode__ (__HI__)));
typedef signed16 HI;
typedef unsigned16 UHI;
unsigned short
--- Comment #4 from ian at airs dot com 2007-05-01 18:59 ---
Fixed on mainline.
--
ian at airs dot com changed:
What|Removed |Added
CC|ian at gcc dot gnu
--- Comment #10 from ian at airs dot com 2007-05-01 18:58 ---
Please let me know if this is still a problem after revision 124334.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31710
--- Comment #3 from ian at gcc dot gnu dot org 2007-05-01 18:52 ---
Subject: Bug 31739
Author: ian
Date: Tue May 1 18:51:56 2007
New Revision: 124334
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124334
Log:
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_m
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Component|target |middle-end
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-01 18:14 ---
Reopening this one as it is not a dup.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from schlake+gccbug at nmt dot edu 2007-05-01 18:05 ---
Ok, thanks. The other compiler we use here at work uses the i suffix to mean
integer, just like l/L for long.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31773
--- Comment #9 from mstein at phenix dot rootshell dot be 2007-05-01 17:59
---
Created an attachment (id=13469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13469&action=view)
from src/sim/frv
This attachment triggers a ICE in set_value_range, at tree-vrp.c:278
with a host gcc f
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 17:58 ---
1i is complex integer where the imangary part is 1 and the real part is 0.
See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Complex.html
This is a gcc extension.
--
pinskia at gcc dot gnu dot org changed:
I had a typo in my code, "id = + 1i" that baffled me as to why it compiled.
Once I realized that it was legal, I noticed that it was producing the wrong
result (aside from the obvious typo).
It appears that always becomes 0 inside gcc. The cut-and-paste
below is from my computer at my desk at w
--- Comment #2 from bangerth at dealii dot org 2007-05-01 17:01 ---
> int x[4];
> for(n=0;n<5;n++)
> x[n]=10;
You're asking for trouble here.
That said, we shouldn't produce a compiler error. I can't seem to reproduce
this, what platform is this on?
W.
--
bangerth at deali
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 15:36 ---
> When I try compile a small program I get an error.
small undefined code at that :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When I try compile a small program I get an error.
[EMAIL PROTECTED]:~> gcc -Wall prog.c -O2 -S
prog.c: In function main:
prog.c:21: error: Attempt to delete prologue/epilogue insn:
(insn/f 92 91 93 0 (set (mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 S4 A8]
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-01 14:55
---
As with pr31251, I do not see the segfault here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-01 14:47
---
With IMPLICIT NONE the double code path goes away and we get just one correct
error message.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-05-01 14:18 ---
Closely related to PR 31251.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
BugsT
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-05-01 14:13 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-05-01 14:11 ---
Subject: Bug 31732
Author: tkoenig
Date: Tue May 1 14:11:36 2007
New Revision: 124326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124326
Log:
2007-05-01 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #1 from jakub at gcc dot gnu dot org 2007-05-01 14:10 ---
Zdenek, this seems to be also related to your cfg cleanup changes.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-01 14:05
---
So my guess is this is related to PR22488 which is rotting since some time...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-05-01 14:00
---
Without -fstrict-aliasing we mark this_20->functor_ = D.2946; obviously
necessary
because it is is_hidden_global_store ():
;; Function sigc::slot0 A::bar() (_ZN1A3barEv)
-Marking useful stmt: this_20->functor_ =
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-05-01 13:35
---
Created an attachment (id=13468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13468&action=view)
slightly simplified testcase
I don't see anything wrong with the testcase. I changed it to not take the
addr
--- Comment #9 from dgregor at gcc dot gnu dot org 2007-05-01 13:32 ---
The easy fix is to SET_TYPE_STRUCTURAL_EQUALITY (fulltype), which will force
structural equality checks rather than use canonical types. I usually don't
like this solution, but it's better than duplicating all of the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-01 11:17 ---
Zdenek, this may be yours.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
/home/richard/src/trunk2/gcc/testsuite/g++.dg/gomp/pr26913.C: In function 'void
_Z3bazv.omp_fn.0(void*)':^M
/home/richard/src/trunk2/gcc/testsuite/g++.dg/gomp/pr26913.C:14: error:
unnecessary EH edge 5->6^M
/home/richard/src/trunk2/gcc/testsuite/g++.dg/gomp/pr26913.C:14: internal
compiler error: ve
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #2 from rob1weld at aol dot com 2007-05-01 10:19 ---
Successfully _forced_ the compile on Cygwin platform and posted a seperate
report about the segmentation fault issue at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31761
After running "make -i check" on Cygwin compile I a
--- Comment #5 from rob1weld at aol dot com 2007-05-01 09:16 ---
This "make -i check" report shows Java compiled with ZERO errors:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html
gcc version 4.2.0 20070427 (prerelease)
---
=== libjava tests ===
Running target unix
=== l
--- Comment #15 from pluto at agmk dot net 2007-05-01 08:58 ---
(In reply to comment #14)
typed_rep points to:
N4sigc8internal14typed_slot_repINS_12bind_functorILin1ENS_16pointer_functor1IPvS4_EEPl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
83 matches
Mail list logo
