--- Comment #9 from stsp at users dot sourceforge dot net 2008-12-28 09:40
---
OK, Andrew, why do you do this?
Mark have confirmed the existance of
the bug here, yet you resolve it as
a duplicate of an INVALID bug.
Why not to fix the -g3 instead of
always closing this?
Anyway, this is
--- Comment #7 from eric-bugs at omnifarious dot org 2008-12-28 11:21
---
I've been meaning to revisit this bug with a recent version of gcc. And, in
fact it still happens with gcc 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11211
there is a bug in the compiled code (e.g. kernel compile) when defining
CFLAGS= -march=i586 or CFLAGS=-march=C3 in make.conf
The compiled kernel requires support for CMOV from the CPU which is a pure i686
feature. (=should be only enabled if march=i686 has been defined)
As a result no code can
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-28 12:05 ---
GCC should not generate cmov instructions if you use -march={i586,c3} and, as
far as I can tell, it does not since gcc 3.2.
Since you have not provided a test case, there is nothing we can do with this
bug report.
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-28 12:20 ---
Re. comment #9
This is imho a bug, but I'd probably just fix it with a small documentation
update. Mark tends to describe the situation as it should be, but I wouldn't
want you to expect Mark, nor anyone else, to
--- Comment #4 from cazfi74 at gmail dot com 2008-12-28 12:31 ---
Yes, it works. I cannot reproduce any more.
--
cazfi74 at gmail dot com changed:
What|Removed |Added
--- Comment #11 from stsp at users dot sourceforge dot net 2008-12-28
12:33 ---
but I wouldn't
want you to expect Mark, nor anyone else, to actually implement that.
Is this because it would be too
much work to implement, or is it
really undesireable?
Just wondering.
--
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-28 12:51 ---
Undesirable. As Mark already pointed out, we'd probably end up breaking legacy
code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #13 from stsp at users dot sourceforge dot net 2008-12-28
13:03 ---
The problem is that -g and -g3 do
behave differently. You can't break any
code by making -g3 to behave similar to
-g, or can you?
Its exactly the opposite. -g3 breaks
the code that otherwise works fine
--- Comment #14 from stsp at users dot sourceforge dot net 2008-12-28
13:04 ---
And what Mark says, is:
---
But, we could make sure that we always pop back from the debug section to
whatever the preceding section was after emitting debug information. That
seems reasonable to me, as I
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-28 13:15 ---
Which part of ...as I don't think people are trying to... gives you the
certainty that really people don't?
Anyway, as far as I'm concerned, this is end of discussion. There is nothing
stopping you from working on
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-28 13:23 ---
In fact, Mark's suggestion wouldn't actually work in all cases. With
-ffunction-sections, your function definition may end up in a section that will
be eliminated by the linker. And if the preceding section was a
--- Comment #17 from stsp at users dot sourceforge dot net 2008-12-28
13:54 ---
Which part of ...as I don't think people are trying to... gives you the
certainty that really people don't?
What gives me that certainty is the
fact that this happens only with -g3.
Do you think someone
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-12-28 14:03
---
Do you think someone depended himself on -g3 and is not compiling his programs
with -g[012], so that this gcc behavior is worth keeping?
It just happens to work at -O0, does not mean it is a bug in GCC,
--- Comment #4 from danglin at gcc dot gnu dot org 2008-12-28 15:53 ---
This bug is fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from danglin at gcc dot gnu dot org 2008-12-28 16:22 ---
Patch here:
http://gcc.gnu.org/ml/fortran/2008-12/msg00315.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31832
--- Comment #2 from eric dot weddington at atmel dot com 2008-12-28 16:32
---
Test case fails, also as of 2008-12-23, with this:
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36998.c -Os
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-12-28 16:44 ---
Is this still an issue with current trunk, or
with 4.3?
If that's the case, please add a test case,
with preprocessed source (even if it is very large)
showing the problem.
--
tkoenig at gcc dot gnu dot org
A bug to hang a few ideas for I/O speedup from.
We have Jerry's first I/O refactoring results (splitting
into formatted read and write) at
http://gcc.gnu.org/ml/fortran/2008-12/msg00114.html
We also would want to pre-parse format strings.
I would really like to pre-parse the option strings
--- Comment #1 from domob at gcc dot gnu dot org 2008-12-28 17:38 ---
I did once write a floating-point parser for FreeWRL. I can dig it out so we
can try to compare it to gfortran's current one, but I've no idea whether it is
fast or not (although I tried at that time to write it as
--
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 #6 from reichelt at gcc dot gnu dot org 2008-12-28 17:57
---
Shorter testcase:
=
struct A
{
A()
{
for (int* p = x; p != x+1; ++p)
*p = 0;
}
A foo()
{
A a;
a.x[0] = x[0];
return a;
}
int x[1];
};
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-12-28 18:01
---
The bug disappeared on mainline between 2008-08-23 and 2008-09-19.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38369
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-12-28 18:24
---
Confirmed. Shorter testcase that crashes with -O -ftree-parallelize-loops=2
(on i686-pc-linux-gnu):
=
void foo(int n, void** p)
{
int i;
for (i = 0; i n; ++i)
p[i] = L;
L:
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-28 18:40
---
Btw, the error message is a little hosed:
bug.c: In function 'foo':
bug.c:2: error: label
L has incorrect context in bb 8bug.c:7: internal compiler error:
verify_flow_info failed
Please submit a full bug report,
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-12-28 18:41
---
I agree with Steven that there are some cases (like -ffunction-sections) where
even popping back from the debug section after generating it doesn't work.
However, I'm not sure that's a reason not to do it --
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-12-28 18:50
---
Shorter testcase without templates:
==
inline void* operator new[](__SIZE_TYPE__, void* p) throw() { return p; }
struct A
{
A() {}
int
--- Comment #12 from mikael at gcc dot gnu dot org 2008-12-28 19:19 ---
(In reply to comment #11)
This test case runs fine here, maybe your trunk is not fully updated?
It works with a fresh checkout and a fresh bootstrap.
My trunk was up to date; it was probably the dirty build tree
--- Comment #2 from regehr at cs dot utah dot edu 2008-12-28 19:47 ---
(In reply to comment #1)
Can you reproduce this now?
Nope-- looks fixed in r142939.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37183
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-28 20:07 ---
Subject: Bug 38650
Author: jakub
Date: Sun Dec 28 20:06:00 2008
New Revision: 142940
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142940
Log:
PR c++/38650
* semantics.c (finish_omp_for): Don't
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-28 20:10 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-28 20:14 ---
Confirmed. The bug went away between r140768 and r142000.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-28 20:22 ---
Guess PR37448 (plus PR37808 follow-up).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37183
--- Comment #8 from danglin at gcc dot gnu dot org 2008-12-28 20:25 ---
The value calculated for b = nearest(0.5,-1.0) is 0.4997 (raw 0x3eff).
The code uses the roundf implementation in c99_functions.
float
roundf(float x)
{
float t;
if (!isfinite (x))
return (x);
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-28
20:39 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0
execution test
On Sun, 28 Dec 2008, danglin at gcc dot gnu dot org wrote:
The value calculated for b = nearest(0.5,-1.0) is 0.4997 (raw
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-28 20:55
---
Daniel, it can't hurt to look.
Also, I have a format data hashing/caching patch in the works. This avoids
re-parsing format strings if they have already been parsed once such as in a
loop containing I/O
--- Comment #11 from kargl at gcc dot gnu dot org 2008-12-28 21:02 ---
(In reply to comment #9)
I think the tests in roundf need to be revised to minimize rounding
issues. Patch attached. This fixes the test on hppa2.0w-hp-hpux11.11.
See libm on FreeBSD.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-28 21:02
---
Created an attachment (id=16997)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16997action=view)
Patch that splits formatted read and write
This is the patch mentioned in comment 0. This patch touches
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 21:13 ---
Confirm to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-28 21:15 ---
mklibgcc.in has since been removed in 4.3.x, is this still an issue in 4.3?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 21:17 ---
This part of the Makefile.in has since been removed from 4.3.x and above. Do
you know if this issue still exists?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-28 21:19 ---
g77 has since been removed and the way bootstrap works now in 4.2 and above is
different. Does this work now in 4.3.x and above?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-28 21:13 ---
Suspend as m68k-*-coff is now obsolete will most likely be removed soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-28 21:22 ---
make install should not be rebuilding anything.
Does this work for you with 4.3.x?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-28 21:23 ---
libjava is not designed to run in single threads mode at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-28 21:25 ---
Is this still true?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28561
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 21:24 ---
You can rerun fixincludes after install glibc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from domob at gcc dot gnu dot org 2008-12-28 21:27 ---
Created an attachment (id=16998)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16998action=view)
Number parsing routines
Sorry for the spam, but this is the parser-code for numbers I promised; it's
just a part
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-28 21:28 ---
You should disable libmudflap and libssp (in newer gcc's) if you want to build
a cross compiler to start stage1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-28 21:30 ---
SHELL is set by make which is always set to a semi borne compatible shell so
the configuration of make is incorrect.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
A broken diagnostic is issued for the following code snippet since GCC 4.3.0:
==
__decltype(0r)* p = 1;
==
bug.cc:1: error: invalid conversion from 'int' to '#'fixed_point_type' not
supported by
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-28 21:31 ---
Well the requirement to use GNU make is documented.
http://gcc.gnu.org/install/prerequisites.html
GNU make version 3.80 (or later)
You must have GNU make installed to build GCC.
So I am going to close this as
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-28 21:33
---
I think the issue was info/.texi files were not generated in that package.
Does this work in a newer release of GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
A broken diagnostic is issued for the following code snippet since GCC 4.3.0:
templateint int foo();
templatetypename F void bar(F f)
{
f((foo0()=0)...);
}
bug.cc: In function 'void bar(F)':
bug.cc:5: error:
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-12-28 21:34
---
You have to set CC to begin with if you are bootstrapping.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-12-28 21:38 ---
THis is not a bug as explained, the compiler needs to decide what kind of
method needs to be called including the return value. So the compiler is guess
it returns an int instead of the float one.
--
pinskia at
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-28
21:48 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
See libm on FreeBSD.
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_roundf.c
So, the ceilf implementation was changed to a
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-12-28 21:55
---
Even shorter testcase:
=
templatetypename... struct A;
templatetypename, typename struct B;
templatetypename... T, typename... U struct
--- Comment #4 from amylaar at gcc dot gnu dot org 2008-12-28 22:07 ---
(In reply to comment #3)
Is this still an issue with current trunk, or
with 4.3?
I had a look at the current trunk and the diffs leading up to it, and I can
confirm that the issue has not been fixed.
However, I
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-12-28 22:11
---
Confirmed. Reduced testcase for comment #1:
=
templatetypename struct A;
templatetypename, templatetypename class = A void foo();
void bar()
{
--- Comment #13 from kargl at gcc dot gnu dot org 2008-12-28 22:14 ---
(In reply to comment #12)
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
See libm on FreeBSD.
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_roundf.c
So, the ceilf
--- Comment #65 from reichelt at gcc dot gnu dot org 2008-12-28 22:16
---
Janis, Manuel, is this fixed now?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-28 22:39
---
Confirmed.
The behavior changed between 2008-10-18 and 2008-11-02.
Looking at the patches in the relevant timeframe,
the following patch might be the cause:
2008-10-20 Manuel López-Ibáñez m...@gcc.gnu.org
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-12-28 22:53
---
Removing error-recovery because the first testcase crashes without previous
error message.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bkorb at gnu dot org 2008-12-28 23:01 ---
It would seem to me that requiring one to read through installation
documentation is unreasonable when a trivial change to the configure script can
tell the hapless builder what is wrong. You are correct in that it is
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-12-28 23:00
---
Might be related to PR35828.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
$cat test3.f90
MODULE TEST3
PRIVATE
CHARACTER(LEN=80) :: TESTCHAR
INTEGER :: TESTINT
REAL :: TESTREAL
COMMON /TESTCOMMON1/ TESTCHAR
COMMON /TESTCOMMON2/ TESTINT
COMMON /TESTCOMMON3/ TESTREAL
END MODULE TEST3
$cat test2.f90
MODULE TEST2
USE TEST3
PRIVATE
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-12-28 23:08
---
Confirmed.
Btw, the following is accepted:
template typename struct X {};
Xdecltype((1 2)) x;
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-28 23:43
---
Simpler testcase:
===
struct A
{
templatetypename T A(T);
};
struct B
{
void foo();
};
A a = B().*(B::foo);
===
This is invalid use of a bound
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-29 00:04
---
Even complete garbage like the following is accepted:
=
templatetypename... struct A;
template struct A+/-.../+/-.../+/-.../+ {};
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-12-29 00:16
---
*** Bug 35497 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-29 00:16
---
Yes, it's indeed a duplicate.
The bug has been fixed for GCC 4.4.0.
*** This bug has been marked as a duplicate of 36460 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed
I would expect a C++ compiler to generate optimal and equivalently efficient
code for both of the functions below. gcc 4.3 generates much worse code for
bar() than for foo() even at -O3.
int foo () { return 1; }
int bar () { try { throw 1; } catch (int i) { return i; } }
--
Summary:
--- Comment #3 from pinskia at gmail dot com 2008-12-29 00:49 ---
Subject: Re: toplevel configure script does not test for GNU Make
On Sun, Dec 28, 2008 at 6:01 PM, bkorb at gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #2 from bkorb at gnu dot org 2008-12-28 23:01
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from bkorb at gnu dot org 2008-12-29 01:24 ---
If GNU Make is only required for the GCC build, then the configure script
for the gcc piece is the only place where such code would be needed.
Anyway, my basic point is that it would be very helpful to not force folks
to find
--- Comment #19 from lucier at math dot purdue dot edu 2008-12-29 01:30
---
Maybe you could offer a few more details; I just tried
% cat ../../mainline/build-and-check-gcc-64-32
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='/usr/bin/gcc-4.0 -mcpu=970 -m64'
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 01:50 ---
You would think that but I think no C++ compiler does that optimization at all.
They might get rid of empty final's but not throw catches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 02:18 ---
Subject: Bug 36610
Author: pinskia
Date: Mon Dec 29 02:16:45 2008
New Revision: 142945
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142945
Log:
2008-12-28 Andrew Pinski pins...@gmail.com
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-29 02:28 ---
If you are using the specific intrinsics, you need to use a literal n here.
Try:
template typename T inline
T rot_veci( T v, const int n ) __atrribute__((always_inline))
template typename T inline
T rot_veci( T
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 02:31 ---
volatile here means noreturn.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-12-29 02:32
---
With a little tweaking the testcase compiles under GCC 4.3.x or even GCC 4.4.0.
It compiles fine without crash using -O -fopenmp and -O3 -fopenmp.
So the bug is really fixed in GCC 4.3.0 and up.
This looks really
--- Comment #9 from reichelt at gcc dot gnu dot org 2008-12-29 02:32
---
*** Bug 33981 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33361
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
GCC
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 02:38 ---
IIRC libgcc_eh.a is only needed for shared targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35857
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-12-29 02:35
---
*** Bug 37058 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 02:35 ---
*** This bug has been marked as a duplicate of 34999 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-12-29 02:42
---
/Users/lucier/programs/gcc/objdirs/mainline/./gcc/as: line 76: exec: : not
found
That means as was not found in the first place.
--target=powerpc-apple-darwin9.6.0
Since build == host != target, you are
--- Comment #21 from lucier at math dot purdue dot edu 2008-12-29 03:06
---
Thanks for your comments.
So, to get back to basics, how do I build a compiler on darwin that has a
64-bit gcc/cc1/etc., but compiles to 32-bit binaries by default?
--
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-29 03:22
---
Instead of a segfault I see a crash in fold_binary, at fold-const.c:9278
Reduced testcase that crashes already with -O -ftree-loop-distribution:
==
extern void *malloc
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-12-29 03:22
---
*** Bug 36116 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-29 03:34
---
*** Bug 38154 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:34 ---
This works on the trunk now. Closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-12-29 03:34
---
*** This bug has been marked as a duplicate of 38153 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:38 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:44 ---
I get a branchless form with -march=i686 -O2:
testl %edx, %edx
leal4(%edx), %ecx
cmovne %ecx, %eax
Also in your case if d is NULL, then b has to be NULL. Nothing to do with
anything
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 03:46 ---
Actually this comes down to optimizing:
int f(int a)
{
if (a)
return a +4;
return 0;
}
Into the sequence which is mentioned, that is using subtract with borrow and
such.
--
pinskia at gcc dot gnu dot
1 - 100 of 136 matches
Mail list logo
