http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126
--- Comment #4 from Freddie Chopin 2013-02-13
07:29:23 UTC ---
Created attachment 29430
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29430
simple fail case
I think I have an even simplier test case, I guess it's the same problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55805
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56285
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56135
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242
vries at gcc dot gnu.org changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #3 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56301
Bug #: 56301
Summary: [4.7 Regression] wrong code with the fix for PR53844
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: norm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273
--- Comment #10 from Andrew Pinski 2013-02-12
23:50:03 UTC ---
(In reply to comment #9)
> ../../../gcc-trunk/libgcc/crtstuff.c: In function 'frame_dummy':
> ../../../gcc-trunk/libgcc/crtstuff.c:463:19: warning: array subscript is above
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56300
--- Comment #2 from chaoyingfu at gcc dot gnu.org 2013-02-12 22:21:09 UTC ---
(In reply to comment #1)
> Use libatomic in 4.8 to fix this.
Good to know this. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56300
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56300
Bug #: 56300
Summary: Add __sync_fetch_and_add_8 and other 8-byte atomic
functions to 32-bit MIPS targets
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Jan-Benedict Glaw changed:
What|Removed |Added
CC||jbg...@lug-owl.de
--- Comment #15 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
--- Comment #17 from Marc Glisse 2013-02-12
20:55:09 UTC ---
(In reply to comment #15)
> Marc, any news on this?
I landed less than 2 hours ago...
I'll see if I can handle it tomorrow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56285
--- Comment #2 from Jason Merrill 2013-02-12
20:47:23 UTC ---
Author: jason
Date: Tue Feb 12 20:47:15 2013
New Revision: 195990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195990
Log:
PR c++/56285
* method.c (add_on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #27 from Dominique d'Humieres
2013-02-12 20:16:29 UTC ---
(In reply to comment #23)
> Try to use LN_S_RECURSIVE:= instead of LN_S_RECURSIVE=
As in
--- ../_clean/libada/Makefile.in2013-02-12 16:45:25.0 +0100
++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #24 from Martin Jambor 2013-02-12
20:10:42 UTC ---
Created attachment 29429
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29429
Experimental patch resolving more dependencies
This is my (untested, highly experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938
--- Comment #5 from Marek Polacek 2013-02-12
20:07:30 UTC ---
Author: mpolacek
Date: Tue Feb 12 20:07:04 2013
New Revision: 195989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195989
Log:
Fix bootstrap with -O3.
Modified:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #26 from Jakub Jelinek 2013-02-12
19:49:34 UTC ---
Yes. Then I have no idea why it doesn't work for you during bootstrap.
Stick some echo ln_s $(LN_S) ln_s_recursive $(LN_S_RECURSIVE) into the targets
that use $(LN_S_RECURSIVE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
--- Comment #4 from Martin Jambor 2013-02-12
19:43:39 UTC ---
Yes, compiling the pre-processed source with -c -O2 -fno-ipa-sra
-fcompare-debug -fno-exceptions fails too. Time for some debug
counters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56204
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51544
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #10 from Michael Meissner 2013-02-12
19:16:56 UTC ---
If -fno-merge-constants (and the default -fsection-anchors) is used, then the
correct alignment for the table is set (and Altivec memory instructions are
used).
At a gues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #25 from Dominique d'Humieres
2013-02-12 19:14:45 UTC ---
> Can you please try the following?
> ...
> Works for me just fine. Perhaps you have buggy make?
Is this working?
[macbook] f90/bug% cat Makefile
LN_S=cp -p
ife
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #9 from Michael Meissner 2013-02-12
19:07:18 UTC ---
The -fsection-anchors option appears to be important. If I use
-fsection-anchors (which is default for powerpc64-linux), LTO does not align
the .rodata section, but uses Alt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #24 from Jakub Jelinek 2013-02-12
18:41:37 UTC ---
Can you please try the following?
echo > Makefile <<\EOF
LN_S=cp -p
ifeq (cp -p,$(LN_S))
LN_S_RECURSIVE=cp -pr
else
LN_S_RECURSIVE=$(LN_S)
endif
all:
echo $(LN_S_REC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
--- Comment #11 from Sérgio Basto 2013-02-12
18:38:06 UTC ---
Vlad, don't wanna rush you , but let me know when we have this patch on gcc of
Fedora rawhide , to continue testing compilation of VirtualBox .
Thanks,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730
--- Comment #10 from Mikael Morin 2013-02-12
18:33:50 UTC ---
Created attachment 29428
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29428
Fairly complete (untested) fix
This patch implements a partial undo framework, in other wor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Michael Meissner changed:
What|Removed |Added
Component|target |lto
--- Comment #7 from Mich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #14 from Dominique d'Humieres
2013-02-12 18:21:53 UTC ---
(In reply to comment #13)
> Please also split the testcase - it contains
> several tests and only one has invalid overflow.
Actually there are three of them
(a)
p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #6 from Michael Meissner 2013-02-12
18:16:28 UTC ---
Created attachment 29427
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29427
slp-perm-1.c assembly file before LTO is run with -mcpu=power6 -O3 -maltivec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
--- Comment #3 from Martin Jambor 2013-02-12
18:16:27 UTC ---
Yes, compiling the pre-processed source with -c -O2 -fno-ipa-sra
-fcompare-debug -fno-exceptions fails too. Time for some debug
counters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #5 from Michael Meissner 2013-02-12
18:13:45 UTC ---
Created attachment 29426
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29426
Assembly file of slp-perm-1.c after lto with -mcpu=power6 -O3 -maltivec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56246
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
--- Comment #10 from Steven Bosscher 2013-02-12
18:12:00 UTC ---
Vlad, could you please explain a bit how you figured out this issue
so quickly? (I mean, apart from experience, of course.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #23 from Karlson2k 2013-02-12 18:11:09 UTC ---
Try to use LN_S_RECURSIVE:= instead of LN_S_RECURSIVE=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #22 from Dominique d'Humieres
2013-02-12 18:07:16 UTC ---
> why is NS_RECURSIVE for you an empty? It should become either cp -pR, or be
> equal to content of LN_S.
No idea. For a successfull bootstrap I see
..
rm -rf ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #21 from Kai Tietz 2013-02-12 18:04:53
UTC ---
"LN_S_RECURSIVE" I mean.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #20 from Kai Tietz 2013-02-12 18:02:56
UTC ---
Hmm,
why is NS_RECURSIVE for you an empty? It should become either cp -pR, or be
equal to content of LN_S.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56285
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #19 from Dominique d'Humieres
2013-02-12 17:51:13 UTC ---
This breaks bootstrap on x86_64-apple-darwin10:
...
test -f stamp-libada || \
make -C ../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=" "LN_S=ln -s"
"SHELL=/bin/sh"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
--- Comment #8 from Vladimir Makarov 2013-02-12
17:44:56 UTC ---
Author: vmakarov
Date: Tue Feb 12 17:44:47 2013
New Revision: 195988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195988
Log:
2013-02-12 Vladimir Makarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #12 from Jason Merrill 2013-02-12
17:40:38 UTC ---
Author: jason
Date: Tue Feb 12 17:40:32 2013
New Revision: 195987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195987
Log:
PR c++/56291
* semantics.c (so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #11 from Jason Merrill 2013-02-12
17:37:10 UTC ---
Author: jason
Date: Tue Feb 12 17:36:58 2013
New Revision: 195986
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195986
Log:
PR c++/56291
* semantics.c (so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #4 from Jan Hubicka 2013-02-12 17:25:31 UTC
---
Hi,
this patch should make ipa_make_edge_direct_to_target to behave properly when
new symbol
needs to be inserted into the symbol table. We already have
canonicalize_construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #9 from Piotr Wyderski 2013-02-12
17:22:08 UTC ---
(In reply to comment #8)
> Compiling that with icc -S t.c results in
>
> f:
> # parameter 1: %xmm0
> # parameter 2: %xmm1
> ..B1.1: # Preds ..B1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
--- Comment #16 from Paolo Carlini 2013-02-12
16:59:39 UTC ---
Jakub, if Marc remains unreachable I'll take care of carefully checking and
committing the patch in #c9 first thing tomorrow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
--- Comment #5 from Dmitry Gorbachev
2013-02-12 16:26:39 UTC ---
Created attachment 29425
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29425
Modified testcase
This slightly modified testcase still shows some strange difference be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273
--- Comment #9 from vincenzo Innocente
2013-02-12 16:24:11 UTC ---
I am just rebuilding (Updated to revision 195983.) and noticed
/home/data/newsoft/gcc-build/./gcc/xgcc -B/home/data/newsoft/gcc-build/./gcc/
-B/afs/cern.ch/user/i/innocent/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
--- Comment #5 from Jan Hubicka 2013-02-12 16:23:37 UTC
---
> Confirmed. We put
>
> register int i asm ("esp");
>
> into the LTO symbol table. Oops. The GCC symtab and the partition contains
>
> (gdb) call debug_symtab_node (node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082
--- Comment #2 from Tobias Burnus 2013-02-12
16:22:26 UTC ---
Author: burnus
Date: Tue Feb 12 16:22:13 2013
New Revision: 195984
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195984
Log:
2013-02-12 Dominique d'Humieres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Paolo Carlini changed:
What|Removed |Added
CC|freddie_chopin at op dot pl |
--- Comment #10 from Paolo Car
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #8 from Richard Biener 2013-02-12
15:47:33 UTC ---
(In reply to comment #6)
> #include
>
> __m128i f(__m128i x, __m128i y) {
>
> return _mm_aesenc_si128(x, y);
> }
Compiling that with icc -S t.c results in
f:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
Kai Tietz changed:
What|Removed |Added
Priority|P2 |P5
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #17 from Kai Tietz 2013-02-12 15:39:07
UTC ---
Author: ktietz
Date: Tue Feb 12 15:38:57 2013
New Revision: 195982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195982
Log:
PR target/52122
* Makefil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #16 from Kai Tietz 2013-02-12 15:37:09
UTC ---
Author: ktietz
Date: Tue Feb 12 15:36:56 2013
New Revision: 195981
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195981
Log:
PR target/52122
* Makefil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #15 from Kai Tietz 2013-02-12 15:32:15
UTC ---
Author: ktietz
Date: Tue Feb 12 15:32:01 2013
New Revision: 195980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195980
Log:
PR target/52122
* Makefil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #9 from Freddie Chopin 2013-02-12
15:31:46 UTC ---
(In reply to comment #8)
> Perhaps because you are the reporter and reporter is always CCed on the PRs,
> no
> matter if on CC or not?
If you remove me from the CC list I w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
--- Comment #8 from Rich Felker 2013-02-12 15:27:58
UTC ---
Is there nothing internal in the sigcontext structure that distinguishes the
version?
Making the reference to __libc_stack_end weak won't help. If the symbol is
undefined, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493
--- Comment #10 from Kai Tietz 2013-02-12 15:27:45
UTC ---
Well, I re-tried to reproduce this issue with current 4.8 gcc version (native).
As before, I can't reproduce that issue. Anyway I don't get what report was
actual doing differentl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
--- Comment #4 from lcid-fire at gmx dot net 2013-02-12 15:23:58 UTC ---
constexpr std::uint8_t value = func() + 2;
does generate the same warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #8 from Jakub Jelinek 2013-02-12
15:17:45 UTC ---
Perhaps because you are the reporter and reporter is always CCed on the PRs, no
matter if on CC or not?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
--- Comment #3 from Richard Biener 2013-02-12
15:14:37 UTC ---
Author: rguenth
Date: Tue Feb 12 15:14:32 2013
New Revision: 195979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195979
Log:
2013-02-12 Richard Biener
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56171
--- Comment #8 from Ian Lance Taylor 2013-02-12 15:02:12
UTC ---
I think we'll need to pull the relevant //sys lines out of socket.go into,
e.g., socket_posix.go, and then add socket_xnet.go, and arrange for the
Makefile to choose between
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222
--- Comment #13 from Georg-Johann Lay 2013-02-12
14:55:22 UTC ---
Author: gjl
Date: Tue Feb 12 14:55:16 2013
New Revision: 195978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195978
Log:
gcc/
PR target/54222
* confi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175
--- Comment #9 from Yuri Rumyantsev 2013-02-12
14:43:53 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > This pattern is already recognized by simplify_bitwis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56171
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-12 14:43:41 UTC ---
> --- Comment #6 from Ian Lance Taylor 2013-02-11
> 19:16:41 UTC ---
[...]
> Note that this test case execs itself in a separate process, so when using
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #42 from Jack Howarth 2013-02-12
14:41:56 UTC ---
(In reply to comment #41)
FYI, most of the codegen issues with xplor-nih compiled with gfortran can be
suppressed with -fno-tree-vectorize at -O3 (hence my interest in a funct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
Paolo Carlini changed:
What|Removed |Added
CC||ers.trion at gmail dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56299
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #7 from Jakub Je
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
Aldy Hernandez changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #41 from Jakub Jelinek 2013-02-12
14:11:28 UTC ---
That is definitely stage1 material, and a lot of work, especially to teach the
vectorizer how to deal with these. And, we don't want to introduce the asan
instrumentation too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #7 from Jakub Jelinek 2013-02-12
14:08:05 UTC ---
Headers are one thing, but you certainly can't use AES builtins in code not
compiled with -maes or functions not using __attribute__((target ("aes"))) or
similar. That just can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
--- Comment #3 from Richard Biener 2013-02-12
14:04:50 UTC ---
Author: rguenth
Date: Tue Feb 12 14:04:44 2013
New Revision: 195976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195976
Log:
2013-02-12 Richard Biener
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #6 from Piotr Wyderski 2013-02-12
13:55:08 UTC ---
#include
__m128i f(__m128i x, __m128i y) {
return _mm_aesenc_si128(x, y);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #5 from Richard Biener 2013-02-12
13:49:41 UTC ---
Can you give me a testcase that I can compile?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
--- Comment #2 from Richard Biener 2013-02-12
13:46:52 UTC ---
GCC 4.7 says
/tmp/ccQAPnYJ.o (symbol from plugin): In function `esp':
(.text+0x0): multiple definition of `esp'
/tmp/ccihIbJc.o (symbol from plugin):(.text+0x0): first defin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56284
--- Comment #10 from janus at gcc dot gnu.org 2013-02-12 13:31:22 UTC ---
(In reply to comment #9)
> Do you understand why the test in gfc_match_return (file match.c)
>
> if (gfc_notify_std (GFC_STD_F95_OBS, "Alternate RETURN "
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #4 from Piotr Wyderski 2013-02-12
13:30:37 UTC ---
@Richard: I don't have ICC right now, so a follow-up question is:
does ICC "enable" those built-in intrinsics conditionally (as does GCC)
or not (as MSVC). I think that ICC is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56299
Bug #: 56299
Summary: Dependent lambda expression breaks explicit template
instantiation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UN
1 - 100 of 148 matches
Mail list logo
