http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
Bug #: 56292
Summary: False positive for constexpr arithmetics
(-Wconversion)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #34 from Jakub Jelinek 2013-02-12
08:39:33 UTC ---
(In reply to comment #32)
> Good news, 0x7fff8000 seems great:
> There is another suggestion (from dvyukov) to use
> -Wl,-Ttext-segment=0x4000
> together with zerobase (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #35 from Dmitry Vyukov 2013-02-12
08:47:21 UTC ---
On Tue, Feb 12, 2013 at 12:39 PM, jakub at gcc dot gnu.org
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
>
> --- Comment #34 from Jakub Jelinek 2013-02-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #36 from Kostya Serebryany 2013-02-12
08:58:56 UTC ---
> I see, but then you could use the global vars (perhaps weak ones in libasan
> with some default), combined together with arguments to __asan_init (or some
> alternative n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #5 from Freddie Chopin 2013-02-12
09:07:37 UTC ---
Yes, sorry about the fuzz with the testcase and thx for confirming.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
Bug #: 56293
Summary: I/O: Segfault in write_float when trying to print a
not-word-aligned REAL(16) / -fno-align-commons
Classification: Unclassified
Product: gcc
Versi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
--- Comment #2 from lcid-fire at gmx dot net 2013-02-12 10:13:17 UTC ---
But should it be evaluated before constexpr are processed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
Tobias Schlüter changed:
What|Removed |Added
CC||tobi at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151
--- Comment #12 from Jakub Jelinek 2013-02-12
10:37:42 UTC ---
Author: jakub
Date: Tue Feb 12 10:37:38 2013
New Revision: 195972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195972
Log:
PR rtl-optimization/56151
* op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
Bug #: 56294
Summary: BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap
comparison failure
Classification: Unclassified
Product: gcc
Version: 4.8.0
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
Bug #: 56295
Summary: [4.8 Regression] Missed optimization with LTO
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
--- Comment #1 from Dmitry Gorbachev
2013-02-12 11:02:05 UTC ---
Created attachment 29423
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29423
Three other testcases
These are unrelated testcases which also demonstrate differences b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
--- Comment #6 from rguenther at suse dot de
2013-02-12 11:06:23 UTC ---
On Mon, 11 Feb 2013, hubicka at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
>
> --- Comment #5 from Jan Hubicka 2013-02-11
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #13 from rguenther at suse dot de
2013-02-12 11:11:11 UTC ---
On Tue, 12 Feb 2013, matt at use dot net wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
>
> --- Comment #12 from Matt Hargett 2013-02-12 02:02:3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #37 from Kostya Serebryany 2013-02-12
11:17:45 UTC ---
http://llvm.org/viewvc/llvm-project?rev=174957&view=rev (and r174958)
change the default offset for x86_64 to 7fff8000
and changes __asan_init to __asan_init_v1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56288
--- Comment #2 from Richard Biener 2013-02-12
11:18:17 UTC ---
Author: rguenth
Date: Tue Feb 12 11:18:05 2013
New Revision: 195973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195973
Log:
2013-02-12 Richard Biener
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56288
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Kostya Serebryany changed:
What|Removed |Added
CC||glider at google dot com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082
--- Comment #1 from Dominique d'Humieres 2013-02-12
11:33:37 UTC ---
I just noticed that I swapped the patches for (a) and (b).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296
Bug #: 56296
Summary: Undefined reference to __sync_add_and_fetch_8 for
int64_t on MIPS32.
Classification: Unclassified
Product: gcc
Version: unknown
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #39 from Jakub Jelinek 2013-02-12
11:42:33 UTC ---
So, if Darwin keeps the old 1ULL << 44, then the corresponding gcc change (to
be applied together with asan merge) would be something like (untested):
--- gcc/sanitizer.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #6 from Jakub Jelinek 2013-02-12
11:50:02 UTC ---
I think the problem is in sort_constexpr_mem_initializers, which doesn't handle
this case. CLASSTYPE_PRIMARY_BINFO (type) is NULL, thus it doesn't reorder
anything, but in this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296
--- Comment #2 from Balazs Kilvady 2013-02-12
12:12:22 UTC ---
(In reply to comment #1)
> Why do you think this is a bug? If a target doesn't support atomic operations
> on certain variable sizes, this is what you get, you are out of luck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
--- Comment #7 from janus at gcc dot gnu.org 2013-02-12 12:15:40 UTC ---
Author: janus
Date: Tue Feb 12 12:15:26 2013
New Revision: 195975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195975
Log:
2013-02-12 Janus Weil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
--- Comment #2 from Richard Biener 2013-02-12
12:28:28 UTC ---
Is it a compare-debug failure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
--- Comment #3 from Richard Biener 2013-02-12
12:29:28 UTC ---
Does it also warn if you make value a constexpr?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
Bug #: 56297
Summary: LTO: multiple definition error with global register
variables
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
Tobias Burnus changed:
What|Removed |Added
Summary|I/O: Segfault in|Segfault when trying to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
--- Comment #4 from Richard Biener 2013-02-12
12:39:55 UTC ---
(In reply to comment #3)
> Also occurs if one calls ("call foo(p)"):
> subroutine foo(x)
> real(16) :: x, y
> y = x ! FAILS HERE
> ! print *, y
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
Bug #: 56298
Summary: wmmintrin.h aborts compilation on the machines without
AES
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56284
--- Comment #9 from Dominique d'Humieres 2013-02-12
12:57:55 UTC ---
Do you understand why the test in gfc_match_return (file match.c)
if (gfc_notify_std (GFC_STD_F95_OBS, "Alternate RETURN "
"at %C") == FAILURE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175
--- Comment #7 from Yuri Rumyantsev 2013-02-12
13:05:16 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > This pattern is already recognized by simplify_bitwise_binary but only for
> > usual int type, i.e. if we change all s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
--- Comment #5 from Tobias Burnus 2013-02-12
13:07:10 UTC ---
Some tests with ifort, which by default uses unaligned commons: The first test
case works, i.e. I/O with the unaligned "p" works. However, if one calls a user
procedure ("call foo(p)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #2 from Richard Biener 2013-02-12
13:16:47 UTC ---
The intrinsics do _not_ work if the corresponding CPU ISA feature is not
enabled
on the command-line. That's a fact - whether that's good is another question.
A CPU feature a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #3 from Piotr Wyderski 2013-02-12
13:22:04 UTC ---
I beg to disagree, Jakub. In that case all the intrinsics
headers are written in a wrong way. At least if one takes
MSVC as a reference (which behaves exactly as I expected).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
--- Comment #7 from Alan Modra 2013-02-12 13:23:59
UTC ---
On thinking about this a little more, the idea of using /proc/self/auxv isn't
that good. MD_FALLBACK_FRAME_STATE_FOR is only needed for older kernels;
Kernels 2.6.15 and later pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175
--- Comment #8 from Richard Biener 2013-02-12
13:25:59 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > This pattern is already recognized by simplify_bitwise_binary but only for
> > > usual
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
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=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=56297
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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=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=55309
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
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=56295
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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=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=56049
Aldy Hernandez changed:
What|Removed |Added
Severity|normal |enhancement
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=56299
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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=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=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=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=56175
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
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=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=56291
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
--
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=56297
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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=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=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=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=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=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=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 #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
Kai Tietz changed:
What|Removed |Added
Priority|P2 |P5
Status|UNCONFIRMED
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=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=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=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=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=56148
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
---
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=56082
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=56111
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
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=56290
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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
1 - 100 of 148 matches
Mail list logo
