--- Comment #1 from chrisp_42 at bigpond dot com 2010-04-15 06:16 ---
This is a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38493
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43749
--- Comment #5 from kargl at gcc dot gnu dot org 2010-04-15 04:13 ---
(In reply to comment #4)
> An ice is an ice. However, this is particularly nasty to me since it is
> trying
> to use reals for index variables.
>
> Have you tried to get this down to a single loop and get the ice?
>
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-04-15 03:35 ---
I've noticed that I applied a wrong patch at revision 158208 and
it causes the problematic reload in the failed case. I'll fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43741
--- Comment #2 from mail dot alexhaase at gmail dot com 2010-04-15 03:33
---
I tested on 32bits and found slightly less confusing, though still confusing
results. Bug id #43756
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43755
--- Comment #1 from mail dot alexhaase at gmail dot com 2010-04-15 03:32
---
Created an attachment (id=20385)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20385&action=view)
a demo of this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43756
I ran my demo code from bug id #43755 on a 32bit host for fun. All the casting
i could dream up for the value of ~0 << 32 resulted in a value of 0 when using
constants. However when using a variable to upshift by 32, I get the result ~0
(4294967295). I'm stumped.
--
Summary: Bit shifi
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-04-15 03:31
---
For the record: Bug is also present in gcc-4.5.0 (final).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
--- Comment #1 from mail dot alexhaase at gmail dot com 2010-04-15 03:16
---
Created an attachment (id=20384)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20384&action=view)
Bug demo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43755
I found four constant unsigned long (64bit) values which do not agree with bit
shifting ~0 by an unsigned long variable holding the value 32 (demo attached):
1) shifting ~0 by 32
2) shifting ~0 by (unsigned long)32
3) shifting ~((unsigned long)0) by (unsigned long) 32
4) shifting ~((unsigned long)0
--- Comment #5 from paolo dot carlini at oracle dot com 2010-04-15 03:09
---
(In reply to comment #4)
> MinGW doesn't have sys/ioctl.h; could we test HAVE_SYS_IOCTL_H? Are there
> likely to be any platforms we support that define FIONREAD but don't have
> sys/ioctl.h?
Dave, if you loo
--- Comment #1 from bdavis at gcc dot gnu dot org 2010-04-15 02:25 ---
i concur. it is a bug.
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2010-04-15 01:17 ---
So the ideal fix would be to change "#ifdef FIONREAD" to something more like
"#if HAVE_IOCTL && defined (FIONREAD)". But that runs into the need-link-test
vs. cross-configure problem.
MinGW doesn't have sys/ioctl.h;
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-15 01:03 ---
Is this a combined-tree build? Sounds like:
http://www.mail-archive.com/g...@gcc.gnu.org/msg27284.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-04-15 00:58 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-15 00:55
---
Dave, any idea? For sure nobody reported build problems so far, and that code
is *very* old...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #10 from kkojima at gcc dot gnu dot org 2010-04-15 00:51
---
Ah, indeed. It should be the right thing. Thanks!
I've confirmed that it fixes the build failure with no doloop
optimization problem. Could you please apply it to trunk?
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-04-15 00:48
---
There are more resent versions of gfortran available at Mingw. Closing this
bug. If the problem persists after updating to more recent, please reopen.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2010-04-15 00:35
---
I think this can be closed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-15 00:17
---
An ice is an ice. However, this is particularly nasty to me since it is trying
to use reals for index variables.
Have you tried to get this down to a single loop and get the ice?
In -fdump-tree-original I see t
--- Comment #9 from bernds at codesourcery dot com 2010-04-15 00:16 ---
Created an attachment (id=20383)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20383&action=view)
Maybe this one.
Actually, following the split leads to another pattern that's broken.
--
bernds at codesour
--- Comment #8 from bernds at codesourcery dot com 2010-04-15 00:10 ---
Created an attachment (id=20382)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20382&action=view)
Another attempt
The patch that was checked in looks wrong to me. How about this one instead?
--
http://gc
--- Comment #7 from kkojima at gcc dot gnu dot org 2010-04-14 23:58 ---
Subject: Bug 43742
Author: kkojima
Date: Wed Apr 14 23:58:10 2010
New Revision: 158361
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158361
Log:
PR target/43742
* config/sh/sh.md (doloop_end
--- Comment #11 from sje at cup dot hp dot com 2010-04-14 22:29 ---
I am going to close out this bug report since there are currently no failures
on IA64, only expected failures for libffi.call/err_bad_abi.c and
libffi.call/err_bad_typedef.c which are XFAIL'ed for all platforms.
--
s
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-14 22:10 ---
Collecting bits and pieces from all over, I'm trying to make a plan...
Consensus on IRC is that LTO data does not need its own Mach-O segment, and
that can it just fit as a section in the _TEXT (since LTO data is rea
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-14 22:06 ---
*** Bug 43754 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-14 22:06 ---
GCC 3.4 is no longer supported and g77 has been replaced with gfortran which is
a Fortran 90/95 compiler (with some support for Fortran 2003 and 2008 now and
majority of support of FORTRAN 77 too).
*** This bug has
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-14 22:05 ---
g77 is no longer maintained. You might want to try GCC 3.4.6 which contains
lots of bugfixes compared to 3.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-04-14 22:04 ---
I've tried to modify doloop_end* along in the line Bernd's patch
suggests, but can't find a good one yet. Although doloop_optimize
can be modified to recognize those patterns, it isn't a very good
idea to add extra
exact version of gcc/g77 in this case
minnie{root}154: f77 -v
Reading specs from /usr/local/lib/gcc/i686-apple-darwin8.8.1/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --enable-languages=f77
Thread model: posix
gcc version 3.4.0
command line that triggers the bug
f77 -Dunix -DMacOSX -I. -c
--- Comment #6 from wilson at gcc dot gnu dot org 2010-04-14 21:59 ---
Created an attachment (id=20381)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20381&action=view)
untested patch that works for testcase
This is logically 3 different patches that can be handled separately. Th
--- Comment #5 from wilson at gcc dot gnu dot org 2010-04-14 21:57 ---
I think the first part of the solution here is to make ira stop handling
zero-size classes as ones that have a potential register pressure problem.
The second part, is that I think we can make ar.lc a fixed register.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |fortran
Ever Conf
--- Comment #3 from sje at cup dot hp dot com 2010-04-14 21:56 ---
Created an attachment (id=20380)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20380&action=view)
Shorter version of pr41928.f90
Here is a cutdown version of the failing test. Note that in this version coset
is a
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-o
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-04-14 21:38
---
I think that's enough evidence to confirm.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from mans at mansr dot com 2010-04-14 21:34 ---
The C99 standard says this about division by zero:
The result of the / operator is the quotient from the division
of the first operand by the second; the result of the % operator
is the remainder. In both operations, i
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-14 21:30 ---
The policy has been AFAIR that we can collapse multiple traps into a single
one,
but not remove traps completely (or of course not introduce new ones).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-04-14 20:50
---
Before confirming this bug, we need to determine if the following program has
well defined behaviour:
int count_div0 = 0;
int __aeabi_div0()
{
count_div0++;
return 0;
}
int divmod(int a, int b)
{
int q =
--- Comment #8 from steven at gcc dot gnu dot org 2010-04-14 20:49 ---
Created an attachment (id=20379)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20379&action=view)
Classic GCSE, resurrected (with some improvements)
Updated patch for trunk r158281.
Bootstrapped and tested on
--- Comment #2 from tfrancuz at mp dot pl 2010-04-14 20:45 ---
Yes, it seems that you are right. I mark it as duplicate of bug #21018
*** This bug has been marked as a duplicate of 21018 ***
--
tfrancuz at mp dot pl changed:
What|Removed |Added
--
--- Comment #9 from tfrancuz at mp dot pl 2010-04-14 20:45 ---
*** Bug 43746 has been marked as a duplicate of this bug. ***
--
tfrancuz at mp dot pl changed:
What|Removed |Added
-
--- Comment #8 from bernds at gcc dot gnu dot org 2010-04-14 20:42 ---
Subject: Bug 21803
Author: bernds
Date: Wed Apr 14 20:42:02 2010
New Revision: 158357
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158357
Log:
gcc/
PR target/21803
* ifcvt.c (cond_exec_proce
--- Comment #2 from tfrancuz at mp dot pl 2010-04-14 20:39 ---
(In reply to comment #1)
> What is your suggestion?
Because VTABLES are generated during compile time and they are const data there
is no need to copy them into SRAM. Appropriate addresses of virtual methods can
be read dire
--- Comment #7 from jason at gcc dot gnu dot org 2010-04-14 20:26 ---
Presumably TREE_USED isn't set on the global declaration because the call uses
the local one. And the local declaration might not be redundant if the
programmer is using it to suppress argument-dependent lookup.
--
--- Comment #9 from jason at gcc dot gnu dot org 2010-04-14 20:18 ---
Subject: Bug 36625
Author: jason
Date: Wed Apr 14 20:17:34 2010
New Revision: 158355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158355
Log:
PR c++/36625
* c-common.c (attribute_takes_identi
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-14
20:05 ---
Subject: Re: ld: Unsatisfied symbol "start" in file c_lto_20091216-1_0.o
> I wonder if using
>
> asm (".globl start");
> asm ("start: nop");
>
> Would work for everyone? I am going to try that on my ni
--- Comment #1 from eric dot weddington at atmel dot com 2010-04-14 19:52
---
What is your suggestion?
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
---
--- Comment #5 from sje at cup dot hp dot com 2010-04-14 19:34 ---
I wonder if using
asm (".globl start");
asm ("start: nop");
Would work for everyone? I am going to try that on my nightly HP-UX and Linux
runs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43283
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-14 19:19 ---
This is a bug in glibc, __i686 is in the implementation namespace. And this
change was done on purpose to correct how GCC was not really configuring for a
i686 compiler.
--
pinskia at gcc dot gnu dot org changed
--- Comment #2 from jue at jue dot li 2010-04-14 19:15 ---
Actually I want a i686 configured gcc and gcc should be able to compile glibc
without setting -march to something different, that's how it works with any
older gcc 4.x.
As you can see in my supplied examples, gcc 4.5.0 sets -mar
--- Comment #9 from sezeroz at gmail dot com 2010-04-14 18:59 ---
(In reply to comment #8)
> +/* { dg-require-effective-target lp64 } */
Adding llp64 to that would be helpful, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-14
18:53 ---
Subject: Re: ld: Unsatisfied symbol "start" in file c_lto_20091216-1_0.o
> Dave, do you have a patch for this? I see it on ia64 hpux too.
Something like this works for hppa*-&-hpux* using gas:
Index: gc
--- Comment #8 from mikpe at it dot uu dot se 2010-04-14 18:23 ---
(In reply to comment #5)
> The patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00466.html
The test case in this patch breaks on 32-bit x86 because gcc complains that the
ms_abi attribute is only available in 64-
--- Comment #10 from steven at gcc dot gnu dot org 2010-04-14 18:04 ---
Yes, release checking is OK. And I don't think it is OK to have 90% of the
compile time spent on calculating debugging info, no matter how crazy the test
case may be. We should try to speed this up. But there are oth
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-14 17:57 ---
IIRC you get one with svn checkin rights
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43719
--- Comment #1 from pinskia at gmail dot com 2010-04-14 17:56 ---
Subject: Re: New: -march unconditionally added to COLLECT_GCC_OPTIONS
Sent from my iPhone
On Apr 14, 2010, at 1:56 AM, "jue at jue dot li" wrote:
> As of 4.5.0 -march is always added to COLLECT_GCC_OPTIONS if gcc i
Sent from my iPhone
On Apr 14, 2010, at 1:56 AM, "jue at jue dot li" > wrote:
As of 4.5.0 -march is always added to COLLECT_GCC_OPTIONS if gcc is
not called
with that option.
Well this was on purpose as before configuring for i686-linux-gnu was
really for i386 arch. Now it is correctly
--- Comment #9 from iains at gcc dot gnu dot org 2010-04-14 17:44 ---
(In reply to comment #8)
> Are you speaking of gcc/testsuite/gcc.dg/pr43058.c?
yes - as per Comments #4 and # 5, you will find that this is less troublesome
m64
(on the same machine 10x faster at m64 => I get around
--- Comment #50 from iains at gcc dot gnu dot org 2010-04-14 17:38 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed work-around for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-14 17:37 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed resolution to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #16 from iains at gcc dot gnu dot org 2010-04-14 17:37 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed resolution to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-14 17:34 ---
Iain,
Are you speaking of gcc/testsuite/gcc.dg/pr43058.c?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
--- Comment #3 from sje at cup dot hp dot com 2010-04-14 16:59 ---
Dave, do you have a patch for this? I see it on ia64 hpux too.
--
sje at cup dot hp dot com changed:
What|Removed |Added
---
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-14 16:58 ---
(In reply to comment #5)
> The testcase is chosen to be quite large (and is expensive mainly for i?86
> -m32, not -m64), if it is much smaller than even unfixed gcc wouldn't start
> eating all available RAM. For me in
--- Comment #6 from iains at gcc dot gnu dot org 2010-04-14 16:56 ---
(In reply to comment #1)
> With checking enabled, anything can happen. Try without.
Hmm, OK I guess this is bogus - from the other comments - so I'll mark the bug
as resolved ...
.. .. but FWIW:
I rebuilt with rele
--- Comment #2 from sje at cup dot hp dot com 2010-04-14 16:49 ---
Fixed by adding -static to link like other tests already do.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--
--- Comment #1 from sje at gcc dot gnu dot org 2010-04-14 16:47 ---
Subject: Bug 43739
Author: sje
Date: Wed Apr 14 16:47:15 2010
New Revision: 158351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158351
Log:
2010-04-14 Steve Ellcey
PR testsuite/43739
* gcc.
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-14 16:11 ---
The testcase is chosen to be quite large (and is expensive mainly for i?86
-m32, not -m64), if it is much smaller than even unfixed gcc wouldn't start
eating all available RAM. For me in high load it sometimes times o
--- Comment #5 from manu at gcc dot gnu dot org 2010-04-14 16:10 ---
FIXED in gcc 4.6.
Thanks Simon for the original idea.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-04-14 16:08 ---
Subject: Bug 42966
Author: manu
Date: Wed Apr 14 16:08:23 2010
New Revision: 158349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158349
Log:
2010-04-14 Manuel López-Ibáñez
PR 42966
* di
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-14 16:06 ---
Created an attachment (id=20378)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20378&action=view)
gcc46-pr43728.patch
Updated patch. There are still cases I'm unsure about. E.g. for:
static void g ();
void f
-v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../src-trunk/configure --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld -with-plugin-ld=ld.gold --enable-gold
--with-fpmath=sse
Thread model: posix
gcc version 4.6.0 20100414
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-14 15:48 ---
(In reply to comment #2)
> FWIW, there are so many "var-tracking is slow" bugs now, that one might
> reasonably question the QoI of it.
> See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
There has been muc
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-14 15:44 ---
FWIW, there are so many "var-tracking is slow" bugs now, that one might
reasonably question the QoI of it.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-14 15:41 ---
With checking enabled, anything can happen. Try without.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
Is this a reasonable expectation?
Execution times (seconds)
garbage collection: 0.16 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall
0 kB ( 0%) ggc
callgraph construction: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
995 kB ( 3%) ggc
callgraph optimization: 0.01 ( 0%) usr
The main GCC manual should mention the existence of the other manuals whenever
other parts of the compiler are mentioned.
In addition, the other manuals should be mentioned in the introduction:
http://gcc.gnu.org/onlinedocs/gcc/index.html#Top
The current "See Introduction" directs to the interna
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-14 15:03 ---
see http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00563.html and its follow up.
section anchors are assumed for powerpc-*-* in target supports - so the
"require-effective-target" won't clear the problem unless we exclu
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-14 15:08 ---
see :
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00535.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
--- Comment #7 from meissner at gcc dot gnu dot org 2010-04-14 15:03
---
Fixed with subversion id 158346.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from meissner at gcc dot gnu dot org 2010-04-14 15:02
---
Subject: Bug 42694
Author: meissner
Date: Wed Apr 14 15:01:40 2010
New Revision: 158346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158346
Log:
PR 42694: Optimize pow (x, 0.25), pow (x, 0.75), pow (x, 1
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-14 14:53 ---
Fixed for 4.6. I propose to WONTFIX this for 4.5.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-14 14:51 ---
Subject: Bug 42963
Author: matz
Date: Wed Apr 14 14:50:33 2010
New Revision: 158345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158345
Log:
PR tree-optimization/42963
* tree-cfg.c (touched_sw
--- Comment #5 from zsojka at seznam dot cz 2010-04-14 14:33 ---
$ make check RUNTESTFLAGS="--target_board=unix/-ftree-ter"
$ cat gcc/testsuite/*/*.log | grep '^FAIL:' | grep 'exec'
FAIL: gfortran.dg/append_1.f90 -O0 execution test
FAIL: gfortran.dg/backspace_1.f -O0 execution test
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.1 |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-14 14:08 ---
P1 for the regression on the release branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fabien dot chene at gmail dot com 2010-04-14 13:34
---
Subject: Re: uninitialized const member incorrectly accepted,
using an array
2010/4/11 rguenth at gcc dot gnu dot org :
> Use a bugzilla account with your @gcc.gnu.org address.
Am I supposed to have o
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-14 13:26 ---
After revision 158291 I get
[macbook] f90/bug% time gfc pr19925_1.f90
pr19925_1.f90:2.27:
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
1
Error: The number of elements in the array cons
--- Comment #6 from mikpe at it dot uu dot se 2010-04-14 13:20 ---
The patch causing this regression was backported to 4.4 in r157850, causing
current 4.4 to also regress.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
--- Comment #20 from dominiq at lps dot ens dot fr 2010-04-14 13:06 ---
I have been able to get the following values before the crash:
DEBav =
0.59252398402327489 1.58848116996742547E-002 2.31157896165751706E-002
8.33002598145726886E-002 9.03564427292446321E-002 -596152.333
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43739
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-14 10:25 ---
> Can you track where the NaN comes from and if it is indeed unexpected
> even with -ffast-math -ffinite-math-only?
First '-ffast-math' implies '-funsafe-math-optimizations -ffinite-math-only'.
To reach
> This is
--- Comment #15 from lopezibanez at gmail dot com 2010-04-14 10:09 ---
Subject: Re: repeated diagnostic when maximum template depth is
exceeded
When that happens? I am sorry but your answer does not help me to find
how to fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #18 from mkuvyrkov at gcc dot gnu dot org 2010-04-14 10:02
---
Subject: Re: [4.6 Regression] Revision 158105
miscompiles doduc.f90
On 4/14/10 1:55 PM, dominiq at lps dot ens dot fr wrote:
> --- Comment #17 from dominiq at lps dot ens dot fr 2010-04-14 09:55
> --
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-14 09:55 ---
> Well, it indeed looks invalid if there is NaNs involved and you use
> -ffinite-math-only.
The NaN appears in the miscompiled executable. Note that I am not the author of
the doduc test, but it has been compiled by
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-14 09:49 ---
(In reply to comment #2)
> Does FSF gcc-4.2 exhibit the problem? Maybe the OSX compiler has local changes
> in the specs processing.
OK, it's not a regression - it never worked ;)
FSF 4.2 does not have the dsymutil s
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-14 09:44
---
Well, it indeed looks invalid if there is NaNs involved and you use
-ffinite-math-only.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-14 09:24 ---
Does FSF gcc-4.2 exhibit the problem? Maybe the OSX compiler has local changes
in the specs processing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-14 09:06 ---
I'll take this for now - since I've got a patch in progress that ought to fix
it.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
---
1 - 100 of 102 matches
Mail list logo
