HP-UX system header files may use version level functioning for some system
calls.
This is a very amusing (what I assume to be) typo in the documentation of
function-level versioning.
Not sure this is the right bug tracker but this is one that I know...
--
Summary: Typo in

--- Comment #1 from dascandy at gmail dot com 2010-09-16 10:23 ---
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
The link where the typo is to be found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688

--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 ---
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end, as the functions are not properly simplified and thus not constant.

--- Comment #5 from janus at gcc dot gnu dot org 2010-09-16 12:10 ---
(In reply to comment #3)
Thanks for the quick fix!
Well, it was *your* fix, so *I* should thank *you* :)
Anyway, I think the patch in comment #2 qualifies as obvious, and has no
regressions, as noted by Dominique.

--- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25
---
Hmm, so do you have any idea where folding should be added for this particular
case?
It always seemed to me that it would make sense to add verifier that all
statements are folded (locally, not by looking at SSA

--- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 ---
Subject: Re: Missed devirtualization
I'm lost in this PR - for what testcase what statement needs folding
(and what pending patches do I need to apply to see that)?
PR is tracking missed optimization in the testcase in

--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-16 13:09 ---
MAXLOC and MINLOC are also missing (see pr25104).
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end, as the

--- Comment #12 from bernds at gcc dot gnu dot org 2010-09-16 13:50 ---
(In reply to comment #6)
So stage1 chooses adds but stage2 and stage3 choose lsls for of the lower
half of a long long. Since the behaviour of a stageN xgcc depends on both the
gcc source code and the compiler

--- Comment #14 from jakub at gcc dot gnu dot org 2010-09-16 13:54 ---
The reason why cfgexpand does increase the alignment is that it believes that
the base slot will be at least PREFERRED_STACK_BOUNDARY bytes aligned, which is
true on all targets but i?86/x86-64, which apparently

hi,
on the recent 4.5 branch i have a problems with dwarf4 and pretty printers.
here's steps to reproduce:
$ make
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++
t.cpp -gdwarf-3 -g2 -o t-dw3
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++

--- Comment #17 from jakub at gcc dot gnu dot org 2010-09-16 14:08 ---
That's true. But many expanders can make use of DECL_ALIGN information, e.g.
to choose faster code. If cfgexpand keeps doing what it does now, namely
bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY

--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-16 14:13
---
(In reply to comment #16)
(In reply to comment #13)
With that patch the assignment generated from memcpy doesn't need more
that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
decl to 128 so

--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-09-16 16:54
---
(In reply to comment #12)
I think it's likely there really is a miscompilation. I've not been able to
get very far trying to set up a native compiler to run on qemu, so it would
help if you could try to

--- Comment #6 from ktietz at gcc dot gnu dot org 2010-09-16 16:56 ---
(In reply to comment #4)
(In reply to comment #2)
http://gcc.gnu.org/bugs/#need
Since this is a bug in the preprocessor it is hard to get a preprocessed
source
that causes a bug.
That's true. Interesting

After upgrading to gcc 4.5.0 from 3.3.4, some of my floating point code fails.
Searched for and could not find a matching bug. It boils down to this very
simple example:
#include stdio.h
#define MY_PI 3.14159265358979323846
int main()
{
double z = MY_PI;
puts(z == MY_PI ? == : !=);

--- Comment #7 from manu at gcc dot gnu dot org 2010-09-16 17:04 ---
(In reply to comment #4)
(In reply to comment #2)
http://gcc.gnu.org/bugs/#need
Since this is a bug in the preprocessor it is hard to get a preprocessed
source
that causes a bug.
I think this is covered by:

--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-16 17:08
---
As an even more general rule, remember to always specify your target: in this
case, for example, I can't reproduce at all the behavior on x86_64 -m64, only
with -m32.
--

--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-16 17:13 ---
i?86 is a FLT_EVAL_METHOD 2 target, so for strict C compliance all floating
operations and constants are supposed to be evaluated in the precision
of long double. The assignment of the constant to a double var or

--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-16 17:36 ---
Hmm, the problem is that foo is virtual self recursive function.
We inline it and then indirect inlining decide that it can devirtualize the
self recursive call since it knows the operand has proper type.
At that

--- Comment #6 from ian at macky dot net 2010-09-16 17:44 ---
Subject: Re: Floating point comparison failure
Thanks everyone. I usually do fuzzy floating-point comparison, except in
certain special circumstances. I will switch to using double constants;
I'm trying for a code that is

--- Comment #11 from dherring at tentpost dot com 2010-09-16 18:54 ---
FWIW, the example given in the C++ draft spec, section 9.5, fails to compile in
g++, even under version 4.5 with the -std=c++0x flag. (This example has been
there for a few years.)
Coupled with requirements such as

Since the test objc/execute/exceptions/throw-nil.m has been introduced at
revision 164024, it has failed on *-apple-darwin* with -m32, see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00816.html
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00835.html
--
Summary: FAIL:

Hi,
(i first reported this to mingw32-w64's bug tracker:
http://sourceforge.net/tracker/?func=detailaid=3067541group_id=202880atid=983354
and was forwarded here)
The attached fortran program aborts() (a host associated variable
changes value from host to hostee without asking) using
gfortran -O1

--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 21:57 ---
Caused by my http://gcc.gnu.org/viewcvs?root=gccview=revrev=163555
change, so will look into it tomorrow.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21560action=view
doesn't break it, only the version that tries

--- Comment #8 from t7 at gmail dot com 2010-09-16 21:58 ---
(In reply to comment #4)
(In reply to comment #2)
http://gcc.gnu.org/bugs/#need
Since this is a bug in the preprocessor it is hard to get a preprocessed
source
that causes a bug.
This is very odd, because I

--- Comment #49 from LpSolit at netscape dot net 2010-09-16 22:51 ---
(In reply to comment #48)
The current bugzilla has
extra separating lines with the column names. The new installation does not.
Yeah, it is so by design. Not something I'm going to reimplement.
Note that we

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-16 23:55 ---
C preprocessor is not a generic preprocessor. The continuation character is
removed so the correct line number is used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed

--- Comment #2 from John dot Tytgat at aaug dot net 2010-09-17 00:04
---
I don't understand why the continuation character should be removed. For the C
parser that character is not special (only for the C preprocessor it is), nor
it confuses its line number accountancy. Or am I

--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 00:06 ---
(In reply to comment #2)
I don't understand why the continuation character should be removed. For the C
parser that character is not special (only for the C preprocessor it is), nor
it confuses its line number