Jeff Law writes:
Ian Lance Taylor wrote:
Adam Nemet ane...@caviumnetworks.com writes:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c
Ian Lance Taylor writes:
truncate has a machine independent meaning.
Yes, I guess with your definition below it does. It's interesting though that
Jim had said the opposite in the excerpts posted by Jeff:
And a later message from Jim:
Truncate converts a value from a larger to a smaller
It seems the bot or whatever that generates the weekly snapshots
has stopped working for the 4.3 branch. I would have expected a
new snapshot 2-3 days ago but found nothing on the mirrors.
(And there has been commits since the last snapshot.)
/Mikael
2009/6/16 Jeff Law l...@redhat.com:
Ian Lance Taylor wrote:
daniel tian daniel.xnt...@gmail.com writes:
There is a problem I encountered. I port gcc to 32bit RISC. The
LOAD/STORE only has 8bit displacement. If the immediate displacement
larger than 256, the displacement must be force into
On Wed, 17 Jun 2009, Mikael Pettersson wrote:
It seems the bot or whatever that generates the weekly snapshots
has stopped working for the 4.3 branch. I would have expected a
new snapshot 2-3 days ago but found nothing on the mirrors.
(And there has been commits since the last snapshot.)
If
Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted from file *.23.greg :
(insn 128 127 130 7 (set (mem/i:SI
On Tue, Jun 16, 2009 at 7:30 PM, Basile
STARYNKEVITCHbas...@starynkevitch.net wrote:
Diego Novillo wrote:
On Tue, Jun 16, 2009 at 13:10, Janis Johnsonjanis...@us.ibm.com wrote:
Basile, people are saying that MELT no longer belongs in a branch of
the GCC repository because now that plug-ins
Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of
individual snapshots or other individual jobs run from cron, you should
follow the gccadmin and overseers lists, where you would have seen the
message showing the breakage and the subsequent discussion
Richard Guenther wrote:
On Tue, Jun 16, 2009 at 7:30 PM, Basile
STARYNKEVITCHbas...@starynkevitch.net wrote:
Diego Novillo wrote:
On Tue, Jun 16, 2009 at 13:10, Janis Johnsonjanis...@us.ibm.com wrote:
Basile, people are saying that MELT no longer belongs in a branch of
the
daniel tian daniel.xnt...@gmail.com writes:
Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted from file
On Wed, 17 Jun 2009, Kai Henningsen wrote:
Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of individual
snapshots or other individual jobs run from cron, you should follow the
gccadmin and overseers lists, where you would have seen the message
Joseph S. Myers wrote:
On Wed, 17 Jun 2009, Kai Henningsen wrote:
Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of individual
snapshots or other individual jobs run from cron, you should follow the
gccadmin and overseers lists, where you would have
DJ Delorie d...@redhat.com writes:
genrecog uses strings to keep track of where it is, specifically,
digits and letters. I've got an insn that writes to more than 26
registers. Would switching to something bigger than [A-Z] be
difficult? Perhaps using Japanese letters instead of English?
Adam Nemet ane...@caviumnetworks.com writes:
Ian Lance Taylor writes:
truncate has a machine independent meaning.
Yes, I guess with your definition below it does. It's interesting though that
Jim had said the opposite in the excerpts posted by Jeff:
And a later message from Jim:
Tomasz Francuz tfran...@mp.pl writes:
Ok, I’ve studied a little bit gcc sources, I’ve found sections
responsible for generating different register loading instructions,
and indeed there is no information telling to the compiler how to load
data
From FLASH. This is easy to correct, I
Dave Korn dave.korn.cyg...@googlemail.com writes:
Joseph S. Myers wrote:
On Wed, 17 Jun 2009, Kai Henningsen wrote:
Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of
individual
snapshots or other individual jobs run from cron, you should follow
I have created a wiki page to act as a repository of GCC plugins:
http://gcc.gnu.org/wiki/plugins
The page is linked from the main wiki page as well. Feel free to add
new entries and other information that I was too lame to add.
Diego.
Ian Lance Taylor wrote:
Dave Korn dave.korn.cyg...@googlemail.com writes:
Joseph S. Myers wrote:
On Wed, 17 Jun 2009, Kai Henningsen wrote:
Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of
individual
snapshots or other individual jobs run from
On Wed, 17 Jun 2009, Ian Lance Taylor wrote:
While overseers sounds like it might be a cool list, in actual
practice most of the traffic consists of please change my e-mail
address.
And most of the gccadmin traffic is completely routine messages from cron
- things don't break that often, and
Adam Nemet wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
Adam Nemet ane...@caviumnetworks.com writes:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
*
Hello All
(In case you don't read gcc-patches@)
I just posted in http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01363.html
some thoughts experiments about gengtype in plugins.
I came to the following tentative conclusions.
All this makes me think that
A. we should generate appropriately a
On Wed, Jun 17, 2009 at 11:15, Basile
STARYNKEVITCHbas...@starynkevitch.net wrote:
All this makes me think that
A. we should generate appropriately a $gccplugins/gtyp-input-plugins.list
B. we should install gengtype as gcc-gengtype at some appropriate place
C. we should document that, and
Ian Lance Taylor writes:
I'm not entirely sure, but I don't think Jim said the opposite. He said
that the way truncate works is machine dependent. I said that the
output of truncate is machine independent. Since truncate is only
defined for fixed-point modes, I think both statements are
Adam Nemet ane...@caviumnetworks.com writes:
Ian Lance Taylor writes:
I'm not entirely sure, but I don't think Jim said the opposite. He said
that the way truncate works is machine dependent. I said that the
output of truncate is machine independent. Since truncate is only
defined for
ASSEZ D'INJUSTICES
Défendez-vous. Cessez d'être les coupables. Avec la Coordination Nationale Des
Indépendants - CNDI - sauvez les petites entreprises.
Elles sont le tissu économique de la France, de notre pays, de notre patrie.
Mobilisez-vous. Allez sur le site Internet :
http://www.cndi.fr/
I'd like to be able to specify registers that are safe across function calls
(without the need to save/restore) and I cannot figure out how to do this.
I know that I can set these particular registers to '0' in
CALL_USED_REGISTERS and then remove the call/restore in the
prologue/epilogue, but
Please ignore this previous message... I found the error in my machine
dependent code.
Dobes wrote:
I'd like to be able to specify registers that are safe across function
calls (without the need to save/restore) and I cannot figure out how to do
this. I know that I can set these particular
On Sun, Jun 14, 2009 at 11:17:32AM -0400, Daniel Jacobowitz wrote:
On Sat, Jun 13, 2009 at 10:08:39PM +0200, Jakub Jelinek wrote:
I really think we need to do (limited) -fvar-tracking even for -O0, it is
really bad that most arguments have wrong locations through the prologue,
while at -O1
That sounds like an awkward insn.
The opcode swaps two register banks. 32 SETs total.
It would be nice if genrecog at least checked for an out of range
letter.
Or used ch-'a' 32 tests, but would that work with EBCDIC build
machines?
DJ Delorie d...@redhat.com writes:
That sounds like an awkward insn.
The opcode swaps two register banks. 32 SETs total.
Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit
machine, using DImode will cut the number of operands in half.
Ian
The opcode swaps two register banks. 32 SETs total.
Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit
machine, using DImode will cut the number of operands in half.
They're DImode already, but I did figure out a workaround that reduces
it to 16 SETs, so I'm all set.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-06-17 06:58
---
Still missing are:
DREAL (GNU extension)
LSHIFT (GNU extension)
RSHIFT (GNU extension)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
Hi,
Please take a look at the testcase faadd.c:
--
int foo (int * p, int i)
{
return __sync_fetch_and_add(p, i);
}
int n = 1;
int main()
{
printf(%d %d\n, foo (n, n), n);
return 0;
}
--- Comment #1 from ubizjak at gmail dot com 2009-06-17 07:32 ---
Works for 4.4.1 and 4.5.0
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work|
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-17 08:04 ---
That's undefined behavior, there is no sequence point between the the
evaluation of foo (n, n) and evaluation of n passed as the next argument.
If foo (n, n) is evaluated first, you will see 1 2 printed, if n is
--- Comment #23 from irar at il dot ibm dot com 2009-06-17 08:22 ---
(In reply to comment #22)
My understanding is that ([istarget *-*-darwin*] [is-effective-target
lp64])
should return false for -m32 and true for -m64. At least it is how it works on
other tests I have looked at.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-17 08:29 ---
Could you specify which version of the source tree this was ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
I use:
GNU Fortran (GCC) 4.5.0 20090617 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
The following piece of code breaks f951 (hangs forever):
REAL, DIMENSION(720,360) :: ZLON_MASK
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,720) /) , DIM=2, NCOPIES=360 )
END
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-17 08:33 ---
The test case is also rejected without being inside a module:
contains
function f()
intrinsic :: sin
procedure(sin), pointer :: f
f = sin
end function f
end
However, if the 'contains' is removed, it
--- Comment #6 from rearnsha at arm dot com 2009-06-17 08:40 ---
Subject: Re: use stm and ldm to access consecutive
memory words
--- Comment #5 from ubizjak at gmail dot com 2009-06-16 18:16 ---
Registers also need to be consecutive, starting from certain register,
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-17 08:54 ---
The error also goes away if 'implicit none' is inserted.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2009-06-17 09:18 ---
See Comment #2!
I tried to enhance ix86_secondary_reload target macro to return XMM
intermediate reg with movdi_to_sse handler for DImode - DFmode moves. However,
handling of this macro has plenty of FIXMEs, and I was
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-06-17 09:19 ---
The new simplifier, probably.
Without checking, I'd think that it doesn't hang, but would complete after a
significant amount of time. My guess: the time is spent to traverse the list to
append new elements to the
/* When compiled with -g -O -mno-sched-prolog, the debug info location
lists for p1 and p2 do not cover the start of f. There are other
inaccuracies, but not covering the start of the function is specific
to -nno-sched-prolog. */
int f (int p1, int p2)
{
extern int bar (int);
int x,
--- Comment #1 from amodra at bigpond dot net dot au 2009-06-17 09:21
---
See http://sourceware.org/bugzilla/show_bug.cgi?id=10231
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
--- Comment #4 from janus at gcc dot gnu dot org 2009-06-17 09:26 ---
Mine. Here's a patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 148518)
+++ gcc/fortran/symbol.c(working copy)
--- Comment #7 from carrot at google dot com 2009-06-17 09:30 ---
My command line option is -O2 -Os -mthumb
The compiler didn't run into load_multiple_sequence and
store_multiple_sequence. The peephole rules specified it applies to TARGET_ARM
only. Is there any special reason we didn't
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-17 09:49 ---
(In reply to comment #7)
My command line option is -O2 -Os -mthumb
The compiler didn't run into load_multiple_sequence and
store_multiple_sequence. The peephole rules specified it applies to TARGET_ARM
only. Is
--- Comment #2 from hailijuan at gmail dot com 2009-06-17 10:07 ---
Subject: Re: __sync_fetch_and_add seems not working well for
-march=i686
Yes, I have seen the difference. Thanks muchly. I will close it.
2009/6/17 jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org:
--- Comment #2 from joseph at codesourcery dot com 2009-06-17 10:13 ---
Subject: Re: linux-eabi.h:79:36: error: identifier not
is a special operator name in C++
On Wed, 17 Jun 2009, ramana at gcc dot gnu dot org wrote:
Could you specify which version of the source tree this was ?
--- Comment #24 from dominiq at lps dot ens dot fr 2009-06-17 10:17 ---
(In reply to comment #23)
If I add to vect-42.c (with my patch) the line
/* { dg-final { scan-tree-dump-times bla bla bla 1 vect { target
vector_alignment_reachable } } } */
I get:
Running target unix
Using
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 10:26 ---
Subject: Bug 40460
Author: rguenth
Date: Wed Jun 17 10:26:24 2009
New Revision: 148593
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148593
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-17 10:27 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-06-17 10:29
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 10:29:22 2009
New Revision: 148597
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148597
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-06-17 10:34
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 10:33:31 2009
New Revision: 148601
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148601
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #25 from irar at il dot ibm dot com 2009-06-17 11:06 ---
(In reply to comment #24)
If I add to vect-42.c (with my patch) the line
/* { dg-final { scan-tree-dump-times bla bla bla 1 vect { target
vector_alignment_reachable } } } */
...
i.e., the test is done for -m32 (and
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu dot org|unassigned at gcc dot gnu
|
When compiling a C or C++ program with gcc 4.3 (and 4.4), there is no longer a
warning about no newline at end of file.
I work with people that use gcc 4.2, which emits the warning, and we use
-Werror, so this is a major hindrance for us.
I'm attaching a trivial C program:
$ gcc-4.2 -o newline
--- Comment #1 from rlerallut at free dot fr 2009-06-17 11:41 ---
Created an attachment (id=18011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18011action=view)
Trivial program that does *not* end with a newline
Make sure that your editor does not add silently a newline
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-17 11:47 ---
It is.
*** This bug has been marked as a duplicate of 22456 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-06-17 11:47
---
*** Bug 40469 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-17 11:55 ---
Subject: Bug 40460
Author: rguenth
Date: Wed Jun 17 11:54:55 2009
New Revision: 148602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148602
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #18 from rguenther at suse dot de 2009-06-17 11:57 ---
Subject: Re: [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c
ICEs on powerpc-apple-darwin9
On Wed, 17 Jun 2009, amylaar at gcc dot gnu dot org wrote:
--- Comment #17 from amylaar at gcc dot gnu dot org
--- Comment #26 from dominiq at lps dot ens dot fr 2009-06-17 11:58 ---
Created an attachment (id=18012)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18012action=view)
dump file with -fdump-tree-vect-details default (-m32) for revision 148502.
Summary:
[karma] f90/bug% grep
--- Comment #22 from manu at gcc dot gnu dot org 2009-06-17 12:00 ---
This bug is about not warning for an empty loop (the empty loop is removed and
there is no warning). Since we don't care (enough to find a fix) about this
case, this bug is considered INVALID.
--
manu at gcc dot
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 12:00 ---
Subject: Bug 40460
Author: rguenth
Date: Wed Jun 17 12:00:40 2009
New Revision: 148603
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148603
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from manu at gcc dot gnu dot org 2009-06-17 12:02 ---
No, it is not. There is no loop here, this is CCP assuming that res is 0
always.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 12:03:08 2009
New Revision: 148604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148604
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #27 from dominiq at lps dot ens dot fr 2009-06-17 12:03 ---
Created an attachment (id=18013)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18013action=view)
dump file with -fdump-tree-vect-details -m64 for revision 148502.
Summary:
[karma] f90/bug% grep peeling
--- Comment #3 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
... so this is actually a duplicate of bug 18501.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
*** Bug 40469 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:04
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:06
---
We are not going to fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 12:06 ---
*** This bug has been marked as a duplicate of 18501 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:06
---
*** Bug 30542 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from manu at gcc dot gnu dot org 2009-06-17 12:09 ---
(In reply to comment #28)
We are not going to fix this.
Why? There are many ways to alleviate this. Doing some warnings in the
front-ends, such LLVM does is one. Or propagate some uninitialized bit, that
can
--- Comment #28 from dominiq at lps dot ens dot fr 2009-06-17 12:12 ---
Does the following patch makes more sense for you:
--- ../_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-05
18:02:02.0 +0200
+++ gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-17 14:08:50.0
--- Comment #31 from manu at gcc dot gnu dot org 2009-06-17 12:17 ---
(In reply to comment #30)
(In reply to comment #28)
We are not going to fix this.
Why? There are many ways to alleviate this. Doing some warnings in the
front-ends, such LLVM does is one. Or propagate some
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 12:28 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 12:28:43 2009
New Revision: 148605
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148605
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-17 12:31 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 12:30:54 2009
New Revision: 148606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148606
Log:
2009-06-17 Richard Guenther rguent...@suse.de
PR
On Linux/ia64, revision 148518 gave:
FAIL: gcc.dg/vect/vect-nest-cycle-1.c scan-tree-dump-times vect OUTER LOOP
VECTORIZED 1
FAIL: gcc.dg/vect/vect-nest-cycle-2.c scan-tree-dump-times vect OUTER LOOP
VECTORIZED 1
Revision 148510 is OK.
--
Summary: [4.5 Regression]
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-06-17 12:34
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-06-17 12:35
---
WONTFIX for 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-17 12:37
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 12:37 ---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:38
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from irar at il dot ibm dot com 2009-06-17 12:40 ---
Oh, so the first dump you attached (in comment #11) was for -m32. Now it makes
sense.
I think, we have to distinguish between vect_no_align and the other cases. I
will prepare a patch tomorrow.
Thanks,
Ira
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:40
---
I have no plans for fixing the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
$ cat test.c
struct R
{
char c;
}
struct R
{
struct R r;
}
int main(void)
{
struct R r;
return 0;
}
$ gcc test.c
test.c:7: error: redefinition of struct R
test.c:11: error: two or more data types in declaration specifiers
test.c:11: error: two or more data
--- Comment #1 from irar at il dot ibm dot com 2009-06-17 12:46 ---
Could you please attach a vectorizer dump for one of them? I need to know what
prevented vectorization.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #30 from dominiq at lps dot ens dot fr 2009-06-17 12:48 ---
Oh, so the first dump you attached (in comment #11) was for -m32. Now it
makes sense.
Since I started to have some doubts about it, I redid it for both cases to be
sure.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-17 12:51 ---
C frontend issue.
The gimplfier is fed (*fp)(0) with fp of type void (*) (const int) but then,
after gimplifying foo we do patch fps type to void (*) (int):
Hardware watchpoint 4: *$2
Old value = (tree)
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-17 12:57 ---
Without checking, I'd think that it doesn't hang, but would complete after a
significant amount of time. My guess: the time is spent to traverse the list
to
append new elements to the constructor ...
You're
--- Comment #32 from rguenth at gcc dot gnu dot org 2009-06-17 12:59
---
We can only fix it with the chance of raising more spurious warnings. One
reason why we run the may be used uninitialized pass very late.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #7 from aldyh at gcc dot gnu dot org 2009-06-17 13:00 ---
Fix for func-ptr-conv-1.c failure.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01344.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-17 13:02 ---
Works for me.
gcc-4.2 --version
gcc-4.2 (GCC) 4.2.4 (Debian 4.2.4-6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-17 13:04 ---
Note that the latest release of g95 gives now:
E
S, S
E
S, S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
1 - 100 of 159 matches
Mail list logo
