--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|amylaar at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #5 from aoliva at gcc dot gnu dot org 2009-09-11 07:44 ---
Subject: Bug 41307
Author: aoliva
Date: Fri Sep 11 07:44:06 2009
New Revision: 151628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151628
Log:
PR debug/41276
PR debug/41307
* cselib.c (cselib_expand_value_r
--- 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=gcc&view=rev&rev=151628
Log:
PR debug/41276
PR debug/41307
* cselib.c (cselib_expand_value_r
--- 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 no
--- 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
-B/sw/src/f
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, int
--- 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=gcc&view=rev&rev=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.
--
http://gcc.gnu.org/bugzilla/show_bug
--- 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 th
--- 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=gcc&view=rev&rev=151635
Log:
2009-09-11 Paolo Carlini
PR libstdc++/41316
--- 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:5
--- 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
n
+++ 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
'el
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
Status|UNC
--- 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
--- 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 compiled with :
Try compiling with -ffree-form.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from denis_scherbakov at yahoo dot com 2009-09-11 15:40
---
I compiled fixed form source with -ffree-form.
"real, volatile :: a" produces correct result
"double precision, volatile :: a" not
Why should I compile fixed form source as a free form at all?
Denis
--
den
--- Comment #4 from denis_scherbakov at yahoo dot com 2009-09-11 15:45
---
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 precision,
volati
--- Comment #2 from joseph at codesourcery dot com 2009-09-11 15:51 ---
Subject: Re: [LTO] Bootstrap failed on RHEL5/ia32 and
RHEL5/ia64
On Fri, 11 Sep 2009, rguenth at gcc dot gnu dot org wrote:
> You need newer libelf.
This should result in a configure error, not an error at a lat
--- 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
Statu
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=18565&action=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 wh
--- 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.
"dou
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 2
--- 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 For
--- 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
> diff
--- 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
+gfc_next_ascii_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=18566&action=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 ...
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #17 from mikael at gcc dot gnu dot org 2009-09-11 21:18 ---
(In reply to comment #16)
> Is this for fixed-form or free-form source code?
> For fixed-form, the above should parse as
> 'volatile doubleprecisiona'
>
Yes, I've just discovered that.
Then the current behaviour is
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: UNCONFIRM
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-09-11
21:33 ---
Created an attachment (id=18567)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18567&action=view)
gzipped preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
In the attached code partial specialization of struct apply in struct
METAFUNCTION2 should be rejected according to C++ Standard 14.7.3/3:
A declaration of a function template or class template being explicitly
specialized shall be in scope at the point of declaration of an explicit
specialization
--- 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=18568&action=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=gcc&view=rev&rev=151645
Log:
2009-09-11 Steven G. Kargl
Backport from mainline, r14
--- 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 gcc
--- 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
BLOCK_NONLOCALIZ
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=18569&action=view)
Failed testcase.
Testcase for failure. Test by running -O2 -g on arm-none-eabi
--
http://gcc.gnu.org/bugzi
--- 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=18570&action=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. Usi
--- 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=18571&action=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
../../../../../build/gcc/gcc/
--- Comment #2 from aoliva at gcc dot gnu dot org 2009-09-12 06:39 ---
Created an attachment (id=18572)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18572&action=view)
patch that might help alleviate the problem
This patch helped me save a lot of memory on another PPC testcase th
--- Comment #2 from ramana at gcc dot gnu dot org 2009-09-12 06:48 ---
This looks like a dup of PR41343. I'm marking this as a dup of PR41343 because
there's a patch submitted there and an extra comment from Alex.
*** This bug has been marked as a duplicate of 41343 ***
--
ramana at
--- Comment #3 from ramana at gcc dot gnu dot org 2009-09-12 06:48 ---
*** Bug 41342 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from ramana at gcc dot gnu dot org 2009-09-12 06:49 ---
This test case fails for an arm-linux-gnueabi target as well.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
76 matches
Mail list logo
