Tadahito Kobayashi koval...@gmail.com writes:
return 0xe+0x1 ;
0xe+0x1 forms a single preprocessing token (a pp-number), but cannot be
converted to a valid token. Add some whitespace around + to break up
the preprocessing token.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
Key
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-02 10:00 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
struct C
{
unsigned int c;
struct D
{
unsigned int columns : 4;
unsigned int fore : 9;
unsigned int back : 9;
unsigned int fragment : 1;
unsigned int standout : 1;
unsigned int underline : 1;
unsigned int strikethrough : 1;
unsigned int reverse : 1;
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.0
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-02 10:03 ---
int i = 0;
for (i = 1; i; ++i) {
invokes undefined behavior (signed overflow is undefined in ISO C).
Use -fwrapv or unsigned arithmetic.
--
rguenth at gcc dot gnu dot org changed:
What
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P3
Target Milestone|4.4.0 |---
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-02 10:10 ---
Confirmed.
typedef unsigned char byte;
typedef struct gx_device_s gx_device;
typedef struct gs_devn_params_s gs_devn_params;
typedef struct gs_devn_params_s {
struct compressed_color_list_s *
g++ 4.3.1 implements std::norm(x) as std::abs(x) squared for built-in floating
point types. I believe this is taking the standard too literally. It says
std::norm should return magnitude of x squared in the mathematical sense
(i.e. a floating-point approximation thereof), which is not necessarily
Understood,
That's a single token according to the definition of pp-number.
It's not a bug.
Thanks for kindly teaching.
-Kovaltan
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-02 10:52 ---
Introduced in r132969.
During esra we have:
D.1656_34 = VIEW_CONVERT_EXPRunsigned int(screen_3(D)-defaults.attr);
D.1657_35 = D.1656_34 23;
attr$B23F9_36 = (unnamed-unsigned:9) D.1657_35;
...
SR.8_37 =
--- Comment #2 from rob1weld at aol dot com 2009-03-02 11:00 ---
(In reply to comment #1)
Subject: Re: New: [LTO] ICE: in make_decl_rtl, at
varasm.c:1288
Thanks for the bug reports.
At this stage, I'm not sure if it's useful to file a bug report for
every test in the
It would be useful to interface C functions with code written in raw assembly
to have a function attribute to make a function save and restore every used
registers, even flags register if possible.
This should not cause big problems because such special functions will still
_respect_ the ABI, but
--- Comment #1 from falk at debian dot org 2009-03-02 11:43 ---
Why not just use -fcall-saved-reg for the relevant registers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
--- Comment #11 from irar at gcc dot gnu dot org 2009-03-02 11:52 ---
Subject: Bug 39318
Author: irar
Date: Mon Mar 2 11:52:15 2009
New Revision: 144541
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144541
Log:
2009-03-02 Richard Guenther rguent...@suse.de
Ira
--- Comment #2 from a dot pignotti at sssup dot it 2009-03-02 11:54 ---
Using -fcall-saved-reg for every reg is a very heavy syntax, and would not work
on flags register. I think that a per function attribute would be better. It
seems that this feature is actually supported for a couple
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-02 12:13 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
We have a rather large suite of fortran (mostly f90 - some f77) code that we
would like to port to gnu fortan. It is today compiled on Sun f90 (derived
from Cray CF90). We do have some issues...
This might not be defined as a gfortran error - but we do not know (how to find
out)
Our current
extern inline __attribute__ ((__always_inline__)) int
foo (char *dest)
{
return __builtin_object_size (dest, 1);
}
struct S
{
union
{
struct { int a, b; char c, d; } f;
struct { struct { int a, b; char c, d[255]; } e; } g;
} u;
};
int
main (void)
{
struct S s;
return foo
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-02 12:38 ---
This causes valid programs to abort with -D_FORTIFY_SOURCE=2, when strcpy etc.
is used to initialize that field. For memcpy etc. it makes no difference,
those use __builtin_object_size (x, 0) always.
--
jakub at
--- Comment #1 from kargl at gcc dot gnu dot org 2009-03-02 12:41 ---
(In reply to comment #0)
We have a rather large suite of fortran (mostly f90 - some f77) code that we
would like to port to gnu fortan. It is today compiled on Sun f90 (derived
from Cray CF90). We do have some
--- Comment #2 from rvatne at gmail dot com 2009-03-02 12:59 ---
(In reply to comment #1)
(In reply to comment #0)
We have a rather large suite of fortran (mostly f90 - some f77) code that we
would like to port to gnu fortan. It is today compiled on Sun f90 (derived
from Cray
We have a rather large suite of fortran (mostly f90 - some f77) code that we
would like to port to gnu fortan. It is today compiled on Sun f90 (derived
from Cray CF90). We do have some issues...
This might not be defined as a gfortran error - but we do not know (how to find
out)
Our current
--- Comment #3 from domob at gcc dot gnu dot org 2009-03-02 13:13 ---
*** Bug 39344 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39342
--- Comment #1 from domob at gcc dot gnu dot org 2009-03-02 13:13 ---
*** This bug has been marked as a duplicate of 39342 ***
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-03-02 13:38
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-02 13:39 ---
First the target needs support for saving those registers. Does it make sense
to mark the TOC register as being saved? How about the thread local storage
register being saved?
Why not used use ABI correctly?
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 13:52 ---
Does -fno-strict-aliasing help ?
Does -fno-strict-overflow help?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Building SurfaceMeshGenerator.cpp of FreeFEM3d ICEs with -O and -O2.
--
Summary: [4.4 Regression] ICE in copy_tree_body_r, at tree-
inline.c:1020
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-02 14:48 ---
Created an attachment (id=17383)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17383action=view)
testcase
Preprocessed source (x86_64).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-02 14:50 ---
Doesn't ICE with -O -g.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-02 15:24 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-02 16:20 ---
Created an attachment (id=17384)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17384action=view)
patch to disable canonicalization of template type args
type canonicalization is the problem here, not a solution;
--- Comment #5 from dave at boost-consulting dot com 2009-03-02 16:39
---
Why do you think I want to see the typedef name when I've explicitly asked for
the opposite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-03-02 17:00
---
And for trunk we have
combiner : 24.76 (15%) usr 0.80 (23%) sys 25.76 (16%) wall
448053 kB (82%) ggc
integrated RA : 68.41 (43%) usr 1.06 (31%) sys 70.23 (42%) wall
3197 kB (
--- Comment #6 from jason at gcc dot gnu dot org 2009-03-02 17:01 ---
Poor reading comprehension?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
The official FSF gcc doesn't have a target port to ARC's MXP architecture.
--
Summary: no mxp target port
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
There is no mode class to describe a SIMD condition code register.
--
Summary: Vector mode class for CCmode is missing
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 17:15 ---
Is there a reason behind why you want this? SIMD CC modes seems a bit weird
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39347
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
There is no mode class to describe a SIMD partial integer register.
--
Summary: Vector mode class for MODE_PARTIAL_INT is missing
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 17:23 ---
Vector modes of partial modes does not make sense since partial modes can only
be used for pointers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39348
--- Comment #2 from janis at gcc dot gnu dot org 2009-03-02 17:28 ---
Please submit the patch to gcc-patc...@gcc.gnu.org.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39325
The loop in cse_insn below the comment:
/* See if we have a CONST_INT that is already in a
wider mode. */
fails to terminate when VOIDmode is reached.
--
Summary: cse_insn has out-of-bounds array access
Product: gcc
Version: 4.4.0
Status:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 17:39 ---
I think this is by defined, you need to include one mode bigger than the
register size. This is done for spu the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39349
--- Comment #4 from il dot basso dot buffo at gmail dot com 2009-03-02
17:42 ---
This reduction gives a different (but probably related) ICE:
void crash_me(int num1, int num2, char * in, char * out)
{
int i, j;
for (j = 0; j num1; j++)
for (i = 0; i num2; i++)
*out++ =
MOVE_BY_PIECES_P is used by rtl optimizers to determine if a chunk of memory is
being moved by pieces. This is wrong when MOVE_BY_PIECES_P returns false
in order to allow a movmem expander emit an efficient move sequence.
There should be a separate optional target macro to tell if a move will be
rtl-factoring.c:compute_init_costs calls compute_rtx_cost with instructions
that have dangling PREV_INSN and NEXT_INSN pointers. That can lead to
crashes when rtx costs depend on context.
--
Summary: compute_init_costs uses unemitted insns
Product: gcc
Version:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 18:08 ---
rtl-factoring.c is so broken that it should be removed ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39351
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 18:09 ---
*** This bug has been marked as a duplicate of 36240 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 18:09 ---
*** Bug 39351 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-03-02 18:16 ---
(In reply to comment #1)
Is there a reason behind why you want this? SIMD CC modes seems a bit weird
The MXP architecture has a SIMD CC register that is pretty close to CC0.
I.e. some moves and adds can be done
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-02 18:19 ---
I still don't understand what you mean by that. Do you mean the registers are
vector based and the instructions effect the conditional register and that
conditional register has slots (elements) that correspond to
--- Comment #7 from jason at gcc dot gnu dot org 2009-03-02 18:24 ---
Actually this issue has nothing to do with typedefs: rather, for template
instantiations GCC prints out the template signature and then the template
arguments, rather than the signature of the instantiation. What
--- Comment #8 from jason at gcc dot gnu dot org 2009-03-02 18:25 ---
Created an attachment (id=17385)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17385action=view)
patch to print the instantiated signature as well as template/args
Is this more what you're looking for?
--
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-03-02 18:26 ---
(In reply to comment #1)
Vector modes of partial modes does not make sense since partial modes can only
be used for pointers.
No, they can also be used to describe integer registers with unusual width, or
the
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-03-02 18:29 ---
(In reply to comment #1)
I think this is by defined, you need to include one mode bigger than the
register size. This is done for spu the same way.
Where does it say that a port for a target with 128 bit
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-02 18:33 ---
This is introduced by revision 144529:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00031.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-02 18:42
---
I'm seeing it on an ACATS test as well (with local compiler modifications).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
The only thing that graphite modifies is from canonicalize_loop_ivs:
here is the diff between 1 that is the debug_loops (3) before
graphite and 2 that is after graphite.
--- 1 2009-03-02 12:20:03.0 -0600
+++ 2 2009-03-02 12:20:18.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds =
--- Comment #5 from sebpop at gmail dot com 2009-03-02 18:57 ---
Subject: Re: ICE in GCC 4.4 with -O[123]
-floop-interchange
Hi,
The only thing that graphite modifies is from canonicalize_loop_ivs:
here is the diff between 1 that is the debug_loops (3) before
graphite and 2
--- Comment #4 from amylaar at gcc dot gnu dot org 2009-03-02 18:59 ---
(In reply to comment #3)
I still don't understand what you mean by that. Do you mean the registers are
vector based and the instructions effect the conditional register and that
conditional register has slots
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-02 19:00 ---
FWIW, I defined OImode (512bit) for AVX. It isn't strictly needed
by x86 backend. But I had to define it. Otherwise, middle-end isn't
happy.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #7 from spop at gcc dot gnu dot org 2009-03-02 19:05 ---
Subject: Re: ICE in GCC 4.4 with -O[123]
-floop-interchange
On Mon, Mar 2, 2009 at 11:42, il dot basso dot buffo at gmail dot com
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #4 from il dot basso dot
/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gfortran/../../gfortran
-B/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gfortran/../../
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/vect/pr39318.f90
-O -c -fopenmp -fexceptions -O2 -ftree-vectorize -S -o pr39318.s
The global variable glob clashes with the compatibility NetBSD libc function
with the same name. The linker emits a warning that causes the test case to
fail. The included patch renames glob to Glob in both tests
--
Summary: Linker warning causing tests to fail (960218 and
--- Comment #1 from aran at 100acres dot us 2009-03-02 19:42 ---
Created an attachment (id=17387)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17387action=view)
Rename glob to Glob.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39353
--- Comment #7 from aran at 100acres dot us 2009-03-02 20:09 ---
Created an attachment (id=17388)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17388action=view)
Gcc 4.3.3 Ada runtime patch for NetBSD 5.0
This patch implements the Ada runtime for NetBSD 5.99. It requires the
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-02 20:09 ---
Created an attachment (id=17389)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17389action=view)
New fix that adds function cv-qual handling to is_function, and fixes compiler
to allow that
Here's a fix along
--- Comment #8 from aran at 100acres dot us 2009-03-02 20:13 ---
Created an attachment (id=17390)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17390action=view)
Gcc 4.3.3 build patch
This patch fixes the header problems that prevent GCC 4.3.3 from compiling on
NetBSD. This also
--- Comment #4 from kargl at gcc dot gnu dot org 2009-03-02 20:23 ---
Is there a (preferred) forum that may be used for this kind of questions,
rather than reporting them as gfortran errors??
Regards
comp.lang.fortarn newsgroup is a great place to ask questions.
Several members and
--- Comment #9 from dave at boost-consulting dot com 2009-03-02 20:24
---
Hi Jason,
Please assume I know what I'm asking for and stop turning it into a different
problem. Go back and look at the original report more closely, particularly
the part that discusses
--- Comment #10 from jason at redhat dot com 2009-03-02 20:35 ---
Subject: Re: deep typedef substitution in error message
dave at boost-consulting dot com wrote:
Please assume I know what I'm asking for and stop turning it into a different
problem.
I know what you're asking for. I
--- Comment #11 from jason at redhat dot com 2009-03-02 20:43 ---
Subject: Re: deep typedef substitution in error message
jason at redhat dot com wrote:
I figured you could apply the patch, rebuild GCC and see if the output
was more to your liking.
But I suppose it's easier to
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-02 20:50 ---
-fexceptions with Fortran looks odd. Does Fortran support exceptions?
To support exceptions, C/C++ initializes eh_personality_libfunc. But
eh_personality_libfunc isn't initialized for Fortran. What does it
mean?
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 20:51 ---
-fexceptions does not seem weird. Since you can call Fortran from C++ code and
want to unwind there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-02 20:54 ---
(In reply to comment #2)
-fexceptions does not seem weird. Since you can call Fortran from C++ code
and
want to unwind there.
I don't believe Fortran front-end has properly set up to support exceptions.
--
--- Comment #45 from pluto at agmk dot net 2009-03-02 21:04 ---
bug ping...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
--- Comment #13 from aesok at gcc dot gnu dot org 2009-03-02 21:54 ---
*** Bug 38558 has been marked as a duplicate of this bug. ***
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from aesok at gcc dot gnu dot org 2009-03-02 21:54 ---
*** This bug has been marked as a duplicate of 34299 ***
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from galtgendo at o2 dot pl 2009-03-02 21:56 ---
I'll check, but, as summary suggests (indirectly),
'-O2 -fno-inline-small-functions' works just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
--- Comment #46 from hjl dot tools at gmail dot com 2009-03-02 21:59
---
(In reply to comment #42)
Created an attachment (id=16389)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) [edit]
internal-error-testcase
I got
gnu-6:pts/4[294] ./xgcc -B./ -S
--- Comment #8 from spop at gcc dot gnu dot org 2009-03-02 22:07 ---
Subject: Bug 39335
Author: spop
Date: Mon Mar 2 22:07:10 2009
New Revision: 144555
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144555
Log:
2009-03-02 Sebastian Pop sebastian@amd.com
PR
--- Comment #4 from galtgendo at o2 dot pl 2009-03-02 22:20 ---
Well, neither helps.
As a sidenote: 'gcc -Q -O2 --help=optimizers' fails to list
'-fstrict-overflow',
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-03-02 22:43 ---
(In reply to comment #3)
I'll check, but, as summary suggests (indirectly),
'-O2 -fno-inline-small-functions' works just fine.
But that just enables more inlining. The problem is most likely somewhere
else.
--
It looks like bug #34020 (reported against IPF Fortran) is also happening with
Intel64 Fortran logical ops. The lhs operand is not reloaded if the cmpxchg
fails.
Testcase:
SUBROUTINE test(lhs, rhs)
LOGICAL lhs, rhs
!$omp atomic
lhs = lhs .or. rhs
END
% gfortran
--- Comment #6 from brian dot e dot bliss at intel dot com 2009-03-02
22:47 ---
See 39354.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34020
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-02 23:47 ---
can_be_nonlocal calls remap_type to return the remapped type. But
it isn't stored anywhere. Is that intentional? I don't know if
this patch makes any senses. It fixed ICE.
Index: tree-inline.c
--- Comment #6 from galtgendo at o2 dot pl 2009-03-03 00:20 ---
(In reply to comment #5)
But that just enables more inlining. The problem is most likely somewhere
else.
If so, why does '-O2' fail and '-O2 -fno-inline-small-functions' work ?
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-03-03 00:21 ---
(In reply to comment #6)
If so, why does '-O2' fail and '-O2 -fno-inline-small-functions' work ?
Because you just disabled some extra inlining. try -O2
-fno-inline-small-functions -finline-functions and you will
Executing on host: /home/dave/gnu/gcc-4.4/objdir/./gcc/g++ -shared-libgcc
-B/hom
e/dave/gnu/gcc-4.4/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/
src/.libs
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-03
02:09 ---
Subject: Re: New: [4.4 Regression] ICE at
dwarf2out.c:10353 in loc_descriptor_from_tree_1
Attached preprocessed source.
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca
--- Comment #8 from galtgendo at o2 dot pl 2009-03-03 03:23 ---
OK, we seem to misunderstand each other.
Anyway, as '-Wall -Wpointer-arith
-Wcast-align -Wmissing-prototypes -Wmissing-declarations'
was set for all files during build and there were no warnings,
the problem is probably
--- Comment #9 from galtgendo at o2 dot pl 2009-03-03 03:43 ---
BTW, this is the workaround, that upstream created:
http://svn.gna.org/viewcvs/freeciv/trunk/common/aicore/cm.c?rev=15556view=diffr1=15556r2=1p1=trunk/common/aicore/cm.cp2=/trunk/common/aicore/cm.c
--
--- Comment #9 from spop at gcc dot gnu dot org 2009-03-03 03:47 ---
Subject: Bug 39335
Author: spop
Date: Tue Mar 3 03:47:22 2009
New Revision: 144564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144564
Log:
2009-03-02 Sebastian Pop sebastian@amd.com
PR
--- Comment #10 from spop at gcc dot gnu dot org 2009-03-03 03:48 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-03-03 03:51
---
for (i = 0, j = 0; i lattice-size || forced_loop; i++) {
i is signed and lattice-size is unsigned so there might be some wrapping.
plus if (lattice-size 0) {
will be changed into lattice-size != 0 .
--- Comment #9 from irar at gcc dot gnu dot org 2009-03-03 07:42 ---
Subject: Bug 39248
Author: irar
Date: Tue Mar 3 07:42:26 2009
New Revision: 144569
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144569
Log:
PR tree-optimization/39248
*
97 matches
Mail list logo
