--- Comment #8 from amodra at bigpond dot net dot au 2005-11-17 07:17
---
In any case, I think the backporting 4.1 patches won't fix this problem
reliably. I can't see anything that really prevents a similar problem on
mainline, ie. of the first scheduling pass moving some instruction
Take the following simple source:
int X[4] = {1};
int *foo() { return &X[1]; }
With -static -O2, we get:
_foo:
lis r3,ha16(_X+4)
la r3,lo16(_X+4)(r3)
blr
---
Which is the most optimial.
With -O2 -mdynamic-no-pic, we get:
_foo:
lis r3,ha16(_X)
la r3,lo16(
--- Comment #5 from jgoerzen at complete dot org 2005-11-17 03:31 ---
Subject: Re: Unrecognized opcode bootstrapping gcc on AIX 5/POWER
On Wed, Nov 16, 2005 at 04:19:42PM -, pinskia at gcc dot gnu dot org wrote:
>
> That is because GNU ld does not work fully for AIX 5 with weak sy
Dear Sirs,
Sorry to bother you. Recently I met with a problem in strtof, a sample
program is like:
#include
#include
main ()
{
float p = strtof ("-10", NULL);
printf ("-10 transform to %f\n", p);
}
In my up-to-date gentoo and debian system, gcc-3.3.6 and gcc-3.3.5 alway
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18594
--- Comment #30 from uweigand at gcc dot gnu dot org 2005-11-17 01:08
---
With that patch applied, Ada bootstraps on s390-ibm-linux and
s390x-ibm-linux. Regression test results are at:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00831.html
http://gcc.gnu.org/ml/gcc-testresults/20
--- Comment #7 from dje at gcc dot gnu dot org 2005-11-17 00:59 ---
That failure is fixed by the zero_reg_mem predicate changes from March:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/predicates.md.diff?cvsroot=gcc&r1=1.6&r2=1.7
This is why I didn't want to go down the
--- Comment #26 from geoffk at gcc dot gnu dot org 2005-11-17 00:33 ---
That's weird. The library exists, there's a -L path pointing to it, it has the
right architecture, so why does libtool say it can't be found?
When I have 2.2 installed, I get a very similar complaint
ld64 failed:
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-17 00:02 ---
A regression hunt with an hppa-linux cross compiler on powerpc-linux using
the testcase from comment #2 identified this large RTL loop versioning
patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=97481
r97481 | hagog |
--- Comment #6 from amodra at bigpond dot net dot au 2005-11-16 23:58
---
Applying this patch results in a bootstrap failure on powerpc64-linux.
/src/gcc-4.0/gcc/libgcc2.c: In function '__fixtfti':
/src/gcc-4.0/gcc/libgcc2.c:1191: error: unrecognizable insn:
(insn:HI 14 13 15 0 /src/gc
--- Comment #37 from rth at gcc dot gnu dot org 2005-11-16 23:47 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #36 from rth at gcc dot gnu dot org 2005-11-16 23:43 ---
Subject: Bug 23497
Author: rth
Date: Wed Nov 16 23:43:39 2005
New Revision: 107107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107107
Log:
PR middle-end/23497
* tree-ssa.c (warn_uninitialized
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-16 23:25 ---
This is a regression from 3.4.0 which would not ICE on this at all, though
would provide wrong-debug/wrong undwind info.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-16 23:22 ---
(In reply to comment #4)
> The current code for the ICE came in with PR 15813 but it seems like it
> should have ICE before that.
Or provided the wrong undwind info really.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-16 23:18 ---
The current code for the ICE came in with PR 15813 but it seems like it should
have ICE before that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24908
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-16 23:10 ---
This is the assert by the way:
/* Saving a register in a register. */
gcc_assert (call_used_regs [REGNO (dest)]
&& (!fixed_regs [REGNO (dest)]
--- Comment #2 from amodra at bigpond dot net dot au 2005-11-16 23:04
---
.ce3
(insn/f 81 80 82 0 /src/tmp/24908.c:11 (set (reg:SI 12 12)
(reg:SI 65 lr)) -1 (nil)
(expr_list:REG_DEAD (reg:SI 65 lr)
(expr_list:REG_MAYBE_DEAD (const_int 0 [0x0])
(nil
--- Comment #1 from jb at gcc dot gnu dot org 2005-11-16 23:00 ---
As discussed on IRC, the solution is to use noinst_LTLIBRARIES instead of
EXTRA_LTLIBRARIES. It was also suggested to name the library
libmatmul_convenience.a. Example in libffi/Makefile.am
--
jb at gcc dot gnu dot or
This patch breaks the build of libgfortran on darwin.
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00601.html
-all_load ./.libs/libmatmul.a -lm ./.libs/libmatmul.a -lc
-Wl,-single_module -install_name
/Volumes/export/gcc/gcc-svn/head/testbin/lib/libgfortran.0.dylib
-compatibility_version 1 -curr
--- Comment #9 from kargl at gcc dot gnu dot org 2005-11-16 22:45 ---
(In reply to comment #1)
> I mean:
> #define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = (r_) + (i_) * 1.0fi} while (0)
>
Does this do the right thing in the presence of special cases?
See PR 24581.
--
http://gcc.gnu.or
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-16 22:34
---
There was a split pattern that was converting a set of a floating point value
into a set of an integer value. This doesn't match anything if the register
being set is a Maverick Co-pro register, and in general we
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-16 22:31
---
Subject: Bug 24861
Author: rearnsha
Date: Wed Nov 16 22:31:14 2005
New Revision: 107105
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107105
Log:
PR target/24861
* arm.md (split for movsf
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-16 22:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-16 22:14
---
Subject: Bug 24861
Author: rearnsha
Date: Wed Nov 16 22:14:38 2005
New Revision: 107104
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107104
Log:
PR target/24861
* arm.md (split for movsf
--- Comment #1 from janis at gcc dot gnu dot org 2005-11-16 22:09 ---
Created an attachment (id=10261)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10261&action=view)
minimized testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24908
Eight SPEC CPU2000 tests fail with an ICE in dwarf2out_frame_debug_expr,
at dwarf2out.c:1554, on powerpc-linux with the options "-g -fpic -O2
-funroll-loops -fno-tree-copyrename". The minimized testcase also fails
with GCC 4.0.0 with those options plus "-fweb -frename-registers" which
are now turn
I am getting a syntax error when compiled as C but not C++.
int f()
{
int x, y, ;
}
Andrew Pinski commented:
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from at least 3.4.0 as 3.3.3 w
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-16 21:32
---
And for the realy record this was fixed by the patch which fixed PR 24003 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-16 21:20
---
*** Bug 24906 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 2005-11-16 21:20 ---
This is a dup of bug 19266 which is fixed for 4.1.0.
*** This bug has been marked as a duplicate of 19266 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Hi,
I get the following message when I try to compile a simple C++ source file
using strings:
strbug.cpp: In member function 'void AClass::meth(AClass::AnInterface&)':
strbug.cpp:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropria
--- Comment #4 from laurent at guerby dot net 2005-11-16 21:04 ---
I have seen the three tests (c954025 c954026 c99004a) failing from time to time
on my x86 or x86_64-linux builds on 4.0 and 4.1, I'll look into increasing
delay values (which are currently shortened in GCC version of ACAT
--- Comment #3 from aldyh at gcc dot gnu dot org 2005-11-16 20:54 ---
What the heck...death by dwarf. I'll take a look at this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #35 from schwab at suse dot de 2005-11-16 20:42 ---
__imag__ a = b looks like a simple assignment, thus it should act like a simple
assignment. You can pack a struct { short a,b; } in a single register, but
that should not result in a warning when assigning a part of it, eve
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-16 20:39
---
Subject: Re: COMPLEX_ASSIGN is wrong
"pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes:
[...]
| > Subject: Re: COMPLEX_ASSIGN is wrong
| >
| > "pinskia at gcc dot gnu dot org" <[EMAIL PROTECT
--- Comment #34 from gdr at integrable-solutions dot net 2005-11-16 20:29
---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about
std::complex
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I should also note that:
| http://gcc.gnu.org/onlined
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-16 20:29 ---
Subject: Re: COMPLEX_ASSIGN is wrong
>
>
>
> --- Comment #6 from gdr at integrable-solutions dot net 2005-11-16 20:27
> ---
> Subject: Re: COMPLEX_ASSIGN is wrong
>
> "pinskia at gcc dot gnu dot org"
--- Comment #10 from jason at gcc dot gnu dot org 2005-11-16 20:27 ---
Subject: Bug 24580
Author: jason
Date: Wed Nov 16 20:27:26 2005
New Revision: 107099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107099
Log:
PR c++/24580
* method.c (locate_copy): Also use
--- Comment #6 from gdr at integrable-solutions dot net 2005-11-16 20:27
---
Subject: Re: COMPLEX_ASSIGN is wrong
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I should also note that:
| http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex
|
| recomends against us
--- Comment #9 from jason at gcc dot gnu dot org 2005-11-16 20:26 ---
Subject: Bug 24580
Author: jason
Date: Wed Nov 16 20:26:06 2005
New Revision: 107098
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107098
Log:
PR c++/24580
* method.c (locate_copy): Also use s
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-16 20:24
---
Subject: Re: COMPLEX_ASSIGN is wrong
"pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: COMPLEX_ASSIGN is wrong
|
| > yields an lvalue. do whatever you want in the *middle end*
--- Comment #8 from jason at gcc dot gnu dot org 2005-11-16 20:22 ---
Subject: Bug 24580
Author: jason
Date: Wed Nov 16 20:22:00 2005
New Revision: 107097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107097
Log:
PR c++/24580
* method.c (locate_copy): Also use s
--- Comment #6 from aldyh at gcc dot gnu dot org 2005-11-16 20:10 ---
I'll take a look at this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #33 from mark at codesourcery dot com 2005-11-16 20:08 ---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
warning about std::complex
pinskia at gcc dot gnu dot org wrote:
> --- Comment #32 from pinskia at gcc dot gnu dot org 2005-11-16 19:58
> ---
--- Comment #32 from pinskia at gcc dot gnu dot org 2005-11-16 19:58
---
(In reply to comment #31)
> This is not a valid argument.
What would you consider a valid argument for an extension which is not that
well documented?
> The point of warnings is not to tell the user how the compil
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-16 19:53 ---
I should also note that:
http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex
recomends against using the extensions anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-16 19:50 ---
Subject: Re: COMPLEX_ASSIGN is wrong
> yields an lvalue. do whatever you want in the *middle end*, but be
> sure you don't transmute that basic semantics constraint.
Gaby, it also prevents a huge amount of optimi
--- Comment #6 from dje at gcc dot gnu dot org 2005-11-16 19:49 ---
Patch committed. Should be fixed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-16 19:43
---
Subject: Re: New: COMPLEX_ASSIGN is wrong
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The defintion of COMPLEX_ASSIGN is wrong,
that is wrong according to Andrew.
| This is in reference
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-16 19:31 ---
A regression hunt using an s390-linux cross compiler on powerpc-linux
identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=103955
r103955 | ian | 2005-09-06 17:51:48 + (Tue, 06 Sep 2005) | 3 li
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-16 19:28
---
Subject: Re: Koenig found functoid ref, but "cannot be used as a function"
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Actually IIRC Koenig lookup only finds functions and not variables.
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:14
---
Subject: Re: [3.4/4.0/4.1 Regression] bizarre diagnostic on valid (?)
constructor
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| I'm pretty sure I've seen this somewhere before -- the question wa
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:05
---
Subject: Re: [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr
"mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Gaby, please apply the simple OBJ_TYPE_REF patch so that we can r
Right now dotprod_c* does:
./generated/dotprod_c4.c: COMPLEX_ASSIGN(conjga, REALPART (*pa), -IMAGPART
(*pa));
./generated/dotprod_c16.c: COMPLEX_ASSIGN(conjga, REALPART (*pa),
-IMAGPART (*pa));
./generated/dotprod_c8.c: COMPLEX_ASSIGN(conjga, REALPART (*pa), -IMAGPART
(*pa));
./gener
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-16 18:58 ---
I mean:
#define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = (r_) + (i_) * 1.0fi} while (0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
--- Comment #31 from mark at codesourcery dot com 2005-11-16 18:58 ---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
warning about std::complex
pinskia at gcc dot gnu dot org wrote:
> From the C perspective the warning is correct as you are loading piece wise
> which
The defintion of COMPLEX_ASSIGN is wrong, it should be defined as:
#define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = r_ + i_ * 1.0fi} while (0)
This is in reference to PR 23497.
--
Summary: COMPLEX_ASSIGN is wrong
Product: gcc
Version: 4.1.0
Status: UNCO
--- Comment #17 from tedoc2000 at gmail dot com 2005-11-16 18:57 ---
Okay.. This definitely seems to be a problem with having libiconv.a in
%{prefix}/lib.
If I move /opt/OPSWbuildtools/1.0.1/lib/libconv.a to
/opt/OPSWbuildtools/1.0.1/lib/libconv.a.blah and run my program, it works as
exp
--- Comment #30 from rth at gcc dot gnu dot org 2005-11-16 18:56 ---
Clearly the only way to stop getting mail in this thread is to fix it.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #29 from pinskia at gcc dot gnu dot org 2005-11-16 18:54
---
(In reply to comment #27)
> From libstdc++ perspective, __imag__ ought to be an lvalue. This is a recurent
> issue for C++ complex<>.
Of course the lvalue is moot, I never said __imag__ should not be lvalue, I
do
--- Comment #28 from gdr at gcc dot gnu dot org 2005-11-16 18:47 ---
(In reply to comment #25)
> Subject: Re: [4.1 regression] Bogus 'is used uninitialized...'
> warning about std::complex
>
> schwab at suse dot de wrote:
> > --- Comment #23 from schwab at suse dot de 2005-11-16
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-16 18:45 ---
Confirmed, this comes from a macro expansion, we really should not warn about
this.
The bug is in stmt.c.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from federico at novell dot com 2005-11-16 18:44 ---
In the original code, art_uta_new() is in a separate module (a whole different
library, actually). I don't know if this will affect inlining in this example.
--
federico at novell dot com changed:
What
--- Comment #27 from gdr at gcc dot gnu dot org 2005-11-16 18:44 ---
(In reply to comment #19)
> There are only two choices: either __imag__ is an lvalue, and the code in
> Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
> issue an error.
>
> Nobody wants to s
--- Comment #26 from gdr at gcc dot gnu dot org 2005-11-16 18:40 ---
(In reply to comment #17)
> (In reply to comment #13)
> > It's nice to see that PR bouncing between you all. Although I don't know
> > anything about C++, I want to add my non-constructive comment to this
> > discussion
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-16 18:36 ---
Reduces down to:
int f(void);
void g(void)
{
(unsigned) f();
}
The typeof gets changed over to unsigned.
Maybe this is not a bug after all. Can someone else comment on this?
--
http://gcc.gnu.org/bugzilla/s
When compiling GCC on IA64 HP-UX with --enable-checking=all I get a bus error
in fold_checksum_tree because of the variable 'buf'. It is created as a char
buffer but later cast to a tree struct. On IA64 HP-UX with it's strict
alignment requirements, this results in a bus error because buf is not
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.0
Known to work||4.0.3
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-16 18:30 ---
Here is a further reduced testcase:
unsigned long t(void);
void apic_write_atomic(unsigned long reg, unsigned int v)
{
((__typeof__(*((volatile unsigned int *)((t())+regt());
}
-Wall is all is needed to reprod
--- Comment #2 from arjanv at redhat dot com 2005-11-16 18:23 ---
(compiler flags used were -O2 -Wall)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24900
--- Comment #1 from arjanv at redhat dot com 2005-11-16 18:21 ---
Created an attachment (id=10257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10257&action=view)
fairly minimal testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24900
attached testcase gives a "value computed is not used" warning.
Testcase comes from the linux kernel which spews this for every .c file
compiled
--
Summary: new "value computed is not used" warning in gcc 4.1
Product: gcc
Version: 4.1.0
Status: UNCONF
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-16 18:07 ---
>From looking at the RTL dumps, old-loop is where the difference is introduced
so blocking the meta-bug for loop.c issues (this goes under section a of that
meta bug).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-16 18:05 ---
-floop-optimize2 fixes it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:57
---
*** Bug 24897 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:57
---
*** This bug has been marked as a duplicate of 21317 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-16 17:56 ---
(In reply to comment #3)
> (In reply to comment #2)
> > The only difference at the tree level is:
> That is -O1 vs -O2
And -fno-optimize-sibling-calls makes no difference.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-16 17:55 ---
(In reply to comment #2)
> The only difference at the tree level is:
That is -O1 vs -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-16 17:55 ---
The only difference at the tree level is:
- uta = art_uta_new (clip_x1, clip_y1, clip_x1 + 1, clip_y1 + 1);
+ uta = art_uta_new (clip_x1, clip_y1, clip_x1 + 1, clip_y1 + 1) [tail call];
- uta = art_uta_new (clip_
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:53
---
*** Bug 24896 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:53
---
*** This bug has been marked as a duplicate of 18659 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:48
---
*** Bug 24898 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:48
---
The "Search" button is your friend. -:)
*** This bug has been marked as a duplicate of 22333 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-16 17:46 ---
Created an attachment (id=10256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10256&action=view)
testcase
Testcase. I'll investigate later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
With the attached testcase, we get a SIGSEGV compiling with -O2 -fno-inline,
with -O1 -fno-inline it's fine.
--
Summary: [4.1 Regression] Miscompiles libgnomecanvas
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
--- Comment #5 from dje at watson dot ibm dot com 2005-11-16 17:45 ---
Subject: Re: Python miscompilation - TOC reload
Appended is a proposed patch to backport the easy_fp_constant
change to 4.0. Can you check if this fixes the problem? This patch may
hurt performance becaus
--- Comment #3 from hjl at lucon dot org 2005-11-16 17:35 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01195.html
--
hjl at lucon dot org changed:
What|Removed |Added
---
Ada tests c34007p, c34007r and c45282b.
raised CONSTRAINT_ERROR : c34007p.adb:83 discriminant check failed
--
Summary: CONSTRAINT_ERROR : discriminant check failed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
P
--- Comment #2 from uttamp at us dot ibm dot com 2005-11-16 17:33 ---
Any error which indicates something like, "dummy argument defined to be larger
than actual argument.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
--- Comment #8 from rth at gcc dot gnu dot org 2005-11-16 17:28 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2005-11-16 17:27
---
> So I guess it would be possible right now to fix the bootstrap issue
> by a pure front-end patch. (This doesn't address the more general
> question of whether or not the gimplifier has a bug that can be expos
--- Comment #15 from rth at gcc dot gnu dot org 2005-11-16 17:27 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from schwab at suse dot de 2005-11-16 17:27 ---
Same for test c32001e and c64105b.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24896
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-16 17:27
---
Patch submitted for review.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
RUN c954026
,.,. C954026 ACATS 2.5 05-11-16 18:17:03
C954026 Check that if the original entry call was a conditional or
timed entry call, the expiration time for a requeue with
abort to a protected entry is the original expiration
time.
* C9
This is Ada test c95086b.
/tmp/cvs/gcc-20051116/Build/gcc/xgcc -c -B/tmp/cvs/gcc-20051116/Build/gcc/
-gnatws -O2 -I/tmp/cvs/gcc-20051116/Build/gcc/testsuite/ada/acats/support
c95086b.adb
+===GNAT BUG DETECTED==+
| 4.1.0 20051116 (experimental
--- Comment #14 from rth at gcc dot gnu dot org 2005-11-16 17:23 ---
Subject: Bug 24160
Author: rth
Date: Wed Nov 16 17:23:23 2005
New Revision: 107093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107093
Log:
PR rtl-opt/24160
PR target/24621
* reload1.c
--- Comment #7 from rth at gcc dot gnu dot org 2005-11-16 17:23 ---
Subject: Bug 24621
Author: rth
Date: Wed Nov 16 17:23:23 2005
New Revision: 107093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107093
Log:
PR rtl-opt/24160
PR target/24621
* reload1.c
--- Comment #21 from aph at gcc dot gnu dot org 2005-11-16 17:20 ---
Accesses to static fields should be fixed already when compiling BC.
We generate a call to _Jv_ResolvePoolEntry(Class, int) for every static field
reference, which resolves the target class and returns a pointer to the
1 - 100 of 164 matches
Mail list logo
