On 2005-06-18 13:52:01 +0200, Toon Moene wrote:
Vincent Lefevre wrote:
Saying that the x86 processor is buggy is just completely silly.
Only some gcc developers think so.
No, Kahan thinks so too (sorry, can't come up with a link just right
now).
I'd be very interested in such a link.
On 2005-06-18 16:45:06 -0400, Robert Dewar wrote:
Mattias Karlsson wrote:
Since the gcc-is-buggy solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.
To this you can add
3) generate less efficient code
Not by changing the rounding
On Sun, 19 Jun 2005, Vincent Lefevre wrote:
Since the gcc-is-buggy solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.
This remains to see. BTW, the Opteron uses SSE by default. Did you see
a lot of regressions?
Opteron is not an issue, when I
On 2005-06-18 18:01:33 -0400, Robert Dewar wrote:
Laurent GUERBY wrote:
If you code run in extra range issue then you'll get expected
results on x86 and it will fail everywhere else, a nice
way to detect those issues indeed (and you won't face
this if you developped your code on non x86).
Vincent Lefevre [EMAIL PROTECTED] writes:
| Other solutions that would fix the bug (but not ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C implementation.
As far as I can see, there is no such claim.
-- Gaby
On 2005-06-19 11:12:49 +0200, Gabriel Dos Reis wrote:
Vincent Lefevre [EMAIL PROTECTED] writes:
| Other solutions that would fix the bug (but not ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C implementation.
As far as I can see, there is no such claim.
The standard
On Sun, 19 Jun 2005, Vincent Lefevre wrote:
Since the gcc-is-buggy solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.
This remains to see. BTW, the Opteron uses SSE by default. Did you see
a lot of regressions?
Opteron is not an issue, when I
Vincent Lefevre [EMAIL PROTECTED] writes:
| I don't understand your IEEE = IEEE. To make things clearer:
| IEEE 754 explicitly allows an extended exponent range. The ISO C
| language doesn't. But this can be solved by stores, then there
| wouldn't by any problem as far as the standards are
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote:
| On Sun, 19 Jun 2005, Vincent Lefevre wrote:
|
| Since the gcc-is-buggy solution of changing x87 rounding modes will:
| 1) Be a lot of work.
| 2) Cause a lot of regressions.
|
| This
--- Gabriel Dos Reis wrote:
Vincent Lefevre writes:
| Other solutions that would fix the bug (but not
ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C
implementation.
As far as I can see, there is no such claim.
It's implied when using -std=c99
[EMAIL PROTECTED] (Florian Weimer) wrote on 18.06.05 in [EMAIL PROTECTED]:
* Paul Schlie:
So in effect the standard committee have chosen to allow any program which
invokes any undefined behavior to behave arbitrarily without diagnosis?
This is a good thing?
It's the way things are.
[EMAIL PROTECTED] (Robert Dewar) wrote on 18.06.05 in [EMAIL PROTECTED]:
Here is an interesting example I have used sometimes to indicate just
how this kind of information can propagate in a manner that would result
in unexpected chaos. (Ada but obvious analogies in other languages)
Kai Henningsen wrote:
But at least, in that case, the compiler could easily issue the
(presumably not required by the standard) warning that the else branch is
unreachable code.
Yes, absolutely, a compiler should generate warnings as much as possible when
it is making these kind of
On 2005-06-19 11:42:04 +0200, Gabriel Dos Reis wrote:
Vincent Lefevre [EMAIL PROTECTED] writes:
| I don't understand your IEEE = IEEE. To make things clearer:
| IEEE 754 explicitly allows an extended exponent range. The ISO C
| language doesn't. But this can be solved by stores, then there
On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
since you seem OK with that solution, would you mind preparing a patch?
(discussions are not executables; someone needs to make things happen.)
This is complete non-sense. One doesn't prepare a patch for an invalid
bug.
--
Vincent Lefvre
On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote:
--- Gabriel Dos Reis wrote:
Vincent Lefevre writes:
| Other solutions that would fix the bug (but not
ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C
implementation.
As far as I can see, there is no such
On Jun 19, 2005 12:55 PM, Vincent Lefevre [EMAIL PROTECTED] wrote:
On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
since you seem OK with that solution, would you mind preparing a patch?
(discussions are not executables; someone needs to make things happen.)
This is complete
On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
I'm testing a patch that resolves the issue. I expect to have additional
details within 24 hrs, and will let you know details.
Is this bug #21405, or some other versioning issue?
thanks -mike
Hi,
it looks like, today, even the simplest queries (by PR #) take forever
to complete. Any idea why?
Thanks,
Paolo.
Mike Hearn wrote:
On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
I'm testing a patch that resolves the issue. I expect to have additional
details within 24 hrs, and will let you know details.
Is this bug #21405, or some other versioning issue?
The issue that Benjamin
Paolo Carlini wrote:
it looks like, today, even the simplest queries (by PR #) take forever
to complete. Any idea why?
Works fine now, sorry for the false alarm: maybe just a temporary high load.
Paolo.
I cannot make sourceware faster, unfortunately :)
I can make sure all the queries are using the right indexes, etc, which
i do.
(I monitor index/key efficiency on the server, as well as number of temp
tables created, scanned, blah blah blah)
On Sun, 2005-06-19 at 15:04 +0200, Paolo Carlini
Daniel Berlin wrote:
I cannot make sourceware faster, unfortunately :)
I can make sure all the queries are using the right indexes, etc, which
i do.
(I monitor index/key efficiency on the server, as well as number of temp
tables created, scanned, blah blah blah)
Ok ;) FWIW, I can confirm that
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
| since you seem OK with that solution, would you mind preparing a patch?
| (discussions are not executables; someone needs to make things happen.)
|
| This is complete non-sense. One doesn't
Haren Visavadia [EMAIL PROTECTED] writes:
| --- Gabriel Dos Reis wrote:
| Vincent Lefevre writes:
|
| | Other solutions that would fix the bug (but not
| ultimate solutions):
| | 1) Do not claim that gcc is a conforming ISO C
| implementation.
|
| As far as I can see, there is no such
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote:
| --- Gabriel Dos Reis wrote:
| Vincent Lefevre writes:
|
| | Other solutions that would fix the bug (but not
| ultimate solutions):
| | 1) Do not claim that gcc is a conforming ISO C
|
On Jun 19, 2005, at 9:54 AM, Gabriel Dos Reis wrote:
Vincent Lefevre [EMAIL PROTECTED] writes:
| Yes, and if GCC developers think it is better to lie concerning the
| C standard comformance, this could be acceptable when such an option
| is given, but this should be clearly documented.
On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
If you think it is an invalid bug, then it effectively is a complete
non-sense that you continue making noise on this list about it.
I've never said that I thought it was an invalid bug.
FWIW, I would remind you that this is not
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| If you think it is an invalid bug, then it effectively is a complete
| non-sense that you continue making noise on this list about it.
|
| I've never said that I thought it was an invalid bug.
On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote:
What exactly do you want to _achieve_ with this thread? Please, do tell,
because you've completely lost most of us by now, I'm sure.
Just that the problem should be considered as a bug, and not a bug
in the users' code (for some of them),
[EMAIL PROTECTED] wrote on 19/06/2005 18:33:55:
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| If you think it is an invalid bug, then it effectively is a complete
| non-sense that you continue making noise on this list about it.
On Sun, 19 Jun 2005 15:06:58 +0200, Paolo Carlini wrote:
The issue that Benjamin just fixed is very simple to explain (much less
to fix ;) : some recently added exported symbols had the default v6
version, that is, 3.4.0, instead of 3.4.5.
Ah I see :)
Are the new symbols new APIs, or will
Mike Hearn wrote:
Are the new symbols new APIs, or will pre-existing code compiled with GCC
3.4.5 depend on these symbols when they would not have done when compiled
with GCC 3.4.0?
AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
in 4.0.1.
Paolo.
Thank you very much. Note that you're re-closed is incorrect because
a SUSPENDED bug is still open (but suspended); look at bugzilla's
documentation... This is important for the above reasons and also
because users will be able to see this bug when searching on bugzilla
(let's hope that this will
On 2005-06-19 15:54:20 +0200, Gabriel Dos Reis wrote:
Vincent Lefevre [EMAIL PROTECTED] writes:
| Yes, and if GCC developers think it is better to lie concerning the
| C standard comformance, this could be acceptable when such an option
| is given, but this should be clearly documented.
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote:
| What exactly do you want to _achieve_ with this thread? Please, do tell,
| because you've completely lost most of us by now, I'm sure.
|
| Just that the problem should be considered as a bug,
On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
Also I think GCC is not the one who is defining it either. It is
glibc who is defining that so complain to them instead.
Thanks for the information (I'm a bit surprised because these are gcc
command-line options that are the first cause of
Michael Veksler [EMAIL PROTECTED] writes:
| [EMAIL PROTECTED] wrote on 19/06/2005 18:33:55:
|
| Vincent Lefevre [EMAIL PROTECTED] writes:
|
| | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| | If you think it is an invalid bug, then it effectively is a complete
| | non-sense that
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
| Also I think GCC is not the one who is defining it either. It is
| glibc who is defining that so complain to them instead.
|
| Thanks for the information (I'm a bit surprised because these are gcc
why??
The problem is that in 'expand_vector_operations_1()' in
tree-vect-generic.c we call 'optab_for_tree_code()' to get an optab for
VEC_RSHIFT_EXPR; 'optab_for_tree_code' does not have a case for
VEC_RSHIFT_EXPR, so the vector-lowering function concludes that this
tree-code is not
On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote:
... because at least for the vector-shift case I need to
check that the shift operand is constant, and only then return
optab_shri/shli.
This isn't true. Just because the altivec patterns don't accept
anything other than a
Richard Henderson [EMAIL PROTECTED] wrote on 19/06/2005 19:49:46:
On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote:
... because at least for the vector-shift case I need to
check that the shift operand is constant, and only then return
optab_shri/shli.
This isn't true.
On 2005-06-19 17:33:55 +0200, Gabriel Dos Reis wrote:
Then, care to explain
On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
since you seem OK with that solution, would you mind preparing a patch?
(discussions are not executables; someone needs to make things happen.)
I noticed that the (vec_select:m ...) couldn't be matched by (match_operand:m
...).
For example:
(set (vec_select:HI (reg:V4QI r3)
(parallel [(const_int 0) (const_int 1)]))
(const_int 0x1122))
couldn't be matched by:
[(set (match_operand:HI 0 register_operand =R)
On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote:
Altivec does support non immediate shift amount (even if less efficiently -
I have to put the shift amount in a vector register first). But since we
have defined these optabs to represent shift operations that take immediate
shift
On Sun, 19 Jun 2005, Vincent Lefevre wrote:
On 2005-06-19 11:12:49 +0200, Gabriel Dos Reis wrote:
Vincent Lefevre [EMAIL PROTECTED] writes:
| Other solutions that would fix the bug (but not ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C implementation.
As far as
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
From: Joseph S. Myers [EMAIL PROTECTED]
no requirements means that *any* translation conforms in the case of
undefined behavior. Only those executions not involving undefined
behavior have any requirements.
What delineates the
On 2005-06-19, at 17:59, Vincent Lefevre wrote:
On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
Also I think GCC is not the one who is defining it either. It is
glibc who is defining that so complain to them instead.
Thanks for the information (I'm a bit surprised because these are gcc
AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
in 4.0.1.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109. This is
also http://sources.redhat.com/bugzilla/show_bug.cgi?id=1022.
This is probably a bug in binutils but I don't have a warm fuzzy
feeling about this.
Steven J. Hill kirjoitti:
zouqiong wrote in 15.4.2005 10:16:
i download the release version of gcc-2.95.3, and binutils 2.15,
then i did the following things:
1. mkdir binutils-build;
.../../binutils-2.15/configure --prefix=/opt/gcc
--target=mipsel-linux -v;
make;make install;
2.i
Richard Henderson [EMAIL PROTECTED] wrote on 19/06/2005 20:33:02:
On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote:
Altivec does support non immediate shift amount (even if less
efficiently -
I have to put the shift amount in a vector register first). But since
we
have
zouqiong kirjoitti:
.../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux
--enable-languages=c --disable-checking -enable-shared -v;
This is not true at all
-B=/opt/gcc-2.95//mipsel-linux/bin/
-I=/opt/gcc-2.95//mipsel-linux/include
Because these rows tell that a
On Sunday 19 June 2005 04:48, Gabriel Dos Reis wrote:
Mathieu Malaterre [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Tommy Vercetti [EMAIL PROTECTED] writes:
| | On Sunday 19 June 2005 03:03, you wrote:
| | Elsa does not parse C++.
| |
| | Elsa is for C/C++, so it says on
Mark Mitchell [EMAIL PROTECTED] writes:
GCC 4.0.1 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616
This version has the libstdc++ versioning changes, and most of the PO
file updates. The PO file that Joseph checked in today is not
included, but will be
On Sun, Jun 19, 2005 at 11:46:52PM +0300, Dorit Naishlos wrote:
The thought was to supply an API that would let the vectorizer ask for the
minimal capability it needs - if all we need is a vector shift of a
constant value in bytes, lets ask exactly for that, so that targets that
don't support
Geoffrey Keating [EMAIL PROTECTED] writes:
| libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc
|
| appears to fail, with lots of complaints like
|
| c99_classification_macros_c.cc:49:21: error: macro isgreaterequal requires
2 arguments, but only 1 given
|
| but the
Below is the error I receive when attempting to run a newly installed
version of netscape 4.79 on centOS 4.0 (RHEL 3), which is my personal
computer at home. This is the only browser that works on linux that is
compatible with the Thorium installer for BMC Patrol. I downloaded the
browser from
On 19/06/2005, at 3:45 PM, Gabriel Dos Reis wrote:
Geoffrey Keating [EMAIL PROTECTED] writes:
| libstdc++-v3/testsuite/26_numerics/cmath/
c99_classification_macros_c.cc
|
| appears to fail, with lots of complaints like
|
| c99_classification_macros_c.cc:49:21: error: macro
isgreaterequal
Geoff Keating [EMAIL PROTECTED] writes:
| On 19/06/2005, at 3:45 PM, Gabriel Dos Reis wrote:
|
| Geoffrey Keating [EMAIL PROTECTED] writes:
|
| | libstdc++-v3/testsuite/26_numerics/cmath/
| c99_classification_macros_c.cc
| |
| | appears to fail, with lots of complaints like
| |
| |
For those who are attending the gcc summit for the first time,
here's a page with a bit more detail about how to
get from the airport to the hotel, etc.
http://kegel.com/gcc/summit2005.html
It's pretty easy, but I remember figuring it out
the first time was harder, so I figured a page
of notes
I complied this list for the local C++ users group several months ago,
it might be helpful.
http://www.nwcpp.org/Misc/Tools_DavidBremner.html
Regards,
David Bremner
Paul Schlie wrote:
The root of the concern being expressed is with respect to the compilers use
of statically identified undefined behaviors as opportunities to invoke
alternative semantics which are easily identified as being inconsistent with
the target's native semantics, thus altering the
Looking at http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00837.html,
LAST_UPDATED: Sun Jun 12 16:16:31 UTC 2005, and this
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01121.html,
LAST_UPDATED: Fri Jun 17 08:33:08 UTC 2005 (and the later one
Thought i should report this...
Building 4.0.1 RC2, i get this error:
make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
make[1]: Entering directory
`/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
make[1]: *** No rule to make target
On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote:
Thought i should report this...
Building 4.0.1 RC2, i get this error:
make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
make[1]: Entering directory
Yes i did... i always do and have never had a problem doing so before.
I will try building in a different directory though and report back.
http://gcc.gnu.org/install/configure.html
To be honest I'm always surprised when it works at all.
-eric
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
The root of the concern being expressed is with respect to the compilers use
of statically identified undefined behaviors as opportunities to invoke
alternative semantics which are easily identified as being inconsistent with
the
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-19
06:32 ---
Subject: Bug 22116
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-19 06:32:31
Modified files:
gcc: ChangeLog tree-ssa-pre.c
Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-19 06:38
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 22055 depends on bug 22116, which changed state.
Bug 22116 Summary: [4.1 Regression] PRE of COMPLEX_EXPR causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22116
What|Old Value |New Value
--- Additional Comments From hkubota at gmx dot net 2005-06-19 06:49
---
Same here when doing probably the same. Used vanilla gcc-3.4.4 sources.
/var/tmp/gcc-3.4.4/h8300-elf/h8300s/normal/libstdc++-v3/include/bits/locale_facets.tcc:
In member function `_InIter std::money_get_CharT,
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:11 ---
Reduced:
CALL TT(10)
CONTAINS
SUBROUTINE TT (I)
INTEGER, INTENT(INOUT) :: I
I = I + 1
END SUBROUTINE
END
Intel says: An actual argument is an expression or constant; this is not valid
since the
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:14 ---
TYPE TEST
REAL, POINTER :: A
END TYPE
INTEGER, POINTER :: IP
TYPE(TEST) :: DD
DD=TEST(NULL(IP))
END
Intel says The type of the NULL(MOLD) element in a structure-constructor
differs from the type of the
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:15 ---
A derived type name can not be the same as the name of any intrinsic type
[DOUBLEPRECISION], says Intel. Confirmed.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:22 ---
I can see why one would expect this to be invalid, but I can't find a compiler
that rejects it (I tried Lahey, Intel, Sun, Portland, MIPS, NEC SX-5, IBM). Does
someone have the Standard reference?
--
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:24 ---
Intel says: fortcom: Error: a.f90, line 10: This derived type name has not been
declared. [FUNCTIONPARAMS]. Confirmed.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:34 ---
On Pentium III (Coppermine), 864 MHz, 256 KB cache, with linux. Timing in
seconds:
g77: 9.52s
gfortran: 9.49s
g77 -O2: 3.11s
gfortran -O2: 3.39s
g77 -O3 -ffast-math: 3.09s
gfortran -O3 -ffast-math:
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
07:51 ---
In fact, gfortran does issue a runtime error (if iostat and err tags are
removed):
Fortran runtime error: FILE parameter must not be present in OPEN statement
But sure, it could be usefull to detect
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-19
08:09 ---
Well, this bug seems to have been fixed by Paul Thomas' character patches. I
don't see the segfault any more on i686-linux (neither this one nor the ones in
the duplicate bug, PR21083).
Could someone
--- Additional Comments From amd at store20 dot com 2005-06-19 09:54
---
It happened with me on 20050618 snapshot bootstrap.
It didn't happen on 20050611
stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -march=pentium3
-pipe -fprofile-generate -DIN_GCC -W -Wall
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-19
10:22 ---
I am using FSF Binutils 2.15
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--- Additional Comments From laurent at guerby dot net 2005-06-19 10:47
---
All fixed, no more cxg failures on x86-linux and x86_64-linux, thanks!
--
What|Removed |Added
--- Additional Comments From laurent at guerby dot net 2005-06-19 10:53
---
Fixed (various other: PR22103 PR22105 PR22053 PR22055)
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-19
11:05 ---
Reopening...
--
What|Removed |Added
Status|RESOLVED|REOPENED
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-19
11:09 ---
...to end this pointless discussion.
Some people call this a bug in the x87 series. Other call it a bug in
gcc. See these mails at least for the reason why this could be considered
a bug in gcc:
--- Additional Comments From laurent at guerby dot net 2005-06-19 11:14
---
On x86_64 and x86-linux as of LAST_UPDATED: Sun Jun 19 07:48:06 UTC 2005, still
failing. More information:
Works at -O0, -O1, fails at -O2 but
works at -O2 -fno-tree-dce
--
What|Removed
--- Additional Comments From laurent at guerby dot net 2005-06-19 11:46
---
Here is a reduced test case, works at -0O, fails at -O1 works at -O1
-fno-tree-dce. First .tNN to be different is p.adb.t24.forwprop1.
--
procedure P is
function F return Integer is
begin
return 1;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
12:18 ---
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
12:18 ---
*** Bug 1098 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
12:33 ---
Huh:
# VUSE D.486_68;
# VUSE C.26_118;
(*a.3_27)[-1 ...]{lb: -1 sz: 1} = D.486;
Why is there no V_MUST_DEF/V_MAY_DEF in there?
This is an aliasing bug.
--
What|Removed
--
What|Removed |Added
Summary|ACATS wrong array copy code |[4.1 Regression] wrong array
|c52102b c52102d (works with |copy code (ACATS c52102b
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
13:04 ---
*** Bug 22045 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
13:04 ---
*** This bug has been marked as a duplicate of 21291 ***
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
13:15 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From jv244 at cam dot ac dot uk 2005-06-19 13:17
---
someone have the Standard reference?
14.6.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20902
See PR10901
Test program (nonlocalgoto.c):
extern int puts (const char *);
extern void abort (void);
int main (void)
{
__label__ l1;
void foo (void)
{
void bar (void)
{
puts (goto l1);
goto l1;
}
bar ();
}
foo ();
abort ();
l1:
puts (label l1);
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
13:20 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From laurent at guerby dot net 2005-06-19 13:25
---
Note that with the following patch on the reduced testcase (supressing the
anonymous array) it works:
- A : array (-F .. 1) of Boolean;
+ type BA is array (Integer range ) of Boolean;
+ A : BA (-F .. 1);
Compiling any program on i686-apple-darwin with -fpic causes an ICE
#include stdio.h
int main( void )
{
printf(Hello World.\n);
return 0;
}
%gcc hello.c -fpic
hello.c: In function `main':
hello.c:9: internal compiler error: in instantiate_virtual_regs_lossage, at
1 - 100 of 215 matches
Mail list logo
