--- Comment #3 from mtrudel at gmx dot ch 2007-07-04 06:59 ---
This is an old discussion and comes up in the mailinglist regularly. The most
promising approach is to explicitly exclude parts of the class library. JNC
(http://jnc.mtsystems.ch/) supports excluding the GUI stuff (AWT/Swing)
--- Comment #19 from spop at gcc dot gnu dot org 2007-07-04 07:04 ---
Subject: Bug 32457
Author: spop
Date: Wed Jul 4 07:04:31 2007
New Revision: 126305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126305
Log:
PR middle-end/32457
* tree-data-ref.c (analyze_siv
--- Comment #20 from spop at gcc dot gnu dot org 2007-07-04 07:08 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-04 07:08 ---
Jerry, I think this is something for you.
y = -0.0 is printed as
0.E+00
instead of
-0.E+00
I think the problem is in io/write.c's output_float.
--
burnus at gcc dot gnu dot org changed:
--- Comment #17 from bonzini at gnu dot org 2007-07-04 07:11 ---
I'm working on this, but don't hold your breath (hence not assigning to
myself).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #5 from bonzini at gnu dot org 2007-07-04 07:12 ---
*** This bug has been marked as a duplicate of 32004 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from bonzini at gnu dot org 2007-07-04 07:12 ---
*** Bug 25216 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from bonzini at gnu dot org 2007-07-04 07:13 ---
PR25216 is a dup of PR32004.
--
bonzini at gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|252
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-04 07:19 ---
> Related to -fbounds-check, isn't it?
As my initial bug is fixed:
Warnung: Actual argument contains too few elements for dummy argument 'in'
(10/11) at (1)
and the missing parts are in PR30939, I dedicate it to the
--- Comment #10 from sebpop at gmail dot com 2007-07-04 07:21 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
> > I can submit a patch for merging that part of code in trunk if you need
> > this flag to test if you are in one or the other
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:25
---
Subject: Bug 31198
Author: fxcoudert
Date: Wed Jul 4 07:25:39 2007
New Revision: 126307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126307
Log:
PR fortran/31198
* trans-intrinsic.c (t
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:27
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Hello!
<...>/configure was invoked with:
<...>/configure --with-mpfr=/usr/local --enable-languages=c,c++,fortran
BOOT_CFLAGS="-O3 -march=nocona -msse3 -funroll-loops -ftree-vectorize
-ffast-math -g"
as suggested in gccinstall.info.
However, BOOT_CFLAGS were not passed to stage2 or stage3 compil
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:43
---
*** This bug has been marked as a duplicate of 29459 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:43
---
*** Bug 31688 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:44
---
(In reply to comment #2)
> *** Bug 31688 has been marked as a duplicate of this bug. ***
Code from PR31688:
MODULE test
IMPLICIT NONE
CONTAINS
SUBROUTINE overlap(s, lds, pab, force_a)
INTEGER, INTENT(IN)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:47
---
I think it's due to the fact that there is no simplification done for INDEX (in
simplify.c).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:49
---
IIRC, F95 requires not to print the minus sign but F2003 allows to do it (and
we should probably do it since we handle negative zeros well on most other
counts).
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-04 07:50
---
Updated partial patch:
Index: trans-array.c
===
--- trans-array.c (revision 126249)
+++ trans-array.c (working copy)
@@ -1695,6 +1695,7
--- Comment #1 from ubizjak at gmail dot com 2007-07-04 08:02 ---
I misread the documentation, BOOT_CFLAGS should be added to make.
However, having something like --default-boot-cflags=... would be a nice
addition to configure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
--- Comment #19 from bonzini at gnu dot org 2007-07-04 08:16 ---
Created an attachment (id=13843)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13843&action=view)
patch under testing
QED (Quite Easily Done :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #2 from spop at gcc dot gnu dot org 2007-07-04 08:12 ---
Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile
Ok, here is the mini patch that captures BOOT_CFLAGS from configure line
and pass it to the makefile machinery. Not tested yet, it's just an idea.
--- Comment #12 from irar at il dot ibm dot com 2007-07-04 08:34 ---
(In reply to comment #10)
> I have committed the attached patch to trunk.
> Sebastian
Thanks a lot!
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
--- Comment #15 from pault at gcc dot gnu dot org 2007-07-04 08:50 ---
> > >
> > is this still correct ?
>
> Adding Paul, so he can see this question and hopefully answer affirmatively.
>
The patch was posted to the list 0615; whilst functional, in that it fixed the
bugs, bootstrapp
--- Comment #5 from eres at il dot ibm dot com 2007-07-04 08:57 ---
You can also try to tune --param max-variable-expansions-in-unroller. The
default is to add one expansion (which seems to be the most helpful due to the
fact that adding more expansions can increase register pressure).
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-04 08:58 ---
(In reply to comment #4)
> > Adding Paul as CC.
This is indeed my doing - sorry. The cause is
PR fortran/31494
* match.c (gfc_match_call): If a host associated symbol is not
a subroutine, buil
--- Comment #16 from jv244 at cam dot ac dot uk 2007-07-04 09:09 ---
(In reply to comment #15)
> The patch was also judged to be
> untimely
> relative to the 4.3 release schedule so I agreed to hold back.
since it is a regression wrt 4.1 , a fix could go in at 'anytime' ? If it is
very
--- Comment #17 from jv244 at cam dot ac dot uk 2007-07-04 09:09 ---
> since it is a regression wrt 4.1 , a fix could go in at 'anytime' ? If it is
> very invasive, one should fix 4.2 before 4.2.1 though...
one should *not* fix 4.2 of course
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #6 from jv244 at cam dot ac dot uk 2007-07-04 09:23 ---
(In reply to comment #5)
> You can also try to tune --param max-variable-expansions-in-unroller. The
> default is to add one expansion (which seems to be the most helpful due to the
> fact that adding more expansions can
--- Comment #2 from pluto at agmk dot net 2007-07-04 09:25 ---
4.3.0 20070703 fails to.
--
pluto at agmk dot net changed:
What|Removed |Added
Known to fail|4.1.2 4.2
--- Comment #18 from pault at gcc dot gnu dot org 2007-07-04 09:26 ---
(In reply to comment #17)
> > since it is a regression wrt 4.1 , a fix could go in at 'anytime' ? If it is
> > very invasive, one should fix 4.2 before 4.2.1 though...
>
> one should *not* fix 4.2 of course
>
All
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-04 09:49 ---
Sorry, I can't see what is wrong. There is no effective difference in assembly
with/without -ftree-vrp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 ---
(In reply to comment #18)
> I'll spend this afternoon on
> it, rather than going on the conference excursion.
depending on location/weather, I'd go for the conference excursion ;-)
--
http://gcc.gnu.org/bugzilla/s
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-04 10:16
---
This is SCEV. From
:;
i_7 = ASSERT_EXPR 4>;
i.10_10 = (unsigned int) i_7;
D.2489_11 = i.10_10 - 7;
if (D.2489_11 <= 2) goto ; else goto ;
we have
Found new range for i.10_10: [5, 12]
Visiting stateme
--- Comment #1 from clemens dot koller at anagramm dot de 2007-07-04 10:34
---
Cannot reproduce this problem on PPC32 with gcc-4.2.0. The result is
with all -Ox correct: 234500
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
When building for a ColdFire V2 CPU, GCC will prefer using shift-and-add over
multiply, even if multiply would generate code that is smaller and as fast, if
not faster, on the target CPU in question. This happens because the multiply
cost is based on ColdFire version rather than the capabilities. B
--- Comment #20 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-07-04 10:51 ---
Subject: Re: [4.2/4.3 regression] TRANSPOSE/RESHAPE and
strings
jv244 at cam dot ac dot uk wrote:
> --- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 ---
> (In rep
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-04 11:14 ---
The vectorizer reports:
pr25621.f90:7: note: reduction used in loop.
pr25621.f90:7: note: Unknown def-use cycle pattern.
because of the seemingly redundant assignment:
c__lsm.63_30 = D.1361_38;
which uses the reductio
--- Comment #30 from dnovillo at google dot com 2007-07-04 11:22 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing
causing removal of live code
On 7/3/07 11:28 PM, mmitchel at gcc dot gnu dot org wrote:
> --- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:
--- Comment #8 from eres at il dot ibm dot com 2007-07-04 11:24 ---
I think c__lsm.63_30 is created during the store motion optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
--- Comment #21 from pault at gcc dot gnu dot org 2007-07-04 11:32 ---
> Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more
> important than anything else :-)
>
There is also the question of what I am expected to do over the weekend after
three weeks away from home
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-04 11:45 ---
Subject: Bug 32482
Author: rguenth
Date: Wed Jul 4 11:44:58 2007
New Revision: 126314
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126314
Log:
2007-07-04 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-04 11:46 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2007-07-04 11:57 ---
Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel
quadcore Core2):
/usr/src/gcc-4.2/obj/gcc/gfortran -B /usr/src/gcc-4.2/obj/gcc/ -L
/usr/src/gcc-4.2/obj/x86_64-unknown-linux-gnu/32/libgfor
--- Comment #13 from ed at fxq dot nl 2007-07-04 12:06 ---
Hello Richard,
I can confirm that the patch fixes this regression. I just installed a patch
compiler on my FreeBSD box and I get a proper binary, even when I build it with
'-O2 -ftree-vrp' (just to be sure). Thanks!
Any chance
--- Comment #3 from ubizjak at gmail dot com 2007-07-04 12:29 ---
(In reply to comment #2)
> Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel
> quadcore Core2):
On core2 the bug doesn't trigger, but it shows on FC4 with:
vendor_id : GenuineIntel
cpu
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-04 12:31 ---
This doesn't ICE any longer on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
--- Comment #4 from ubizjak at gmail dot com 2007-07-04 12:32 ---
(In reply to comment #1)
> gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 rnflow.f90
>
> time ./a.out
> user0m37.982s
> gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 -ftree-vectorize
> rnfl
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-07-04 12:38
---
Subject: Bug 32500
Author: rguenth
Date: Wed Jul 4 12:38:23 2007
New Revision: 126315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126315
Log:
2007-07-04 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-04 12:40
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-07-04 12:39
---
Subject: Bug 32500
Author: rguenth
Date: Wed Jul 4 12:39:42 2007
New Revision: 126316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126316
Log:
2007-07-04 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #6 from manu at gcc dot gnu dot org 2007-07-04 13:08 ---
(In reply to comment #4)
>
> No idea how to untangle -pedantic from -Wtabs or -Wampersand if
> -pedantic-errors has been given, but -Werror has not.
>
What gfortran should do is that if pedantic enables Wtabs, then th
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-04 13:27 ---
Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in
that file, it will just work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from nickc at redhat dot com 2007-07-04 13:28 ---
Hi Rask,
Well the patch is definitely an improvement, so I have applied it. I will
try to find time to look at the regressions in the next week or two.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #7 from nickc at redhat dot com 2007-07-04 13:40 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Brooks,
> So, if I understand correctly: all of the options are listed somewhere, but we
> no longer provide any information about which of th
--- Comment #20 from bonzini at gnu dot org 2007-07-04 13:54 ---
The attached patch makes PR30311 resurface; this seems like a minor problem
because that code is dubious, and can be worked around by not doing the
transformation when the modes mismatch.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from spop at gcc dot gnu dot org 2007-07-04 13:42 ---
Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile
> Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in
> that file, it will just work.
Right, that's also what I saw, and
--- Comment #18 from rakdver at gcc dot gnu dot org 2007-07-04 13:32
---
(In reply to comment #0)
> The fix to PR31360 has caused significant code size regressions on ARM-EABI.
> An example of this is from zlib (adler32.c) and is attached, compile with -Os
> -mcpu=arm7tdmi -fno-short-e
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-04 14:05 ---
(In reply to comment #5)
OK, I now have it understood. The patch in the previous comment is the clue.
The patch for pr31494 was marking generic interfaces as subroutines, thereby
screwing up the mechanism for detect
--- Comment #9 from ubizjak at gmail dot com 2007-07-04 14:11 ---
(In reply to comment #1)
> Most likely -pg is changing the alignment of the stack which is incorrect. Oh
> -pg code is emitted by the target specific code so this is a target issue.
Hm, on x86_64 pg inserts:
fprintf (fi
--- Comment #10 from ubizjak at gmail dot com 2007-07-04 14:16 ---
(In reply to comment #9)
> So, it loads %r11 and calls mcount. The only thing that can go wrong is, that
> some value in %r11 gets rewritten.
Not even that because x86_64 is a NO_PROFILE_COUNTERS by default.
--
htt
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
--
Just as an update:
I have been working with richi (I code, he tests :P) diligently on a
patch for mainline, and have one that fixes the dealii regression (and
thus, should fix this as well).
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-07-04 14:16
---
Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --
Just as an update:
I have been working wi
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-04 14:24 ---
Here is a reduced testcase which has only one function in it:
int inb(int);
void is870(unsigned int wkport, unsigned char j)
{
unsigned int tmport;
unsigned char i;
for (i = 0; i < 16; i++)
{
tmport = wkport +
--- Comment #11 from ubizjak at gmail dot com 2007-07-04 14:26 ---
Hm...
--cut here--
// just a stupid testcase, don't bother with source
long long test(long long a, long long b)
{
return a / b;
}
--cut here--
cc1 -O2:
test:
.LFB2:
movq%rdi, %rdx
movq%rdi, %r
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-04 14:36
---
Please forget comment #3. The reason for the ICE is that substring
simplification was written without taking into account the possibility of
foo(14:) or foo(:14), ie one of the substring bounds being implicit. The
The following part of r126198 causes a 5% slowdown of tramp3d for the
non-leafify
tests (with leafify it makes it run faster):
2007-07-02 Richard Guenther <[EMAIL PROTECTED]>
* fold-const.c (fold_convert): Revert fix for PR15988.
* tree-inline.c (setup_one_parameter): Instead f
--- Comment #12 from jv244 at cam dot ac dot uk 2007-07-04 14:51 ---
(In reply to comment #11)
>
> Just a wild guess, could this depend on PR32450? Could you check if there is
> an
> access to stack after leave insn?
>
Hi Uros,
thanks for looking into this, but I'm afraid I don't reall
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-04 15:23
---
OK, you talked me into it. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2007-07-04 15:34 ---
Therefore, can we close the PR?
--
pcarlini at suse dot de changed:
What|Removed |Added
C
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-04 16:11 ---
This seems to be an aliasing problem. Somehow we do not prune SMTs enough
after
the patch. MPT grouping doesn't trigger in.
An example function to look at is (x86_64)
_ZN14MultiArgKernelI9MultiArg4I5FieldI22Unifor
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 ---
Created an attachment (id=13844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13844&action=view)
alias6 dump of the function without the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
--- Comment #4 from pcarlini at suse dot de 2007-07-04 16:16 ---
Feedback not forthcoming.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|WAIT
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-04 16:24 ---
I've compared the output of -fdump-tree-original for 4.2 and trunk, and
the only significant difference is
internal (j)
{
int4 k;
+ int4 i;
logical4 __result_internal;
That is, the implicitly typed 'i' in tr
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-04 16:25 ---
I thought I had confirmed this as a bug. Let's try again.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from kargl at gcc dot gnu dot org 2007-07-04 16:27 ---
Add wrong-code keyword.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Keywo
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 ---
Created an attachment (id=13845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13845&action=view)
alias6 dump of the function with the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-04 16:31 ---
So, the following patch brings performance back in-line:
Index: tree-inline.c
===
--- tree-inline.c (revision 126325)
+++ tree-inline.c (wo
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-04 16:35 ---
Created an attachment (id=13846)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13846&action=view)
gcc43-pr32337.patch
The problem seems to be caused by the addition of the
emitted_frame_related_regs
array, there
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-04 17:02
---
>Which is almost the best you can do :).
Well except to use store with update but that is an IV-OPTs issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
--- Comment #7 from patchapp at dberlin dot org 2007-07-04 17:15 ---
Subject: Bug number PR32526
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-07/msg00381.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18
---
Subject: Bug 31388
Author: mmitchel
Date: Wed Jul 4 17:18:22 2007
New Revision: 126329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126329
Log:
PR c++/31388
* cp-tree.h (ARITHMETIC_TYPE)
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18
---
Subject: Bug 31338
Author: mmitchel
Date: Wed Jul 4 17:18:22 2007
New Revision: 126329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126329
Log:
PR c++/31388
* cp-tree.h (ARITHMETIC_TYPE)
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-07-04 17:27
---
Fixed in 4.2.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #17 from ed at fxq dot nl 2007-07-04 17:35 ---
Sorry if I'm being a nitpick...
The committed testcase contains a small error; it has an off-by-one bug that
causes a small buffer overflow.
The line:
foo(numbers[i]);
should be replaced with:
foo(numbers[i - 1])
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-04 17:44 ---
This is my doing - that makes two this week. *groan*
The regression is caused by the patch for pr31204, which goes back to April.
For some reason that I do not yet see, the variable i in the statement function
is bei
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-07-04 17:58
---
Yep this was fixed by Pointer_plus.
The load of hmm->tsc is no longer in the inner most loop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
> cat ../gcc/LAST_UPDATED
Wed Jul 4 19:21:37 CEST 2007
Wed Jul 4 17:21:37 UTC 2007 (revision 126328)
rm -f stage_current
make[3]: Leaving directory `/data/vondele/gcc_trunk/obj'
Comparing stages 2 and 3
tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbeginS.o' for
reading: No
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-04 18:00 ---
could be due to an interupted & restarted build. I'm trying again with a clean
build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-04 18:10 ---
> This a regression with respect to 4.2.
I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I
therefore changed the summary from "4.2 regression" to "4.3 regression".
--
burnus at gcc dot gnu
We probably need:
-fcheck-*
with
all
bounds
pointers
recursive
The recursive test is simple. C example:
bla(...)
{
static recursive = 0;
if(recursive)
exit_with_error
recursive = 1
...
recursive = 0; // Last statement
}
--
Summary: Run-time check for recursive functions
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-04 18:15 ---
> A more general case as described in PR30939?
Well, my example in PR30939 is actually fixed by PR30940, however, as NAG f95
proofs, one can test this at run time. I thus changed the purpose of that bug.
This PR is
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-04 18:29 ---
Clean up from my Bind(C) notes: The following should give an error such as:
Error: 'fptr' argument of 'c_f_procpointer' intrinsic at (1) must be a
PROCEDURE POINTER
use iso_c_binding
type(c_funptr) :: cfunptr
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-04 18:34 ---
a clean bootstrap passes now
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
St
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-04 18:48 ---
Related:
print *, c_loc(4)
end
gives an ICE. Expected:
Error: .f90, line 5: The argument to C_LOC must be a pointer or target
additionally with -std=f2003:
Error: .f90, line 5: Derived type C_PTR in io-l
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-04 18:51 ---
just checked that current trunk (Wed Jul 4 17:21:37 UTC 2007 (revision
126328)) still exhibits the same problem. I don't see the same problem on an
opteron, only on a core2 (both using -march=native), so it could be so
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #14 from jv244 at cam dot ac dot uk 2007-07-04 19:02 ---
Created an attachment (id=13847)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13847&action=view)
bad assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
1 - 100 of 133 matches
Mail list logo
