On Thu, 5 Mar 2009, Geert Bosch wrote:
Hi Richard,
Great to see that you're addressing this issue. If I understand correctly,
for RTL all operations are always wrapping, right?
That's true (we don't have signedness information there) and I don't
plan to change that.
I have been
Hi,
I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
no extern linker lib when i understand right.
But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0
I also link with libgcc.but does not help
also my includes-fixed/math.h
contain a
On Fri, Mar 6, 2009 at 12:27 PM, Bernd Roesch nospamn...@web.de wrote:
Hi,
I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
no extern linker lib when i understand right.
But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0
I also link with
This build problem has been occuring for at least a month,
both on the most recent snapshots and on trunk.
The compiler is configured as follows:
../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared
On Fri, Mar 6, 2009 at 1:48 PM, Piotr Wyderski piotr.wyder...@gmail.com wrote:
This build problem has been occuring for at least a month,
both on the most recent snapshots and on trunk.
The compiler is configured as follows:
../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
Richard Guenther wrote:
Where is windows.h included?
I am not 100% sure yet -- the build process is in progress right
now, so I don't want to interfere. I suspect it is the one included
by gthr-win32.h. It contains the following lines:
#include windows.h
/* Now undef the windows BOOL. */
On Fri, Mar 6, 2009 at 2:05 PM, Piotr Wyderski piotr.wyder...@gmail.com wrote:
Richard Guenther wrote:
Where is windows.h included?
I am not 100% sure yet -- the build process is in progress right
now, so I don't want to interfere. I suspect it is the one included
by gthr-win32.h. It
On Fri, 6 Mar 2009, Richard Guenther wrote:
There is of course the problem that we have to be careful not to
introduce new traps via folding, a problem that doesn't exist with
the no-overflow variants (I can simply drop to the wrapping variants).
With for example (a -/v 10) +/v 10 would you
Piotr Wyderski wrote:
Richard Guenther wrote:
Where is windows.h included?
I am not 100% sure yet -- the build process is in progress right
now, so I don't want to interfere. I suspect it is the one included
by gthr-win32.h. It contains the following lines:
WAG: Do not pass
On Fri, 6 Mar 2009, Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Richard Guenther wrote:
There is of course the problem that we have to be careful not to
introduce new traps via folding, a problem that doesn't exist with
the no-overflow variants (I can simply drop to the wrapping
Dave Korn wrote:
Piotr Wyderski wrote:
Richard Guenther wrote:
Where is windows.h included?
I am not 100% sure yet -- the build process is in progress right
now, so I don't want to interfere. I suspect it is the one included
by gthr-win32.h. It contains the following lines:
WAG: Do
On Fri, 6 Mar 2009, Richard Guenther wrote:
Ok, I didn't think of generating optimal code for the overflow checks,
but it should be reasonably possible to if-convert the explicit
overflow checks back to builtins that can be specially expanded
(that would also help explicit overflow checks in
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x +nv y
(((s ^ x) (s ^ y)) 0) ? trap () : s
d = x -nv y
(((d ^
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini bonz...@gnu.org wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x
Richard Guenther wrote:
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini bonz...@gnu.org wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the
Richard Guenther richard.guent...@gmail.com writes:
I agree. Btw, for the addition case we generate
leal(%rsi,%rdi), %eax
xorl%eax, %esi
xorl%eax, %edi
testl %edi, %esi
jns .L2
.value 0x0b0f
.L2:
rep
On Fri, Mar 6, 2009 at 4:09 PM, Paolo Bonzini bonz...@gnu.org wrote:
Richard Guenther wrote:
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini bonz...@gnu.org wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to
On Mar 6, 2009, at 09:15, Joseph S. Myers wrote:
It looks like only alpha and pa presently have insn patterns such as
addvsi3 that would be used by the present -ftrapv code, but I expect
several other processors also have instructions that would help in
overflow-checking code. (For example,
On Mar 6, 2009, at 04:11, Richard Guenther wrote:
I didn't spend too much time thinking about the trapping variants
(well, I believe it isn't that important ;)). But in general we would
have to expand the non-NV variants via the trapping expanders
if flag_trapv was true (so yeah, combining
On Fri, 6 Mar 2009, Richard Guenther wrote:
Well, I was thinking about detecting the pattern on the tree level instead.
s_6 = x.0_2 + y.1_4;
D.1597_7 = s_6 ^ x_1(D);
D.1598_8 = s_6 ^ y_3(D);
D.1599_9 = D.1597_7 D.1598_8;
if (D.1599_9 0)
goto bb 3;
else
goto bb 4;
On Fri, 6 Mar 2009, Geert Bosch wrote:
this task may be more difficult. So lowering them early during
gimplification looks like a more reasonable plan IMHO.
Right, that was my intention. Still, I'll need to add code to
handle the new tree codes in fold(), right?
If you add new trapping
On Fri, 6 Mar 2009, Geert Bosch wrote:
In any case, while I'd really like to move the checked signed
integer overflow from Gigi (GNAT-to-GNU tree translator) to
the language independent part of GCC, I want to have the absolute
minimum amount of changes that is necessary to achieve this goal.
Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
Multiple front ends want the same thing. This is why it would be better
to introduce the codes in GENERIC and
Dear GCC developers,
I tried to use plugin frameworks
svn://gcc.gnu.org/svn/gcc/branches/plugin (old?) and
svn://gcc.gnu.org/svn/gcc/branches/plugins (current).
'plugin' has transform_ctrees() API. - callback on every fndecl
'plugins' has PLUGIN_CXX_CP_PRE_GENERICIZE. - only supported in C++
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
Multiple front ends want the same thing. This is why it would be
Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Geert Bosch wrote:
this task may be more difficult. So lowering them early during
gimplification looks like a more reasonable plan IMHO.
Right, that was my intention. Still, I'll need to add code to
handle the new tree codes in fold(), right?
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check for overflow directly...
ADDSR0,
On Thu, 2009-03-05 at 18:24 +0100, Laurent GUERBY wrote:
On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote:
On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote:
Laurent GUERBY wrote:
On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote:
Laurent GUERBY wrote:
I'm not sure
On Mar 5, 2009, Jan Hubicka hubi...@ucw.cz wrote:
The patch adds mechanizm for tracking inline substitutions, so we
actually note that on whole scope of its existence ARGUMENT is having
same value as OTHERARGUMENT.
Beautiful!
So if we want to have DEBUG_INSN approach, those aproaches
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check for overflow directly...
ADDSR0, R1, R2
SWIVS #trap
Of course, I was thinking
Richard Earnshaw rearn...@arm.com writes:
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check for
Ian Lance Taylor wrote:
Richard Earnshaw rearn...@arm.com writes:
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM
Laurent GUERBY wrote:
On i686-linux for c,ada:
3.4.4 bootstraped 4.3.2 fine (your configuration)
3.4.0 bootstraped 4.3.1 fine
3.4.0 bootstraped trunk 143919 fine
I'm not going to test more, a priori what the documentation
currently says for Ada is correct at least for i686-linux,
the
On Fri, 6 Mar 2009, Geert Bosch wrote:
On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
If you add new trapping codes to GENERIC I'd recommend *not* making fold()
handle them. I don't think much folding is safe for the trapping codes
when you want to avoid either removing or introducing
Snapshot gcc-4.4-20090306 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090306/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Geert Bosch wrote:
this task may be more difficult. So lowering them early during
gimplification looks like a more reasonable plan IMHO.
Right, that was my intention. Still, I'll need to add code to
I'm happy to report that the gcc-in-cxx branch can now bootstrap. That
is, the code in gcc proper can now be compiled with a C++ compiler.
My plan going forward is as follows (when we are back in stage 1):
* For each difference between trunk and gcc-in-cxx:
+ Try to implement a -Wc++-compat
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if interested.
Thank you,
Silvius
Motivation
==
int foo(int x)
{
int i = 100;
do
{
if (x 0)
x = x 1; /* After this insn, all bits
I'm thinking about adding bitwise dataflow analysis support to RTL.
Before embarking on this, I'd suggest playing with the bitwise domain
analysis that one of my students did as part of his cXprop tool:
http://www.cs.utah.edu/~coop/research/cxprop/#DOWNLOADS
This is a source-level
Sent from my iPhone
On Mar 6, 2009, at 7:00 PM, Silvius Rus r...@google.com wrote:
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if
interested.
There is already some bitwise dataflow implemented in
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-06 09:46 ---
Created an attachment (id=17404)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17404action=view)
gcc44-pr39372.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-06 09:48 ---
Subject: Bug 39387
Author: jakub
Date: Fri Mar 6 09:48:25 2009
New Revision: 144666
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144666
Log:
PR debug/39387
* dwarf2out.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-06 10:01 ---
Indeed. 0 shouldn't match T U::*
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-06 10:31 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from balrogg at gmail dot com 2009-03-06 10:34 ---
(In reply to comment #2)
You need to use a memory clobber instead. =X (params[1]) says to GCC
that the asm operand 0 should be stored to params[1], which it does
(it allocates %eax to it).
Note that =r doesn't
--- Comment #9 from rob1weld at aol dot com 2009-03-06 11:07 ---
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #6)
After the workaround we get 10 failures on i686 and 33 failures
on x86_64 when compiling trunk revision 144629, results here:
Results for
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-06 12:48 ---
The problem is that mark_all_vars_used only marks blocks used by actual code,
but on the testcase the only reference to a one BLOCK is from TYPE_MAX_VALUE
(TYPE_DOMAIN (type)) containing a PLUS_EXPR with that BLOCK as
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-06 12:58 ---
Yeah, we should drop TREE_BLOCK from anything not in stmts. Definitely for
expressions in the types sizes and domains.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39367
Another problem with aliasing: The following code snippet triggers a bogus
warning when compiled on trunk with -O -Wall:
==
#includeset
struct A
{
A() : i() {}
int i;
};
struct B
{
bool operator() (const A x, const A
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-03-06 13:10
---
Created an attachment (id=17405)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17405action=view)
Partially reduced testcase
Somewhat reduced testcase.
--
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-03-06 13:27
---
Oops, typo: I meant the bug is triggered with -O3 -Wall.
The reduced testcase already triggers the warning with -O2 -Wall thanks to
some additional inlines.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-06 13:36 ---
Confirmed with the reduced testcase only, at -O2 -Wall. The warning happens
after PTA triggered by SRA.
Relevant constraints:
__y_7 = s.64+64
D.2839_21 = __y_7
__x.8_43 = D.2839_21
and code:
D.2839_21 =
ref iec/iso c++ section 3.4.2
gcc correctly reports an error when the argument is one of the fundamental type
and the associated namespace is empty. like the call to 'f' in the attached
example.
However if the argument is a pointer to function the associated name space
should be the one
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-03-06 14:05 ---
Created an attachment (id=17406)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17406action=view)
Example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39391
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-06 14:06 ---
Normally TYPE_MAX_VALUE etc. shouldn't contain anything but constants or
VAR_DECLs after gimplification, gimplify_type_sizes is supposed to take care of
this.
The problem here is that build_new_1 when it creates its
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-03-06 14:16 ---
Scheduling another pass_phi_only_cprop after VRP removes the single-argument
PHI nodes (I think that really cfg-cleanup should do this, as they usually
result from edge removal). While this is reasonably cheap it
--- Comment #6 from algrant at acm dot org 2009-03-06 14:44 ---
Right. The existence of a statically initialized object whose size can
be determined at compile-time to be larger than the (notional) type size,
is specific to GCC. Here's another thing: the assembler output shows
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-03-06 15:12 ---
Well, the issues in driver seems to be related to pexecute in protoize.c. On a
first glance, I noticed that here for pid's an 'int' type is used (btw in
libiberty a 'long' is used for keeping the pids, which is for
--- Comment #48 from amylaar at gcc dot gnu dot org 2009-03-06 15:54
---
Created an attachment (id=17408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17408action=view)
patch to take POST_DEC and POST_MODIFY into account
The Copyright assignment issue has been resulved now.
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-06 17:24 ---
I think it is the new:
3384 if (TREE_STATIC (var) !TREE_ASM_WRITTEN (var))
3385{
3386 if (var_ann (var) referenced_var_check_and_insert (var))
3387cfun-local_decls = tree_cons
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-03-06 17:27 ---
Reopening.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #9 from hubicka at ucw dot cz 2009-03-06 17:30 ---
Subject: Re: [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
part. So, either tree-inline.c needs to do the same, or it can't use
referenced_vars bit as a test whether it has been queued already onto
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-06 17:53 ---
To do the same the easiest would be probably change add_referenced_var to
return bool, whatever referenced_var_check_and_insert returned, and use
add_referenced_var instead of referenced_var_check_and_insert in
Trying to compile latest ffmpeg (ffmpeg-checkout-2009-03-06) Using
mingw-w64-bin_i686-mingw_20090303 I get an ICE on mingw compiling for x64.
$ make
x86_64-pc-mingw32-gcc -DHAVE_AV_CONFIG_H -I. -I/c/ffmpeg-checkout-2009-03-06
-D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99
--- Comment #1 from jkolb at wsi dot com 2009-03-06 18:00 ---
Created an attachment (id=17409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17409action=view)
Offending Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #2 from jkolb at wsi dot com 2009-03-06 18:01 ---
Created an attachment (id=17410)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17410action=view)
#included by h264.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #3 from jkolb at wsi dot com 2009-03-06 18:02 ---
Created an attachment (id=17411)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17411action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-06 18:16 ---
Most likely a duplicate of bug 39360.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-06 19:11 ---
Created an attachment (id=17412)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17412action=view)
gcc44-pr39360.patch
Patch I'm bootstrapping/regtesting now.
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #9 from v dot merkatz at gmx dot net 2009-03-06 22:06 ---
Works fine with gcc 4.3.2.
--
v dot merkatz at gmx dot net changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-06 22:47 ---
Jason, if you think you can fix this by not using a VLA at all, please take
this bug over.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-06 22:49 ---
Subject: Bug 39372
Author: jakub
Date: Fri Mar 6 22:49:39 2009
New Revision: 144682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144682
Log:
PR debug/39372
* dwarf2out.c
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-06 22:51 ---
Subject: Bug 39360
Author: jakub
Date: Fri Mar 6 22:51:28 2009
New Revision: 144683
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144683
Log:
PR middle-end/39360
* tree-flow.h
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-06 22:52 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-06 22:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from paolo at gcc dot gnu dot org 2009-03-06 23:52 ---
Subject: Bug 33492
Author: paolo
Date: Fri Mar 6 23:52:02 2009
New Revision: 144686
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144686
Log:
/cp
2009-03-06 Paolo Carlini paolo.carl...@oracle.com
--- Comment #7 from paolo dot carlini at oracle dot com 2009-03-06 23:53
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from linuxl4 at sohu dot com 2009-03-07 00:12 ---
thanks a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
On an x86_64 bit machine, if an attempt to compile code containing an invalid
instruction is attempted, an error will correctly occur:
cat /etc/testasm.c
int main(void)
{
asm(cpuid); /* Invalid on the i386 */
}
gcc -march=i386 -Wa,-march=i386 testasm.c
Error: `cpuid' is not
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-07 01:01 ---
Since this is an inline-asm, it gets processed by the assembler and not GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-07 01:31 ---
(In reply to comment #0)
On an x86_64 bit machine, if an attempt to compile code containing an invalid
instruction is attempted, an error will correctly occur:
cat /etc/testasm.c
int main(void)
{
--- Comment #20 from hjl at gcc dot gnu dot org 2009-03-07 01:47 ---
Subject: Bug 37520
Author: hjl
Date: Sat Mar 7 01:47:25 2009
New Revision: 144692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144692
Log:
2009-03-06 H.J. Lu hongjiu...@intel.com
PR c++/37520
--- Comment #21 from hjl dot tools at gmail dot com 2009-03-07 01:48
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from markhobley at yahoo dot co dot uk 2009-03-07 02:40
---
Subject: Re: invalid instructions accepted in inline assembly language on 32
bit machines
--- On Sat, 7/3/09, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
I got
h...@gnu-9 tmp]$ gcc
--- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30 ---
OK, I've done a little test and I'd like to know,
if it's results actually mean anything:
I've compiled freeciv with CFLAGS=-O2 -finline-functions
-fno-guess-branch-probability and it did not crash.
Does the above confirm
Sent from my iPhone
On Mar 6, 2009, at 8:30 PM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30
---
OK, I've done a little test and I'd like to know,
if it's results actually mean anything:
I've compiled
--- Comment #17 from pinskia at gmail dot com 2009-03-07 04:35 ---
Subject: Re: gcc 4.3.3 miscompiles when -finline-small-functions is used
Sent from my iPhone
On Mar 6, 2009, at 8:30 PM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #16 from
-help.c
It has been like that for about two weeks. This machine attempts to compile
gcc-svn and glibc daily. Sometimes it works sometimes not.
I tested with glibc 2.9 and gcc appears to still segfault.
--
Summary: gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7
90 matches
Mail list logo
