Hello,
The following error is received on ppc64.
Thanks,
Revital
symtab.o -MT symtab.o -MMD -MP -MF .deps/symtab.Po
../../gcc/libcpp/symtab.c
/home/eres/mainline_lim/build/./prev-gcc/xgcc
-B/home/eres/mainline_lim/build/./prev-gcc/
Mark Shinwell wrote:
As you say, one unusual thing about this situation must be the fact
that the reload register is getting chosen by the code in
push_reload heralded by If this is an input reload and the operand
contains a register that dies in this insn and is used nowhere else,
see if it
Bernd Schmidt wrote:
My gut feeling is that this example will work as a consequence.
... note that I inserted some other insn which could conceivably use
R9 as an input reload, as the hard reg is dead. Where would we
invalidate previous information about R9? I assume it would be the loop
at
I can modify it to catch it pretty easily, just walk back a few vuses
if the current set of vuses is defined by something that does not
actually touch our offset.
This sounds like what I am trying to do in ccp...
I am not sure I understand. The new patch uses the infrastructure of
the
Mark Shinwell wrote:
This code is guarded by
/* I is nonneg if this reload used a register.
If rld[r].reg_rtx is 0, this is an optional reload
that we opted to ignore. */
if (i = 0 rld[r].reg_rtx != 0)
and in this [my original] case, i is negative (see my
Bernd Schmidt wrote:
It appears that spill_reg_index is only set up for registers that go
through the choose_reload_regs process, not for the ones selected during
find_reloads. That's probably a bad thing, as a reg_rtx chosen in
find_reloads could be used as a spill reg in a previous insn (as
Hi gcc group,
I added vector compare and mov insns in gcc for our architecture
(cross_gcc), but when I
use these insns in c, I have to use builtin functions instead of
generic vector compare.
for example:
typedef short int v2hi __attribute__ ((vector_size (4))); // vector of
two short
Could someone tell me how to do vector compare in generic way?
AFAICT every target which supports vector operations has it's own
list of built-in function for vector comparison. For example, Altivec
has vec_cmpgt and other built-ins for vector compare instructions.
(see altivec.h file for the
Mark Shinwell wrote:
and the code following in emit_reload_insns? Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.
So what do you think is the best approach to fix all of this? :-)
Sounds like you gave the answer yourself
[EMAIL PROTECTED] wrote:
Hello,
The following error is received on ppc64.
Thanks,
Revital
symtab.o -MT symtab.o -MMD -MP -MF .deps/symtab.Po
../../gcc/libcpp/symtab.c
/home/eres/mainline_lim/build/./prev-gcc/xgcc
-B/home/eres/mainline_lim/build/./prev-gcc/
Bernd Schmidt wrote:
Mark Shinwell wrote:
and the code following in emit_reload_insns? Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.
So what do you think is the best approach to fix all of this? :-)
Sounds like you gave
Tim Prince [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
../../gcc/libcpp/traditional.c: In function â_cpp_scan_out_logical_lineâ:
../../gcc/libcpp/traditional.c:349: error: âfmacro.argsâ may be used
uninitialized in this function
../../gcc/libcpp/traditional.c:349: error:
Aaron Gray writes:
There is something weird with the switch statement in cp/decl.c:7105.
GITWeb :-
http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=407e5db8d650f1d19c618c7b67566407c2d35fce;hb=master#l7105
Can someone verify this.
Take a close look in a text editor
On 6/5/07, Aaron Gray [EMAIL PROTECTED] wrote:
There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say about
the GCC's C parser, is this legal C ?
Yes this is legal C :).
Just for everyone else the code looks
Andrew Pinski writes:
On 6/5/07, Aaron Gray [EMAIL PROTECTED] wrote:
There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say about
the GCC's C parser, is this legal C ?
Yes this is legal C :).
Just
On 4th June 2007 at 07:24:37 Frank Eigler wrote:
First thing is to get past that autoconf error. Check your linker
script for the default entry point symbol's name, and give it to
libmudflap/configure.ac (then regenerate configure).
Next, overcome build problems (if any) to the extent that a
With apologies for being new:
In porting a hardware configuration from gcc-3.4.1 to gcc-4.2.0, I'm getting the
following error message:
In file included from /cygdrive/c/gcc-4.2.0/gcc/crtstuff.c:68:
/cygdrive/c/gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: Segmentation
fault.
Lines 52-54
Steve Kargl wrote:
Can someone explain why libjava *must* commit binary files to the
repository?
It is due to a couple of factors:
We are now using an java - class compiler (ecj) that is written in
java. The creates a bootstrap problem in that java files cannot be
compiled until the
On 6/5/07, Aaron Gray [EMAIL PROTECTED] wrote:
There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say
about
the GCC's C parser, is this legal C ?
Yes this is legal C :).
Just for everyone else the code looks
Steve Kargl writes:
Can someone explain why libjava *must* commit binary files to the
repository? A merge of trunk to the fortran-experiments branch
generated 70 conflicts that I need to resolve. This is a complete
waste of time that would have been spent towards cutting a diff
of the
Andrew Pinski [EMAIL PROTECTED] writes:
On 6/5/07, Aaron Gray [EMAIL PROTECTED] wrote:
There is something weird with the switch statement in cp/decl.c:7105.
I dont think it will effect the decl.c's logic, but what does it say about
the GCC's C parser, is this legal C ?
Yes this is legal
Ian Lance Taylor wrote:
And Simon already sent in a tested patch for a couple of days ago:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html
This patch is OK, thanks.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Tuesday 05 June 2007, Ying Yi wrote:
Hi gcc group,
I added vector compare and mov insns in gcc for our architecture
(cross_gcc), but when I
use these insns in c, I have to use builtin functions instead of
generic vector compare.
...
Could someone tell me how to do vector compare in
Fu, Chao-Ying wrote:
2. Joseph, at that point, would you please invest a a little
bit of time
(a couple of hours) to look at the branch, and provide some feedback?
Please provide comments to Chao-Ying, and also please let me know
whether you think the work is nearly ready for inclusion?
Hello,
This is the first time I'm posting so sorry if I have posted this in the
wrong forum...
I'm been developing an application on SUSE 9.3, gcc 3.3.5 and within my
makefile I have the following for the CPPFLAGS -g -O0 and the code
complied and linked fine.
I reached the end of the
On 6/5/07, Aaron Gray [EMAIL PROTECTED] wrote:
MS Visual Studio does not parse it. Are you sure its legal C ?
Yes I am. Try this:
int f(int a)
{
switch (a)
{
case 1:
{
int b = 2;
break;
case 2:
break;
}
}
}
This is valid C90 and C99, though invalid C++98.
If
On Jun 5, 2007, at 10:26 AM, ronnie_raj wrote:
This is the first time I'm posting so sorry if I have posted this in
the
wrong forum...
I'd recommend the boost users list, then gcc-help... 3.3.5 is kinda
old, I'd probably recommend upgrading to 4.1.x if you can, it may well
just work
On 6/5/07, Revital1 Eres [EMAIL PROTECTED] wrote:
I can modify it to catch it pretty easily, just walk back a few vuses
if the current set of vuses is defined by something that does not
actually touch our offset.
This sounds like what I am trying to do in ccp...
I am not sure I
On Tue, 2007-06-05 at 11:49 -0400, [EMAIL PROTECTED] wrote:
With apologies for being new:
In porting a hardware configuration from gcc-3.4.1 to gcc-4.2.0, I'm getting
the
following error message:
In file included from /cygdrive/c/gcc-4.2.0/gcc/crtstuff.c:68:
I'm getting the following ICE with gcc 4.3 20070604:
(sid)25247:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2
-ftree-vectorize
~/ascpu-ascpu_x.c
/home/tbm/ascpu-ascpu_x.c: In function 'real_average':
/home/tbm/ascpu-ascpu_x.c:11: internal compiler error: in
I'm getting the following ICE with -O2 -ftree-vectorize and gcc 4.3
20070604. PR30958 mentions a similar ICE but the testcase looks quite
different.
(sid)25289:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2
-ftree-vectorize
fceu-sound.c
fceu-sound.c: In function 'SetSoundVariables':
--- Comment #5 from tbm at cyrius dot com 2007-06-05 06:48 ---
(In reply to comment #0)
Preprocessed source code attached. Flags -ftree-vectorize -Os -mno-sse
required.
I don't see this with gcc 4.3 20070604. Do you still get this failure?
--
--- Comment #10 from tbm at cyrius dot com 2007-06-05 06:54 ---
I don't suppose you've come to an agreement yet as to which fix is correct?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31724
The following valid program ends up in a segfault at the UNPACK function call
with gfortran 4.3.0 20070605 (experimental binaries from gcc site):
program bug_report
implicit none
integer,parameter:: rp = kind(1.d0),na = 6
real(rp),allocatable:: hhe(:,:,:),hhc(:,:,:),dv(:)
integer:: nhh,ndv
nhh = 0
I'm getting the following segfault on IA-64 with current 4.2 and 4.3.
This goes back at least to 20060721 - I don't have anything older to
test here at the moment. I don't see this segfault on x86_64.
Unfortunately I don't have a working gdb on ia-64 at the moment so
I cannot supply a backtrace.
Hi Zdenek, Hi Daniel, Hi Geoff,
I think that I have found a small bug in the loop invariant code.
The problem is exhibited when building newlib for the xstormy16-elf
toolchain although it may happen with other targets as well. The
problem occurs when an insn contains an r-value use of a
Hello,
I think that I have found a small bug in the loop invariant code.
The problem is exhibited when building newlib for the xstormy16-elf
toolchain although it may happen with other targets as well. The
problem occurs when an insn contains an r-value use of a register
that is
I think that I have found a small bug in the loop invariant code.
The problem is exhibited when building newlib for the xstormy16-elf
toolchain although it may happen with other targets as well. The
problem occurs when an insn contains an r-value use of a register
that is going to
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-06-05 09:27
---
See this testcase (reduced from spec2k6 dealII by Micha):
struct I {
int ix;
struct II {
int j,i;
void *ptr;
} ii;
};// inner;
struct O : public I {
// int x;
int y;
};
static int
Hello,
I think that I have found a small bug in the loop invariant code.
The problem is exhibited when building newlib for the xstormy16-elf
toolchain although it may happen with other targets as well. The
problem occurs when an insn contains an r-value use of a register
that
following testcase causes gpf on i386.
$ cat exe.c
extern void f() __attribute__((weak,visibility(hidden)));
extern int puts( char const* );
int main()
{
f ? f() : puts( f == null, skipped. );
return 0;
}
$ gcc exe.c -fPIE --save-temps -m32 -O1 ./a.out
Segmentation fault
this
Hi Zdenek,
(parallel [
(set (pc)
(if_then_else (lt:SI (reg:SI 45)---
(reg:SI 26))
(label_ref:HI 129)
(pc)))
(clobber (reg:SI 45))
Hello,
(parallel [
(set (pc)
(if_then_else (lt:SI (reg:SI 45)---
(reg:SI 26))
(label_ref:HI 129)
(pc)))
(clobber (reg:SI 45))
--- Comment #8 from andreast at gcc dot gnu dot org 2007-06-05 10:46
---
This is the commit causing this failure:
http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00052.html
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-06-05 12:05
---
The problem in this PR is, that the structure we mess up points-to info has no
fields in its lower half, but only two varinfos (D.2860, offset 128 size 64
and D.2860.visited_, offset 192 size 64 -- the first one
--- Comment #1 from pluto at agmk dot net 2007-06-05 12:53 ---
btw, imho the weak+hidden is not a valid combination.
such symbol can't be resolved in runtime because it doesn't exist
in elf rel.plt/rel.dyn tables. it can be resolved only during
linking several objects into one piece
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 13:30 ---
f always will bind local ...
Also you should be using -PIE when linking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #9 from malitzke at metronets dot com 2007-06-05 13:44 ---
Mr. Tobler
Thanks for pursuing this. For me. as a user, it is solved. My analysis, as an
outsider, points to the corruption, inadvertent chang, update malfunction of an
include file shared by the *.c files leading
--- Comment #3 from pluto at agmk dot net 2007-06-05 14:10 ---
(In reply to comment #2)
Also you should be using -PIE when linking.
hmm, it doesn't work with int main();
$ gcc -s main.c -fpie -Wl,-pie
/usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against
`__libc_csu_fini'
--- Comment #4 from pluto at agmk dot net 2007-06-05 14:13 ---
(In reply to comment #2)
f always will bind local ...
so, should gcc reject weak attribute in this (hidden visibility) case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
While rebuilding one of my programs with the new version of gfortran, I hit
this error (This worked on an older version of gfortran)-
[dranta:~/tests] dir% gfortran -O3 -std=legacy -c ad78b.f
ad78b.f: In function 'derv':
ad78b.f:1: internal compiler error: in eliminate_temp_copies, at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
While rebuilding one of my programs with the new version of gfortran, I hit
this error (This worked on an older version of gfortran)-
[dranta:~/tests] dir% gfortran -O3 -std=legacy -c ad78b.f
ad78b.f: In function 'derv':
ad78b.f:1: internal compiler error: in eliminate_temp_copies, at
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-05 14:54 ---
*** This bug has been marked as a duplicate of 32220 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-05 14:54 ---
*** Bug 32221 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32220
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-06-05 15:01
---
Created an attachment (id=13657)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13657action=view)
patch
Patch in testing. It makes sure to create fields for all addressable
components
(such as empty bases)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-05 15:03 ---
for what target?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from cjain at ca dot ibm dot com 2007-06-05 15:17 ---
(In reply to comment #1)
for what target?
I tried the testcase on a SLES10 machine. Here is the output on sles9 with g++
3.3.3:
Here
Printing an object on 4 bytes
Byte 0 is 0
Byte 1 is 1
Byte 2 is 0
Byte 3 is 1
--- Comment #3 from cjain at ca dot ibm dot com 2007-06-05 15:46 ---
We would like to propose a target of 3.4 if possible.
--
cjain at ca dot ibm dot com changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-05 15:52 ---
I mean, what architecture are you testing on? Btw, all GCC older than 4.1.2
are
out of maintainance and will not be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32210
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-05 15:53 ---
Note there were some changes to bitfield packing in 4.1.0 -- see PR22275.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32210
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-05 15:54 ---
..(In reply to comment #3)
We would like to propose a target of 3.4 if possible.
Anything before 4.1.x is no longer maintained. Also I don't remember the rules
for oversized bit-fields to confirm this is a bug or
--- Comment #33 from rguenth at gcc dot gnu dot org 2007-06-05 15:57
---
Actually,
+ if (minoffset != 0)
must be changed to
+ if (minoffset != 0 count != 0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
model: posix
gcc version 4.3.0 20070605 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E
-lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v test.F90
-mtune=generic -o /tmp/ccdbfKTt.f95
ignoring nonexistent directory
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc
--- Comment #34 from dberlin at gcc dot gnu dot org 2007-06-05 16:20
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 09:27:34 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #30 from
--- Comment #166 from rguenth at gcc dot gnu dot org 2007-06-05 16:20
---
It causes a 10% performance regression for tramp3d. There appear to be no
significant changes in libstdc++ performance testing. Fixing tramp3d-v4
with the below patch cures the performance regression.
---
This compiled with out a warning on older versions of gfortran. It does not
seem to like the '\0', but it says something else -
[dranta:~/tests/gfortran-D] dir% gfortran -c linlab.f
linlab.f:3.33:
data bzero /'0', '.', '0', '\0','0'/
--- Comment #35 from rguenther at suse dot de 2007-06-05 16:30 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based
--- Comment #29 from hjl at lucon dot org 2007-06-05 16:45 ---
Here are SPEC CPU 2006 -O2 -ffast-math differences between revision
125281 without the second reassoc and revision 125281 on Intel64:
(r125281 w/o reassoc2 - r125281)/r125281
400.perlbench
--- Comment #6 from dcb314 at hotmail dot com 2007-06-05 16:51 ---
(In reply to comment #5)
(In reply to comment #0)
Preprocessed source code attached. Flags -ftree-vectorize -Os -mno-sse
required.
I don't see this with gcc 4.3 20070604. Do you still get this failure?
Hard to
I'm seeing the following ICE with current trunk. This was introduced at
some point between 20070131 (works) and 20070303 (ICE). This is on x86_64.
(sid)25015:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O
-ftree-vectorize
gmp-export.c
gmp-export.c: In function 'gmpz_export':
--- Comment #2 from richard-gccbugzilla at metafoo dot co dot uk
2007-06-05 17:21 ---
Points worthy of note:
1) The OP's code is legal (to my reading of the standard) but meaningless.
Private members in unnamed classes are legal, while private members in
anonymous unions are not. So
--- Comment #11 from rob1weld at aol dot com 2007-06-05 17:22 ---
[EMAIL PROTECTED]
IEEE 754 does not discuss any of the functions you list above.
Comment #4 From Rob
That page is a report of the libc6 tests that are ran when the code is built
[EMAIL PROTECTED]
Compare the ...
--- Comment #24 from pluto at agmk dot net 2007-06-05 17:26 ---
(In reply to comment #23)
Confirmed. I'm working on a fix.
This is due to template instantiations marked as anonymous.
any news?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-05 17:27 ---
The error message is ok as you have the string \ + 0, which does not fit
into a character(len=1) variable. bzero(4) contains \, which is consistent
with several compilers.
-fbackslash implies that C-style control
--- Comment #22 from rob1weld at aol dot com 2007-06-05 17:28 ---
I'm leaving the currect status of RESOLVED FIXED and I've changed this from
blocker to normal since for the past few days gcc does not break during the
make of libjava.
It would be good to use the same version of libtool
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-05 17:38 ---
Some more information:
Change the interpretation of backslashes in string literals from
#8220;C-style#8221; escape characters to a single backslash character.
$ cat char.f90
character(len=1) :: c
DATA c / '\0' /
--- Comment #11 from tbm at cyrius dot com 2007-06-05 17:43 ---
Created an attachment (id=13658)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13658action=view)
testcase
Here's another testcase. This one needs -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
--- Comment #36 from dberlin at gcc dot gnu dot org 2007-06-05 17:45
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 16:30:32 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
--- Comment #35 from rguenther
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-05 17:40 ---
Fails in gfc_trans_assignment_1 with:
gcc_assert (lse.ss == gfc_ss_terminator
rse.ss == gfc_ss_terminator);
Works with: 2007-06-04-r125305
Fails with: 2007-06-05-r125327
The only Fortran
--- Comment #37 from matz at gcc dot gnu dot org 2007-06-05 18:24 ---
We are pointing to cell, and using that to access cell.i
No. We are pointing to cell.ii, and use that pointer to access cell.ii.i
(via in-i). Hence of course the points-to set of 'in' needs to include
cell.in.i
--- Comment #4 from rob1weld at aol dot com 2007-06-05 18:54 ---
[EMAIL PROTECTED]
open_errors.f90 is testing for some OS dependent text in error messages. ...
I would very much appreciate if you could post the output from that program.
I'd be glad to help but I am not at that stage
--- Comment #38 from dberlin at gcc dot gnu dot org 2007-06-05 19:07
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 18:24:54 -, matz at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #37 from matz at
--- Comment #1 from brolley at redhat dot com 2007-06-05 19:57 ---
Created an attachment (id=13659)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13659action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #39 from rguenther at suse dot de 2007-06-05 19:59 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
--- Comment #38 from dberlin at gcc dot gnu dot org 2007-06-05
--- Comment #2 from brolley at redhat dot com 2007-06-05 20:09 ---
The macro invocation TYPE_MODE (type) causes the ICE when tree checking is
enabled because TREE_CODE_CLASS (type) is ERROR_MARK. Checking for this before
checking the tree and returning NULL_TREE allows the compiler to
--- Comment #1 from uros at gcc dot gnu dot org 2007-06-05 20:24 ---
Subject: Bug 32215
Author: uros
Date: Tue Jun 5 20:23:58 2007
New Revision: 125343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125343
Log:
PR tree-optimization/32215
* tree-vectorizer.c
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2007-06-05 20:23
---
Subject: Bug 18923
Author: jvdelisle
Date: Tue Jun 5 20:23:44 2007
New Revision: 125342
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125342
Log:
2007-06-05 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from ubizjak at gmail dot com 2007-06-05 20:34 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-05 20:39 ---
This patch is incorrect and just wrong, the C++ front-end should be catching
this before calling size_binop. Also the code is invalid so we should have an
error.
This patch also allows us to get around the ICE (but
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #167 from ian at airs dot com 2007-06-05 20:48 ---
Can you give me a .ii file for the performance regression, and point me at the
relevant function?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #3 from brolley at redhat dot com 2007-06-05 20:11 ---
Typo (sorry!)
4.2 and 4.3 above should be 4.1 and 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #1 from ubizjak at gmail dot com 2007-06-05 21:04 ---
In _.101t.vect, we have:
vect_var_.36_43 = VEC_UNPACK_FLOAT_LO_EXPR vect_vec_iv_.40_41 ;
vect_var_.36_44 = VEC_UNPACK_FLOAT_HI_EXPR vect_vec_iv_.40_41 ;
D.2004_4 = (double) x_13;
vect_var_.41_46 =
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 21:08 ---
D.2098_70 = VIEW_CONVERT_EXPRvector unsigned int({D.2094_66, D.2097_69});
is the problem. Now the question comes what types are D.2094_66?
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #168 from rguenther at suse dot de 2007-06-05 21:17 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Tue, 5 Jun 2007, ian at airs dot com wrote:
--- Comment #167 from ian at airs dot com 2007-06-05 20:48
quantize_fs_dither (unsigned width, short *errorptr, int dir)
{
short bpreverr;
unsigned col;
for (col = width; col 0; col--)
errorptr += dir;
errorptr[0] = (short) bpreverr;
}
SCCP goes funny for this (have not looked why yet).
--
Summary: ICE in alias.c with
Hi,
I found this missed optimization when looking into an ICE on the pointer_plus
branch.
For this code:
quantize_fs_dither (unsigned width, short *errorptr, int dir)
{
short bpreverr;
unsigned col;
for (col = width; col 0; col--)
errorptr += dir;
errorptr[0] = (short) bpreverr;
}
1 - 100 of 131 matches
Mail list logo
