I found this interesting thing. The "array" content is destroyed after the
"catch" statement but it shouldn't be. It behaves the same in MinGW 4.2.0 and
3.4.4 for me. It seems like the "array" is unwound out when the exception is
caught.
---
#include
#include
#include
int main () {
int n =
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 08:37 ---
This is SJLJ related as it works just fine on x86-linux and powerpc-darwin both
uses dwarf2 exceptions.
One should note that VLA are an extension to C++.
--
pinskia at gcc dot gnu dot org changed:
Wha
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-13 09:00 ---
Fixed now, I don't know by what off hand but I think it was:
2006-12-11 Daniel Berlin <[EMAIL PROTECTED]>
* tree-ssa-structalias.c (handle_ptr_arith): Return false when we
can't handle the pointer
--- Comment #4 from echristo at apple dot com 2006-12-13 09:25 ---
I'm seeing it on x86_64-darwin with compile/20031023-4.c.
--
echristo at apple dot com changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-13 09:36 ---
No feedback (or testcase) in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-13 09:37 ---
No testcase in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #46 from pinskia at gcc dot gnu dot org 2006-12-13 09:38
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-13 09:46 ---
I'll fix it after vacation.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-12-13 10:27
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-12-13 10:29
---
Fixed on the mainline, backport to 4.2 pending.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
I have a patch.
--
Summary: cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: mid
--- Comment #5 from schwab at suse dot de 2006-12-13 10:37 ---
On ia64 it is crashing in libiberty/md5.c.
--
schwab at suse dot de changed:
What|Removed |Added
I have a patch.
--
Summary: __real / __imag cexpi (x) can be folded to cos (x) / sin
(x)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
--- Comment #1 from jakub at gcc dot gnu dot org 2006-12-13 11:09 ---
"Fixed" by http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01014.html
modified_type_die rearrangment, which dropped the assert (not sure if
intentionally or not).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30189
--- Comment #27 from niemayer at isg dot de 2006-12-13 11:37 ---
I would like to mention that this problem seems to have worsened a lot for the
current snapshots of gcc-4.2 (currently testing with 4.2.0 20061205
(prerelease)) when compiling with at least -O1 - maybe due to the static
con
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-12-13 12:01
---
Created an attachment (id=12793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12793&action=view)
patch for fpa-related floating point problems
--
rearnsha at gcc dot gnu dot org changed:
What
--- Comment #2 from rearnsha at gcc dot gnu dot org 2006-12-13 12:02
---
Sorry, your proposed patch isn't interworking safe. Can you try the patch I've
attached and let me know if that works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
--- Comment #2 from lindig at cs dot uni-sb dot de 2006-12-13 12:09 ---
Created an attachment (id=12794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12794&action=view)
preprocessed file to reproduce the bug.
I have now attached the file that reproduces the bug to make everyone's
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-13 12:48 ---
Created an attachment (id=12795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12795&action=view)
patch
The testcase depends on 30172 to be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30197
--- Comment #2 from dcb314 at hotmail dot com 2006-12-13 13:25 ---
(In reply to comment #1)
> Does this work now on the mainline?
The only access to mainline I have is
by the weekly snapshots.
I expect to try out 4.3-20061216.
Thus, answer expected Monday 18 Dec 2006.
--
http://g
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-12-13 13:25 ---
(In reply to comment #5)
> Set the classpath
>
> gij -classpath : PR18699
Unfortunately, that still doesn't work:
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
../gij -classp
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-12-13 13:26
---
Subject: Bug 28740
Author: lmillward
Date: Wed Dec 13 13:25:47 2006
New Revision: 119830
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119830
Log:
PR c++27316
* g++.dg/inherit/error3.C: N
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 13:31 ---
__complex__ ( x, y ) * I == __complex__ ( -y, x )
__complex__ ( x, y ) * -I == __complex__ ( y, -x )
but only if we don't honor NaNs or signed zeros.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30172
--- Comment #36 from pault at gcc dot gnu dot org 2006-12-13 13:37 ---
Joost,
> input_cp2k_motion.f90
> input_cp2k_motion.f90: In function ‘create_neb_section’:
> input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
> fold-const.c:2150
>
> in fact, this is on a file
--- Comment #7 from aph at gcc dot gnu dot org 2006-12-13 13:42 ---
You wrote
../gij -classpath PR18699.class:../libgcj-4.3.0.jar PR18699.class
But I wrote:
../gij -classpath .:../libgcj-4.3.0.jar PR18699
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-12-13 13:59
---
Subject: Bug 28740
Author: lmillward
Date: Wed Dec 13 13:58:43 2006
New Revision: 119831
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119831
Log:
PR c++/27316
* g++.dg/inherit/error3.C:
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-12-13 13:59
---
Subject: Bug 27316
Author: lmillward
Date: Wed Dec 13 13:58:43 2006
New Revision: 119831
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119831
Log:
PR c++/27316
* g++.dg/inherit/error3.C:
--- Comment #37 from jv244 at cam dot ac dot uk 2006-12-13 14:01 ---
(In reply to comment #36)
well, this was reduced, filed as PR30147, and fixed. Tobias reduced another one
and filed it as PR30190 (see dependencies).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #38 from burnus at gcc dot gnu dot org 2006-12-13 14:03 ---
Hi Paul,
(In reply to comment #36)
> > input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
>
> A reduced version of this one would be very nice - if I would guess, it will
> be an assignment in
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-12-13 14:11
---
Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64 and
ppc64).
$ make check-gcc RUNTESTFLAGS=dg.exp=pr19633-1.c
[...]
Test Run By dnovillo on Wed Dec 13 09:05:53 2006
Native configuration is x86
The GCC compiler on FreeBSD does not handle #pragma pack(push, ) since
gcc/config/freebsd.h does not define HANDLE_PRAGMA_PACK_PUSH_POP. There is no
reason for this:
1. gcc/config/linux.h defines HANDLE_PRAGMA_PACK_PUSH_POP. No reason why Linux
and FreeBSD should be different here.
2. The 'native'
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-12-13 14:29
---
Subject: Bug 28740
Author: lmillward
Date: Wed Dec 13 14:28:47 2006
New Revision: 119833
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119833
Log:
PR c++27316
* g++.dg/inherit/error3.C: N
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> gfortran
test.f90
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> ./a.out
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> valgrind
--tool=memcheck ./a.out
==16188== Memcheck, a memory
--- Comment #39 from jv244 at cam dot ac dot uk 2006-12-13 15:25 ---
I had a look at one of the failing testcases from CP2K testsuite, and under
valgrind there were a number of errors that could be reproduced in the small
testcase of PR30200
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 15:54 ---
I just exposed this on the mainline with my GIMPLE_REG vector patch for a lot
more cases so I am going to take it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-12-13
15:58 ---
patch posted at
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00948.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2006-12-13 16:21:54 |2006-12-13 1
While developing a Free C++ library, I am facing what I think is a bug in gcc:
it doesn't unroll nested loops. Namely, in the example program that I paste
below, there is a nested loop like
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
do_something( i, j );
and only the inner lo
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 16:24 ---
Created an attachment (id=12796)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12796&action=view)
patch
It unfortunately miscompares ... (but the testsuite is clean)
--
http://gcc.gnu.org/bugzilla/show_b
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |middle-end
h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 16:33 ---
Actually there are two issues with this bug, one issue is that we change
(float)(CMP) into CMP?1.0:0.0 early on which in the end causes us to produce
three different versions of the inner loop. If we write the inner
--- Comment #4 from pinskia at gmail dot com 2006-12-13 16:37 ---
Subject: Re: [4.3 Regression]
gcc.dg/pr19633-1.c fails on the mainline
On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org
wrote:
> Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, i
The attached sample code (as usual, much reduced but possibly not yet minimal)
produces the subject error.
[EMAIL PROTECTED] BUGS]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-20061212/configure --prefix=/usr/local/gcc42
--with-mpfr=/home/sfilippo/COMPIL
--- Comment #1 from sfilippone at uniroma2 dot it 2006-12-13 16:39 ---
Created an attachment (id=12797)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12797&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30202
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-12-13 16:50
---
(In reply to comment #4)
> Subject: Re: [4.3 Regression]
> gcc.dg/pr19633-1.c fails on the mainline
>
> On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org
> wrote:
> > Works for me with @1
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-13 16:59 ---
(In reply to comment #5)
> You completely misunderstood. It works for me on my *mainline* tree that has
> the mem-ssa patch applied.
Then why does it fail for FX right after your patch?
--
http://gcc.gnu.org/bu
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 17:07 ---
Confirmed. Fails on trunk as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2006-12-13 17:18:56 |2006-12-13 1
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:32
---
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00959.html fixes the ICE in the
operand scanner.
The alias times should be back to saner values, but the memory consumption
problem is still there. Still looking into
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return size_type(end() - begin()); }
A faster implementation is
size_type
size() const
{ return _M_impl._M_finish - _M_impl._M_start; }
Which avoids the temporary iterato
--- Comment #7 from dnovillo at gcc dot gnu dot org 2006-12-13 17:41
---
(In reply to comment #6)
> (In reply to comment #5)
> > You completely misunderstood. It works for me on my *mainline* tree that
> > has
> > the mem-ssa patch applied.
> Then why does it fail for FX right after y
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:49
---
(In reply to comment #2)
> Looks like the mem-ssa patches cause this.
> There are no other patches in that time frame.
>
There must be. mem-ssa is @119760. If you can reproduce with @119760, then
let me know and
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-13 17:59 ---
(In reply to comment #8)
> There must be. mem-ssa is @119760. If you can reproduce with @119760, then
> let me know and I'll take a look.
I can reproduce it at @119761 which is the same revision for the trunk as
1
vector::operator[](size_type) in bits/stl_vector.h is currently implemented as
reference
operator[](size_type __n)
{ return *(begin() + __n); }
const_reference
operator[](size_type __n) const
{ return *(begin() + __n); }
A faster implementation would be:
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:07 ---
-O1 is enough to remove all advantages of this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:08 ---
-O1 is enough to remove all advantages of this patch.
Also, that isn't really a fair timing comparison, as you've removed the
function call altogether (I still expect it to be faster, but possibly not by
10x)
--
c
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-13
18:11 ---
Subject: Re: FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
> This is a testsuite failure as this testcase will fail on targets which don't
> have C99 math functions.
Target has trunc but not lfloor.
Da
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-13 18:47 ---
Subject: Bug 30157
Author: danglin
Date: Wed Dec 13 18:47:04 2006
New Revision: 119842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119842
Log:
PR testsuite/30157
* lib/target-supports.exp
--- Comment #2 from danglin at gcc dot gnu dot org 2006-12-13 18:49 ---
Subject: Bug 30157
Author: danglin
Date: Wed Dec 13 18:49:16 2006
New Revision: 119843
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119843
Log:
PR testsuite/30157
* lib/target-supports.exp
--- Comment #2 from jacob at math dot jussieu dot fr 2006-12-13 18:54
---
Not understanding much in compiler stuff, I tried what you said, namely replace
the loop with
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
{
bool a = (i == j);
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-13 18:56 ---
(In reply to comment #2)
> than the original 1.9 seconds, but still far from the 0.3 seconds I get
> manually unrolling the loop.
Try with -ffast-math, you should get the same speed. Again the problem is with
signe
--- Comment #3 from danglin at gcc dot gnu dot org 2006-12-13 18:58 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from bergner at gcc dot gnu dot org 2006-12-13 19:19 ---
Subject: Bug 30191
Author: bergner
Date: Wed Dec 13 19:19:03 2006
New Revision: 119844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119844
Log:
PR middle-end/30191
Revert:
* reload1
--- Comment #7 from bergner at vnet dot ibm dot com 2006-12-13 19:25
---
Ok, the reload fix has been reverted until we can find another way to fix this.
Sorry for all of the trouble.
Author: bergner
Date: Wed Dec 13 19:19:03 2006
New Revision: 119844
URL: http://gcc.gnu.org/viewcvs?r
--- Comment #1 from jv244 at cam dot ac dot uk 2006-12-13 19:28 ---
This problem seems to be at the root of most CP2K regtest failures described in
PR29975
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bergner at gcc dot gnu dot
|dot org
--- Comment #8 from bergner at gcc dot gnu dot org 2006-12-13 19:34 ---
The offending patch has been reverted.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-12-13 19:47 ---
(In reply to comment #7)
Sorry, I misunderstood you. Now the test works - most of the time:
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
/home/amylaar/bld/2006-11-27-29858/i6
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-13 19:47 ---
Simplified version (might not cover all problems):
character(len=20) myfmt
myfmt="(1X,a,'x')"
WRITE(*,fmt=trim(myfmt)) "y"
END
If one looks now at the dump:
_gfortran_string_trim (&len.2, (void * *) &
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-13 20:11 ---
CC: some more libgfortran/io experienced persons.
There seems to go something wrong when one uses
format = "(1X,a,'xyz')"
write(*,fmt=trim(format)) "A"
The result is:
Az'
Expected:
Axyz
The values in write_co
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-12-13 20:22 ---
Subject: Re: gcc doesn't unroll nested loops
> Not understanding much in compiler stuff, I tried what you said, namely
> replace
> the loop with
>
> for( int i = 0; i < 3; i++ )
>
--- Comment #5 from jacob at math dot jussieu dot fr 2006-12-13 20:22
---
Nope... with -O3 -ffast-math I get 1.9 seconds in average (this is a laptop
with CPU frequency scaling, so it's difficult to get precise numbers). Adding
-funroll-loops in addition to -ffast-math doesn't seem to m
--- Comment #6 from jacob at math dot jussieu dot fr 2006-12-13 20:24
---
(In reply to comment #4)
> most likely not in 4.2. I think something could be done in 4.3 timeframe.
ah, ok. Thanks for the information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
--- Comment #3 from tobi at gcc dot gnu dot org 2006-12-13 20:46 ---
Fixed by Ira in r119730, thanks.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-13 21:12 ---
(In reply to comment #3)
> CC: some more libgfortran/io experienced persons.
>
> There seems to go something wrong when one uses
> format = "(1X,a,'xyz')"
> write(*,fmt=trim(format)) "A"
> The result is:
> Az'
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-13 21:32 ---
ICE is gone, if one removes intent(out).
ICE is at gfc_conv_descriptor_data_addr:
gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
program class_scal_p
implicit none
type scal_p
real, allocatable :: b(:)
end ty
--- Comment #36 from tkoenig at gcc dot gnu dot org 2006-12-13 21:37
---
Fixed for trunk and 4.2. Will not backport to 4.1.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from John dot Tytgat at aaug dot net 2006-12-13 22:01
---
Proposed patch works fine. Interworking safeness isn't important for my target
so that's why didn't consider your approach. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
--- Comment #4 from John dot Tytgat at aaug dot net 2006-12-13 22:03
---
Just to avoid confusion, in comment #3 I was talking about patch with id 12793,
not mine. I've tested it and works equally well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
g++ and gcj should take an --unmangle option (or some such). The effect would
be to tell ld to deliver its undefined symbols error messages with names that
have been unmangled by the algorithm appropriate to the language used.
Actually, I think this should be the default, and you should have to d
This problem occurs after creating a module file with one compilation, and then
trying to use that module file in a second compilation, as shown below:
# gfortran -I/usr/local/openmpi-1.1.2-gcc/include -c -Wall -Jmod -I. -Imod -g
Source/Constants.f90 -o obj/Constants.o
# gfortran -I/usr/local/ope
--- Comment #1 from dmcr at Princeton dot EDU 2006-12-13 22:24 ---
Created an attachment (id=12798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12798&action=view)
The source file whose module file appears to be corrupt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
--- Comment #2 from dmcr at Princeton dot EDU 2006-12-13 22:25 ---
Created an attachment (id=12799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12799&action=view)
Module file created by gfortran from Constants.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
--- Comment #3 from dmcr at Princeton dot EDU 2006-12-13 22:26 ---
Created an attachment (id=12800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12800&action=view)
Source file that contains "USE CONSTANTS"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 22:37
---
(In reply to comment #9)
> (In reply to comment #8)
> > There must be. mem-ssa is @119760. If you can reproduce with @119760, then
> > let me know and I'll take a look.
>
> I can reproduce it at @119761 which i
--- Comment #4 from kargl at gcc dot gnu dot org 2006-12-13 23:22 ---
You code compiles fine with newer versions of gfortran
troutmask:sgk[224] gfc --version
GNU Fortran 95 (GCC) 4.2.0 20060927 (experimental)
troutmask:sgk[225] gfc4x --version
GNU Fortran 95 (GCC) 4.3.0 20061211 (exper
--- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50
---
The memory problem is quite simple: We just have a *lot* of pointers and a
*lot* of addressable symbols. Here is a breakdown of what happens on the first
call to compute_may_aliases:
During the first call to com
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 23:54
---
(In reply to comment #9)
> The memory problem is quite simple: We just have a *lot* of pointers and a
> *lot* of addressable symbols. Here is a breakdown of what happens on the
> first
> call to compute_may_alia
--- Comment #7 from jvdelisle at verizon dot net 2006-12-14 00:12 ---
Subject: Re: Namelist issues when reading in asterisk
preceeded arrays
Thanks for checking the latest 4.1, I just updated my 4.1 branch last night and
I had not had a chance to check it.
Also, the namelist I/O pre
--- Comment #5 from jvdelisle at verizon dot net 2006-12-14 00:26 ---
Subject: Re: write(*,myfmt="(1X,a,'xyz')") "A" prints
Az' instead of Axyz
I wonder if this is not a case of the io.h dependency bug hitting yet again. I
would fix it if I knew how.
--
http://gcc.gnu.org/bugz
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-12-14 01:11
---
Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory
On 13 Dec 2006 23:50:17 -, dnovillo at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #9 from dnovillo at gcc
--- Comment #7 from tobi at gcc dot gnu dot org 2006-12-14 01:18 ---
I have a patch, but it adds another ugly layer of code, I'll try to clean this
mess up and then submit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-12-14 02:29
---
More information. I get Tobias bad result with -m64 on x86-64-Linux. The
problem goes away with -m32.
$ gfortran -m32 pr30200-2.f90
$ ./a.out
Axyz
$ gfortran -m64 pr30200-2.f90
$ ./a.out
Az'
I get a simila
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 02:47 ---
Can you test with -O1 or above?
As mentioned in comment #1, this should remove all advatages gained from the
"inlined" version.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 02:49 ---
Can you test with -O1 or above?
As mentioned in comment #1, this should remove all advatages gained from the
"inlined" version.
> Also, that isn't really a fair timing comparison, as you've removed the
> function ca
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 02:50
---
(In reply to comment #11)
> I'll give the bitmaps a try for the operand scanner and see how it works.
>
OK. Hopefully that won't introduce a huge slowdown in the operand scanner.
Assigning back to you.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-14 02:54 ---
You should use -Wl,--demangle really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30205
1 - 100 of 124 matches
Mail list logo
