As suggested in PR29652, a meta-bug for interfaces in fortran.
--
Summary: [meta-bug] fortran interfaces
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
--- Comment #6 from kloedej at knmi dot nl 2006-10-31 08:25 ---
A short additional remark on this item:
I just learned (thanks to Paul Poli) that the NAGware f95 compiler does behave
in the same way as gfortran, i.e. refusing to compile the constant -2147483648
in:
integer(KIND=4) :: i
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-10-31
08:29 ---
Subject: RE: Module loading is not good at all
FX
-Message d'origine-
De : fxcoudert at gcc dot gnu dot org
[mailto:[EMAIL PROTECTED]
Envoyé : mardi 31 octobre 2006 08:01
I like that
--- Comment #8 from drewmccormack at mac dot com 2006-10-31 08:51 ---
Unfortunately, though the fix did work for the example code, it doesn't seem to
be general enough. In particular, if you change the example code to include
just one extra subroutine call, the same compiler error
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-31 08:59 ---
(In reply to comment #8)
Here is new code demonstrating the error. It is simply the original code with
one extra subroutine call:
That is the same as PR 29565.
So closing this bug as fixed.
--
pinskia at gcc
--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de
2006-10-31 09:13 ---
Right!
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29648
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-31 09:26 ---
works for me with g++-4.2 (GCC) 4.2.0 20061023 (prerelease).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29658
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-10-31 09:34 ---
Thanks for fixing this for real Eric.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
--- Comment #14 from bkoz at gcc dot gnu dot org 2006-10-31 09:42 ---
Eric, it looks like you've got this fixed now: great news. Solaris test results
for 2.10, 2.9, and 2.8 looked fine for the last month and a half, so I'd
assumed this patch was not problematic.
As a side note, it's
--- Comment #26 from vincent at vinc17 dot org 2006-10-31 09:54 ---
(In reply to comment #25)
As I think about it more, I'm leaning toward having a new function
mpfr_lgamma.
This is because if we want this mpfr function to mimic the behavior of
lgamma,
we need some mechanism to
--- Comment #1 from r dot emrich at de dot tecosim dot com 2006-10-31
11:06 ---
(In reply to comment #0)
jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
similiar problem here.
hppa2.0w-hp-hpux11.00
gcc-4.2.0 revison 118176
--- Comment #8 from l_heldt at poczta dot onet dot pl 2006-10-31 11:12
---
There is a similar problem in _M_detach_all() function. It iterates through
list of iterators without obtaining lock.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-10-31 11:16
---
Eric, it looks like you've got this fixed now: great news. Solaris test
results for 2.10, 2.9, and 2.8 looked fine for the last month and a half,
so I'd assumed this patch was not problematic.
I think it is,
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-31 11:26 ---
(In reply to comment #0)
As suggested in PR29652, a meta-bug for interfaces in fortran.
Oh thanks, Daniel - I was going to do it myself, so you have saved me a bit of
hassle. We have a brief break from work (for
--- Comment #4 from razya at gcc dot gnu dot org 2006-10-31 11:36 ---
Subject: Bug 29122
Author: razya
Date: Tue Oct 31 11:36:28 2006
New Revision: 118227
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118227
Log:
2006-10-31 Razya Ladklesky [EMAIL PROTECTED]
*
--- Comment #9 from pcarlini at suse dot de 2006-10-31 11:38 ---
To be honest, I don't think this code has been designed with thread safety in
mind. Fixing it completely after the fact is going to be very complex, I'm
afraid. I'll try to spend some more time on those issues, but if
Preprocessor statements (as if|else|endif|error|warning) must start in colum 1,
otherwise gfortran tries to handle them itself?!
$ cat pp.F90
PROGRAM test_preprocessor
#error EEE ! whitespace is significant
END PROGRAM
$ gfortran-4.3 -g -Wall pp.F90
In file pp.F90:3
#error EEE
1
--- Comment #10 from pcarlini at suse dot de 2006-10-31 11:47 ---
... that said, if we don't care *at all* about performance, fixing MT-safety
bugs in the _Safe_sequence or _Safe_iterator functions it's easy, just use
everywhere the iterator_base_mutex. The nasty correctness problems
--- Comment #16 from kreckel at ginac dot de 2006-10-31 11:48 ---
A quote from http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF:
While on the subject of miscreant compilers, we should remark their
increasingly common tendency to reorder operations that can be executed
--- Comment #11 from pcarlini at suse dot de 2006-10-31 11:49 ---
(In reply to comment #10)
... that said, if we don't care *at all* about performance, fixing MT-safety
bugs in the _Safe_sequence or _Safe_iterator functions it's easy,...
Of course I meant _Safe_sequence_base and
--- Comment #5 from razya at il dot ibm dot com 2006-10-31 12:08 ---
(In reply to comment #4)
Subject: Bug 29122
Author: razya
Date: Tue Oct 31 11:36:28 2006
New Revision: 118227
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118227
Log:
2006-10-31 Razya Ladklesky [EMAIL
--- Comment #6 from patchapp at dberlin dot org 2006-10-31 12:19 ---
Subject: Bug number PR29122
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01457.html
--
--- Comment #12 from pcarlini at suse dot de 2006-10-31 12:19 ---
About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(),
thus only when the container itself is destructed. Therefore, I don't think it
may cause problems in practice.
--
--- Comment #1 from burnus at gcc dot gnu dot org 2006-10-31 12:48 ---
The problem is that gfortran calls cpp with the -traditional-cpp option.
This causes some more modern constructs not to work and it also is the reason
behind your problem. (cf. PR 28662).
We need to use
--- Comment #3 from burnus at gcc dot gnu dot org 2006-10-31 13:03 ---
Confirm my bug. See also 29671 (# must be in the first column).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2006-10-31 13:02 ---
Confirm and mark as enhancement.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2006-10-31 12:54 ---
This is a useful improvement to an enhancement, so I have marked it as
enhancement.
I'd call improvement to an enhancement an euphemism as it produces wrong code
(uninitialized variables), albeit it is not easy to
--- Comment #13 from l_heldt at poczta dot onet dot pl 2006-10-31 13:12
---
(In reply to comment #12)
About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(),
thus only when the container itself is destructed. Therefore, I don't think it
may cause problems in
--- Comment #15 from l_heldt at poczta dot onet dot pl 2006-10-31 13:42
---
(In reply to comment #14)
(In reply to comment #13)
We actually encountered this problem - this is not taken from code review
only.
Again, adding a mutex to that those *_base functions it's trivial.
--- Comment #16 from pcarlini at suse dot de 2006-10-31 13:45 ---
(In reply to comment #15)
I tried to prepare a simple testcase but without any success. It seems to be
extremely hard to hit the moment when pointers are actually changed. Trivial
programs do not reveal the problem.
--- Comment #17 from amylaar at gcc dot gnu dot org 2006-10-31 14:34
---
(In reply to comment #4)
It is curious that life2 is running immediately before sched, instead of
immediately after combine. If we ran it immediately after combine, we could
get rid of the REG_DEAD/REG_UNUSED
--- Comment #10 from hjl at lucon dot org 2006-10-31 15:02 ---
It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-10-31 15:05
---
Subject: Re: [Tree-ssa] alias analysis deficiency
Details, source, etc needed.
On 31 Oct 2006 15:02:02 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #10 from hjl at lucon dot org
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2006-10-31
14:14 ---
As I mentioned to Jerry in a private email, his suggestion of...
Index: io/write.c
===
--- io/write.c (revision 118229)
+++ io/write.c
--- Comment #18 from bkoz at gcc dot gnu dot org 2006-10-31 14:37 ---
I tried to prepare a simple testcase but without any success.
This is encouraging, that you attempted it. To be clear: we just need something
that we can use to reproduce it. Please try for a complex or big testcase
Details, source, etc needed.
On 31 Oct 2006 15:02:02 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #10 from hjl at lucon dot org 2006-10-31 15:02 ---
It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.
--- Comment #14 from pcarlini at suse dot de 2006-10-31 13:23 ---
(In reply to comment #13)
We actually encountered this problem - this is not taken from code review
only.
Again, adding a mutex to that those *_base functions it's trivial. Now, please
start preparing reduced
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-10-31 18:02
---
Hopefully put to rest on mainline and 4.2 branch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:01
---
(In reply to comment #3)
coredumping is easy, simply call abort() or kill(0,SIGSEGV)
The usual signal to request a core dump is SIGQUIT.
However, I'm more a fan of either coredumping
Same opinion here.
--- Comment #17 from pcarlini at suse dot de 2006-10-31 14:30 ---
Created an attachment (id=12517)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12517action=view)
Draft patch for the issue in Comment #8 only
For the last issue, can you try this patch? If it works, then probably we
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:46
---
(In reply to comment #16)
I understood that remainder (a, b) = a - round (a/b) * b, whereas
mod (a, b) = a - int (a/b) * b
and modulo (a, b) = a - floor (a/b) * b
Right you
--- Comment #3 from burnus at gcc dot gnu dot org 2006-10-31 15:54 ---
Nice idea.
coredumping is easy, simply call abort() or kill(0,SIGSEGV)
and make sure that ulimit -c (csh: limit core) shows a big enough number.
This is actually what NAG f95 does and has the advantage that one can
--- Comment #14 from pault at gcc dot gnu dot org 2006-10-31 15:56 ---
Created an attachment (id=12518)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12518action=view)
A fix for the PR:
FX and Uros,
I believe that this correctly detects the presence of the built_in. It also
does
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:05
---
(In reply to comment #14)
It also does MODULO correctly
Why not use remainder{f,,l}? Is it incorrect?
although I am not sure that I understand why anybody
would use this intrinsic knowingly!
Agreed :)
--
--- Comment #17 from pault at gcc dot gnu dot org 2006-10-31 16:21 ---
The fortran version of Uros' #13:
real(8) :: x
real(8) :: t = 0.0
x = 1000.0
do while (x 0.0)
t = t + mod (x, 1.7e-8)
x = x - 1.0
end do
print *, t
end
Yields:
$ /irun/bin/gfortran -O2
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:02
---
Created an attachment (id=12519)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12519action=view)
Example of how to use unwind for backtrace purposes
The patch I was quoting in my previous comment; here, it
--- Comment #16 from paul dot richard dot thomas at cea dot fr 2006-10-31
16:14 ---
Subject: RE: Intrinsic MOD incorrect for large arg1/arg2 and slow.
FX,
--- Comment #15 from fxcoudert at gcc dot gnu dot org
2006-10-31 16:05 ---
(In reply to comment #14)
It also
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #19 from pcarlini at suse dot de 2006-10-31 17:01 ---
Created an attachment (id=12520)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12520action=view)
Draft patch using the _M_get_mutex idiom for _M_invalidate
This one, instead, using the _M_get_mutex idiom (similarly
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-10-31 17:55
---
Subject: Bug 24071
Author: ebotcazou
Date: Tue Oct 31 17:54:58 2006
New Revision: 118259
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118259
Log:
PR target/24071
* gthr-posix.h
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-10-31 17:56
---
Subject: Bug 24071
Author: ebotcazou
Date: Tue Oct 31 17:55:32 2006
New Revision: 118262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118262
Log:
PR target/24071
* gthr-posix.h
--- Comment #20 from l_heldt at poczta dot onet dot pl 2006-10-31 17:23
---
(In reply to comment #16)
(In reply to comment #15)
I tried to prepare a simple testcase but without any success. It seems to be
extremely hard to hit the moment when pointers are actually changed. Trivial
--- Comment #9 from hjl at lucon dot org 2006-10-31 14:59 ---
FYI, the fix for this bug miscompiles gcc in SPEC CPU 2006 on both x86 and
x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-31
15:38 ---
Subject: Re: jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes
jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
similiar problem here.
--- Comment #5 from sje at cup dot hp dot com 2006-10-31 18:15 ---
I forgot to include the PR number in my ChangeLog entry but this defect is
fixed with the patch in comment #4. It has been backported to the 4.0, 4.1,
and 4.2 branches as well as being checked in on the ToT.
--
sje
`-fdump-tree-inlined' creates no files.
Environment:
System: Linux 2.2.19-7.1.asp.2.gin #1 Tue Jun 15 16:42:13 MSD 2004 i686
unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure
How-To-Repeat:
--- Comment #6 from burnus at gcc dot gnu dot org 2006-10-31 18:37 ---
Using unwind is the way to go for a more serious solution.
Looks nice as a starting point. (My biggest problem with developing this would
be to find out whether it works on strange machines like Sparc, Windows etc.)
Sees:
When compiling using the -Wconversion flag the strtok_r the comppiler complains
with a
warning: passing argument 2 of __strtok_r_1c with different width due to
prototype
Expects:
No warning when the -Wconversion option is specified
System Info:
gcc (GCC) 4.1.1 20061011 (Red Hat
- Support for coredumps (compile time? Environment variable? The latter
overwriting the former?)
[Advantage compile-time option: The core is there, if one needs it. Advantage
run-time option: One can quickly turn it on, if needed.]
- Traceback support more or less as outlined above (comment
--- Comment #7 from pinskia at physics dot uc dot edu 2006-10-31 19:10
---
Subject: Re: Force core dump on runtime library errors
- Support for coredumps (compile time? Environment variable? The latter
overwriting the former?)
[Advantage compile-time option: The core is there, if
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-31 19:12 ---
__strtok_r_1c is due to glibc having a define for strtok_r so this is not a bug
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from gin at mo dot msk dot ru 2006-10-31 19:17 ---
Subject: Re: can not build libgcc.a on stage 1
Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is
certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of
4.1.1 release.
--
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-31 19:36
---
Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is
certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of
4.1.1 release.
It is not obsolete, it is not supported. Sun did the
--- Comment #3 from charlet at gcc dot gnu dot org 2006-10-31 19:41 ---
Fixed on mainline.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from ghazi at gcc dot gnu dot org 2006-10-31 20:08 ---
(In reply to comment #26)
Yes, it's true that it is useful to have this value. But determining it
separately is quite easy, without taking a noticeable additional time in
average.
It's likely that I'll end up
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-10-31 20:15
---
Subject: Bug 29067
Author: fxcoudert
Date: Tue Oct 31 20:15:22 2006
New Revision: 118338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118338
Log:
PR fortran/29067
* decl.c
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-10-31 20:58 ---
Subject: Bug 29627
Author: tkoenig
Date: Tue Oct 31 20:58:26 2006
New Revision: 118341
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118341
Log:
2006-10-31 Thomas Koenig [EMAIL PROTECTED]
PR
My boss teared my hair off with heavy sarcasm when we turned on -fbound-check.
The runtime executable proudly reported an array reference out of bounds.
My boss screamed Which bloody one?!
While I am very happy to know we have an array reference out of bounds
I can see his point. Could the
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-31 21:37 ---
Steve Lionel from Intel wrote
http://groups.google.com/group/comp.lang.fortran/tree/browse_frm/thread/062ce3447e5ef570/7e2c6b5723c3b228#doc_a7f0b804f755e27b
For a record length greater than
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-31 21:38 ---
Upgrade to the a 4.2 pre-release version of gfortran or
the mainline version. Please report back if you find
a problem.
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-31 21:41 ---
The other thing is with debugging option such as -fbounds-check, you can also
use gdb to figure out which one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29677
My boss teared my hair off with heavy sarcasm when we turned on -fbound-check.
The runtime executable proudly reported an array reference out of bounds.
My boss screamed Which bloody one?!
While I am very happy to know we have an array reference out of bounds
I can see his point. Could the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-31 21:48 ---
*** This bug has been marked as a duplicate of 29677 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-31 21:48 ---
*** Bug 29678 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29677
--- Comment #12 from hjl at lucon dot org 2006-10-31 21:48 ---
Created an attachment (id=12521)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12521action=view)
A testcase
Here is a testcase. Both bad.s and good.s are compiled with -O2. The
difference in assembly output is
[EMAIL
--- Comment #28 from vincent at vinc17 dot org 2006-10-31 22:15 ---
(In reply to comment #27)
It's likely that I'll end up doing it, so would you please tell me how?
According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if
[iff] x 0 remainder(floor(x), 2) !=
--- Comment #13 from hjl at lucon dot org 2006-10-31 22:22 ---
Created an attachment (id=12522)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12522action=view)
A smaller testcase
Here is a smaller testcase.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-31 23:24
---
Jack,
I don't think this is the final fix. However, after you test that other
possibility I sent you I think I can finalize a patch. If zero terminating
buffer does not solve the problem, then I think it
/20061031-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/loop.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-10-31 23:38
---
Should be fixed now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from aldot at gcc dot gnu dot org 2006-10-31 23:39 ---
Subject: Bug 29537
Author: aldot
Date: Tue Oct 31 23:38:58 2006
New Revision: 118347
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118347
Log:
fortran/ChangeLog:
2006-11-01 Bernhard Fischer [EMAIL
--- Comment #12 from aldot at gcc dot gnu dot org 2006-10-31 23:42 ---
(In reply to comment #10)
Bernhard,
This is ok for trunk.
Thanks. Worth backporting this to 4.2 (and 4.1) in a week or two?
--
aldot at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2006-10-31 23:47 ---
Subject: Re: ICE in gfc_match_common for blank common in BLOCK DATA unit
On Tue, Oct 31, 2006 at 11:42:42PM -, aldot at gcc dot gnu dot org wrote:
Bernhard,
This is ok for trunk.
In this code, the shape of 'a1(1,1:3)' in the initialization of b1 should be 3,
but it is appearantly '1 3', i.e. we fail to remove the '1' from the
shape-list.
erik:~/gcc$ cat bug.f90
program init
implicit none
integer, parameter :: a1(2,6) = reshape([1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
--- Comment #21 from pcarlini at suse dot de 2006-10-31 23:53 ---
(In reply to comment #20)
I think we are totally misunderstood here.
No, no, there is something *completely* different to it. Sorry, but I'm now
convinced that you are here with the *wrong* spirit, aren't technical
The fix for PR14784 causes misscompilation of gcc in spec2006, at -O2. Some
discussion of the problem is in PR14784, I am moving it to a separate bug
report.
--
Summary: Misscompilation of spec2006 gcc
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from rakdver at gcc dot gnu dot org 2006-11-01 00:07 ---
Created an attachment (id=12523)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12523action=view)
The testcase.
--
rakdver at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-11-01 00:12 ---
The problematic piece of .alias5 dump:
p_27 = fde_13-dw_fde_cfi;
# VUSE SMT.48_79;
D.1763_23 = fde_13-dw_fde_cfi;
if (D.1763_23 != 0B) goto L8; else goto L10;
# p_18 = PHI p_30(9), p_27(8);
L10:;
#
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-11-01 00:49 ---
access_can_touch_variable determines that fde_13-dw_fde_cfi cannot touch
cie_cfi_head; the list of virtual operands of the load thus becomes empty, and
we insert SMT.48 for it.
On *p, we cannot eliminate
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-11-01 01:29 ---
Subject: Re: Misscompilation of spec2006 gcc
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-11-01 00:49
---
access_can_touch_variable determines that fde_13-dw_fde_cfi cannot touch
--- Comment #3 from sayle at gcc dot gnu dot org 2006-11-01 02:56 ---
Subject: Bug 23470
Author: sayle
Date: Wed Nov 1 02:56:45 2006
New Revision: 118355
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118355
Log:
PR middle-end/23470
* tree.h
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-01 04:30 ---
(In reply to comment #3)
This is now fixed on mainline provided the user specifies -ffast-math.
There are some complications where imagpart(z*~z) can be non-zero, if
imagpart(z) is non-finite, such as an Inf or a
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2006-11-01
04:33 ---
I have pinned down the problem. On Darwin PPC with Xcode 2.4, at -O1 or
higher we have problems with the isfinite() macro from libgfortran.h. For the
nan_inf_fmt testcase it should always return 0, but
--- Comment #5 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 ---
Subject: Bug 11377
Author: geoffk
Date: Wed Nov 1 04:47:30 2006
New Revision: 118356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118356
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
--- Comment #13 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 ---
Subject: Bug 16622
Author: geoffk
Date: Wed Nov 1 04:47:30 2006
New Revision: 118356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118356
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-01 04:48
---
(In reply to comment #15)
I think it we need to cast both x variables in the macro to unsigned long.
No, that would be incorrect.
Jack, can you attach the preprocessed source for write.c?
--
pinskia at gcc
--- Comment #14 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 ---
Subject: Bug 16622
Author: geoffk
Date: Wed Nov 1 04:48:15 2006
New Revision: 118357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118357
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 ---
Subject: Bug 11377
Author: geoffk
Date: Wed Nov 1 04:48:15 2006
New Revision: 118357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118357
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
--- Comment #9 from geoffk at gcc dot gnu dot org 2006-11-01 04:53 ---
Subject: Bug 15834
Author: geoffk
Date: Wed Nov 1 04:53:33 2006
New Revision: 118358
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118358
Log:
PR 15834
* config/darwin.h
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-11-01 04:56
---
Jack is right about one thing and I should have noticed this. For that test
case we should never get into output_float where we are segfaulting. The
handling of nan and inf are handled in the calling function
1 - 100 of 113 matches
Mail list logo
