--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2006-10-06 06:09 ---
Created an attachment (id=12389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12389&action=view)
foo.C - testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
How to reproduce: g++ -c foo.C
Compiling the attached code using g++-4.2 generates the warning
foo.C:11: warning: 'foo::bar' has a base '::gazonk' whose type uses
the anonymous namespace
I fail to see why this construct should be warned about
--
Summary: Unnecessary anonymous names
--- Comment #10 from mrs at apple dot com 2006-10-06 05:46 ---
> Apple has no long double library support
This is false. What we don't have is symbol versioning and the `normal' names
refer to an abi different long double, 8 bytes as I recall.
The impact to the fortran frontend should
--- Comment #5 from robert dot wilhelm at gmx dot net 2006-10-06 04:36
---
valgrind output:
==6316== Invalid read of size 4
==6316==at 0x8598C55: compute_all_dependences (tree-data-ref.c:3975)
==6316== Address 0x44C0D20 is 0 bytes inside a block of size 20 free'd
==6316==at 0x
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06
03:53 ---
Andrew,
Could you flesh out the code fragment a bit so it is clearer exactly how
you intended to hook this into darwin.c? Also, if you could just show how
you were going to handle the table of symbols f
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-06 03:51 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 03:08 ---
Paul,
I read the patch, and think that you can commit it.
gfortran certainly can't recover for a mangled module.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
--- Comment #8 from pinskia at physics dot uc dot edu 2006-10-06 03:06
---
Subject: Re: real kind=16 failures on powerpc-darwin
On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote:
> It is unclear to me where you intend to put this function.
> If it is in the gfortra
On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote:
> It is unclear to me where you intend to put this function.
> If it is in the gfortran frontend, I will outright reject
> the patch and lobby to have it removed if anyone applies.
It should be in darwin.c in the back-end. C
--- Comment #7 from kargl at gcc dot gnu dot org 2006-10-06 03:04 ---
(In reply to comment #6)
> The last work on this by Andrew was to propose the code fragment
> below for remapping the functions...
>
> static void
> darwin_patch_builtin (int fncode)
> {
> }
It is unclear to me where
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-06 02:51 ---
Subject: Bug 28349
Author: pinskia
Date: Fri Oct 6 02:51:33 2006
New Revision: 117479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117479
Log:
2006-10-05 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-06 02:48 ---
Fixed also on the 4.1 branch now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06
01:32 ---
Geoff,
This bug is also radar://4759173. I've been asked to...
Please debug and produce a small self-contained (that is, not including
gfortran) testcase showing what goes wrong.
Could you expand in
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-10-06
01:20 ---
The last work on this by Andrew was to propose the code fragment
below for remapping the functions...
static void
darwin_patch_builtin (int fncode)
{
tree fn = built_in_decls[fncode];
const char *newna
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 00:33 ---
I have a patch, but it requires libm to have ldexp{f,l}.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
If one compiles
-
module test
implicit none
type epot_t
integer :: c
type(nonexist),pointer :: l
end type epot_t
end module test
-
no error (and no warning) is shown. If one removes the keyword "pointer", the
error message "Derived type at (1) has not b
--- Comment #5 from gregory dot fruth at aero dot org 2006-10-06 00:04
---
The patch works perfectly in 4.2.0(svn). My application now
builds and runs successfully under gfortran. Thanks, Jakub!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
The following invalid code snippet triggers an ICE on mainline:
==
template void foo()
{
throw A();
struct A {} a;
}
template void foo<0>();
==
bug.cc: In function 'void foo()':
bug.cc:3: error: there are no arguments to 'A' that depend
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-05 23:29
---
I meant Jason's patch for PR 26696, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28346
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-10-05 23:28
---
Because of Jason's patch for PR 28346 the code is now wrongly accepted
on the 4.0 branch. With a slightly different testcase I can still
trigger the ICE, though:
==
bool b;
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-05 22:03 ---
Also happens with gcc svn head.
I was also going to CC dog :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #3 from mark at gcc dot gnu dot org 2006-10-05 22:01 ---
Confirmed with classpath CVS:
$ /usr/local/jamvm/bin/jamvm CDescription
java.lang.NullPointerException
at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:452)
at gnu.xml.transform.TransformerImpl.str
--- Comment #8 from pault at gcc dot gnu dot org 2006-10-05 21:20 ---
Created an attachment (id=12388)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12388&action=view)
A fix for this PR
This checks for the presence of "GFORTRAN module" as the first utterances in
the .mod file. Th
--- Comment #2 from jjohnstn at redhat dot com 2006-10-05 21:12 ---
Created an attachment (id=12387)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12387&action=view)
sample cdtproject file that is used by test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 21:00
---
Fixed on mainline by Lee's patch for PR26938.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jmbnyc at gmail dot com 2006-10-05 20:57 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Thanks for looking at it. Uli Drepper helped me to look at the asm and
conclude (just about one hour ago) that indeed the problem is with
"as". It clea
--- Comment #10 from drow at gcc dot gnu dot org 2006-10-05 20:49 ---
FYI, the testcase does not build with my system g++ 4.1.2; remove the "static"
from 'extern "C" static'. The result does not choke my system's binutils, i.e.
it links successfully.
If I use the provided .s file inste
--- Comment #1 from jjohnstn at redhat dot com 2006-10-05 20:48 ---
Created an attachment (id=12386)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12386&action=view)
Testcase that exhibits problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
The new FC6 eclipse cdt generates a java.lang.NullPointerException everytime it
tries to save the .cdtproject project file. This occurs when changes are made
to a CDT project. For example, adding a new source folder causes the error.
I have isolated the problem to a stand-alone testcase which re
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 ---
*** Bug 29360 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 ---
*** This bug has been marked as a duplicate of 20416 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:36 ---
well a testcase is needed to reproduce the problem in the first place anyways
so yes a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-10-05 20:31
---
*** Bug 29021 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 20:31
---
The bug is actually only a 4.2 regression as it only affected mainline
(sorry for the incorrect info).
Yes, indeed "affected" and not "affects": The bug has been fixed by Mark's
patch for PR 29105.
Since the backt
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-05 19:58
---
Fixed on mainline by Lee's patch for PR27667.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
I have some code which when compiled:
Using gcc 4.0.3(ubuntu 4.0.3-lubuntu5) I have no problems.
Using gcc version 4.1.0 (SUSE Linux) and -O2 or -O3, I have no problems.
HOWEVER, using no compile flags, the code seg faults.
Is it worth generating a small test case and test data file?
--
According to 12.2 ; 5, in the following code:
int count;
class C
{
public:
int i;
C() : i(1) { ++count;}
C(const C &c) : i(c.i) { ++count;}
~C() { --count;}
};
int
f ()
{
static const C &c = C();
return c.i;
}
int
main ()
{
int i = f ();
return count < i;
}
the temporary to whi
--- Comment #25 from stsp at users dot sourceforge dot net 2006-10-05
19:29 ---
> "i"(&var) of course can't work with -fpic,
I tried it on an x86_64 today, and it seems to work.
If I use -m32, then it doesn't. Why?
> it would only work at the expense
> of text relocations, but those ar
--- Comment #9 from jmbnyc at gmail dot com 2006-10-05 18:51 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Fair enough. I did report it to them, but never heard back. Uli
Drepper is going to try to help me get to the right people. He has
also offered to look
--- Comment #8 from jmbnyc at gmail dot com 2006-10-05 18:48 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
One last comment. From the below, I think it is clear that the
compiler is the problem. If I compile with -g then I get the problem,
however if I compil
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 18:48 ---
> If you disagree with that assertion then please tell me.
Yes I do disagree because GCC only produces a .s file which then binutils
assembles and links.
Then again you are using a GCC and binutils that were modified
--- Comment #6 from jmbnyc at gmail dot com 2006-10-05 18:41 ---
This bug might be a duplicate as you suggest but (my fault for opening new
instead of updating original) it is not 'resolved'. On the original post you
said to report to binutils because you suggested the bug was not in the
--- Comment #5 from jmbnyc at gmail dot com 2006-10-05 18:27 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Look, I am not trying to be a jerk, but this new filing has a test
case associated with it (another thing that you asked for). In
addition, I took your
--- Comment #4 from jmbnyc at gmail dot com 2006-10-05 18:23 ---
(In reply to comment #3)
> Didn't I already tell you to post this to binutils?
>
yes you did and I did what you asked. However, I now believe that the problem
is with the compiler. I also came up with a test case that demo
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:19 ---
Didn't I already tell you to post this to binutils?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 ---
*** Bug 29359 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29244
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 ---
*** This bug has been marked as a duplicate of 29244 ***
*** This bug has been marked as a duplicate of 29244 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from jmbnyc at gmail dot com 2006-10-05 18:18 ---
Created an attachment (id=12385)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12385&action=view)
gzip'd tar file with README that shows how to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
I have been encountering the following problem for several weeks. I compile and
create few c++ shared libraries (can happen with just one, so it has nothing to
do with the number). I then attempt to link a program and I get the following
type of segv during the link step:
collect2: ld terminated
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-05 17:54 ---
(In reply to comment #0)
>
> 1. Whether a certain minimum version of GMP/MPFR is required to avoid known
> bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x
--- Comment #9 from patchapp at dberlin dot org 2006-10-05 17:34 ---
Subject: Bug number PR19260
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00255.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from patchapp at dberlin dot org 2006-10-05 17:32 ---
Subject: Bug number PR fortran/28415
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00258.html
--
http://gcc.gnu.org/bu
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org
|dot org
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 17:17 ---
(In reply to comment #2)
> Did you read the bug report? The problem is that the warning is issued
> twice when it should be issued once.
Woops, I am too tried
>
> I'd guess that the issue that that the system hea
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 17:15 ---
(gdb) p debug_tree (function)
SI
size
unit size
align 32 symtab 0 alias set -1
attributes
value
chain
--- Comment #3 from pf dot hugues at gmail dot com 2006-10-05 17:11 ---
I don't contest the warning, but why is it printed 2 times ?!
--
pf dot hugues at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from joseph at codesourcery dot com 2006-10-05 17:10 ---
Subject: Re: Warning issued two times with snprintf
On Thu, 5 Oct 2006, pinskia at gcc dot gnu dot org wrote:
> uint32_t is unsigned int on those targets and this is not a bug.
Did you read the bug report? The p
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 17:07 ---
uint32_t is unsigned int on those targets and this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following snipped of code compiled with -Wall emits two times the same
warning :
#include
#include
#include
int main(void)
{
uint32_t foo = 42;
char bar[] = "bla";
char *buffer = malloc(10);
snprintf(buffer, 10, "%lu %s\n", foo, bar);
free(buffer);
return 0;
}
gcc -Wall
--- Comment #5 from daney at gcc dot gnu dot org 2006-10-05 17:02 ---
Another idea:
In the SIGCHLD signal handler record the pid of the process that exited. Then
look it up in the pidToProcess map. If it belongs to the libgcj runtime, then
do waitpid(pid, ...) on it. Otherwise ignore
--
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 #8 from paulthomas2 at wanadoo dot fr 2006-10-05 16:17 ---
Subject: Re: ICE using intrinsics as arguments
FX
>That bug is fixed by my submitted patch about INTRINSICS
>(http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html).
>
>
>
>
I'll review it tomorrow - I am going to
--- Comment #41 from debian-gcc at lists dot debian dot org 2006-10-05
16:06 ---
the patch was applied in the redhat/gcc-4_1-branch, not in the gcc-4_1-branch.
either the target milestone should be changed or the bug reopened.
Matthias
--
debian-gcc at lists dot debian dot org ch
--- Comment #1 from avi at argo dot co dot il 2006-10-05 16:05 ---
Created an attachment (id=12384)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12384&action=view)
proposed documentation patch
I don't have a coypright assignment, but most of this is copied verbatim from
the inter
the form %c0, as in
asm ( "movl $42, %c0(%1)" : : "i"(offsetof(...)), "r"(...) : "memory" );
is not documented.
--
Summary: inline asm %c0 template form not documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: trivial
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 15:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-10-05 15:47
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 15:44 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-05 15:40
---
This looks related to PR 26926.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Ot
<$rstr7-19b>
--- Comment #41 from dje at gcc dot gnu dot org 2006-10-05 15:18 ---
Subject: Bug 27287
Author: dje
Date: Thu Oct 5 15:18:18 2006
New Revision: 117458
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117458
Log:
Backport from mainline
2006-09-11 Guenter Roeck <[
--- Comment #10 from debian-gcc at lists dot debian dot org 2006-10-05
15:13 ---
are other patches than r111381 (trunk) required for a backport of
long-double-128
to the 4.1 branch?
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-05 14:34
---
Fixed in 4.1 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sum
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-05 14:33
---
Subject: Bug 28980
Author: pinskia
Date: Thu Oct 5 14:33:46 2006
New Revision: 117456
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117456
Log:
2006-10-05 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 14:30 ---
As far as I can tell this has nothing to do with PCH.
>It might be a pch problem, since that ice does not occur if I compile the
> testsuite file without using any library
What do you mean by this?
--
pinskia a
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 ---
*** Bug 29356 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 ---
I think
*** This bug has been marked as a duplicate of 7221 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
In this code:
typedef class
{
public:
void m();
} C;
void
C::m()
{
}
void
f()
{
C c;
c.m();
}
// { dg-final { scan-assembler "(.globl|.global)\[ \t]+[_]+ZN1C1mEv" } }
C is a typedef name which accroding to 7.1.3 is used to denote the unnamed
class. 3.5 ; 4, 3rd item, specifies that this
--
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 #15 from eweddington at cso dot atmel dot com 2006-10-05 12:49
---
(In reply to comment #14)
> GCC_EXEC_PREFIX does not control the search directories for header files.
> Could
> you verify that your target actually compiles before applying the patches?
In the test that I
--
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 #1 from pcarlini at suse dot de 2006-10-05 09:28 ---
Ok, thanks for the report. The issue is the following: tellp() calls
pubseekoff, whereas seekp() calls pubseekpos. Since we are implementing the
resolution of DR 453, which allows pubseekoff to not fail when the stream is
e
The function seekp(pos_type) fails on an empty stream,
even when the target position is the value returned
by tellp.
---
#include
#include
#include
int
main()
{
std::ios::pos_type const
err = std::ios::pos_type( std::ios::off_typ
--- Comment #5 from markus dot schoepflin at comsoft dot de 2006-10-05
08:49 ---
(In reply to comment #3)
> With the attached patch, at least the unmodified boehm-gc 6.7 tested
> successfully.
I stumbled accross this bug when investigating why the boost thread library
tests started to
--- Comment #14 from carlos at codesourcery dot com 2006-10-05 08:33
---
GCC_EXEC_PREFIX does not control the search directories for header files. Could
you verify that your target actually compiles before applying the patches?
Both gcc and cpp need to be taught taught not to search th
--- Comment #3 from roberto dot costa at st dot com 2006-10-05 08:15
---
I tested what happens if the first PHI-OPT pass is moved right before the first
VRP pass in gcc/passes.c
It looks like PHI-OPT should be run both before and after VRP and DOM.
The example reported shows that, when
When I bootstrap gcc with the commands given below I get a testsuite failure
in libstdc++-v3/testsuite/25_algorithms/rotate/1.cc
It might be a pch problem, since that ice does not occur if I compile the
testsuite file without using any library
Michael Cieslinski
Command to build and test gcc:
e
--- Comment #5 from patchapp at dberlin dot org 2006-10-05 08:07 ---
Subject: Bug number PR27588
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00234.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-05 08:05
---
(In reply to comment #6)
> I am glad to see that you are pursuing that one. I nearly bust my head on it
> my notes indicate that I had a fix that broke everything else; no details, so
> not much help I'm afraid.
--- Comment #2 from uros at kss-loka dot si 2006-10-05 07:51 ---
(In reply to comment #0)
> The mode switching for floating point rounding that the i386 backend does
> does not actually place mode switches, but rather the calculation of values
> used for mode switches. Not only does tha
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-05 07:45 ---
(In reply to comment #5)
> FX,
> > When the len in "call sub(len)" is resolved, it is never given its correct
> > return type, which leads to the ICE. I still don't understand why the
> > implicit
> > none is doing th
--- Comment #4 from federico dot carminati at cern dot ch 2006-10-05 07:44
---
Subject: Re: Ambiguous warning with -Weffc++
Thanks for your answer. However, if I just code in the following way
int f(a lhc) {
if (lhs) return TRUE;
else if g() return TRUE;
retur
--- Comment #8 from uros at kss-loka dot si 2006-10-05 07:08 ---
> try -O2 -msse2, you get:
> _Z8todoubledd:
> subl$12, %esp
> fldl24(%esp)
> faddl 16(%esp)
> fstpl (%esp)
> movsd (%esp), %xmm0
> addl$12, %esp
> c
94 matches
Mail list logo
