--- Comment #4 from bonzini at gnu dot org 2006-01-09 07:47 ---
Changing the summary then.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-01-09
07:36 ---
Subject: RE: Module loading is not good at all
Andrew,
> --- Comment #1 from pinskia at gcc dot gnu dot org
> 2006-01-07 05:10 ---
> Looking at the profile for PR 21130 makes me think fixing
Took the tarball gcc-4.0.2 and extracted. Configured using the below command.
configure --target=avr --enable-languages=c
Did a "make", got the compilation errors. Below are the errors I got.
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
/home/bhanup/STKgcc/gcc/xgcc -B/home/bhanup/STK
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2006-01-09 05:36:35 |2006-01-09 05:43:
--- Comment #1 from hp at gcc dot gnu dot org 2006-01-09 05:43 ---
Forgot to mention that the revision where I repeated this was
LAST_UPDATED "Thu Jan 5 03:26:35 UTC 2006 (revision 109371M)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25718
--- Comment #1 from lawless at spamcop dot net 2006-01-09 05:39 ---
Created an attachment (id=10597)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10597&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25719
The 'c_str()' method of the STL 'basic_string' class template
returns a pointer to free memory when called against a
string returned by the 'str()' method of the 'basic_ostringstream'
class template. ISO/IEC 14882 [21.3.6] indicates pointers returned
by 'c_str()' should be good until the next non-
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
For this code:
unsigned foo(unsigned a)
{
unsigned l;
l = (a >= (~0u - 512) ? (~0u - 512) : a);
return l;
}
At any optimization level, including -O0, -O1 and -O2, you get
(at varying lines, of course):
x.s: Assembler messages:
x.s:14: Error: Immediate value not in 8 bit range: -513
The offe
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-01-09 05:27
---
This one is cute. We have user space data showing up in the bytes_left
counter. Really! I may have found the root of all evils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.3 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
--- Comment #23 from kazu at gcc dot gnu dot org 2006-01-09 04:42 ---
Checked in a patch to both 4.1 and 4.2.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.0 |
Known to work|4.0.3 4.2.0 |4.0.3 4.1.0 4.2.0
Ta
--- Comment #7 from neil at daikokuya dot co dot uk 2006-01-09 04:38
---
Subject: Re: [4.0/4.1/4.2 Regression] Internal compiler error (segfault)
instead of error message
steven at gcc dot gnu dot org wrote:-
> Sadly I have no idea what this variable is for, and Joseph did not add an
steven at gcc dot gnu dot org wrote:-
> Sadly I have no idea what this variable is for, and Joseph did not add any
Detecting jumps over variably modified types as required in C99.
Neil.
--- Comment #22 from kazu at gcc dot gnu dot org 2006-01-09 04:37 ---
Subject: Bug 25125
Author: kazu
Date: Mon Jan 9 04:37:09 2006
New Revision: 109495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109495
Log:
gcc/
PR tree-optimization/25125
* convert.c (conve
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-09 04:29 ---
This is basicially fixed now after PR 12456:
t.f: In function 'warn_integer':
t.f:19: warning: 'a' is used uninitialized in this function
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is use
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-09 04:25
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from fengwang at gcc dot gnu dot org 2006-01-09 02:54
---
Subject: Bug 12456
Author: fengwang
Date: Mon Jan 9 02:54:25 2006
New Revision: 109491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109491
Log:
fortran
2006-01-09 Feng Wang <[EMAIL PROTECTED]>
--- Comment #12 from fengwang at gcc dot gnu dot org 2006-01-09 02:27
---
Subject: Bug 12456
Author: fengwang
Date: Mon Jan 9 02:27:45 2006
New Revision: 109489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109489
Log:
fortran ChangeLog entry:
2006-01-09 Feng Wang <[EMAIL P
--- Comment #10 from dje at gcc dot gnu dot org 2006-01-09 02:19 ---
Fix committed to all mainline, 4.1, 4.0.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dir at lanl dot gov 2006-01-09 01:52 ---
Having a read immediately follow a write - seems to cause the errors. I have
run several million I/O tests where the only legal thing not permitted is a
read immediately after a write - without getting a single error.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-09 01:31 ---
Hmm, when cpp0 was removed in 3.3, this was caused.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-09 01:28 ---
Actually this is a true bug and it was fixed in the past too:
http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01533.html
I have to see where it started to fail now.
Confirmed.
--
pinskia at gcc dot gnu dot org cha
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-09 00:27 ---
Hmm, __STDC__ is treated special inside the preprocessor.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2006-01-08 22:53 ---
Subject: Re: Jumping into blocks gives error rather than
warning
steven at gcc dot gnu dot org wrote:
> --- Comment #12 from steven at gcc dot gnu dot org 2006-01-08 22:23
> ---
The -dM option is documented to provide a complete list of all defined macros,
including all predefined macros, however the list is incomplete. In particular,
the following will not list __STDC__ even though it is defined:
touch test.h; gcc -dM test.h
If you modify test.h to include:
#ifde
--- Comment #12 from steven at gcc dot gnu dot org 2006-01-08 22:23 ---
Yes please.
And what do you think of the other idea to speed things up?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
--- Comment #11 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2006-01-08 22:16 ---
Subject: Re: Jumping into blocks gives error rather than
warning
steven at gcc dot gnu dot org wrote:
> --- Comment #9 from steven at gcc dot gnu dot org 2006-01-08 21:45
> ---
--- Comment #8 from mueller at kde dot org 2006-01-08 21:59 ---
Created an attachment (id=10596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10596&action=view)
updated patch
I agree, that makes it much more readable. updated accordingly and rediffed
against current trunk. bootst
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-08 21:54 ---
Note that this code in resolve_branch is only slow for deeply nested programs
with many gotos. The code in resolve_branch is linear in the size of the
program, but if your program has many GOTO statements, say of th
--- Comment #17 from bero at arklinux dot org 2006-01-08 21:50 ---
Might be my {C,CXX}FLAGS...
I can reproduce this on Linux 2.6.15, glibc 2.3.6, binutils 2.16.91.0.4, gcc
4.1 branch (SVN Revision 108760) with
--enable-fast-install --enable-libstdcxx-pch --enable-__cxa_atexit --enable-
--- Comment #9 from steven at gcc dot gnu dot org 2006-01-08 21:45 ---
Actually we already know for sure that the label exists and that it is a valid
jump target. From resolve_branch:
/* Step one: is this a valid branching target? */
if (lp->defined == ST_LABEL_UNKNOWN)
{
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-08 21:42 ---
No, this is not sufficient, because you'll still need to find the label, unless
we have some gross code duplication that I'm not aware of. What needs to be
done is adding a search through the entire program unit if no
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-08 21:33 ---
(From update of attachment 10595)
See comment #6
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-08 21:32 ---
(From update of attachment 10595)
Index: resolve.c
===
--- resolve.c (revision 109449)
+++ resolve.c (working copy)
@@ -3579,9 +3579,12 @@ resolve_br
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-08 21:30 ---
Created an attachment (id=10595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10595&action=view)
allow jumping into blocks in legacy mode
Something like this is probably all that's needed.
--
http://gcc.g
--- Comment #9 from dje at gcc dot gnu dot org 2006-01-08 20:55 ---
Subject: Bug 25662
Author: dje
Date: Sun Jan 8 20:55:39 2006
New Revision: 109477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109477
Log:
2006-01-08 Ian Lance Taylor
David Edelsohn <[EMAIL PR
--- Comment #8 from dje at gcc dot gnu dot org 2006-01-08 20:54 ---
Subject: Bug 25662
Author: dje
Date: Sun Jan 8 20:54:28 2006
New Revision: 109476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109476
Log:
2006-01-08 Ian Lance Taylor
David Edelsohn <[EMAIL PR
--- Comment #19 from pault at gcc dot gnu dot org 2006-01-08 20:27 ---
(In reply to comment #8)
> Not all of the underlying are just g77 features. Some like 18540/25705 are
> legal f90, f95, f06 code an just calling them "excremental" is unprofessional.
> This diminishes the 90% plus of
Executing on host: /test/gnu/gcc-4.1/objdir/gcc/testsuite/../gfortran
-B/test/gn
u/gcc-4.1/objdir/gcc/testsuite/../
/test/gnu/gcc-4.1/gcc/gcc/testsuite/gfortran.
dg/char_result_11.f90 -O -pedantic-errors -S -o char_result_11.s
(timeou
t = 300)
In file /test/gnu/gcc-4.1/gcc/gcc/testsuite/gf
cross-gcc configured with '--without-headers --disable-threads' doesn't build.
(...)
/home/users/pluto/rpm/BUILD/gcc-4.1-20060106/obj-ppc64-pld-linux/./gcc/xgcc
-B/home/users/pluto/rpm/BUILD/gcc-4.1-20060106/obj-ppc64-pld-linux/./gcc/
-B/usr/ppc64-pld-linux/bin/ -B/usr/ppc64-pld-linux/lib/
-isyste
--- Comment #16 from tromey at gcc dot gnu dot org 2006-01-08 18:41 ---
I tried the new reduced test case from comment #13, using
my svn trunk build. It worked fine.
I suspect something in your configuration is triggering a gcc
bug -- i.e., that it is not really a "java" problem but in
--- Comment #34 from steven at gcc dot gnu dot org 2006-01-08 18:40 ---
Another factor contributing to the huge compile time requirements of VRP for
this test case is the number of equivalences recorded:
Value ranges after VRP ("..." meaning I cut away a *cough* few b_i SSA names
;-):
--- Comment #33 from steven at gcc dot gnu dot org 2006-01-08 18:32 ---
So where are we wrt. GCC 3.3-hammer at -O2?
compiler absolute time relative to 3.3-hammer
GCC 3.3 0m30.390s 1.00
GCC 4.0 0m38.118s 1.25
GCC 4.1 0m51.059s 1.68
--- Comment #5 from pluto at agmk dot net 2006-01-08 18:29 ---
hmm, CFLAGS_FOR_TARGET picks up CFLAGS.
--- gcc-4.1-20060106/Makefile.in.orig 2005-12-15 15:02:02.0 +0100
+++ gcc-4.1-20060106/Makefile.in2006-01-08 19:27:18.406458250 +0100
@@ -329,9 +329,9 @@
# CFLAGS wi
--- Comment #32 from steven at gcc dot gnu dot org 2006-01-08 18:16 ---
I have bootstrapped 4.0 and 4.1 and re-timed:
GCC 4.0 0m38.118s
GCC 4.1 0m51.059s
The distribution of the compile time is not significantly different from the
timings of the -O0 compilers.
--
http://gcc.gnu.org
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-01-08 17:53
---
Subject: Bug 25093
Author: eedelman
Date: Sun Jan 8 17:52:57 2006
New Revision: 109474
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109474
Log:
fortran/
2005-01-08 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #5 from pcarlini at suse dot de 2006-01-08 17:38 ---
"Insert as close to hint as possible" also done, for 4.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #3 from steven at gcc dot gnu dot org 2006-01-08 17:35 ---
Re. #1, where you wrote: "What the using community needs are not arguments but
continued use of working programs. Rewrites are OK when there are clear
advantages in efficiency or less susceptibility to fraudulent use
--- Comment #4 from paolo at gcc dot gnu dot org 2006-01-08 17:34 ---
Subject: Bug 22102
Author: paolo
Date: Sun Jan 8 17:34:32 2006
New Revision: 109473
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109473
Log:
2006-01-08 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-08 17:26 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #18 from sgk at troutmask dot apl dot washington dot edu
2006-01-08 16:37 ---
Subject: Re: [meta-bug] g77 features lacking in gfortran
On Sun, Jan 08, 2006 at 10:41:15AM -, malitzke at metronets dot com wrote:
>
> one had called your work a piece of excrement. Excreme
--- Comment #48 from aoliva at gcc dot gnu dot org 2006-01-08 16:30 ---
Mark, please reassign this to me when the promised review is ready. I'm being
held responsible for the patch not being in on IRC because the bug is assigned
to me, and I think that's not fair. Thanks,
--
aoliva
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
--- Comment #31 from steven at gcc dot gnu dot org 2006-01-08 16:14 ---
Re. the timings in comment #29, I should have said that my GCC 3.3 was
bootstrapped, but the GCC 4.0 and GCC 4.1 I used were built with "-O0 -g". I
added 3.3 numbers for "ballpark" reference, not for actual comparis
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-08 16:08 ---
Other than VRP taking so much time for GCC 4.1, there are no surprises in the
timings I just added in comment #29 for GCC 4.0 and GCC 4.1.
Computing dominance frontiers is just not a linear operation (especially not
--- Comment #29 from steven at gcc dot gnu dot org 2006-01-08 16:02 ---
User times:
optimization| GCC version
level | 3.3-hammer 4.0 4.1
+
-O0 | 0m7.248s0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
Known to work|
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-08 15:24 ---
*** Bug 25664 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-08 15:24 ---
*** This bug has been marked as a duplicate of 8923 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-08 15:15
---
(In reply to comment #5)
> Andrew, Lahey's code checking utility gives
Lahey's Fortran 95 code checker that is online gives:
2604-S: "SOURCE.F90", line 3: The name 'foo' cannot be specified as both
external proc
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-08 15:09 ---
Of course I mean "[finish_decl] _is_ called after the point where we fail now".
The error for (int)&a not being a constant is issued from finish_decl, but we
ICE before we call finish_decl for buf.
We ICE during a c
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-08 15:05 ---
Created an attachment (id=10594)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10594&action=view)
Robustify
Ideally we would be able to reject (int)&a as non-constant and therefore
illegal because the storage s
--- Comment #10 from dorit at il dot ibm dot com 2006-01-08 13:49 ---
> Reopening since many of the intrinsics could still vectorize better.
Could help if you list specific functions that you expect to get vectorized. As
far as dotprod is concerned - if it's operating on floats, you nee
--- Comment #17 from tobi at gcc dot gnu dot org 2006-01-08 13:18 ---
Instead of continuing a pointless flame war in a PR which is only
organisationally related to the bug we're talking about, let me explain a few
procedural details which will hopefully make you understand that noone cal
--- Comment #16 from malitzke at metronets dot com 2006-01-08 10:41 ---
Well I am very glad you people are offended. Imaging how you would feel I some
one had called your work a piece of excrement. Excrement (with some minor
variation in spelling) comes from Latin and means vernacular M.
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-01-08 10:35
---
(In reply to comment #9)
> Actually that is still a violation of the aliasing rules, as you are acessing
> a
> character as a Foo. Yes that is violation, though I think GCC does not define
> it as one.
I think t
--- Comment #9 from paulthomas2 at wanadoo dot fr 2006-01-08 09:49 ---
Subject: Re: named common block confused as procedure
- runtime segfault
pinskia at gcc dot gnu dot org wrote:
>--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-08 06:13
>---
>(In reply to comm
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-01-08 09:40
---
I will take a gander at this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-01-08 09:39
---
Patch submitted for review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25631
72 matches
Mail list logo
