--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
---
--
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 #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
--- 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 #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
--
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 #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
--- 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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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
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
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
> ---
--- 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 #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
--
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 #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
-
--- 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 #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 #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 #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 #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 #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 #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
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 #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
--
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 #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
Target Milestone|4.0.3 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
--- 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
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
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
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-
--- 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
--- 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
--
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:
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
--- 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
--- 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
72 matches
Mail list logo
