--- Comment #2 from vijay dot x dot jain at jpmchase dot com 2009-09-11
06:31 ---
Yes our build works on solaris 8. Just that our solaris 8 support is coming to
an end and hence we are migrating to solaris 10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41333
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-09-11 06:37
---
Yes our build works on solaris 8.
If the exact same operation works on Solaris 8 but not on Solaris 10, you may
have run into a limitation of GNU ld on Solaris 10. The workaround is probably
to build a GCC
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-09-11 07:44 ---
Subject: Bug 41276
Author: aoliva
Date: Fri Sep 11 07:44:06 2009
New Revision: 151628
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151628
Log:
PR debug/41276
PR debug/41307
* cselib.c
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-11 09:35 ---
Does the GCC you built for Solaris 10 have symbol versioning enabled? You can
check this by looking in the libstdc++-v3/config.log or by running:
nm /path/to/gcc/lib/libstdc++.so | fgrep @GLIBCXX
If that produces
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-11
09:54 ---
The pr39779.c test case is ICEing the compiler in gcc trunk on
x86_64-apple-darwin10 at r151625 as follows...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc/xgcc
model: posix
gcc version 4.5.0 20090911 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39779
model: posix
gcc version 4.5.0 20090911 (experimental) (GCC)
--
Summary: gcc.dg/graphite/run-id-1.c fails execution test
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
--- Comment #6 from rahul at icerasemi dot com 2009-09-11 10:03 ---
An interesting regression results as a side effect of loop header copying (this
occurs even in vanilla O2). If I modify my original test case to
struct struct_t {
int* data;
};
void testAddr (struct struct_t* sp,
--- Comment #9 from jakub at gcc dot gnu dot org 2009-09-11 10:45 ---
That's because Uros didn't actually revert the testcase together with the
reversion of the patch (only testsuite/ChangeLog says so).
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-11 11:08 ---
Subject: Bug 41275
Author: matz
Date: Fri Sep 11 11:08:38 2009
New Revision: 151631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151631
Log:
PR middle-end/41275
* tree-inline.c (remap_decls):
--- Comment #10 from ubizjak at gmail dot com 2009-09-11 11:22 ---
(In reply to comment #9)
That's because Uros didn't actually revert the testcase together with the
reversion of the patch (only testsuite/ChangeLog says so).
Eh, done now.
--
--- Comment #19 from juergen dot reuter at physik dot uni-freiburg dot de
2009-09-11 11:56 ---
Subject: Re: [4.5 Regression] PPC call rejected (related to user-defined
assignment?)
On Friday 11 September 2009 00:51, janus at gcc dot gnu dot org wrote:
--- Comment #18 from janus
--- Comment #8 from matz at gcc dot gnu dot org 2009-09-11 12:13 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
I am using GCC 4.3.2, but I tested this also with 4.3.4, 4.4.1, 4.4-latest and
4.5-latest. Most of the are compiled with ../configure --prefix=MYPREFIX
--enable-language=fortran
From Fortran docs: If a variable is volatile, the processor is expected to
fetch the value from memory every time that
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-11 13:19 ---
Works for me now. Re-open if it still fails for you.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from paolo at gcc dot gnu dot org 2009-09-11 13:48 ---
Subject: Bug 41316
Author: paolo
Date: Fri Sep 11 13:47:36 2009
New Revision: 151635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151635
Log:
2009-09-11 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #24 from paolo dot carlini at oracle dot com 2009-09-11 13:50
---
Ed, I went ahead and committed this, I don't think we can do much better, for
now.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-09-11 13:51
---
Looks good to me. Btw, other containers might be affected by similar issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41316
--- Comment #26 from paolo dot carlini at oracle dot com 2009-09-11 13:52
---
Richard, I'm not sure whether you need this change in 4_4-branch too, in case
just ask me or go ahead yourself, should be backportable as-is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41316
--- Comment #27 from rguenther at suse dot de 2009-09-11 13:53 ---
Subject: Re: [C++0x] forward_list::sort violates strict
aliasing rules
On Fri, 11 Sep 2009, paolo dot carlini at oracle dot com wrote:
--- Comment #26 from paolo dot carlini at oracle dot com 2009-09-11
13:52
--- Comment #28 from paolo dot carlini at oracle dot com 2009-09-11 13:54
---
I'll have a look, but I don't think we are really playing these multiple up and
down tricks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41316
--- Comment #6 from vijay dot x dot jain at jpmchase dot com 2009-09-11
14:19 ---
As suggested i had put /usr/xpg4/bin in PATH in precedence.
from config.log
lt_cv_path_SED=/usr/xpg4/bin/sed
SED='/usr/xpg4/bin/sed'
BUt still versioning is not used
a_dod...@upests-dn24d:.libs:[53] !nm
+++ This bug was initially created as a clone of Bug #38992 +++
On RHEL5/ia32 and RHEL5/ia64, revision 151545 gave
cc1: warnings being treated as errors
../../src-lto/gcc/lto/lto-elf.c: In function 'validate_file':
../../src-lto/gcc/lto/lto-elf.c:453:3: error: implicit declaration of function
On Intel Core i7 with make -j8, I got
flex -ogengtype-lex.c /export/gnu/import/gcc-lto/gcc/gengtype-lex.l
echo #define BUILDING_GCC_MAJOR `echo 4.5.0 | sed -e 's/^\([0-9]*\).*$/\1/'`
bversion.h
make[1]: *** No rule to make target `build/gencondmd', needed by `s-condmd'.
St
op.
make[1]: ***
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-11 14:48 ---
You need newer libelf.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-11 15:01 ---
Pilot error.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from denis_scherbakov at yahoo dot com 2009-09-11 15:10
---
I studied the error a little bit more.
volatile double precision a declares a variable doubleprecisiona which is
not used.
real, volatile :: a works and produces expected result
volatile :: a works, but type
--- Comment #7 from redi at gcc dot gnu dot org 2009-09-11 15:20 ---
(In reply to comment #6)
configure:114866: WARNING: === Linker version 1800 is too old for
configure:114868: WARNING: === full symbol versioning support in this release
of GCC.
configure:114870: WARNING: === You
--- Comment #2 from steven at gcc dot gnu dot org 2009-09-11 15:26 ---
file test.F compiled with gfortran -std=f2003 -O2 test.F -o test-F:
Try compiling with -ffree-form.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from debian-gcc at lists dot debian dot org 2009-09-11
16:50 ---
checked the backport of the 2nd chunk on the 4.4 branch without regressions on
i386 and amd64.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
--- Comment #3 from steven at gcc dot gnu dot org 2009-09-11 17:29 ---
needs configure magician...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-09-11 17:30 ---
...but bug is real.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC 4.5.0 20090910, compile with `cc1 -O3 -g tree.i' command.
--
Summary: High memory consumption when compiling with -O3 -g
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-09-11
17:53 ---
Created an attachment (id=18565)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18565action=view)
gzipped preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41338
--- Comment #22 from ro at gcc dot gnu dot org 2009-09-11 18:06 ---
Fixed for 4.5.0. Before, the patch had only been applied to two RedHat vendor
branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
--- Comment #5 from kargl at gcc dot gnu dot org 2009-09-11 18:18 ---
(In reply to comment #4)
I tested real, volatile and double precision, volatile with fixed form and
free form and real* works, double* - not.
So it is not a question of a source form now, but rather why double
--- Comment #6 from denis_scherbakov at yahoo dot com 2009-09-11 18:38
---
By saying works I mean that on my system program with
real, volatile :: a
returns nonzero result. This is correct, because 80-bit floating point
gets truncated to 64-bit and then loaded again into FPU.
double
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2009-09-11 18:57 ---
Subject: Re: VOLATILE in Fortran does not take effect
- Comment #6 from denis_scherbakov at yahoo dot com 2009-09-11 18:38 ---
By saying works I mean that on my system program with
--- Comment #8 from denis_scherbakov at yahoo dot com 2009-09-11 19:02
---
Ok, but then real and double precision datatypes should
behave in the same way? No?
Denis
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335
--- Comment #9 from denis_scherbakov at yahoo dot com 2009-09-11 19:12
---
And how would you know that by leaving a in FPU register after a = aU*aU
you still have the most recent version of a during computation of c without
storing it?
Denis
--
--- Comment #10 from mikael at gcc dot gnu dot org 2009-09-11 19:39 ---
(In reply to comment #5)
Can you define what you mean by works?
The following change in the provided testcase (fixed form):
--- pr41335.f.old 2009-09-11 23:12:01.0 +0200
+++ pr41335.f 2009-09-11
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2009-09-11 19:45 ---
Subject: Re: VOLATILE in Fortran does not take effect
Ok, but then real and double precision datatypes should
behave in the same way? No?
They do behave the same at least from the Fortran
--- Comment #12 from denis_scherbakov at yahoo dot com 2009-09-11 20:05
---
Steve Kargl,
What is your hardware? x86 or something else?
I have Atlon 2000 MP and Intel Quad and on both of these systems I get
differences
in output for real and double precision.
What I can do to prove
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2009-09-11 20:26 ---
Subject: Re: VOLATILE in Fortran does not take effect
What is your hardware? x86 or something else?
Opteron.
I have Atlon 2000 MP and Intel Quad and on both of these systems I get
--- Comment #14 from mikael at gcc dot gnu dot org 2009-09-11 20:39 ---
With this:
Index: scanner.c
===
--- scanner.c (revision 151461)
+++ scanner.c (working copy)
@@ -1274,6 +1274,16 @@
}
+char
--- Comment #15 from denis_scherbakov at yahoo dot com 2009-09-11 20:54
---
I just tried -ffloat-store and the results stay the same.
I would like to note that for real and double precision different assembler
code is produced. At least on my machine. Could somebody use -same-temps
While mucking around with gcc internals, I noticed that occasionally the
same tree can occur several times in the same cfun-local_decls list.
That seems like a bug(let). Here's a testcase:
int f() {}
void g(void) { f(); }
The problem shows up at -O2, presumably due to inlining:
gcc -c -O2
--- Comment #1 from baldrick at free dot fr 2009-09-11 21:05 ---
Created an attachment (id=18566)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18566action=view)
Debugging patch that shows the problem
You need to build with checking enable. You need to define VERIFY_LOCAL_DECLS
--- Comment #16 from sgk at troutmask dot apl dot washington dot edu
2009-09-11 21:08 ---
Subject: Re: VOLATILE in Fortran does not take effect
On Fri, Sep 11, 2009 at 08:39:38PM -, mikael at gcc dot gnu dot org wrote:
I get:
pr41335.f:3.23:
volatile double
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-09-11 21:12 ---
Is this after http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41275 ?
Because we should not have local_decls should be empty for these two functions
as far as I can tell ...
--
GCC 4.5.0 20090903, 20090910: bootstrap with `--enable-build-with-cxx' failed.
cc1plus -O2 -g rtl.ii
--
Summary: [4.5 Regression] G++ produces different code with and
without -g option
Product: gcc
Version: 4.5.0
Status:
--- Comment #1 from tomek at jot23 dot org 2009-09-11 21:40 ---
Created an attachment (id=18568)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18568action=view)
the offending code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41341
--- Comment #18 from burnus at gcc dot gnu dot org 2009-09-11 22:07 ---
I looked at the assembler and the result is the following (non volatile vs.
volatile) [which is essentially the same with REAL(8) and REAL(4)]:
@@ -9,7 +9,7 @@
movl%esp, %ebp
subl$392, %esp
--- Comment #8 from kargl at gcc dot gnu dot org 2009-09-11 22:11 ---
Subject: Bug 39876
Author: kargl
Date: Fri Sep 11 22:11:06 2009
New Revision: 151645
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151645
Log:
2009-09-11 Steven G. Kargl ka...@gcc.gnu.org
Backport
--- Comment #5 from kargl at gcc dot gnu dot org 2009-09-11 22:16 ---
I've merged revision 147279 from mainline to the 4.4 branch.
Thanks for the bug report.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from sgk at troutmask dot apl dot washington dot edu
2009-09-11 22:39 ---
Subject: Re: VOLATILE in Fortran does not take effect
On Fri, Sep 11, 2009 at 06:18:35PM -, kargl at gcc dot gnu dot org wrote:
program VolatileTest
double precision, volatile :: a
--- Comment #16 from rth at gcc dot gnu dot org 2009-09-11 23:15 ---
Mine.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-09-11 23:38 ---
I ran into too many problems when I tried to inhibit value_expr
PARM_DECL substitutions in the gimplifier. At the moment I believe we
should not use the value_expr just for debug info and rather try
For the attached case distilled from eglibc sources - the compiler ends up by
running out of Virtual memory for compilations with -O2 -g . Turning this off
using -fno-var-tracking-location appears to workaround the issue.
Here's the memory usage that I see for this one.
PID USER PR NI
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-11 23:52 ---
Created an attachment (id=18569)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18569action=view)
Failed testcase.
Testcase for failure. Test by running -O2 -g on arm-none-eabi
--
--- Comment #17 from rth at gcc dot gnu dot org 2009-09-12 00:00 ---
Created an attachment (id=18570)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18570action=view)
trampoline push, version 1
Here's a lightly tested patch that implements the idea in comment #14.
Will those that
--- Comment #20 from kargl at gcc dot gnu dot org 2009-09-12 01:31 ---
AFAICT, this PR 323.
program VolatileTest
implicit none
real(8), volatile :: a
real(8) uA, uB, b, c
real(4), volatile :: ra
real(4) ruA, ruB, rb, rc
read(*,*) uA, uB, rua, ruB
a = uA * uA
b = uB
When compiling the attached file as:
powerpc-linux-gnu-gcc dosincos.i -g -O2 -std=gnu99 -fgnu89-inline
-fmerge-all-constants
The memory use of GCC balloons to 4GB+. I have a low ulimit on my machine, so
I don't know whether leaving it alone with more memory would let the
compilation finish.
--- Comment #1 from froydnj at gcc dot gnu dot org 2009-09-12 04:05 ---
Created an attachment (id=18571)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18571action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343
--- Comment #12 from nightstrike at gmail dot com 2009-09-12 05:36 ---
Current warning list as of revision 151630:
../../../../../build/gcc/gcc/libgfortran/io/write.c:328:8: warning: passing
argument 2 of 'write_default_char4' from incompatible pointer type
66 matches
Mail list logo
