http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53495
--- Comment #4 from Jakub Jelinek 2012-08-14
07:43:15 UTC ---
Author: jakub
Date: Tue Aug 14 07:43:09 2012
New Revision: 190376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190376
Log:
PR middle-end/53411
PR rtl-optimization/534
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411
--- Comment #8 from Jakub Jelinek 2012-08-14
07:43:14 UTC ---
Author: jakub
Date: Tue Aug 14 07:43:09 2012
New Revision: 190376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190376
Log:
PR middle-end/53411
PR rtl-optimization/534
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53495
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54248
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54248
--- Comment #1 from Jonathan Wakely 2012-08-14
08:01:44 UTC ---
> Should this comment really be talking about boost?
N.B. I don't see any actual harm in talking about Boost, seeing as the concept
checking code came straight from there. We don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Bug #: 54249
Summary: [C++11] No ::nullptr_t in header
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Daniel Krügler changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Daniel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233
--- Comment #3 from Richard Guenther 2012-08-14
08:23:16 UTC ---
Multiple iterations may still paper over missed-optimization bugs in passes.
Using LTO to drive the iteration makes more sense (well, if iterating makes
any sense ...), as it will c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54138
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234
--- Comment #4 from Tobias Burnus 2012-08-14
09:35:02 UTC ---
Forgot to mention in the initial report that this issue came up at c.l.f, cf.
http://www.rhinocerus.net/forum/lang-fortran/711699-quality-fortran-code-posted-rosettacode.html
But the i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #3 from Daniel Krügler
2012-08-14 09:52:30 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > "Every C header, each of which has a name of the form name.h, behaves as if
> > each name placed in the standard library namesp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234
--- Comment #5 from Tobias Burnus 2012-08-14
10:22:11 UTC ---
Author: burnus
Date: Tue Aug 14 10:22:06 2012
New Revision: 190378
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190378
Log:
2012-08-14 Tobias Burnus
PR fortran/54
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881
--- Comment #8 from Tobias Burnus 2012-08-14
10:26:16 UTC ---
Author: burnus
Date: Tue Aug 14 10:26:11 2012
New Revision: 190379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190379
Log:
2012-08-14 Tobias Burnus
PR fortran/40
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #4 from Marc Glisse 2012-08-14 10:35:56
UTC ---
(In reply to comment #3)
> I don't want to start a lengthy discussion here about the C++ Standard Library
> specification, but it must be clear that removing above paragraph would have
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #5 from Paolo Carlini 2012-08-14
10:38:45 UTC ---
It's true however, that, as I mentioned already somewhere, in general our
implementation doesn't have control over the underlying *.h headers. Thus, it
seems mildly inconsistent to add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #6 from Marc Glisse 2012-08-14 10:48:48
UTC ---
(In reply to comment #5)
> It's true however, that, as I mentioned already somewhere, in general our
> implementation doesn't have control over the underlying *.h headers.
Although it d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #7 from Jonathan Wakely 2012-08-14
10:50:40 UTC ---
(In reply to comment #5)
> seems mildly inconsistent to add things only to the *few* *.h headers over
> which we do have control.
Better to be mildly inconsistent than ship a knowin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #8 from Paolo Carlini 2012-08-14
10:52:38 UTC ---
Sure, grab the low-hanging fruits, like this one ;) But while we do that we
should also do an audit and establish what is missing from headers which we do
not control and at least talk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
--- Comment #6 from Mathias Gaunard 2012-08-14
10:53:07 UTC ---
I've had this happen with 4.7.1 without any may_alias involved.
Why is this bug still marked 'waiting'? Are more testcases necessary?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #9 from Paolo Carlini 2012-08-14
10:56:02 UTC ---
I must also add that frankly personally I don't consider these issues so
serious: IMHO a new C++ project should immediately use the c* headers. I see
these issues mostly about legacy c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
Paolo Carlini changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Paolo Carlini 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #10 from Jonathan Wakely 2012-08-14
10:59:41 UTC ---
N.B. see also http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00375.html and
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00192.html and the stdalign.h part
of http://gcc.gnu.org/ml/gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #11 from Daniel Krügler
2012-08-14 11:01:47 UTC ---
(In reply to comment #9)
> I must also add that frankly personally I don't consider these issues so
> serious: IMHO a new C++ project should immediately use the c* headers. I see
> t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
--- Comment #8 from Marc Glisse 2012-08-14 11:03:31
UTC ---
Although if you have a testcase without may_alias, you should attach it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
Daniel Krügler changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #9 from William J. Schmidt 2012-08-14
11:44:35 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Something else is broken, too, as the optab handlers for cmov on powerpc64
> > appear to have gone missing. I'll get one o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #10 from Richard Guenther 2012-08-14
11:47:01 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Something else is broken, too, as the optab handlers for cmov on powerpc64
> > > appear to ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54250
Bug #: 54250
Summary: Segmentation fault when decltype of a struct field is
used in nested lambdas
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54250
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54245
--- Comment #3 from William J. Schmidt 2012-08-14
12:34:24 UTC ---
I'm putting together a for-now patch that disables the optimization when a
widening cast produces the stride. In the long run this can be re-enabled so
long as we can retain the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #44 from Richard Guenther 2012-08-14
12:38:41 UTC ---
Author: rguenth
Date: Tue Aug 14 12:38:32 2012
New Revision: 190382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190382
Log:
2012-08-14 Richard Guenther
PR tree-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54251
Bug #: 54251
Summary: FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++[98,11]
scan-assembler-times debug_types 2
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #15 from Gary Funck 2012-08-14 13:17:26
UTC ---
(In reply to comment #14)
> Yeah, IMHO it should have added
> %{!mpower*: %(asm_default)}} \
> line instead of
> %{!mpowerpc*: -mcom}} \
That change fixed the build failure on a POW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54201
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #45 from Marc Glisse 2012-08-14
13:20:55 UTC ---
(In reply to comment #11)
> > Marc, do you know where the use of the
> > flatten attribute comes from in your code?
> Comes from the Eigen library, I'll talk to them about it and see if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54251
--- Comment #1 from Jack Howarth 2012-08-14
13:25:47 UTC ---
Appears these failures have been present since the addition of the
g++.dg/debug/dwarf2/nested-4.C test case in...
r189676 | jason | 2012-07-19 16:01:56 -0400 (Thu, 19 Jul 2012) | 3 lin
h-gmp-version=5.0.5 --with-gcc-version=4.8.0 --with-gdb-version=7.3.x
--disable-bootstrap --disable-libquadmath --disable-plugin --with-arch=armv5te
--program-transform-name='s&^&arm-linux-androideabi-&'
Thread model: posix
gcc version 4.8.0 20120814 (experimental) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #7 from Andrew Macleod 2012-08-14
13:45:50 UTC ---
If NULL is passed as the second parameter, *both* functions are per type. They
only become per-object based when an object is actually passed as the second
parameter. libstdc++ cou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
Bug #: 54253
Summary: [C++11] constexpr constructor crashes with polymorphic
base classes
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254
Bug #: 54254
Summary: libiberty: demangling is broken since r167781
(http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=1677
81)
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
--- Comment #2 from Paolo Carlini 2012-08-14
14:34:00 UTC ---
It would be nice to have 2 slightly more complex testcases too, like const3.cc
and one for your third case. Care to add something? Thanks in advance.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54201
--- Comment #8 from Richard Guenther 2012-08-14
14:37:42 UTC ---
Does not help the 2nd testcase btw, because we do not CSE the loads:
movdqa .LC0, %xmm3
movdqa .LC0, %xmm2
pand%xmm3, %xmm0
pcmpeqb %xmm2, %xm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
--- Comment #3 from mrks at koios dot de 2012-08-14 14:45:31 UTC ---
Created attachment 28012
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28012
first base polymorphic
multiple inheritance, first base class is polymorphic
-> complains about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
--- Comment #4 from Paolo Carlini 2012-08-14
14:48:45 UTC ---
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
mrks at koios dot de changed:
What|Removed |Added
Attachment #28012|application/octet-stream|text/plain
mime type|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253
mrks at koios dot de changed:
What|Removed |Added
Attachment #28012|application/octet-stream|text/plain
mime type|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54255
Bug #: 54255
Summary: FAIL: gcc.target/i386/asm-dialect-1.c (test for excess
errors) fails on x86_64/i686 darwin
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54212
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54256
Bug #: 54256
Summary: IPA-SRA debug info issues
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54255
--- Comment #1 from Jack Howarth 2012-08-14
15:00:04 UTC ---
Issue appeared with the introduction of the new test case at...
r189854 | rth | 2012-07-25 12:01:17 -0400 (Wed, 25 Jul 2012) | 8 lines
Split out do_assembler_dialects.
* fina
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257
Bug #: 54257
Summary: gcc.target/i386/pr53249.c failure at -m64 on
x86_64-apple-darwin
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257
--- Comment #1 from H.J. Lu 2012-08-14 15:57:34
UTC ---
The problem is -m64 overrides -mx32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54053
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54258
Bug #: 54258
Summary: Wrong size of a named union.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259
Bug #: 54259
Summary: Regression in move construction for std::pair
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259
--- Comment #1 from oleg at smolsky dot net 2012-08-14 16:27:35 UTC ---
Created attachment 28015
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28015
minimal expressive test case
Compiles correctly in g++ 4.6.3, 4.8/Trunk and VS2010/sp1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54258
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47586
--- Comment #1 from Mikael Morin 2012-08-14
16:46:07 UTC ---
Author: mikael
Date: Tue Aug 14 16:45:55 2012
New Revision: 190394
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190394
Log:
fortran/
PR fortran/47586
* trans-expr.c (e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259
Jonathan Wakely changed:
What|Removed |Added
Target|debian on amd64 |
Host|debian on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47586
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54260
Bug #: 54260
Summary: GCC 4.7.1 fails to build.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #17 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54260
--- Comment #1 from Andrew Pinski 2012-08-14
17:14:09 UTC ---
Can you attach x86_64-unknown-linux-gnu/libgcc/config.log ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54260
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #19 from Matt Hargett 2012-08-14 17:25:40 UTC
---
Does this mean there will be a fix for this regression committed for 4.7.2? If
there's a patch I can test ahead of time, please let me know. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233
--- Comment #4 from Matt Hargett 2012-08-14 17:43:30 UTC
---
I agree it's more appropriate in LTO, but can still provide measurable benefit
for template-heavy C++ applications where lots of implementation bodies are in
header files by necessity.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #31 from Oleg Endo 2012-08-14
17:54:35 UTC ---
Author: olegendo
Date: Tue Aug 14 17:54:28 2012
New Revision: 190395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190395
Log:
PR target/50751
* config/sh/constraints.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52933
--- Comment #2 from Oleg Endo 2012-08-14 17:59:11
UTC ---
Author: olegendo
Date: Tue Aug 14 17:59:03 2012
New Revision: 190396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190396
Log:
PR target/52933
* config/sh/sh.md (cmp_div0s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54037
H.J. Lu changed:
What|Removed |Added
Attachment #27836|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53518
--- Comment #4 from gee 2012-08-14 18:49:53 UTC ---
cppcheck fails to compile because of this bug.
cli/cmdlineparser.o: In function `~basic_istream':
/usr/include/c++/4.8.0/istream:106: undefined reference to `construction vtable
for std::basic_i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54261
Bug #: 54261
Summary: reverse sync/atomic operators when only
sync_compare_and_swap_optab libfuncs implemented
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52239
--- Comment #3 from Frédéric Buclin 2012-08-14
18:58:00 UTC ---
Another reason why I cannot simply download the 4.2 tarball and install it till
bzr is available: Bugzilla 4.2 requires MySQL 5.0.15, but the version available
is 4.1.22, a way too o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632
--- Comment #10 from Frédéric Buclin 2012-08-14
19:01:12 UTC ---
(In reply to comment #9)
> I don't know if anything was changed, but the speed seems OK now
It seems very slow to me. It took a while to send 3 bugmails only.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #11 from William J. Schmidt
2012-08-14 19:48:40 UTC ---
Well. It turns out that cmov_optab was a red herring. Apparently no ports are
generating this, and actually movcc_optab is what's being used instead. My
guess is that cmov_opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54261
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54262
Bug #: 54262
Summary: LOC shouldn't use copy-in/copy-out
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259
--- Comment #3 from oleg at smolsky dot net 2012-08-14 21:09:03 UTC ---
Thank you Jonathan. The workaround works on all three compilers and I can move
forward.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54263
Bug #: 54263
Summary: C_F_POINTER wrongly accepts a SHAPE= for scalar
pointers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54243
--- Comment #3 from janus at gcc dot gnu.org 2012-08-14 21:27:25 UTC ---
The patch in comment 2 regresses on typebound_operator_11.f90, which can be
fixed by the following:
Index: gcc/fortran/resolve.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
Steve Ellcey changed:
What|Removed |Added
CC||sje at gcc dot gnu.org
--- Comment #10 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54264
Bug #: 54264
Summary: internal compiler error on sample program from the C++
standard
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54264
--- Comment #1 from meng at g dot clemson.edu 2012-08-14 21:44:31 UTC ---
here is my command line:
~/gcc/4.7.0/bin/c++ -std=c++11 -Wall -O3 t1.cc
and its output:
t1.cc: In substitution of ‘template decltype (i(h())) f(T) [with T
= int]’:
t1.cc:8:5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #8 from Hans-Peter Nilsson 2012-08-14
22:16:00 UTC ---
(In reply to comment #7)
> ,,,
> In fact, the compiler implements __atomic_is_lock_free() by (paraphrased):
ITYM *will* implement. :) Right now we still have PR54004.
> So if a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #9 from Andrew Macleod 2012-08-14
22:44:53 UTC ---
Actually, that's the way __atomic_is_lock_free() has always been implemented
(even in 4.7).
The change is simply wrong and needs to be reverted. __atomic_is_lock_free()
*must* ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #31 from Chip Salzenberg 2012-08-14
22:46:12 UTC ---
I've tested the attached patch, and I find that it succeeds in preventing the
current missed optimizations in structs passed by value from affecting 128-bit
structs.
IOW: Works for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
--- Comment #17 from Chip Salzenberg 2012-08-14
22:50:01 UTC ---
The patch posted in Bug 20020 prevents missed optimization for 128-bit
structures on x86_64. So this bug does seem to be all about the BLKmode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #18 from Segher Boessenkool 2012-08-14
22:54:35 UTC ---
Right, but
%{!mpowerpc*: %(asm_default)}} \
instead, since the -mpower option is no more.
I didn't even pick the wrong condition branch there: the original
code does not do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54265
Bug #: 54265
Summary: Documentation of "preferred attribute syntax for
Types" contradicts examples in info.
Classification: Unclassified
Product: gcc
Version: 4.6.3
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54266
Bug #: 54266
Summary: atomic / sync preprocessor macros inconsistent with
(does not reflect) functionality of atomic / sync
support.
Classification: Unclassified
Product
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54261
Hans-Peter Nilsson changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #32 from Chip Salzenberg 2012-08-14
23:09:01 UTC ---
More good data: this patch reduces the size of libstdc++.so by .5%
$ size usr/lib/libstdc++.so.6.0.17 /usr/lib/libstdc++.so.6.0.17
textdata bss dec hex filename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128
--- Comment #7 from Steve Ellcey 2012-08-14 23:35:03
UTC ---
The cutdown test case only shows the difference in code generation (between
"-O2" and "-O2 -g") in big-endian mode. The original larger test case had
differences in both big-endian and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #33 from H.J. Lu 2012-08-14 23:43:24
UTC ---
We must make sure that
---
union S160
{
long double a;
};
extern union S160 check160 (void);
extern void checkx160 (union S160);
void
test160 (void)
{
checkx160 (check160 ());
}
---
c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #34 from Gary Funck 2012-08-14 23:55:57
UTC ---
(In reply to comment #33)
> We must make sure that
>
> ---
> union S160
> {
> long double a;
> };
> extern union S160 check160 (void);
> extern void checkx160 (union S160);
> void
> t
1 - 100 of 112 matches
Mail list logo
