ptimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-07 11:34 ---
I forgot:
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(TM) XP 2600+
stepping: 1
cpu MHz : 2083.200
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-12-07 11:55 ---
On x86_64:
With 4.3.3:
$ ./a.out
subroutine with explicit interface and unroll(1):1.5400960 s
With 4.4.0:
$ ./a.out
subroutine with explicit interface and unroll(1):1.5480961 s
Probably
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-12-07 12:25 ---
I'll upgrade to current trunk and run another test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-12-09 22:12 ---
Created an attachment (id=16866)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16866&action=view)
better test case
Thou shalt use IMPLICIT none, especially if you think you don't need it...
Her
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-11 21:22 ---
This is still active with gcc -cx-complex-rules:
:
foo (&c);
D.2256 = (double) REALPART_EXPR ;
D.2258 = (double) IMAGPART_EXPR ;
if (ABS_EXPR < ABS_EXPR != 0)
goto ;
else
goto ;
:
Inva
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-11 21:28 ---
Still doesn't work with current trunk:
$ gcc -march=i386 -O2 -m32 hh.c
hh.c: In function 'foo':
hh.c:19: error: can't find a register in class 'GENERAL_REGS' while reloading
'asm
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-12-13 19:55 ---
Has this been fixed in the meantime?
Uros, you wrote in
http://gcc.gnu.org/ml/gcc/2008-12/msg00228.html that bootstrap works
on Alpha...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-17 07:33 ---
Not a regression:
gfortran ice.f90
ice.f90: In function 'xmain':
ice.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with pr
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-12-19 17:20
---
(In reply to comment #10)
> Many thanks, Dominique! At least I have something to work on. It's a cursed
> nuisance not having access to a fully functioning system, when I have time to
> work on gfo
t string comparisons
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDe
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-21 12:03 ---
To clarify, we could detect that the variable only ever
has the value of 'yes'. We already do the right
thing with constants:
$ cat foo-2.f90
program main
character(len=3), parameter :: a = 'yes&
ty: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38601
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-21 18:00 ---
... using the command
gcc -O2 -S -fomit-frame-pointer -march=core2 pr34256.c
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from tkoenig at gcc dot gnu dot org 2008-12-22 00:01
---
There are quite a few new failures on x86_64-unknown-linux-gnu.
No time tonight to look at this.
=== gfortran tests ===
Schedule of variations:
unix/-fdefault-integer-8
Running target unix
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-12-25 14:16 ---
Works with 4.3:
$ gfortran mangle.f90
/tmp/cckeR5NO.o: In function `MAIN__':
mangle.f90:(.text+0x2f): undefined reference to `__m_MOD_g'
collect2: ld returned 1 exit status
$ gfortran-4.3
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-25 15:53 ---
This is now an error:
$ gcc -mmmx -fcall-saved-mm0 bug.c
bug.c: In function 'f':
bug.c:6: error: incompatible type for argument 1 of '__builtin_ia32_pxor'
bug.c:6: note: expected 'int __vec
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-12-25 15:59
---
Original test case still takes a long time.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from tkoenig at gcc dot gnu dot org 2008-12-25 15:55
---
There hasn't been activity on this for a long time.
Is this still an issue?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-12-25 21:49 ---
Is this still current?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-25 21:52 ---
This works now:
$ cat foo.c
int a; // ok
int (b); // ok
typeof(a) c; // ok
typeof(a) (d); // error
$ gcc -S foo.c
$ gcc-4.3 -S foo.c
$ gcc-4.2 -S foo.c
(may originally have been caused by the missing semicolon
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-12-25 21:55 ---
The preprocessed source no longer compiles with gcc 4.3.2:
n file included from /usr/include/c++/3.3.4/bits/basic_ios.h:45,
from /usr/include/c++/3.3.4/ios:52,
from /usr/include/c
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-26 09:10 ---
(In reply to comment #3)
> > Works with 4.3:
>
> Well, not really. gfortran 4.1/4.2/4.3 only call the module procedure, but for
> "call f()" the contained procedure should be called, which
"/home/tkoenig/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/libgcc.a", O_RDONLY)
= 11
[pid 15560] open("/lib/libc.so.6", O_RDONLY) = 12
[pid 15560] open("/usr/lib/libc_nonshared.a", O_RDONLY) = 5
[pid 15560] open("/lib64/ld-linux-x86-64.so.2", O_RDONLY) = 6
[pid 15
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-26 10:54 ---
Same problem with g++:
tkoe...@gcc16:/tmp$ g++ hello.cc
tkoe...@gcc16:/tmp$ g++ -V4.3.3 hello.cc
/tmp/ccQtuMbq.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit s
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-12-26 11:46 ---
Closing, then.
Once again, the number of gcc bugs goes down by approximately 0.02% :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-26 11:49 ---
This bug hasn't been active for a long time.
Is this still an issue?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-26 15:44 ---
(In reply to comment #3)
> IIRC this is by design.
What on earth for?
Especially, what could be the reason for having -V, while making sure
it doesn't work?
I'll try the switch suggested by Daniel.
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-26 16:02 ---
Is there a test case which shows the wrong-code
behavior, and which can be checked against the
new register allocator?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-26 16:07 ---
Failing with 183 failures with
gcc -std=c99 foo.c -lm
on current trunk with x86_64-unknown-linux-gnu
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-12-26 16:08 ---
Is this still an issue with current trunk?
gcc 3.4 has been out of maintenance for some time.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-12-26 16:11 ---
Works with current trunk, 4.1 is no longer maintained.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-26 16:40 ---
(In reply to comment #2)
> --enable-version-specific-runtime-libs, maybe?
>
Doesn't do what I want:
tkoe...@gcc16:/tmp$ g++ -V4.3.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Conf
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.2
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-12-26 22:48
---
(In reply to comment #8)
> Plus this is documented this way:
> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Target-Options.html#index-V-901
I see this works for gcc. I also see (in the 4.4.0 docs)
#
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-12-28 16:44 ---
Is this still an issue with current trunk, or
with 4.3?
If that's the case, please add a test case,
with preprocessed source (even if it is very large)
showing the problem.
--
tkoenig at gcc dot gnu do
us: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38654
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-29 12:24 ---
Some simple test cases:
$ cat write-dollar.f
program main
do i=1,10**6
write (10,fmt='(A$)') 'a'
end do
end
$ g77-3.4 -O write-dollar.f && time ./
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-12-29 15:18 ---
Test case compiled flawlessly with ~ 530 mb
maximum memory usage with -O3 on current trunk
on i686-pc-linux-gnu.
I'd say this is fixed.
--
tkoenig at gcc dot gnu dot org changed:
What|Re
normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-29 21:15 ---
Created an attachment (id=17004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17004&action=view)
failing test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.2
Known to work||4.4.0
ority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 38654
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38668
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-30 10:02 ---
Strange to say, this depends on the bittian-ness.
On x86_64-unknown-linux-gnu with -m32 and on i686-pc-linux-gnu, I get
the behavior described.
On x86_64-unknown-linux-gnu without -m32, I get
lseek(3, 9613
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-12-30 11:16 ---
(In reply to comment #1)
> Strange to say, this depends on the bittian-ness.
> On x86_64-unknown-linux-gnu with -m32 and on i686-pc-linux-gnu, I get
> the behavior described.
> On x86_64-unknown-linux
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-01-01 18:38 ---
This is looking promising (and passes regression-test), and I think
that this does the right thing (the symbol in question doesn't need
to be a procedure, correct?)
Paul, could you maybe comment?
$ svn diff
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 23169
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38691
--- Comment #9 from tkoenig at gcc dot gnu dot org 2009-01-02 11:04 ---
(In reply to comment #8)
> There is no way to tell the middle-end about anonymous readonly memory.
So, we could either
- teach that to the middle-end (I couldn't, though :-)
- make a duplicate variable fo
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-01-03 11:32 ---
Confirmed, goes back at least to 4.2 (so not a regression).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from tkoenig at gcc dot gnu dot org 2009-01-05 11:08
---
Reduced test case
- works on i686-pc-linux-gnu for all optimization levels
- works with -m32 on x86-64-unknown-linux-gnu
- works with 4.3.2
--
tkoenig at gcc dot gnu dot org changed:
What
--- Comment #7 from tkoenig at gcc dot gnu dot org 2009-01-05 10:43 ---
Subject: Bug 38672
Author: tkoenig
Date: Mon Jan 5 10:43:39 2009
New Revision: 143074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143074
Log:
2009-01-05 Thomas Koenig
PR fortr
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-01-05 10:46 ---
Fixed on trunk, will wait for a few days before committing
to 4.3.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-01-05 14:24 ---
Marking as regression according to Dominique's comment.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.3.3 4.4.0 |4.3.3
Known to work|4.3.2 |4.3.2 4.4.0
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-01-06 13:05 ---
This appears to resolve the issue(s):
Index: interface.c
===
--- interface.c (revision 143076)
+++ interface.c (working copy)
@@ -2411,9 +2411,12
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-01-06 23:03 ---
Subject: Bug 38220
Author: tkoenig
Date: Tue Jan 6 23:03:18 2009
New Revision: 143140
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143140
Log:
2009-01-06 Thomas Koenig
PR fortr
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-01-06 23:05 ---
Fixed on trunk, closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-01-13 20:46 ---
This is a dup of PR 20618, which was closed as WONTFIX at the time.
The semantics of variable formats are very tricky (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618#c1 ),
so this is hard to get right
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-01-14 10:32 ---
It would also make a lot of sense to do this for allocated
arrays, as well.
(Original request from Clive Page on c.l.f)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38957
--- Comment #10 from tkoenig at gcc dot gnu dot org 2009-01-24 21:49
---
Subject: Bug 38672
Author: tkoenig
Date: Sat Jan 24 21:49:28 2009
New Revision: 143655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143655
Log:
2009-01-24 Thomas Koenig
PR fortr
--- Comment #11 from tkoenig at gcc dot gnu dot org 2009-01-24 21:50
---
Fixed on 4.3 as well.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-01-26 09:11 ---
(In reply to comment #2)
> the lbound should be simplified in simplify_bound even if the ARRAY argument
> is
> not a full array.
>
Here's a tentative patch:
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-01-26 09:14 ---
> Here's a tentative patch:
... which causes regressions.
Back to the drawing board.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38914
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-01-26 21:04 ---
Created an attachment (id=17186)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17186&action=view)
patch
Here's something that at least passes all the *bound* tests.
--
tkoenig at gcc dot
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-01-26 22:50 ---
> Here's something that at least passes all the *bound* tests.
Regression test passed - formal submission of the patch tomorrow,
probably.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38914
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-01-31 22:00 ---
Test case now generates this assembly:
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
#APP
# 18 "gaga.c" 1
#start1
# 0 "" 2
# 20 &quo
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-05-08 06:27 ---
Subject: Bug 37577
Author: tkoenig
Date: Fri May 8 06:27:37 2009
New Revision: 147269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147269
Log:
2009-05-08 Thomas Koenig
PR fortr
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-16 16:36 ---
Subject: Bug 37577
Author: tkoenig
Date: Sat May 16 16:36:22 2009
New Revision: 147618
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147618
Log:
2009-05-16 Thomas Koenig
PR fortr
e in SHAPE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot g
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-19 17:14 ---
Created an attachment (id=17893)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17893&action=view)
Failing test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-05-19 17:17 ---
Created an attachment (id=17894)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17894&action=view)
Driver for failing test case (identical to c_f_pointer_shape_tests_2_driver.c)
$ g
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-05-19 17:18 ---
Since I'm working in this area anyway, I might as well take this.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-21 16:31 ---
Works with 3.4:
$ cat > tmp.c
unsigned char foo(unsigned char a)
{
a >> 2;
return a;
}
$ gcc-3.4 -S -O3 -Wall tmp.c
tmp.c: In function `foo':
tmp.c:3: warning: statement with no effect
--
tkoe
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.5 |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-05-22 05:34 ---
Subject: Bug 37577
Author: tkoenig
Date: Fri May 22 05:34:10 2009
New Revision: 147791
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147791
Log:
2008-05-22 Thomas Koenig
PR fortr
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-05-23 11:42 ---
AFAIK, P3 regressions cannot be "enhancement", setting
severity to "normal".
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-05-24 19:03 ---
Switching the "known to fail" versions around to make this bug appear
on the 4.5.0 regression list... maybe this will work.
--
tkoenig at gcc dot gnu dot org changed:
What
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-05-27 05:27 ---
Subject: Bug 40187
Author: tkoenig
Date: Wed May 27 05:27:31 2009
New Revision: 147894
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147894
Log:
2009-05-27 Thomas Koenig
PR libfortr
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-05-30 13:17 ---
Subject: Bug 37577
Author: tkoenig
Date: Sat May 30 13:17:14 2009
New Revision: 148002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148002
Log:
2009-05-30 Thomas Koenig
PR fortr
--- Comment #7 from tkoenig at gcc dot gnu dot org 2009-05-30 13:17 ---
Subject: Bug 40187
Author: tkoenig
Date: Sat May 30 13:17:14 2009
New Revision: 148002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148002
Log:
2009-05-30 Thomas Koenig
PR fortr
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-06-07 14:24 ---
Does this need a 4.4 backport? I'm inclined to think not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-06-07 14:39 ---
I don't want to do any backport to 4.3 any more.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from tkoenig at gcc dot gnu dot org 2009-06-07 14:41 ---
If nobody minds, I'll do this (it's part of PR 34670
anyway).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-06-08 18:12 ---
This also causes missed warnings about unitizialized variables:
$ cat foo.f
print *,x
end
$ gfortran -O3 -Wall -Wextra foo.f
We should have some way of marking that pointer as read-only.
--
http
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-06-21 19:25 ---
Subject: Bug 37577
Author: tkoenig
Date: Sun Jun 21 19:24:55 2009
New Revision: 148769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148769
Log:
2009-06-21 Thomas Koenig
PR fortr
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-06-22 19:28 ---
Confirmed.
Backtrace:
0 0xb7e574ab in __gmpz_get_si () from /usr/local/lib/libgmp.so.3
#1 0x08132738 in gfc_simplify_spread (source=0x8c370b8, dim_expr=0x8c37128,
ncopies_expr=0x8c37198) at ../../../gcc
iority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40576
--- Comment #1 from tkoenig at gcc dot gnu dot org 2009-06-28 21:10 ---
I don't have a 4.4 compiler around to test currently.
Jerry, do you have any idea?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #10 from tkoenig at gcc dot gnu dot org 2009-06-30 17:10
---
Subject: Bug 40576
Author: tkoenig
Date: Tue Jun 30 17:10:06 2009
New Revision: 149109
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149109
Log:
2009-06-30 Thomas Koenig
PR fortr
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
GCC target triplet: x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-07-04 10:16 ---
(In reply to comment #1)
> Very naive question: is it not what -m32 should do?
The gcc info page states
`-m32'
`-m64'
Generate code for a 32-bit or 64-bit environment. The 32-bit
environ
--- Comment #4 from tkoenig at gcc dot gnu dot org 2009-07-04 11:34 ---
This would be something like Intel's -mcmodel=small, see
http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/copts/common_options/option_mcmodel.htm
--
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-07-14 19:18 ---
See also PR 30694.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40643
--- Comment #12 from tkoenig at gcc dot gnu dot org 2009-07-19 15:07
---
Subject: Bug 34670
Author: tkoenig
Date: Sun Jul 19 15:07:21 2009
New Revision: 149792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149792
Log:
2009-07-19 Thomas Koenig
PR libfortr
--- Comment #10 from tkoenig at gcc dot gnu dot org 2009-07-19 15:07
---
Subject: Bug 36874
Author: tkoenig
Date: Sun Jul 19 15:07:21 2009
New Revision: 149792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149792
Log:
2009-07-19 Thomas Koenig
PR libfortr
101 - 200 of 1518 matches
Mail list logo
