--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-14 06:43 ---
Using
data ( string(i) ,i=-3,1 ) / &
'A', 'B', 'C', 'D', 'E' /
gives even an ICE.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
subroutine test(n)
character(len=20), dimension(n) :: string
data ( string(i) ,i=1,n ) / &
'A', 'B', 'C', 'D', 'E' /
end subroutine
gives currently:
data ( string(i) ,i=1,n ) / &
1
Error: iterator end at (1) does not simplify
which is unclear, how abou
--- Comment #11 from spark at gcc dot gnu dot org 2007-06-14 03:53 ---
(In reply to comment #10)
> Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
>
> > It's my turn to ask: so what information does hppa_can_use_return_p
> > need to make the decision ?
>
> We ne
--- Comment #50 from dannysmith at users dot sourceforge dot net
2007-06-14 03:21 ---
(In reply to comment #37)
> I think basically you are messed up untill Cygwin switches to dwarf2
> exceptions.
>
This is now (=gcc 4.3) possible by adding --disable-sjlj-exceptions to
configure.
Can w
gcc/testsuite/gcc.dg/dfp/dfp-except.h has
extern void __dfp_clear_except (int);
#define DFP_CLEAR_EXCEPT(M) __dfp_clear_except(M)
extern int __dfp_test_except (int);
#define DFP_TEST_EXCEPT(M) __dfp_test_except(M)
However, libdecnumber/decExcept.h has
void __dfp_clear_except (void);
int __dfp_te
--- Comment #7 from pinskia at gmail dot com 2007-06-14 02:56 ---
Subject: Re: Thread race segfault in std::string::append with -O and -s
> bug 21334 seems to deal with multiple threads accessing the same shared object
> at the same time. However, the sample code provided here involve
bug 21334 seems to deal with multiple threads accessing the same shared object
at the same time. However, the sample code provided here involves separate
private objects so there should not be any such issues. If it is not possible
to assume that separate threads can access unrelated STL objects
--- Comment #6 from jlawson-gcc at bovine dot net 2007-06-14 02:42 ---
bug 21334 seems to deal with multiple threads accessing the same shared object
at the same time. However, the sample code provided here involves separate
private objects so there should not be any such issues. If it
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-14 02:16 ---
This was fixed by:
2007-06-12 Seongbae Park <[EMAIL PROTECTED]>
* gcse.c (cpro_jump): Don't emit barrier in cfglayout mode.
As the barrier was being created by gcse (before the merge of df branch).
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-14 01:30 ---
Can you provide the preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32322
--- Comment #41 from pinskia at gcc dot gnu dot org 2007-06-14 01:27
---
*** Bug 32261 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-14 01:27 ---
*** This bug has been marked as a duplicate of 21334 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from pinskia at gmail dot com 2007-06-14 01:14 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
On 14 Jun 2007 01:09:16 -, dougkwan at google dot com
<[EMAIL PROTECTED]> wrote:
> Unless the compiler can prove that f() does not s
--- Comment #17 from dougkwan at google dot com 2007-06-14 01:09 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Unless the compiler can prove that f() does not save the pointer to c
and use it later, it cannot share a stack slot for c & c1. This
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-14 01:02
---
The problem is that it needs also source style scoping also:
take:
int f(int *a);
int g(int b)
{
{
int c;
f(&c);
}
{
int c1;
f(&c1);
}
}
Without source based ones, we don't know if c/c1 can
--- Comment #15 from dougkwan at google dot com 2007-06-14 00:59 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Then the stack local sharing code is very broken. It should do a real
live-range analysis instead of using block scoping information f
--- Comment #14 from pinskia at gmail dot com 2007-06-14 00:52 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
On 14 Jun 2007 00:46:28 -, dougkwan at google dot com
<[EMAIL PROTECTED]> wrote:
> Yes, I saw the code there yesterday and I was won
--- Comment #13 from dougkwan at google dot com 2007-06-14 00:46 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Yes, I saw the code there yesterday and I was wondering if the block
scope got fixed up somehow.
14 Jun 2007 00:42:23 -, pinskia
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-14 00:42
---
This code has been there since 4.0.0 so this has been true since then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-14 00:42
---
Look at the code in cfgexpand.c, expand_used_vars, this looks at the source
blocks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- Comment #10 from dougkwan at google dot com 2007-06-14 00:35 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Talked to Dan Berlin and Diego Novillo here at Google. They told me
that all locals are promoted to function scope.
In generally, the
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-14 00:28 ---
(In reply to comment #8)
> Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
> code
>
> I thought like you do initially. But then I was told that in gimple
> everything is promoted to fu
--- Comment #8 from dougkwan at google dot com 2007-06-14 00:14 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
I thought like you do initially. But then I was told that in gimple
everything is promoted to function scope. So dest is not out of sco
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 23:50 ---
Read the documentation, use `externally_visible' as the docs say to.
There is nothing here really except you did not read the docs at all, even
though you quoted them :).
--
pinskia at gcc dot gnu dot org change
The bug report is about the use of the option "-fwhole-program".
When I compiled a program (crlibm-0.18beta1.tar.gz , described in bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180 ) I found that GCC 4.2.0 with
option "-O2" produced code that was _slightly_ faster than GCC 4.3.0 with
--- Comment #15 from rob1weld at aol dot com 2007-06-13 23:39 ---
>Can you provide a working patch?
Soon. I am trying to fix the math inaccurcy in GCC 4.3.0 and merge a a new math
library. You can try sticking that oneliner into your configure if your in a
rush.
--
http://gcc.gnu.o
--- Comment #5 from tdragon at tdragon dot net 2007-06-13 22:47 ---
Is it possible that an optimization enabled by -O2 *assumes* that hashitem()
will conform with strict aliasing by not dereferencing that argument, and thus
optimizes those lines away? (Not the case.) If this is what is h
--- Comment #4 from tdragon at tdragon dot net 2007-06-13 22:36 ---
(In reply to comment #2)
> Though we could have an alias violation if you don't cast back in hashitem to
> the correct type of the argument.
hashitem() uses the type as punned to HASHDATA* (where HASHDATA is a struct
wit
--- Comment #10 from geoffk at gcc dot gnu dot org 2007-06-13 22:31 ---
I think this problem is limited to just typeinfo.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tdragon at tdragon dot net 2007-06-13 22:27 ---
(In reply to comment #2)
> Do you mean the last two stores to b:
> b->time = time;
> b->progress = found ? 4 : 2;
Yes, those two lines are the ones that are wrongly skipped.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 22:21 ---
Do you mean the last two stores to b:
b->time = time;
b->progress = found ? 4 : 2;
Though we could have an alias violation if you don't cast back in hashitem to
the correct type of the argument. This is still a b
--- Comment #7 from echristo at apple dot com 2007-06-13 22:16 ---
Um. Right. :)
The new version is fine if it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 ---
(In reply to comment #6)
> Fixing alias analysis in 4.2.0 will make this problem go away but it
> does not change the underlying issue in the stack local sharing code.
Is that really true? The underlying issue is s
--- Comment #6 from dougkwan at google dot com 2007-06-13 21:50 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live
code
Fixing alias analysis in 4.2.0 will make this problem go away but it
does not change the underlying issue in the stack local sharing co
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 ---
(In reply to comment #2)
> The address of dest has been passed to memcpy() and the alias analysis
> considers the varaible to escape. So potentially foo() can see the value of
> dest if memcpy() stash the pointer som
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 21:37 ---
On the trunk, dest is changed to be non addressable in alias5, why is it not
doing it in 4.2?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-13 21:32 ---
No, it should be marked as non escaping later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
--- Comment #2 from dougkwan at google dot com 2007-06-13 21:25 ---
The address of dest has been passed to memcpy() and the alias analysis
considers the varaible to escape. So potentially foo() can see the value of
dest if memcpy() stash the pointer somewhere. This is impossible but the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 21:20 ---
Why is the store to dest not being removed?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tdragon at tdragon dot net 2007-06-13 21:19 ---
Created an attachment (id=13701)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13701&action=view)
Preprocessed example source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
When the attached file is compiled with a mingw32 build of GCC 4.2.0 using the
-O2 option (gcc -O2 -c timestamp2.i), lines 159 and 160 are never executed when
running the program that uses this file. Since the hashitem function modifies
the variable b which is passed to it by-address, leaving those
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:49
---
(In reply to comment #9)
> I don't see the point of these questions though. After all, I confirmed your
> bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3. So the remaining
> question is whether this w
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:45
---
Hard to tell what is going wrong. I've been building and using compilers on
i386-darwin with no problem. Please contact the people behind HPC MacOS X to
see if they can help you using this compiler, or download ou
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #6 from daney at gcc dot gnu dot org 2007-06-13 20:39 ---
Created an attachment (id=13700)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13700&action=view)
Revised patch.
I don't know what I was thinking with the first version of the patch :-( The
new version I think
--- Comment #25 from ubizjak at gmail dot com 2007-06-13 20:20 ---
RFC patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00916.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-13 20:14 ---
Fixed in 4.3.
As it is neither a regression nor a wrong-code bug, it will not be fixed for
4.2.1 or 4.1.3.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-13 20:12 ---
Subject: Bug 32323
Author: burnus
Date: Wed Jun 13 20:12:40 2007
New Revision: 125684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125684
Log:
2007-06-13 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #6 from dje at gcc dot gnu dot org 2007-06-13 20:00 ---
>From IRC:
see.c:2732 makes a copy of an insn and then hacks on it with validate_change
(and it's close relatives). This copy has a basic_block, even though it is not
in the insn stream, as well as the same insn_uid as
Given the following code:
--
typedef unsigned int size_t;
typedef unsigned long long uint64;
extern "C" {
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n) /*throw ()*/;
}
ex
--- Comment #5 from daney at gcc dot gnu dot org 2007-06-13 19:44 ---
Unfortunatly the patch causes an ICE compiling crtstuff.c. I will have to
adjust it a bit...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
--- Comment #2 from patchapp at dberlin dot org 2007-06-13 19:30 ---
Subject: Bug number PR32323
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/2007-06/msg00910.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-13 19:27
---
*** Bug 32326 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 19:27 ---
> It does not occur targeting
I doubt those use dwarf2/3 :).
*** This bug has been marked as a duplicate of 29436 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
This may be a duplicate of PR 28868
a.c
=
typedef struct a1 {
int x;
} a1_t __attribute__((may_alias));
=
a.c:3: internal compiler error: in splice_child_die, at dwarf2out.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bug
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:
checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
config.log reveals:
configure:13794: checking for exception model to u
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 18:03 ---
Thanks for finding this bug! I think it is the following in the Fortran 2003
standard:
"12.4.1.2 Actual arguments associated with dummy data objects"
"If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT)
--- Comment #2 from andrew dot stubbs at st dot com 2007-06-13 18:00
---
As it happens, I encountered your real problem quite recently. :)
"(int)(1<<31)" is undefined (C99 standard 6.5.7/4).
This modified version gives the same result both ways:
int main (){
unsigned long long a =
--- Comment #5 from appfault at hotmail dot com 2007-06-13 17:56 ---
Ok well, I'll take your word on that, since I can't really tell where gcc and
ld end and glibc begins. It's perhaps glibc that is in need of better
documentation then. However if I file such a zilla I suspect it will
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 17:53 ---
Look at PR 17108 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDep
--- Comment #18 from kargl at gcc dot gnu dot org 2007-06-13 17:52 ---
> The libm library is the least accurate and on average the fastest; though not
> fastest for every function instance. The most accurate is always CRLibm,
> sometimes it is fastest. The MPFR library is second most acc
--- Comment #4 from appfault at hotmail dot com 2007-06-13 17:38 ---
Yes in addition to the issue of adding a test case, it is quite unsettling to
not know what might have fixed it. Reopening pending response to comment 2 and
comment 3.
--
appfault at hotmail dot com changed:
--- Comment #7 from jconner at apple dot com 2007-06-13 17:09 ---
(In reply to comment #6)
> I see that PR25505 caused a bunch of code generation regressions.
> On i?86, with -O2 -m32:
> ...
When you say regressions, I assume you mean size/performance, not correctness,
right? If so, th
--- Comment #1 from gcc at axel-naumann dot de 2007-06-13 16:50 ---
Created an attachment (id=13699)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13699&action=view)
Test case as stated in the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
The result of the division of 18446744065119617024llu by the result of (1<<31)
is wrong on a 32bit platform.
Reproduce: gcc s.c && ./a.out
should have exit code 0 but doesn't.
Expected: gcc -DEXPECTED s.c && ./a.out
has exit code 0 as expected.
gcc -v
Reading specs from /usr/lib/gcc/i386-red
[EMAIL PROTECTED] cat run.f90
module mod
implicit none
contains
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
end module mod
program ff
use mod
implicit none
integer,dimension(10)::w
w=1
call aa(w((/3,2,1/)))
write(*,*)w
end
[EMAIL PROTECTED] gfortra
--- Comment #3 from terry at chem dot gu dot se 2007-06-13 16:23 ---
(In reply to comment #2)
> Neither SUN nor Intel fortran compilers issue such a warning.
>
Indeed. That does not imply that gfortran shouldn't, though. Hence the
enhancement request.
--
http://gcc.gnu.org/bugzi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||spark at gcc dot gnu dot org
Keywords|
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-13 16:17 ---
Neither SUN nor Intel fortran compilers issue such a warning.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from terry at chem dot gu dot se 2007-06-13 16:10 ---
Ah. Of course explicit interfaces are required for automatic array arguments.
My Fortran-Fu seems to be deserting me at the moment. :-(
--
terry at chem dot gu dot se changed:
What|Removed
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-13 15:57 ---
If you would provide an explicit interface for AA, the binary would not
segfault:
$> cat pr32319.f90
program ff
implicit none
integer,dimension(4)::w
w=1
write(*,*)w
call aa(w(2:3))
write(*,*)w
contains
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-06-13 15:57 ---
(In reply to comment #2)
> The generic implementation, including for SSE, is
> isgreater (abs(f), FLT_MAX)
> For isfinite, use islessequal instead. For isnan, one can use
> isunordered(f, f)
> For isnormal, it'd
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-06-13 15:45 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html
by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00842.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tsarkov at cs dot man dot ac dot uk 2007-06-13 15:42
---
Created an attachment (id=13697)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13697&action=view)
Preprocessed sources
Code that triggers ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
In a template-context, pointers to overloaded methods are not correctly
resolved. the following main.cpp does not compile on gcc 4.1.2, however it does
compile on version 3.4.6:
#include
#include
#include
#include
namespace mi = boost::multi_index;
struct field_ts
{
int ts() const { return
>gcc-4.3 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-checking --prefix=/opt/gcc
--enable-shared --enable-threads --program-suffix=-4.3 --enable-__cxa_atexit
--disable-nls --with-mpfr=/usr/local
--enable-languages=c,c++,objc,obj-c++,treelang,fortran
+++ This bug was initially created as a clone of Bug #27668 +++
The following invalid code snippet triggers an ICE since GCC 3.4.0:
==
template struct A {};
template void foo(A);
==
bug.cc:1: error:
[EMAIL PROTECTED] cat run.f90
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
program ff
implicit none
integer,dimension(10)::w
w=1
write(*,*)w
call aa(w(1:5))
write(*,*)w
end
[EMAIL PROTECTED] gfortran -Wall -W -fbounds-check -O --std=f95 --pedantic
The spec file explains that the picture "%c" stands for
locale's date and time (including the time zone).
However, the replacement picture doesn't include %z (which
isn't supported AFAICS.)
from the spec:
-- %c locale's date and time (Sat Nov 04 12:02:33 EST 1989)
from the body:
--- Comment #6 from jakub at gcc dot gnu dot org 2007-06-13 15:22 ---
I see that PR25505 caused a bunch of code generation regressions.
On i?86, with -O2 -m32:
_Complex double foo (_Complex double x)
{
return __builtin_cexp (x);
}
generated code got much worse, similarly:
elemental fun
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-13 15:00 ---
I goofed - the previous does not fix it at all.
I hope that I am not too late to stop folk from building with this patch.
Cheers
Paul
PS Compiling the subroutines separately or padding out the first aux32 both fix
--- Comment #2 from ckirshen at gnupower dot net 2007-06-13 14:37 ---
This problem definitely exists on both hpux 11v2 and 11v3, even when passing in
--with-gnu-as and --with-as. I'm trying this on gcc-3.4.3 and gcc-3.4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18388
--- Comment #2 from patrick dot pastoor at onespin-solutions dot com
2007-06-13 14:26 ---
I am really sorry. But I think there is no possiblity to upload a preprocessed
source here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
--- Comment #1 from terry at chem dot gu dot se 2007-06-13 13:43 ---
(Whoops. Mixed up output in that last post. Only 8 reals are printed in
reality. My bad.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
--- Comment #9 from dir at lanl dot gov 2007-06-13 13:39 ---
Your Welcome Paul,
With a little luck, the fix for this will cure the remaining problems that I
have been having with my programs when optimization is turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
Even when an explicit interface is known, no warnings are generated when array
argument bounds (available to the compiler) don't match. Consider the
following:
module mod
implicit none
contains
subroutine a(n,v)
integer,intent(in)::n
real,dimension(n),intent(in)::v
write(*,*)v
end subroutine a
--- Comment #7 from rask at sygehus dot dk 2007-06-13 13:36 ---
Looking at this again, I don't think the transformation I'm making with the
splitter is valid, because I'm making up a zero extension which wasn't there to
begin with. The upper part could have been non-zero before the instr
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13
13:28 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> It's my turn to ask: so what information does hppa_can_use_return_p
> need to make the decision ?
We need to know that the return
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 13:24 ---
Sorry if I was not clear before. This is the correct fix for the testcase but
not the bug itself. Users could accidently use the %q0 and then get the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 13:14 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-13
12:36 ---
Which RTL pass should take care of such induction variable optimization in 4.3
? For e.g In 4.1, It was old-loop that was doing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
--- Comment #8 from pault at gcc dot gnu dot org 2007-06-13 12:26 ---
This fixes it but is, as yet unregtested. I'll do the business tonight and
will commit as 'obvious', if all is well.
Thanks, Dale!
Paul
Index: gcc/fortran/trans-common.c
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-13 12:08
---
Can you provide a working patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
--- Comment #3 from ubizjak at gmail dot com 2007-06-13 11:55 ---
(In reply to comment #2)
> > Sorry about the breakage. Does it work for you if you change the testcase
> > as follows?:
>
> Yes it will fix it but note there is still a bug in the ia64 back-end anyways
> so this bug shou
--- Comment #17 from joseph at codesourcery dot com 2007-06-13 11:30
---
Subject: Re: Paranoia UCB GSL TestFloat libm tests fail
- accuracy of recent gcc math poor
I previously suggested to the crlibm authors that they consider assigning
it to the FSF for contribution to libgcc-math
1 - 100 of 115 matches
Mail list logo
