--- Comment #48 from rakdver at gcc dot gnu dot org 2008-01-12 03:59
---
(In reply to comment #47)
> Most of the PRE/FRE memory is spent in copied VOPs VECs. Unfortunately we
> cannot move them to heap memory easily as the get shared in the PRE tables...
> I tried to be explicit in man
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 03:27 ---
I think this is really just PR 10179 which was fixed for 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34747
__attribute__((aligned(x))) is not derivable and etc. Here is the tests which
discovering the bugs:
///
#include
#ifdef __GNUC__
#define DECLARE_ALIGN(x) __attribute__((aligned(x)))
#elif defined(_MSC_VER)
#define DECLAR
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2008-01-12 00:30
---
> After playing with dbgcounts to see what happens, I indeed found the same as
> what Eric notes in comment #27. The proposed fix makes perfect sense.
Thanks. Assigning to self.
--
ebotcazou at gcc dot gnu
--- Comment #30 from steven at gcc dot gnu dot org 2008-01-12 00:25 ---
After playing with dbgcounts to see what happens, I indeed found the same as
what Eric notes in comment #27. The proposed fix makes perfect sense.
I won't be fixing this, I think Eric has already proposed the corre
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-01-12 00:24
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #14 from sebpop at gmail dot com 2008-01-12 00:11 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00518.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #5 from hutchinsonandy at aim dot com 2008-01-11 23:40 ---
An instant work around for Tiny Targets is to optimise at higher level (-Os)
This will most likely remove need for frame pointer and skirt around the bug.
Though it will still happen if there are more auto variables
--- Comment #4 from hutchinsonandy at aim dot com 2008-01-11 23:32 ---
Created an attachment (id=14928)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14928&action=view)
Fix expander patch
Prior analysis is correct. Typo resulted in QI addition to HI mode frame
pointer, when Tiny s
--- Comment #6 from dominiq at lps dot ens dot fr 2008-01-11 23:21 ---
With the patch there is a regression for the following tests:
[ibook-dhum] f90/bug% gfc
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_initializer_1.f90
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_initia
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #7 from stsp at users dot sourceforge dot net 2008-01-11 22:02
---
Thank you for the prompt reply!
I also think simply changing to the previous
section is the good fix because the main problem,
as I see it, is that the -g3 currently has the
different behaveour than the othe
--- Comment #12 from tbm at cyrius dot com 2008-01-11 22:01 ---
(In reply to comment #11)
> Created an attachment (id=14907)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14907&action=view) [edit]
> Lightly tested fix.
>
> I'll give it a whirl on IA-64 but it would be nice to test
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-11 22:01 ---
(In reply to comment #4)
Will 2.5s do you on amd64/Cygwin_nt?
Index: gcc/fortran/array.c
===
*** gcc/fortran/array.c (revision 131469)
--- gcc/fortran/ar
--- Comment #12 from wilson at gcc dot gnu dot org 2008-01-11 21:52 ---
Fixed on mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #11 from wilson at gcc dot gnu dot org 2008-01-11 21:50 ---
Mine, as I wrote a patch for it.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from wilson at gcc dot gnu dot org 2008-01-11 21:42 ---
Subject: Bug 26015
Author: wilson
Date: Fri Jan 11 21:42:03 2008
New Revision: 131477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131477
Log:
PR target/26015
* config/vax/elf.h (FRAME_POINTER_CFA_OFFSET):
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-11
21:29 ---
Subject: Re: [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit
2.6.20 kernel
Eric,
> More precisely the QTY is changed after the reg has been entered with a hash.
> This is expected, but the
Fallout from the patch for PR 34670:
http://gcc.gnu.org/ml/fortran/2008-01/msg00146.html
--
Summary: [4.3 Regression] wrong formats in libgfortran's
runtime_error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity:
--- Comment #3 from wilson at gcc dot gnu dot org 2008-01-11 21:23 ---
The ia64 code to insert stop bits has a built-in assumption that if we see a
register set twice in the same instruction, then we goofed, and must ICE.
The testcase has an extended asm with 3 outputs and 4 inputs. No
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-01-11 21:23
---
I do think this is a bug. It's certainly not going to meet user expectations.
I think this is another case of a GCC extension that could have been
better-designed. If we were starting from scratch, I think sayi
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:20
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:18
---
Subject: Bug 34722
Author: jvdelisle
Date: Fri Jan 11 21:18:10 2008
New Revision: 131476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131476
Log:
2008-01-11 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:16
---
Subject: Bug 34722
Author: jvdelisle
Date: Fri Jan 11 21:15:41 2008
New Revision: 131475
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131475
Log:
2008-01-11 Jerry DeLisle <[EMAIL PROTECTED]>
Jerry DeLisle noted in
http://gcc.gnu.org/ml/fortran/2008-01/msg00142.html
that it might be good to collect the bounds-checking code
for intrinsics into a single function.
--
Summary: collect array bounds checking
Product: gcc
Version: 4.3.0
Status:
Memory leak with empty Fortran programs: latest trunk
Given:
program gamsanal
end
$ valgrind --leak-check=full f951 pr34722.f90
==20839== 1,408 bytes in 20 blocks are definitely lost in loss record 2 of 6
==20839==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==20839==by 0xB1B567: xmal
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-11 20:21 ---
Subject: Bug 34670
Author: tkoenig
Date: Fri Jan 11 20:21:05 2008
New Revision: 131473
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131473
Log:
2008-01-11 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-11 20:14
---
Actually I don't believe it is not a bug.
The properly functional code cannot be
miscompiled that easily only because of
the different -g option.
Adding Mark to CC for the final judgement
on this. :)
--
s
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2008-01-11 19:47
---
Fixed on the mainline. I'm not sure we want to put this on the other branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2008-01-11 19:45
---
Subject: Bug 31309
Author: ebotcazou
Date: Fri Jan 11 19:44:40 2008
New Revision: 131472
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131472
Log:
PR middle-end/31309
* expr.c (copy_blkm
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-11 19:12 ---
(In reply to comment #3)
Breaking up the expression for h1, thusly:
hh = (/(exp(-2*pi*(0,1)*mod(k*L,N)/N)*h2(L),L=0,N-1)/)
h1 = (/(sum(hh),k=0,N-1)/)
cures the problem.
Paul
--
http://gcc.gnu.
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-11 18:27 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-11 18:26 ---
Subject: Bug 34537
Author: pault
Date: Fri Jan 11 18:25:29 2008
New Revision: 131470
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131470
Log:
2008-01-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09
---
Created an attachment (id=14927)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14927&action=view)
Lightly tested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09
---
> Obviously, the problem is that the hash of reg 66 is changed after a hash
> table element is created for it in the bucket for the original hash. I have
> no idea yet whether this is expected, or if not, what i
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-01-11 18:05 ---
Paolo, as a quick aside, you might find it useful to look at the concept GCC
library sources for stuff like this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 16:39 ---
We even mark all pointed-to vars of value-escaping pointers as call-clobbered.
So I believe NMTs itself need never be call-clobbered. But there's also
hints that we cover bugs somewhere:
FIXME: This is no
--- Comment #12 from sebor at roguewave dot com 2008-01-11 15:59 ---
(In reply to comment #11)
[...]
> So while I agree that "NUL thousands_sep means no grouping" to stdio and to
> iostreams in C++,
I should clarify that in C++ it means that only if the NUL comes from libc
(e.g.,
via lo
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-11 15:57 ---
It's doing the correct thing. We have
p_1, name memory tag: NMT.14, is dereferenced, points-to vars: { SFT.3 SFT.7 }
(SFT.3 is x.x, SFT.7 is z.x)
Now, NMT.14 is marked call clobbered:
NMT.14, UID D.1582, struct
--- Comment #11 from sebor at roguewave dot com 2008-01-11 15:56 ---
I think the disconnect might be in how each of us is looking at the LC_NUMERIC
data. To me, it's just a bunch of values that are independent of one another.
You, OTOH, seem to view it more as a set of rules described by
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-11 15:39
---
The problem here is really how we handle extern inline functions redefining
non-extern inline functions.
What forntend does is to handle all extern inline or extern functions of same
name in all units as single f
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-01-11 15:25 ---
I am testing the attached patch. It disables the transformation and produce:
in_cols.0 = (char *) in_cols;
D.1180 = in_cols.0 + 500;
perhaps more canonical way would be
in_cols.0 = in_cols + 500;
d.1180 = (
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-11 15:24 ---
Amusingly enough (since this is the second time this has happened today), this
problem occurs both with and without variadic templates. The following code is
ill-formed according to C++98, but GCC accepts it:
temp
--- Comment #12 from aldot at gcc dot gnu dot org 2008-01-11 15:21 ---
Honza, the IPA pass reordering also caused PR31529, perhaps they are related?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #14 from steven at gcc dot gnu dot org 2008-01-11 15:09 ---
Whee, thanks Kenny and Richi!!!
Zapp...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-11 14:56
---
Subject: Bug 30905
Author: rguenth
Date: Fri Jan 11 14:55:34 2008
New Revision: 131468
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131468
Log:
2008-01-11 Steven Bosscher <[EMAIL PROTECTED]>
P
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-11 14:51
---
4.0: 448376 kB
4.1: 424788 kB
4.2: 512644 kB
4.3: 249496 kB
I don't have a 64bit 3.4 compiler and 3.3 doesn't grasp the C++ used.
Nothing obvious from the 4.3 numbers, the CU looks simply large:
parser
The test stopped testing what it's supposed to test. The call to function
baz() should not be inlined. This patch to the test exposes the failure. The
operand scanner is adding non-clobbered symbols to the call site.
Details at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00477.html
--
As requested on the mailing list:
Document the kind of integer passed for string lengths
http://gcc.gnu.org/ml/fortran/2008-01/msg00134.html
| The character length variables you mention are always (for gfortran)
| 32-bit integer signed variables, so if you need to address them in
| gfortran, you
The following out-of-bounds problem (in the if clause) is not detected:
character, pointer :: ptr(:)
allocate(ptr(9))
ptr = transfer('Sample#0'//achar(0),ptr) ! Causes ICE
if (any (ptr .ne. ['S','a','m','p','l','e','#','0'])) call abort
end
NAG f95 finds:
Rank 1 of array operand has e
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-11 14:21 ---
Paul's patch (approved): http://gcc.gnu.org/ml/fortran/2008-01/msg00131.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-11 14:11 ---
This code is ill-formed, and should be rejected because "Args" cannot be
deduced from "typename Args::is_applied". Interestingly enough, this problem
actually has nothing to do with variadic templates: take away the
--- Comment #10 from T dot Mittelstaedt at cadenas dot de 2008-01-11 14:10
---
A colleague just told me, that aix only gives an application 256 MB memory
except
if you set a certain environment variable (don't know yet) or
specify something like -Wl,-bmaxdata:0x8000 to the linker.
W
--- Comment #11 from hubicka at ucw dot cz 2008-01-11 14:04 ---
Subject: Re: internal compiler error: in cgraph_estimate_size_after_inlining,
at ipa-inline.c:106
The bug re-appeared due to yet another reorganization of IPA pass queue.
The issues with function changing their types are q
--- Comment #9 from burnus at gcc dot gnu dot org 2008-01-11 14:02 ---
For the following ill-defined program, also a warning should be printed. It
comes from PR 34537 and had before an ICE. NAG f95 prints "Intrinsic TRANSFER
has partly undefined result".
program main
implicit none
c
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-11 14:01 ---
What about:
namespace A {
extern "C" int g (double);
}
namespace B {
extern "C" int g (int);
}
using namespace A;
using namespace B;
void f ()
{
g (1.0);
}
I don't believe this is valid, as extern "C" means the
For the following program, I expect an out-of-bounds error; NAG f95 shows at
run time:
Rank 1 of array operand has extent 7 instead of 8
character, pointer :: ptr(:)
allocate(ptr(8))
ptr = transfer('Sample'//achar(0),ptr)
end
--
Summary: -fbounds-check with TRANSFER misse
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-11 13:57 ---
Created an attachment (id=14926)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14926&action=view)
testcase
Adjusted to also build with 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|R
--- Comment #12 from stevenb dot gcc at gmail dot com 2008-01-11 13:48
---
Subject: Re: [4.3 Regression] Fails to cross-jump
Richi, could you commit it for me?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-11 13:41
---
The patch is ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #10 from aldot at gcc dot gnu dot org 2008-01-11 13:30 ---
Still fails for me on trunk (revision 131461):
gcc-4.3-HEAD -Os --combine -c -o pr28779.o pr28779a.c pr28779b.c
pr28779b.c: In function 'e1000_write_reg_io':
pr28779b.c:12: internal compiler error: in cgraph_estimate
--- Comment #47 from rguenth at gcc dot gnu dot org 2008-01-11 13:29
---
Most of the PRE/FRE memory is spent in copied VOPs VECs. Unfortunately we
cannot move them to heap memory easily as the get shared in the PRE tables...
I tried to be explicit in managing the memory, but it gets re
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-11 13:25 ---
Related:
void foo (int i, int j = 6);
void foo (int i = 4, int j);
int bar (void)
{
foo ();
}
is accepted (correctly), but:
extern "C" {
void foo (int i, int j = 6);
void foo (int i = 4, int j);
}
int bar (void)
{
--- Comment #8 from T dot Mittelstaedt at cadenas dot de 2008-01-11 13:19
---
Created an attachment (id=14925)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14925&action=view)
preprocessed source stripped of system includes via uninclude
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-11 13:15
---
stevens patch bootstrapped and regression tested on x86-86, ppc-32 and ia-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-11 13:09 ---
Created an attachment (id=14924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14924&action=view)
uninclude
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-11 13:09 ---
The preprocessed testcase is useless, nobody has ppc-aix5 available. Please
strip system includes with 'uninclude'.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-11 13:09
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ghazi at gcc dot gnu dot org wrote:
> --- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-11 03:57
>
--- Comment #9 from T dot Mittelstaedt at cadenas dot de 2008-01-11 12:55
---
(In reply to comment #7)
> I have just tried to compile after detarring with GNU tar 1.19, and it
> compiled
> succesfully! Therefore the problem was a depackaging bug in an older version
> of
> tar. I'll co
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Ever Confirmed|0 |1
Know
--- Comment #7 from echristo at apple dot com 2008-01-11 11:48 ---
Created an attachment (id=14923)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14923&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-11 11:48 ---
(In reply to comment #4)
> It's in the bug and I have assignment issues currently and he asked me to?
You mean Apple has issues, not you technically and legally IIRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #6 from ijeukens at yahoo dot com dot br 2008-01-11 11:43
---
Not a bug (wrong variable type (int instead of size_t) triggered strange
behavior.
--
ijeukens at yahoo dot com dot br changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-11 11:38 ---
Preprocessed source? The testcase listed here is not going to show the issue
on most targets anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-11 11:33 ---
No what happened with 4.0 is rather DOM would prop x+1 for each x.
Really this comes down to scheduling of instructions and moving them closer to
their usage.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from echristo at apple dot com 2008-01-11 11:26 ---
It's in the bug and I have assignment issues currently and he asked me to?
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2008-01-11 11:24 ---
So where is the "a testcase" that you found?
And why, pray tell, assign the bug to Richi instead of just trying to backport
it yourself? ;-)
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from echristo at apple dot com 2008-01-11 11:19 ---
Doesn't ice under 4.0 so it is a regression.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-11 11:18 ---
We should at least understand where all the memory is going.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-11 11:09 ---
Not a regression, so won't be fixed in 4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
Found a testcase that ice's the ppc-darwin backend at -O3 -ffast-math that is
fixed by the full backport of the patches in 28796. In particular, this part:
Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118001
Log:
2006-10
--- Comment #10 from pcarlini at suse dot de 2008-01-11 10:18 ---
(In reply to comment #9)
> I don't agree that localeconv()->grouping is garbage just because
> thousands_sep
> is NUL. I'm not aware of anything in C or POSIX that says that.
We are working on this assumption. You agreed
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-11 10:13 ---
I have had a brief attempt to resolve this one and have driven my head against
a brick wall!
Starting with this development of the original testcase:
! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3
! For 4.3 th
--- Comment #4 from T dot Mittelstaedt at cadenas dot de 2008-01-11 09:54
---
Sorry forgot to add contents of an earlier mail which I sent to gcc-help and
gcc-bugs mailing lists, that version 4.1.1 which I downloaded from ftp.hvcc.edu
(pware) and an earlier 4.1 version, which we built a
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-11 09:50 ---
You have not enough memory. 250MB is not unreasonable to compile this file.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 09:42 ---
Confirmed.
void foo(char *p);
void test1(char * p)
{
foo(p++);
foo(p++);
foo(p++);
foo(p++);
}
void test2(char * p)
{
foo(p); p++;
foo(p); p++;
foo(p); p++;
foo(p); p++;
}
The prob
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-11 09:35 ---
I see the same problem at any level of optimization I have tried on
i686-apple-darwin9 for the test case gcc.target/i386/asm-3.c:
[ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O0
/opt/gcc/_gcc_clean/gcc/testsuite/g
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 09:28 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-11 09:14 ---
Actually, I don't know if --combine is really that obscure. People seem to use
it with some success, see e.g. http://lwn.net/Articles/197097/. Also, others
seem to think IMA is importan enough to upgrade bugs to P1
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-11 09:12 ---
Honza, is this bug fixed by your commit of comment #8?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #8 from krebbel at gcc dot gnu dot org 2008-01-11 09:03 ---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00460.html
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from T dot Mittelstaedt at cadenas dot de 2008-01-11 08:59
---
Created an attachment (id=14922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14922&action=view)
assembly source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
--- Comment #1 from T dot Mittelstaedt at cadenas dot de 2008-01-11 08:58
---
Created an attachment (id=14921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14921&action=view)
gzipped preprocessed source (was too big otherwise)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-01-11 08:57
---
Recategorizing as per Ulrich's analysis.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
Hallo,
This happens when compiling file src/script/qscriptcontext_p.cpp in trolltech's
qt 4.3.0 sources.
gcc -c -mpowerpc -mminimal-toc -O2 -Wall -W -D_THREAD_SAFE -DQT_SHARED
-DQT_BUILD_SCRIPT_LIB -DQLALR_NO_QSCRIPTGRAMMAR_DEBUG_INFO
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-01-11 08:52
---
I am investigating.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #1 from wvangulik at xs4all dot nl 2008-01-11 08:17 ---
Created an attachment (id=14920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14920&action=view)
Test case showing the three cases
Compile using -fno-line.
For the AVR I used: avr-gcc -Wall -Os -fno-inline -mmcu=
Consider the following:
char *x;
volatile int y;
void foo(char *p)
{
y += *p;
}
void main(void)
{
char *p1 = x;
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
}
For the AVR target this
99 matches
Mail list logo
