--- 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=gcc&view=rev&rev=144569
Log:
PR tree-optimization/39248
* gcc.dg/vect/vect-compl
--- 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 !=
--- 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 #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=gcc&view=rev&rev=144564
Log:
2009-03-02 Sebastian Pop
PR middle-end/39335
*
--- 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=15556&view=diff&r1=15556&r2=1&p1=trunk/common/aicore/cm.c&p2=/trunk/common/aicore/cm.c
--
http://gc
--- 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 non
--- 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 2009
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 -B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/b
--- 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
--- 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 ?
--
http://gcc.gnu.org/bugzilla/sho
--- 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 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
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 #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.
-
--- 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 #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=gcc&view=rev&rev=144555
Log:
2009-03-02 Sebastian Pop
PR middle-end/39335
*
--- 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=16389&action=view) [edit]
> internal-error-testcase
>
I got
gnu-6:pts/4[294]> ./xgcc -B./ -S /tmp/
--- 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 #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 #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 #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 #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 #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 #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? Does
--- 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 ju
--- 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.
--- 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 boost::result_of::type.
--- 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
--- 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=17390&action=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 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=17389&action=view)
New fix that adds function cv-qual handling to is_function, and fixes compiler
to allow that
Here's a fix along t
--- 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=17388&action=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 Net
--- 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=17387&action=view)
Rename glob to Glob.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39353
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
/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
/net
--- 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
wrote:
>
>
> --- Comment #4 from il dot basso dot buffo at gmail dot com
--- 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|Remove
--- 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 #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 "
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 (pred
--- 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
--- 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 #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 regist
--- 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 ca
--- 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=17385&action=view)
patch to print the instantiated signature as well as template/args
Is this more what you're looking for?
--
j
--- 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 you'
--- 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 t
--- 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 w
--- 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 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 #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
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:
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 d
--- 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++
--- 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
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: UNCONFIR
--- 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
--- 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
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: oth
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- 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
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
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
Assigne
--- 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
--- 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 ( 1%)
--- 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 #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=17384&action=view)
patch to disable canonicalization of template type args
type canonicalization is the problem here, not a solution
--- 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
AssignedTo|una
--- 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 Mi
--- 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=17383&action=view)
testcase
Preprocessed source (x86_64).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
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: ice-on-valid-code
--- 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
--- 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? Beca
--- 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 #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 #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
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 comp
--- 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
--- 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 #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 g
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 (s.u.
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 comp
--- 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
AssignedTo|unassigned
--- 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 #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=gcc&view=rev&rev=144541
Log:
2009-03-02 Richard Guenther
Ira Rosen
PR
--- 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
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 #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 i
--- 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_EXPR(screen_3(D)->defaults.attr);
D.1657_35 = D.1656_34 >> 23;
attr$B23F9_36 = () D.1657_35;
...
SR.8_37 = attr$B23F9_36 >> 7;
SR.9_50 = (u
Understood,
That's a single token according to the definition of pp-number.
It's not a bug.
Thanks for kindly teaching.
-Kovaltan
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
--- 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 * compressed_color_li
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P3
Target Milestone|4.4.0 |---
http://gcc.g
--- 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|Removed
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.0
http://gcc.g
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;
unsigne
--- 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
Tadahito Kobayashi 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 fingerprint = 58CA
97 matches
Mail list logo