http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176
Bug #: 55176
Summary: [4.8 Regression] Out of memory during Chromium build
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: norm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
--- Comment #3 from Ralf Corsepius 2012-11-02
05:35:18 UTC ---
DJ,
any chances to see your patch from comment#1 be commited?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167
Hans-Peter Nilsson changed:
What|Removed |Added
Depends on||55001
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175
Bug #: 55175
Summary: i386/sfp-exceptions.c:52:7: error: impossible
constraint in 'asm'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #39 from Andrew Pinski 2012-11-02
02:41:37 UTC ---
(In reply to comment #38)
> Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug. And
> comment #36 should have read:
> ..previous test was for *either* at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #38 from Alan Modra 2012-11-02 02:39:29
UTC ---
Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug. And
comment #36 should have read:
..previous test was for *either* atomic bool or atomic int.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #37 from Andrew Pinski 2012-11-02
02:16:48 UTC ---
(In reply to comment #36)
> The change I mention in #c22
> http://gcc.gnu.org/viewcvs?view=revision&revision=184110
> tests for atomic ops on all of bool, short, int and long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #36 from Alan Modra 2012-11-02 02:13:20
UTC ---
The change I mention in #c22
http://gcc.gnu.org/viewcvs?view=revision&revision=184110
tests for atomic ops on all of bool, short, int and long long, where the
previous test was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #35 from Andrew Pinski 2012-11-02
01:35:35 UTC ---
I get the same "randomish" failure on MIPS64 (the Octeon 1 with 16 cores) with
GCC 4.7. The patch listed below will not help me at all as the code is already
using the __atomi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174
Bug #: 55174
Summary: internal compiler error: Segmentation fault with bad
array reference
Classification: Unclassified
Product: gcc
Version: unknown
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #50 from eraman at gcc dot gnu.org 2012-11-02 00:28:45 UTC ---
Author: eraman
Date: Fri Nov 2 00:28:40 2012
New Revision: 193085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193085
Log:
Backport 191302 and 1926
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55001
Marc Glisse changed:
What|Removed |Added
Summary|Handle VEC_COND_EXPR in |Handle VEC_COND_EXPR better
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55001
--- Comment #2 from Marc Glisse 2012-11-01 23:39:48
UTC ---
Author: glisse
Date: Thu Nov 1 23:39:44 2012
New Revision: 193077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193077
Log:
2012-11-01 Marc Glisse
PR middl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #20 from Manuel López-Ibáñez 2012-11-01
23:23:41 UTC ---
(In reply to comment #19)
> Reported as bug 55173. I'm not going to claim to understand bug 43486
> sufficiently to know it is the same issue, but if you are sure, please feel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103
Steve Ellcey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
--- Comment #17 from H.J. Lu 2012-11-01 23:07:06
UTC ---
T(In reply to comment #16)
> > I think the bug is in unsigned array index computation as
> > shown in Comment 7. dyn->d_tag is signed type and Pmode
> > != ptr_mode here.
>
> Pos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
--- Comment #7 from Paolo Carlini 2012-11-01
23:06:54 UTC ---
*** Bug 55173 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55173
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #19 from Matthew Woehlke
2012-11-01 23:04:42 UTC ---
Reported as bug 55173. I'm not going to claim to understand bug 43486
sufficiently to know it is the same issue, but if you are sure, please feel
free to close as duplicate.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55173
Bug #: 55173
Summary: GCC gives wrong location, and ignores -isystem, when
warning about default arguments
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
--- Comment #16 from Eric Botcazou 2012-11-01
23:00:06 UTC ---
> The patch compiles testcase, but totally miscompiles glibc.
Ouch. Then this means that the existing non-PIC code is wrong as well.
> I think the bug is in unsigned array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172
Bug #: 55172
Summary: ICE on invalid: gfc_variable_attr(): Bad array
reference
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #17 from Paolo Carlini 2012-11-01
22:42:05 UTC ---
If you like, sure. I want to emphasize again that the issue really is about the
behavior of the pragma vs warnings for default arguments, *any* warning, and if
you check is *ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
--- Comment #9 from H.J. Lu 2012-11-01 22:37:20
UTC ---
Like this:
# Return 1 if -mx32 can compile, 0 otherwise.
proc check_effective_target_maybe_x32 { } {
return [check_no_compiler_messages maybe_x32 object {
void foo (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
--- Comment #8 from H.J. Lu 2012-11-01 22:31:45
UTC ---
(In reply to comment #7)
> Shouldn't the gcc.target/i386/pr54457.c testcase be...
>
> Index: gcc/testsuite/gcc.target/i386/pr54457.c
> =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
--- Comment #15 from H.J. Lu 2012-11-01 22:30:16
UTC ---
All binaries die before main:
Starting program:
/export/build/gnu/glibc-x32-long/build-x86_64-linux/libio/bug-fclose1
Program received signal SIGSEGV, Segmentation fault.
0xf7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from H.J. Lu 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|NEW
Component|target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #16 from mwoehlke.floss at gmail dot com 2012-11-01 22:03:46 UTC ---
On 2012-11-01 16:52, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
> --- Comment #15 from Paolo Carlini
> 2012-11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29963
--- Comment #2 from Jorn Wolfgang Rennecke
2012-11-01 21:42:12 UTC ---
(In reply to comment #1)
> I'm not sure how the proposed optimization could be done in a generic way. It
> would not work for code (i.e. text section) that resides in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55160
--- Comment #3 from Oleg Endo 2012-11-01 21:28:53
UTC ---
Author: olegendo
Date: Thu Nov 1 21:28:49 2012
New Revision: 193071
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193071
Log:
PR target/55160
* gcc.target/sh/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29963
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938
--- Comment #7 from Oleg Endo 2012-11-01 21:19:53
UTC ---
I guess this is done, isn't it Easwaran?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171
Bug #: 55171
Summary: incorrect virtual thunk on mingw
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55047
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55047
--- Comment #4 from paolo at gcc dot gnu.org
2012-11-01 21:09:57 UTC ---
Author: paolo
Date: Thu Nov 1 21:09:51 2012
New Revision: 193070
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193070
Log:
2012-11-01 Haakan Younes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #15 from Paolo Carlini 2012-11-01
20:52:15 UTC ---
This is what I meant when I said that the issue is different, and is much more
general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:
#pragma GCC system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168
--- Comment #2 from Jan Hubicka 2012-11-01 20:49:18 UTC
---
This actually looks like a previously latent issue in predict.c For all but
estimate_num_iterations_int. It uses the funny definition of number of
iterations (i.e. 0 means that l
This actually looks like a previously latent issue in predict.c For all but
estimate_num_iterations_int. It uses the funny definition of number of
iterations (i.e. 0 means that loop will exit at first invocation of the exit
condition and that is what it will be predicted with when nitercst == 1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170
--- Comment #1 from Rafael Avila de Espindola 2012-11-01 20:29:02 UTC ---
The relevant thread seems to be
http://sourcerytools.com/pipermail/cxx-abi-dev/2011-April/002404.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168
Hans-Peter Nilsson changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170
Bug #: 55170
Summary: incorrect mangling, should not include prefix
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167
--- Comment #3 from Marc Glisse 2012-11-01 20:22:14
UTC ---
(In reply to comment #2)
> It could be; that PR lacks a description of the effects, so my pre-report
> search did not find it. (It only speaks of something missing in the code,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169
--- Comment #3 from Paolo Carlini 2012-11-01
19:59:48 UTC ---
Of course, of course. But in 4_7-branch we are going to change only the three
distributions using std::vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103
Steve Ellcey changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167
--- Comment #2 from Hans-Peter Nilsson 2012-11-01
19:52:02 UTC ---
(In reply to comment #1)
> Since the error happens in expand, I assume this is a dup of PR 55001, for
> which I posted a patch earlier today.
It could be; that PR lacks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169
--- Comment #2 from Chris Nell 2012-11-01
19:48:43 UTC ---
After a bit more poking, it appears that param() returns a copy (not a const
reference) for all distributions, not just discrete_distribution. As such, it
might we worth looking i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169
Bug #: 55169
Summary: std::discrete_distribution::operator(generator&) makes
unnecessary copy of parameter vector
Classification: Unclassified
Product: gcc
Version: 4.7.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168
Bug #: 55168
Summary: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE,
all but -O0
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #14 from Paolo Carlini 2012-11-01
19:07:10 UTC ---
Ok, I can reproduce this. Note, I don't think it's the same issue reported here
earlier. Apparently something is going wrong with the pragma. A WA is writing:
Bar(Foo = Foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167
--- Comment #1 from Marc Glisse 2012-11-01 19:05:13
UTC ---
Thanks.
Since the error happens in expand, I assume this is a dup of PR 55001, for
which I posted a patch earlier today. Note that AFAIK, anything that starts
failing because o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150
--- Comment #5 from Vladimir Makarov 2012-11-01
19:02:48 UTC ---
Author: vmakarov
Date: Thu Nov 1 19:02:40 2012
New Revision: 193065
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193065
Log:
2012-11-01 Vladimir Makarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167
Bug #: 55167
Summary: [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55166
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55166
Bug #: 55166
Summary: c++11: std::string and =std:move makes swapping
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164
Sharad Singhai changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54957
--- Comment #21 from rbmj at verizon dot net 2012-11-01 18:05:36 UTC ---
That fixes it for me :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #13 from Matthew Woehlke
2012-11-01 17:56:49 UTC ---
...and with your example I do indeed get no warning.
Simplified test case:
$ cat zero-as-pointer.h
#pragma GCC system_header
class Foo
{
public:
Foo(void** = 0);
};
class Bar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164
--- Comment #2 from Sharad Singhai 2012-11-01
17:55:46 UTC ---
Author: singhai
Date: Thu Nov 1 17:55:23 2012
New Revision: 193064
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193064
Log:
2012-11-01 Sharad Singhai
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #12 from Matthew Woehlke
2012-11-01 17:47:04 UTC ---
Requires qt-devel installed, but has the benefit of being the exact issue I'm
having in production (on the chance it's something screwy about Qt...):
$ cat zero-as-pointer.cpp
#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164
--- Comment #1 from singhai at google dot com 2012-11-01 16:26:21 UTC ---
Found the culprit. A flag was accidentally committed in wrong order.
The following patch fixes it. I am testing it.
Thanks,
Sharad
2012-11-01 Sharad Singhai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #3 from Daniel Krügler
2012-11-01 15:11:51 UTC ---
(In reply to comment #2)
Hmmh, it doesn't look like that one, maybe I was wrong about an existing issue.
But it seems that gcc doesn't ignore the const (in "const T*" or "const auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55165
--- Comment #1 from Mikael Pettersson 2012-11-01
14:38:50 UTC ---
Change the first two (long) casts to (uintptr_t) and the third one to
(intptr_t).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55165
Bug #: 55165
Summary: Build failure for x86_64-w64-mingw32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #2 from Paolo Carlini 2012-11-01
14:25:26 UTC ---
Daniel, you mean PR54111 maybe?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
--- Comment #13 from Eric Botcazou 2012-11-01
14:20:17 UTC ---
Created attachment 28591
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28591
Tentative fix
This generates (essentially) the same RTL as in non-PIC mode, so the generat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
Eric Botcazou changed:
What|Removed |Added
Component|middle-end |target
--- Comment #12 from Eri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104
--- Comment #5 from Jan Hubicka 2012-11-01
12:44:22 UTC ---
Author: hubicka
Date: Thu Nov 1 12:44:13 2012
New Revision: 193062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193062
Log:
PR middle-end/55104
* ipa-inl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078
Jan Hubicka changed:
What|Removed |Added
Blocks|55104 |
--- Comment #6 from Jan Hubicka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104
Jan Hubicka changed:
What|Removed |Added
Depends on||55078
--- Comment #4 from Jan Hub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #11 from Paolo Carlini 2012-11-01
11:53:26 UTC ---
I see, thanks Daniel for the additional analysis. Indeed, I can confirm that
with the operator+ return type fixed, ICC doesn't throw either. Now I guess
it's my job to figure o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150
--- Comment #4 from Ryan Mansfield 2012-11-01
11:47:54 UTC ---
Created attachment 28590
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28590
second preprocessed src testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150
--- Comment #3 from Ryan Mansfield 2012-11-01
11:46:24 UTC ---
I found similar crash that happens with the fix in comment #2 applied. i.e.
using rev193061:
$ ./xgcc -B. -m32 -Os -fpic -g ~/ice.i
/home/ryan/ice.i: In function ‘DES_ede3_cbcm_enc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164
Bug #: 55164
Summary: -fdump-*-all not working
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55163
Bug #: 55163
Summary: Ongoing problem with gengtype-lex.c under CygWin with
CRLF text mode line endings since 4.8
Classification: Unclassified
Product: gcc
Version: 4.8.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55132
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55154
Uros Bizjak changed:
What|Removed |Added
Target Milestone|--- |4.8.0
--- Comment #3 from Uros Bi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55154
--- Comment #2 from Uros Bizjak 2012-11-01 10:40:37
UTC ---
(In reply to comment #1)
> Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192719
> The interesting thing is that this happened before, definitely in r190614,
> af
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834
Nicolai Josuttis changed:
What|Removed |Added
CC||nico at josuttis dot de
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
--- Comment #1 from Oleg Endo 2012-11-01 10:11:46
UTC ---
(In reply to comment #0)
> The same could be done on SH, too (comparing against the end address instead
> of
> using a loop counter), but it would add a loop setup overhead. In th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
Bug #: 55162
Summary: Loop ivopts cuts off top bits of loop counter
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147
--- Comment #6 from Uros Bizjak 2012-11-01 09:48:50
UTC ---
(In reply to comment #5)
> Created attachment 28589 [details]
> gcc48-pr55147.patch
>
> So like this? Or do you want to merge the bswap{si,di}2 expanders using SWI48
> iterat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147
--- Comment #5 from Jakub Jelinek 2012-11-01
09:44:22 UTC ---
Created attachment 28589
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28589
gcc48-pr55147.patch
So like this? Or do you want to merge the bswap{si,di}2 expanders usin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147
Uros Bizjak changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Summary|x86: wron
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #10 from Daniel Krügler
2012-11-01 09:10:56 UTC ---
(In reply to comment #9)
I don't think that the standard says (or intends to say) that an implementation
has to defer all evaluations here. For example, assume you provide
polymorp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #9 from Paolo Carlini 2012-11-01
08:39:48 UTC ---
Oops, sorry about the rvalue stupid mistake, you are right. Thus I understand
that this type of wording means that assuming it's a glvalue, the null pointer
can appear anywhere,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54996
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55161
Bug #: 55161
Summary: internal compiler error: in schedule_reg_moves, at
modulo-sched.c:731
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53746
vincenzo Innocente changed:
What|Removed |Added
Known to work||4.8.0
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #8 from Daniel Krügler
2012-11-01 07:11:56 UTC ---
(In reply to comment #7)
The error is real. The original example belongs to 5.2.8 p2:
"When typeid is applied to a **glvalue expression** whose type is a polymorphic
class type [..]
1 - 100 of 101 matches
Mail list logo
