--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-18 06:44 ---
You have the wrong inline-asm:
sqrtsd %0, %1
That is wrong because with ATT style x86 asm, the src is first and the dest is
second.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-18 06:45 ---
Oh I forgot to mention, sqrt will use sqrtsd and will be inlined so you don't
need to use inline-asm yourself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-04-18 06:48
---
*** Bug 43780 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 2010-04-18 06:48 ---
Yes your experience is with 4.5.0 but there is no reason to file a new bug
about a known issue. I don't know if the C++ defect report 743 have been voted
on yet or not (if not then PR 6709 is suspended because we
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-18 06:49 ---
How do we know if this is valid code or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43775
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-04-18 07:15
---
Present on x86 and x86-64/Linux, as well as on the 4.4 branch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #5 from pluto at agmk dot net 2010-04-18 08:35 ---
(In reply to comment #4)
How do we know if this is valid code or not?
comeau online testdriver accept this code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43775
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-18 11:09 ---
It turns out this problem is not specific to the OOP stuff on fortran-dev, but
instead is due to an underlying problem with PROCEDURE statements (which
affects procedure pointers as well as PPCs), demonstrated by this
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-18 11:48 ---
Marked as a 4.5/4.6 regression.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from irar at gcc dot gnu dot org 2010-04-18 12:20 ---
Subject: Bug 43771
Author: irar
Date: Sun Apr 18 12:20:34 2010
New Revision: 158484
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158484
Log:
PR tree-optimization/43771
* tree-vect-slp.c
--- Comment #15 from faisalv at yahoo dot com 2010-04-18 12:56 ---
I had (In reply to comment #14)
*** Bug 43780 has been marked as a duplicate of this bug. ***
The DR 743 has been voted into FCD (CD2) - shouldn't this be unsuspended?
thanks!
--
--- Comment #26 from janus at gcc dot gnu dot org 2010-04-18 13:13 ---
(In reply to comment #25)
A provisional fix for this PR
Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR
--- Comment #3 from pluto at agmk dot net 2010-04-18 13:34 ---
Created an attachment (id=20408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20408action=view)
some tree dumps from 4.3/4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--- Comment #4 from pluto at agmk dot net 2010-04-18 13:44 ---
during analysis the boost::thread::start_thread() function which causes
invalid writes detected by valgrind i've noticed that gcc-4.5 generates
bigger and more complex code of this function with few more lock'ed opcodes.
--- Comment #27 from pault at gcc dot gnu dot org 2010-04-18 13:50 ---
(In reply to comment #26)
(In reply to comment #25)
A provisional fix for this PR
Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
cleanly on x86_64-unknown-linux-gnu, and the
--- Comment #28 from dominiq at lps dot ens dot fr 2010-04-18 13:55 ---
I am still getting the message:
Me too with a clean fortran-dev r158481.
Note that the patch in comment #25 fixes it without regression for the test
suite and my own tests.
--
--- Comment #20 from jason at gcc dot gnu dot org 2010-04-18 14:42 ---
(In reply to comment #19)
Well, the patch is mostly done, it reduces the output from 11 to 1 lines and
it
neatly points out where is the recursive instantiation. So I hope you may
reconsider, unless you think
--- Comment #8 from jason at gcc dot gnu dot org 2010-04-18 15:04 ---
*** Bug 43775 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2010-04-18 15:04 ---
Dup of 43608.
*** This bug has been marked as a duplicate of 43608 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 15:04 ---
Confirmed for gcc version 4.4.2, but this pr seems to be fixed for 4.5 (at
least since revision 154654) and trunk. Unless someone is able to point when it
has been fixed and want to backport the fix to 4.4, this pr
--- Comment #7 from jason at gcc dot gnu dot org 2010-04-18 15:08 ---
That is, the problem is that template_arity_impl calls
arity_helper(type_wrapperF,...) in a way that uses arg-dependent lookup,
which means looking up arity_helper within F, which means instantiating F,
which in this
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-18 15:17 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00585.html
and:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00131.html
--
iains at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-18 15:20 ---
It is caused by revision 158380:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00486.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 15:28 ---
Both the bogus error and the ICE (also with std=f95) are still there. The PR
should be marked NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-18 15:31
---
Re-confirmed.
We have no bounds checking code in fortran/io.c nor in the I/O library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-18 15:37 ---
Confirmed. Note that between 4.4 and 4.5 the error from the second test of
comment #0 has changed from:
MODULE PROCEDURE myplus
1
Error: Intrinsic operator interface at (1) must be a
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 15:42 ---
Confirmed with trunk, fixed with fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-18 15:49 ---
Still there on trunk - should be marked as NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
);
}
$ gcc test.c ./a.out
ab=9.64506e-159
xy=9.64506e-159
$ gcc -O test.c ./a.out
ab=1.23457e-158
xy=9.64506e-159
$ gcc --version | head -1
gcc (GCC) 4.5.1 20100418 (prerelease)
The correct value is 1.23457e-158:
$ echo 1.1*1.111 | bc
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-04-18 15:56
---
Subject: Bug 43769
Author: ebotcazou
Date: Sun Apr 18 15:56:32 2010
New Revision: 158490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158490
Log:
PR tree-optimization/43769
* tree-sra.c
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 15:56 ---
I cannot reproduce the error at
http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html neither with trunk nor with
fortran-dev. Could this PR be more explicit about the problem?
--
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-18 15:57
---
Subject: Bug 43769
Author: ebotcazou
Date: Sun Apr 18 15:56:56 2010
New Revision: 158491
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158491
Log:
PR tree-optimization/43769
* tree-sra.c
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-04-18 16:00
---
On all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from manu at gcc dot gnu dot org 2010-04-18 16:16 ---
(In reply to comment #20)
(In reply to comment #19)
Well, the patch is mostly done, it reduces the output from 11 to 1 lines
and it
neatly points out where is the recursive instantiation. So I hope you may
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 16:18 ---
What about pr42274? Is it a duplicate or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-18 16:21 ---
Could this PR be more explicit about the problem?
No it cannot; as written: For SAME_TYPE_AS and EXTENDS_TYPE_OF one should add a
compile-time simplification to simplify.c.
Currently, only the run-time version is
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-18 16:24 ---
The tests in comments #0 and #1 give a Segmentation fault with trunk or
fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600
Tested revisions:
r158486 - fail
r158225 - OK
4.5 r158131 - OK
4.4 r158133 - OK
Compiler output:
$ /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/gcc -Os
-fkeep-inline-functions testcase.c ./a.out
Aborted
--
Summary: [4.6 Regression] -Os -fkeep-inline-functions causes
--- Comment #1 from zsojka at seznam dot cz 2010-04-18 16:26 ---
Created an attachment (id=20409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20409action=view)
reduced testcase (from gcc.c-torture/execute/builtins/pr22237.c)
Command line:
gcc -Os -fkeep-inline-functions
in GCC 4.4.2, the following compiles, but in GCC 4.5.0, it does not:
#include iostream
#include math.h
int main(int argc, char** argv)
{
uint32_t x = 1;
uint32_t y = 2;
std::make_pairuint32_t,uint32_t(x, y);
return 0;
}
In GCC4.5.0 the error is:
test.cpp: In function int
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-18 16:42 ---
(In reply to comment #5)
What about pr42274? Is it a duplicate or not?
I don't think so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
--- Comment #1 from navin dot kumar at gmail dot com 2010-04-18 16:43
---
Arguments: g++ -Wall -std=c++0x
--
navin dot kumar at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 16:44 ---
Confirmed. Related to pr24978. Should probably be marked as blocking pr31392
and pr33056.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41922
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-18 16:47 ---
Currently, only the run-time version is implemented.
So could the pr marked as NEW?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580
--- Comment #22 from jason at gcc dot gnu dot org 2010-04-18 17:09 ---
(In reply to comment #21)
Is that ok or you would prefer the following?
/home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
maximum of 1024 (use -ftemplate-depth= to increase the maximum)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #29 from pault at gcc dot gnu dot org 2010-04-18 17:24 ---
Subject: Bug 42353
Author: pault
Date: Sun Apr 18 17:24:35 2010
New Revision: 158492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158492
Log:
2010-04-18 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #30 from pault at gcc dot gnu dot org 2010-04-18 17:25 ---
Subject: Bug 42353
Author: pault
Date: Sun Apr 18 17:25:41 2010
New Revision: 158493
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158493
Log:
2010-04-18 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #31 from pault at gcc dot gnu dot org 2010-04-18 17:29 ---
Fixed on fortran-dev.
Thanks for the report, Harald.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
--- Comment #32 from pault at gcc dot gnu dot org 2010-04-18 17:29 ---
Hmmm better mark it as fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2010-04-18 17:33 ---
Created an attachment (id=20410)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20410action=view)
Fix for the problem
This needs to be regtested but I believe it to be bombproof.
However, I should attempt to
--- Comment #23 from manu at gcc dot gnu dot org 2010-04-18 17:40 ---
Oh, that is not very difficult to do. But notice that you will still get the
last line:
/home/manuel/src/pr9335.C:4:17: instantiated from here
so we go from 11 to 3 lines. I think that is ok.
So go ahead, commit
- was trying to compile bc on gentoo
- lto1 process didnt finish after over an hour
- i cat as many c-files as possible into my.c and used resulting my.i
- different flags result in different reaction.
a)
x86_64-pc-linux-gnu-gcc -c -o my.o my.i -flto
x86_64-pc-linux-gnu-gcc -c -o numeric.o
The following code compiles runs fine on GCC 4.4.2, it compiles segfaults
on GCC 4.5.0, arguments: -std=c++0x -g -fno-inline
#include iostream
#include math.h
#include type_traits
class empty_t {};
static_assert(std::is_emptyempty_t::value, sanity check);
int main(int argc, char** argv)
{
--- Comment #1 from baronchaos at ymail dot com 2010-04-18 17:54 ---
Created an attachment (id=20411)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20411action=view)
my.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43786
--- Comment #2 from baronchaos at ymail dot com 2010-04-18 17:55 ---
Created an attachment (id=20412)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20412action=view)
numeric.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43786
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-18 18:13 ---
I'm not sure the testcase is valid. We copy a single byte at 0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43784
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-18 18:22 ---
This needs a testcase. The libdecnumber code is a mess (and I can't find
an implementation for bid128_ext_fma()).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-18 18:24 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-18 18:30 ---
(In reply to comment #4)
during analysis the boost::thread::start_thread() function which causes
invalid writes detected by valgrind i've noticed that gcc-4.5 generates
bigger and more complex code of this
--- Comment #8 from pault at gcc dot gnu dot org 2010-04-18 18:30 ---
(In reply to comment #6)
(In reply to comment #5)
What about pr42274? Is it a duplicate or not?
I don't think so.
My patch fixes pr42274 comment #9 but not the main part of it. Janus is quite
right that the
--- Comment #2 from navin dot kumar at gmail dot com 2010-04-18 18:31
---
Only GCC4.5.0 is emitting a copy-constructor that copies 1 byte of data
(probably because sizeof(empty_t) == 1 according to the C++ ABI). The
copy-constructor *should* be a noop, and indeed GCC4.4.2 issues a
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-18 18:32 ---
warnings should be issued when a
deprecated entity is used and not when that deprecation is declared.
it is not that deprecation that is declared in your examples but a
deprecation that is declared.
--
--- Comment #3 from navin dot kumar at gmail dot com 2010-04-18 18:33
---
At the very least, you'd agree that it's a performance bug to be copying bytes
from memory when the class is empty. At the severe use-case, it breaks
existing code.
--
--- Comment #2 from roman at binarylife dot net 2010-04-18 18:34 ---
(In reply to comment #1)
This needs a testcase. The libdecnumber code is a mess (and I can't find
an implementation for bid128_ext_fma()).
bid128_ext_fma() is in libgcc/config/libbid/bid128_fma.c
--
--- Comment #6 from pluto at agmk dot net 2010-04-18 19:01 ---
Created an attachment (id=20413)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20413action=view)
testcase.#0.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #2 from bangerth at gmail dot com 2010-04-18 19:02 ---
Confirmed. Including utility doesn't help.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-18 19:03 ---
(In reply to comment #2)
warnings should be issued when a
deprecated entity is used and not when that deprecation is declared.
it is not that deprecation that is declared in your examples but a
deprecation that
--- Comment #7 from pluto at agmk dot net 2010-04-18 19:04 ---
(In reply to comment #5)
(In reply to comment #4)
during analysis the boost::thread::start_thread() function which causes
invalid writes detected by valgrind i've noticed that gcc-4.5 generates
bigger and more complex
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-18 20:14 ---
Loop invariant motion breaks this.
bb 6:
- g_313.0_6 = pretmp.4_9;
- *g_313.0_6 = 0B;
bb 8:
# m_21 = PHI 0(11), m_3(D)(2)
+ g_313.8_12 = *g_313.0_6;
+ g_313.0_6 = pretmp.4_9;
goto bb 5;
we insert
--- Comment #8 from pluto at agmk dot net 2010-04-18 20:28 ---
debbuging 4.3 vs 4.5 start_thread() shows different results:
4.3:
182x void thread::start_thread()
183x {
184x thread_info-self=thread_info;
185tint const res =
Command line:
g++ -fwhopr -r -nostdlib -ftoplevel-reorder 20081204-1_1.C
--- 20081204-1_1.C ---
struct Foo { virtual ~Foo(); };
struct Bar:public Foo { Bar() { } };
void Func() { new Bar(); }
--
g++.dg/lto/20081204-1_1.C
Tested revisions:
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-18 20:32 ---
(In reply to comment #8)
debbuging 4.3 vs 4.5 start_thread() shows different results:
4.3:
182x void thread::start_thread()
183x {
184x thread_info-self=thread_info;
185tint const
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-18 20:33
---
Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394
applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--- Comment #2 from zsojka at seznam dot cz 2010-04-18 22:14 ---
-floop-block -fstrict-aliasing also makes
gfortran.fortran-torture/execute/forall_1.f90 to timeout at -O[123s]
--
zsojka at seznam dot cz changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-18 22:29 ---
This is invalid because you access a null pointer
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from jason at gcc dot gnu dot org 2010-04-18 22:35 ---
We didn't get the error cascade in 2.95; we did in 3.4. I don't have any
releases in between handy.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from navin dot kumar at gmail dot com 2010-04-19 00:22
---
Andrew,
What about the performance bug?
empty_t x; // line1
empty_t y = x; // line2
Line2 should not result in copying memory for empty classes. And that was the
old behavior pre-4.5.0
--
--- Comment #6 from navin dot kumar at gmail dot com 2010-04-19 00:22
---
Andrew,
What about the performance bug?
empty_t x; // line1
empty_t y = x; // line2
Line2 should not result in copying memory for empty classes. And that was the
old behavior pre-4.5.0
--
navin dot kumar
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-19 00:30 ---
Well at least change the summary to say what the issue is about. There is
always a copy constructor for classes including POD in C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-19 01:06 ---
With C++0x we have:
templateclass _T1, class _T2
inline pairtypename __decay_and_strip_T1::__type,
typename __decay_and_strip_T2::__type
make_pair(_T1 __x, _T2 __y)
Which is correct that lvalues cannot
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-19 01:08 ---
Just a littke more: alignof (struct _x_t) is 4 therefor so is the alignof(_x_t
::data).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43774
--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-19 02:06
---
Andrew, the situation isn't *that* simple as you seem to believe, because
make_pair is *templatized*, thus in general it works perfectly well with
lvalues. For example, this works:
--- Comment #5 from paolo dot carlini at oracle dot com 2010-04-19 02:08
---
Of course by standard I meant the current working draft, the FCD. We are in
the realm of the still *highly* experimental C++0x mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-19 02:13
---
In any case, Andrew is right (if I understand correctly the gist of his
message), that a conforming implementation of the FCD can *only* fail to
compile the provided snippet *when* the types are explicitely
--- Comment #7 from dirtysalt1987 at gmail dot com 2010-04-19 02:25 ---
(In reply to comment #6)
Just a littke more: alignof (struct _x_t) is 4 therefor so is the alignof(_x_t
::data).
3ku very much,with your explanation I think I can understand it..3ku very much.
--
Gcc already contains useful warnings for almost certainly incorrect code. I
propose adding a warning when pointer arithmetic is used inside sizeof, that
degrades an array to a pointer.
char a[]=blabla;
sizeof(a-1);
If the intention was _actually_ to get sizeof(char), it is a really awful way
to
--- Comment #7 from bangerth at gmail dot com 2010-04-19 02:59 ---
I think the point Andrew wanted to make is that it's a regression
*from the user perspective*. I had a half dozen places in our code
that now no longer compile in c++0x mode. Apparently others do too.
If the standard is
--- Comment #3 from roman at binarylife dot net 2010-04-19 04:25 ---
Starting from r150519 gcc compiles its own internal libbid wrong.
With the previous revision of gcc, the output of the above test.c is correct:
$ gcc -O test.c ./a.out
ab=1.23457e-158
xy=1.23457e-158
--
/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --enable-language=c,c++
--disable-nls
Thread model: posix
gcc version 4.6.0 20100418 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-o
93 matches
Mail list logo
