--- Comment #5 from hp at gcc dot gnu dot org 2005-10-22 07:40 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01369.html>.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:24
---
Not SPARC/Solaris specific.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:29
---
Present on mainline for SPARC 64-bit too:
http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00788.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:34
---
2005-01-24 Eric Botcazou <[EMAIL PROTECTED]>
PR bootstrap/19364
* config.gcc (sparc-*-elf*): Remove sol2.h, sparc/sol2.h and
sparc/elf.h, add sparc/sp-elf.h.
(sparc-*-rtems*): Li
--- Comment #1 from laurent at guerby dot net 2005-10-22 09:08 ---
I confirm that 4.0.2 and 4.1.0 20051021 (experimental) show the same error:
$ gcc -c levelx.adb
levelx.adb:25:51: no visible subprogram matches the specification for
"Any_Image3"
levelx.adb:26:51: no visible subprogram m
--- Comment #13 from olle at cb dot uu dot se 2005-10-22 09:43 ---
(In reply to comment #12)
> Workaround patch here:
> http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html
>
> Rest of discussion here:
> http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html
>
> Seems to be a gnatbind bug present
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-10-22
09:52 ---
Subject: Re: [4.0 Regression] missing error messages passing vectors with
-mno-altivec -mabi=altivec
I *think* it is also fixed on 4.0; a grep for the error message in
config/rs6000/rs6000.c would confir
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-22 10:37
---
Subject: Bug 24297
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-22 10:37:17
Modified files:
. : ChangeLog Makefile.tpl Makefile.in
Log messa
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-10-22 10:38
---
fix committed, the more complex patch will have to wait for 4.2
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
---
PROBLEM:
Tried to compile libapreq2-2.06 from the FreeBSD ports collection. Failed with
this message:
---
cc -DHAVE_CONFIG_H -I. -I. -I../include
-I/usr/local/include/apache2/modules/perl -I/usr/local/include/apache2
-I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -O -pipe
--- Comment #1 from richard at hirner dot at 2005-10-22 11:05 ---
Created an attachment (id=10044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10044&action=view)
generated with -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
--- Comment #8 from christian dot joensson at gmail dot com 2005-10-22
11:49 ---
oops, sorry, present on sparc/sparc64 linux too, see, e.g,
http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00927.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21554
--- Comment #9 from christian dot joensson at gmail dot com 2005-10-22
11:50 ---
(In reply to comment #8)
> oops, sorry, present on sparc/sparc64 linux too, see, e.g,
> http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00927.html
hmm, make that sparc64
--
http://gcc.gnu.org/bu
--- Comment #1 from jrandom-gcc at i2p dot net 2005-10-22 11:57 ---
Found the cause & can reproduce it. The bug can be reproduced by dealing with
a truncated gzip stream, as shown below. The fix, I believe, would have
GZIPInputStream using inf.getRemaining() to determine the tmp[] buff
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-22 13:05 ---
The following instruction does not make sense at all:
(insn 66 172 67 8 util.c:44 (set (reg/f:SI 75)
(match_insn 677090144 ("C"))) -1 (nil)
(nil))
If you try to compile again, does it work?
--
pinsk
--- Comment #3 from richard at hirner dot at 2005-10-22 13:34 ---
No, I get the same error, even if I compile again without -O and -march.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-22 13:40 ---
I cannot reproduce this on i686-pc-linux-gnu, Can you report this to freebsd?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
--- Comment #14 from bugzilla-gcc at thewrittenword dot com 2005-10-22
13:40 ---
(In reply to comment #13)
> (In reply to comment #12)
> > Workaround patch here:
> > http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html
> >
> > Rest of discussion here:
> > http://gcc.gnu.org/ml/gcc/2005-10/m
--- Comment #9 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:55
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:56
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:56
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #25 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:57
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:57
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:57
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:58
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:58
---
Won't work on it for a long while.
--
lerdsuwa at gcc dot gnu dot org changed:
What|Removed |Added
---
Hi,
While compiling this (very simplified) code under Linux
<<
Below you will find the C code for which I believe `gcc' generates an incorrect
assignment in `my_buggy_routine' (below) because it computes the destination
address too early. In other word, the assignment:
*(char *)(Current + 9) = my_computation (Current, i);
as the effect of
ch
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-10-22 16:24
---
> In other word, the assignment:
>
> *(char *)(Current + 9) = my_computation (Current, i);
>
> as the effect of
>
> char * tmp = Current + 9
> *tmp = my_computation (Current, i);
>
> but
--- Comment #2 from manus at eiffel dot com 2005-10-22 16:37 ---
I'm fine that you comply to the standard, but what I was reporting was not an
incoherence with the standard, but with the fact that for the past 15 years
`gcc' has always evaluated the source before evaluating the target.
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-10-22 16:50
---
> In other words this is a breaking change.
The change breaks nothing except invalid code. Your code has worked by
accident up to now with GCC, it may never have worked with another compiler.
> Is there an expl
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-22 17:02
---
Subject: Bug 24426
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-22 17:02:42
Modified files:
gcc/fortran: ChangeLog decl.c
gcc/testsuite : Chang
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-22 17:09
---
Subject: Bug 24426
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-22 17:09:04
Modified files:
gcc/fortran: ChangeLog decl.c
--- Comment #4 from manus at eiffel dot com 2005-10-22 17:20 ---
I agree that relying on gcc's behavior might be the wrong thing to do, but when
this is 15 years old code, you can expect that it will still continue to work.
Moreover, it works on all the C compilers I've ever used except
On Saturday 22 October 2005 13:20, manus at eiffel dot com wrote:
> Would it make sense to have a new option in `gcc' to say that target is
> always evaluated after source is?
>
Not really possible. You are correct that it occurs at any optimization
level.
The bug in your code is exposed when G
--- Comment #5 from dnovillo at redhat dot com 2005-10-22 17:32 ---
Subject: Re: gcc generates incorrect assignment because of reordering
On Saturday 22 October 2005 13:20, manus at eiffel dot com wrote:
> Would it make sense to have a new option in `gcc' to say that target is
> alway
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-10-22 17:34
---
> Would it make sense to have a new option in `gcc' to say that target is always
> evaluated after source is? I think that would make transition to gcc 4.0.
No, the compiler has already far too many command line
On Saturday 22 October 2005 13:32, Diego Novillo wrote:
> The bug in your code is exposed when GCC creates the intermediate
> representation for your program. In that intermediate representation,
> GCC is explicitly exposing the sequence points in expression evaluation
> using the standard rules.
--- Comment #7 from dnovillo at redhat dot com 2005-10-22 17:42 ---
Subject: Re: gcc generates incorrect assignment because of reordering
On Saturday 22 October 2005 13:32, Diego Novillo wrote:
> The bug in your code is exposed when GCC creates the intermediate
> representation for yo
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-22 17:46 ---
The C++ standard says they are ambiguous.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from bru dot pages at wanadoo dot fr 2005-10-22 17:58
---
(In reply to comment #1)
> The C++ standard says they are ambiguous.
>
ok, in this case g++ 3.3.3 is wrong because it says nothing, even with -Wall
regards
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=244
The basic block frequencies used when compiling without profiling information
appear to be non-sensical. For instance, a case where block 0 is fed by the
entry block but has a frequency of 0. This causes EDGE_FREQUENCY to return
zero, which affects optimizations such as final.c:compute_alignments
--- Comment #13 from arno at heho dot snv dot jussieu dot fr 2005-10-22
20:58 ---
Shouldn't part of boehm-gc .h and config files be installed and picked up by
#include ?
Especially boehm-gc doc says pthread_create (and some other thread-functions)
should not be called directly, but
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-22 21:22 ---
Fixed in 4.0.3 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24394
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.3 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
--- Comment #8 from rpjday at mindspring dot com 2005-10-22 21:36 ---
Just now tested with new snapshot gcc-4.1-20051022, same result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.2.0
http
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-22 21:51 ---
Does this work now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.2.0
http
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-22 21:53
---
Sorry but my machine went bonkers and I cannot submit this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.2.0
http
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-22 21:55
---
I am no longer working on this and my machine went bust today, sorry. If
someone wants to take my patch and fix up for future comments, please do.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
GCC target triplet|i686-pc-* |i686-*-*
h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.2.0
http
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.2.0
http
It would be nice for the C++ compiler to warn users when they implement copy
assignment operator that does not copy all parts of an object.
Build the following (contrived) program at maximum warning level:
class Copy
{
public:
Copy() : m_value(0), m_flag(false) {}
Copy& operator=(
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.2.0
http
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-22 21:58
---
This most likely can be produced using C code, just has not found a testcase
yet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-22 21:59 ---
Can someone try sparc-linux, I would not doubt this could be reproduced there
too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-22 22:02 ---
Use -O1 -Wuninitialize and use another.m_flag and you will see that it warns
about that. Copy constructs and copy assignment operators should never be
treated special.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-10-22 22:31
---
Patch posted (for simple cases only).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from falk at debian dot org 2005-10-22 22:42 ---
(In reply to comment #7)
> Can someone try sparc-linux, I would not doubt this could be reproduced there
> too.
Actually, it can't, as I tried to explain in comment #6, it is probably a
bug in config/alpha/predicates.md (an
The following test case reads past the end of record because sf_read is being
executed before the check for length is performed. Discovered during testing
of arrayio. See message: http://gcc.gnu.org/ml/fortran/2005-10/msg00382.html
The following simplified test case shows the problem without usi
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-10-22 22:58
---
Created an attachment (id=10045)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10045&action=view)
Fix for this PR
The attached patch fixes this PR. I will commit to mainline as obvious.
--
http://gcc.
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-22 23:59 ---
I don't have time to work on this any more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-23 00:01
---
And I don't have time for this any more. Maybe After I have laptop fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-23 00:01 ---
Not working on this any more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-10-23 00:02
---
No longer working on this. If someone to take my patch and update it and also
update the testsuite, that is ok with me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-23 00:02 ---
No longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-23 00:03
---
No longer working on this. Sorry, if someone wants to take my patch and
update, that is ok with me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-23 00:04 ---
I am no longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-23 00:04 ---
No longer working on this, laptop is dead.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-23 00:05 ---
I don't have time to work on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-23 00:06 ---
The patch above is almost correct and I just lost the correct one as my laptop
is dead so I am no longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-23 00:08 ---
No longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-23 00:08
---
No longer working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from arno at heho dot snv dot jussieu dot fr 2005-10-23
00:21 ---
Created an attachment (id=10046)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10046&action=view)
CC test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
--- Comment #15 from arno at heho dot snv dot jussieu dot fr 2005-10-23
00:22 ---
Created an attachment (id=10047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10047&action=view)
simple class
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
--- Comment #6 from schwab at suse dot de 2005-10-23 00:23 ---
No, it is still the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
--- Comment #16 from arno at heho dot snv dot jussieu dot fr 2005-10-23
00:24 ---
Created an attachment (id=10048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10048&action=view)
template for using jnew.java and gc-thread-register.cc
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #17 from arno at heho dot snv dot jussieu dot fr 2005-10-23
00:28 ---
I quickly wrote a testcase to illustrate my point (attached jnew.java Makefile
gc-thread-register.cc) :
Compiling and running gives :
./gc-thread-register
Starting first thread ...done
Collecting
Environment:
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure : (reconfigured) ./configure
--enable-languages=c,c++,fortran,java,objc --no-create --no-recursion
Thread model: posix
gcc version 4.1.0 20051022 (experimental)
Program:
#include
int main
--- Comment #1 from danglin at gcc dot gnu dot org 2005-10-23 04:48 ---
Are U_IS_STUB_OR_CALLX and U_is_shared_pc in libcl.a on 11.23? Do you
know if the 11.23 release notes document the observed changes to libcl.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
--- Comment #3 from danglin at gcc dot gnu dot org 2005-10-23 04:56 ---
2.95.3 doesn't support HP-UX 11. This is documented in the installation
notes. This problem is fixed in later releases.
--
danglin at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from danglin at gcc dot gnu dot org 2005-10-23 05:15 ---
Hmmm, I thought this problem was fixed by
2004-12-04 John David Anglin <[EMAIL PROTECTED]>
PR middle-end/18730
* emit-rtl.c (get_first_nonnote_insn, get_last_nonnote_insn): When
the first/
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-23 06:47 ---
There's an Eclipse PR for this, fwiw:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=108720
If you look there you can see further motivation -- in particular,
the continuation messages that gcc sometimes prints are b
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-23 06:59
---
Subject: Bug 24311
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-23 06:59:18
Modified files:
gcc/fortran: trans-expr.c iresolve.c ChangeLog
li
1 - 100 of 102 matches
Mail list logo
