http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #6 from Jakub Jelinek 2013-01-08
08:13:02 UTC ---
On HP-UX or Linux? The test is guarded with
! { dg-require-effective-target tls_runtime }
does the OS have assembly/linker and runtime TLS support?
Can you attach libgomp.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844
--- Comment #6 from Jakub Jelinek 2013-01-08
08:14:12 UTC ---
Author: jakub
Date: Tue Jan 8 08:14:04 2013
New Revision: 195005
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195005
Log:
PR sanitizer/55844
* c-c++-comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851
--- Comment #10 from Jakub Jelinek 2013-01-08
08:32:21 UTC ---
Author: jakub
Date: Tue Jan 8 08:32:12 2013
New Revision: 195006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195006
Log:
PR middle-end/55851
* fold-con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120
--- Comment #14 from Jakub Jelinek 2013-01-08
08:33:50 UTC ---
Author: jakub
Date: Tue Jan 8 08:33:43 2013
New Revision: 195007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195007
Log:
PR tree-optimization/54120
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890
--- Comment #7 from Jakub Jelinek 2013-01-08
08:38:58 UTC ---
Author: jakub
Date: Tue Jan 8 08:38:50 2013
New Revision: 195008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195008
Log:
PR middle-end/55890
* tree-ssa-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #33 from Dmitry Vyukov 2013-01-08
09:17:31 UTC ---
(In reply to comment #32)
> (In reply to comment #30)
> > The formatting in the patch is wrong (multiple issues).
>
> I've tried to fix them in the version below.
>
> It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868
--- Comment #3 from Tobias Burnus 2013-01-08
09:37:00 UTC ---
(In reply to comment #2)
> I'd say GFC_PREFIX wouldn't improve this, I'd keep using $ unless
> NO_DOLLAR_IN_LABEL, otherwise fallback to . if NO_DOT_IN_LABEL and as last
> fall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
Joyabrata Ghosh changed:
What|Removed |Added
CC||joy.career at gmail dot com
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868
--- Comment #4 from Jakub Jelinek 2013-01-08
09:41:29 UTC ---
Fine with me. Just a note, sprintf (dt_name, "%s", "STAR"); would be better
written as strcpy (dt_name, "STAR");
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195
--- Comment #10 from janus at gcc dot gnu.org 2013-01-08 09:47:17 UTC ---
For comment #8, resolve_typebound_intrinsic_op is called twice: Once for the
base type 'nc', and once for the extended type 'ncb'.
A crude way to avoid this is the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594
--- Comment #9 from Rainer Orth 2013-01-08 09:48:02 UTC
---
Author: ro
Date: Tue Jan 8 09:47:55 2013
New Revision: 195009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195009
Log:
Restrict -Wa,-nH use to Solaris (PR libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594
Rainer Orth changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829
--- Comment #2 from Jakub Jelinek 2013-01-08
09:58:05 UTC ---
Created attachment 29103
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29103
gcc48-pr55829.patch
Yeah, comparing the vec_dupv2df and *vec_concatv2df patterns shows that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55790
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #15 from Richard Biener 2013-01-08
10:17:16 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > Eh. Diego, how does GTY((user)) work here? It smells like a bug in vec.h
> > to me.
> >
> > /* Garbage collectio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55801
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
--- Comment #4 from Jonathan Wakely 2013-01-08
10:27:55 UTC ---
This is not a bug in GCC, there's nothing to fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55801
--- Comment #2 from vlukas at gmx dot de 2013-01-08 10:46:55 UTC ---
Thank you for working on this. Strangely, I just tested this again and could
remove one line from my testcase:
class C;
thread_local C O,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
--- Comment #5 from Joyabrata Ghosh 2013-01-08
10:48:36 UTC ---
Hi Jonathan Wakely,
Just wanted to confirm the doubt:
Do you wanted to mean that, the initializer_list behaviour is exactly like
this(work for local stack members) and th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53489
--- Comment #2 from Tal 2013-01-08 10:58:57 UTC ---
Please add a C# front end to gcc:
there two open source for this, you can continue / add / migrate / use them
http://www.mono-project.com/Main_Page
http://www.gnu.org/software/dotgnu/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
--- Comment #5 from Manuel López-Ibáñez 2013-01-08
11:14:49 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
>
> > Well - confirmed. Unlikely to be fixed.
>
> That's _very_ unfortunate. It makes the pragma almost useless in practi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #5 from Jakub Jelinek 2013-01-08
11:27:12 UTC ---
The problem is that dbxout.c (unlike dwarf2out.c; not sure about other debug
backends) emits assembly immediately into asm_out_file, pretty much everywhere,
instead of creating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
Richard Biener changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |stabs
Host|hppa2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
--- Comment #9 from Dominique d'Humieres 2013-01-08
12:34:01 UTC ---
It looks like a duplicate of pr44672.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55824
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122
--- Comment #6 from Jonathan Wakely 2013-01-08
12:39:26 UTC ---
(In reply to comment #5)
> Hi Jonathan Wakely,
>
> Just wanted to confirm the doubt:
That's not a "doubt" it's a question.
> Do you wanted to mean that, the initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #7 from Jakub Jelinek 2013-01-08
12:42:06 UTC ---
dbxout.c already defines a handle_pch hook, so it is apparently told when
pch_init and write_pch are called, so in theory this could be handled in
dbxout.c only (still, the ques
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55086
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908
Bug #: 55908
Summary: Problem binding a const member function to a const
object
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #8 from Jakub Jelinek 2013-01-08
13:28:56 UTC ---
Note this isn't limited to dbxout.c, pretty much all *out.c debug backends but
dwarf2out.c suffer from these issues, they all emit assembly immediately, only
dwarf2out.c just cr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55908
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.7.3
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #3 from Richard Biener 2013-01-08
13:50:58 UTC ---
Eh, we do totally crazy (recursive) inlining here ...
struct section_info
{
intrusive_ptr < section_info > parent;
};
struct file_info
{
intrusive_ptr < file_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55579
--- Comment #7 from Martin Jambor 2013-01-08
14:10:52 UTC ---
Author: jamborm
Date: Tue Jan 8 14:10:44 2013
New Revision: 195015
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195015
Log:
2013-01-08 Martin Jambor
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55579
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #4 from Richard Biener 2013-01-08
14:24:59 UTC ---
Solution to put off recursive inlining through iteration:
Index: ipa-inline.c
===
--- ipa-inline.c(re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418
--- Comment #9 from Jakub Jelinek 2013-01-08
14:44:51 UTC ---
Created attachment 29104
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29104
gcc48-pr48418.patch
Untested fix. To avoid warning twice, this warns in c_fully_fold_inter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902
--- Comment #4 from Václav Zeman 2013-01-08
15:00:09 UTC ---
I have fixed the Google doc sharing. It should be accessible now.
I am not sure if I can check GCC 4.7.2, I am using what Ubuntu provides as
package. I believe that MinGW cross compil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189
--- Comment #8 from Jakub Jelinek 2013-01-08
15:02:52 UTC ---
Created attachment 29105
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29105
gcc48-pr48189.patch
I'd say this isn't difficult to solve enough to warrant having it open
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #5 from Richard Biener 2013-01-08
15:07:16 UTC ---
(In reply to comment #3)
>
> : :
> ...
> 20: 03c21021 adduv0,s8,v0 20: 03c21021 adduv0,s8,v0
>
> 24:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48181
--- Comment #4 from Jakub Jelinek 2013-01-08
15:16:52 UTC ---
But then, won't the exact same issues potentially happen in very large
functions where ira_conflicts_p isn't also true, because the conflict table
would be too big? I'd say zer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #6 from Richard Biener 2013-01-08
15:25:46 UTC ---
GCC clealy thinks that
(insn 21 20 0 2 (set (mem/j:SI (plus:SI (reg/f:SI 195)
(const_int 10 [0xa])) [0+-2 S4 A32])
(reg:SI 201)) t.i:85 -1
is 4-by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55760
--- Comment #5 from vincenzo Innocente
2013-01-08 15:29:18 UTC ---
we just got "hit" by this great type of code (copysign is unknown to
scientists)
most probably gcc could optimize it for -Ofast to return copysignf(1.f,x); (x/x
is optim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884
--- Comment #7 from dave.anglin at bell dot net 2013-01-08 15:29:49 UTC ---
On 1/8/2013 3:13 AM, jakub at gcc dot gnu.org wrote:
> On HP-UX or Linux? The test is guarded with
> ! { dg-require-effective-target tls_runtime }
> does the OS ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #7 from Richard Biener 2013-01-08
15:47:10 UTC ---
Ok with respect to alignment the issue is that when we expand_assignment
for to == dmfe[i_1].use_alt_rd_dqs we fall into the old trap for
STRICT_ALIGNMENT targets to use the mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #8 from Richard Biener 2013-01-08
15:54:46 UTC ---
Or more correct
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 195014)
+++ gcc/emit-rtl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875
--- Comment #7 from Jan Hubicka 2013-01-08
16:12:25 UTC ---
Created attachment 29106
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29106
patch in testing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
Rainer Orth changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49592
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829
--- Comment #5 from Uros Bizjak 2013-01-08 16:27:23
UTC ---
(In reply to comment #3)
> BTW, there is a slight inconsistency between the two patterns, the first
> pattern uses sselog1 type for both the unpckldp %0, %0 and %vmovddup %1, %0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42661
Steve Ellcey changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852
--- Comment #10 from Andreas Schwab 2013-01-08 16:55:58
UTC ---
The test case fails because the match is too strict.
$ grep iszs intrinsic_size_3.f90.003t.original
integer(kind=2) iszs;
iszs = (integer(kind=2)) MAX_EXPR <(D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #48 from Jakub Jelinek 2013-01-08
17:02:13 UTC ---
Author: jakub
Date: Tue Jan 8 17:01:58 2013
New Revision: 195025
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195025
Log:
PR fortran/55341
* asan.c (asa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
Bug #: 55909
Summary: libtool test exposes what I think is some alignment
issue in libstd++
Classification: Unclassified
Product: gcc
Version: unknown
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #16 from H.J. Lu 2013-01-08 17:12:57
UTC ---
(In reply to comment #15)
> So I'm still not sure what HJ means with "it's collected". GC roots are
> never collected. HJ, should your patch fix anything? What do you think
> the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #50 from Joost VandeVondele
2013-01-08 17:26:19 UTC ---
(In reply to comment #49)
> Fixed.
Thanks, for fixing this issue.
Shouldn't the PR be kept open to look into what I'm rather sure is a
miscompilation as discussed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #9 from stevenb.gcc at gmail dot com
2013-01-08 17:39:23 UTC ---
> I think reverting would be backward - we should clearly move forward. One
> way forward is to simply declare PCH unsupported with stabs.
This is what I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
Bug #: 55910
Summary: One of instances generated for a method with -O3 uses
incorrect parameter cleanup size with 'ret'
Classification: Unclassified
Product: gcc
Version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
Paolo Carlini changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #10 from Jakub Jelinek 2013-01-08
17:51:10 UTC ---
All that to avoid one #include "output.h" in one file? That doesn't seem
appropriate to me. I'm not questioning it is a desirable change, but I'd
reapply it only when all the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
--- Comment #3 from Oleh Derevenko 2013-01-08
17:51:59 UTC ---
Well, this is an optimizer issue which goes away with -O2. And optimizer is
something that is hard to predict and reproduce, when you run over an issue in
complex code with lot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875
--- Comment #8 from Jan Hubicka 2013-01-08
17:55:42 UTC ---
Created attachment 29109
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29109
updated patch
There is another bug triggered by this testcase. Some of the bounds, like those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
--- Comment #4 from Paolo Carlini 2013-01-08
17:57:28 UTC ---
Indeed, and that's exactly why we need a precise, specific testcase, no hand
waving.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #2 from philip.copeland at oracle dot com 2013-01-08 17:59:14 UTC
---
Created attachment 29110
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29110
compressed tarball of .ii files
Adding .ii files as a compressed tarball
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845
--- Comment #11 from Jakub Jelinek 2013-01-08
18:00:30 UTC ---
Author: jakub
Date: Tue Jan 8 18:00:10 2013
New Revision: 195028
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195028
Log:
PR rtl-optimization/55845
* df
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #11 from stevenb.gcc at gmail dot com 2013-01-08 18:04:09 UTC ---
> All that to avoid one #include "output.h" in one file?
Is that one little thing really the only change you see? I see a
different picture.
The change is a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910
--- Comment #5 from Oleh Derevenko 2013-01-08
18:11:42 UTC ---
IMHO, I've localized the issue clearly enough. The code that generates
instances for methods may sometimes consider some of those instances as having
no parameters in method in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
--- Comment #6 from Martin Jambor 2013-01-08
18:16:24 UTC ---
Created attachment 29111
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29111
Untested fix
I'm currently bootstrapping and testing this patch to fix the issue on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resoluti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902
--- Comment #5 from Václav Zeman 2013-01-08
18:26:47 UTC ---
(In reply to comment #3)
> Does it only reproduce with -flto-partition=none?
Yes. Changing either the LTO partitioning algorithm or adding -r or -nostdlib
makes the error go away.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875
--- Comment #9 from Jakub Jelinek 2013-01-08
18:27:44 UTC ---
FYI, the execute/pr55875.c with -O1 started failing with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138207
aka tuples merge.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #3 from Paolo Carlini 2013-01-08
18:45:14 UTC ---
Per the bug submitting instructions we need a *single* self-contained *.ii
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753
Jason Merrill changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #13 from Jas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
philip.copeland at oracle dot com changed:
What|Removed |Added
Attachment #29110|0 |1
is o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #47 from Uros Bizjak 2013-01-08 19:23:41
UTC ---
(In reply to comment #44)
> Can't reproduce on x86_64-linux with current trunk at -O3 -g -ffast-math, both
> with LRA and when LRA is disabled. From what I understood, this bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55879
--- Comment #2 from npl at chello dot at 2013-01-08 19:30:29 UTC ---
(In reply to comment #1)
> The problem also occurs for gcc 4.8.0 20121209 (experimental). Let me remark
> that according to C++11 the variable s_Memmap could not be used in const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45836
--- Comment #4 from Mikael Morin 2013-01-08
19:42:49 UTC ---
Author: mikael
Date: Tue Jan 8 19:42:38 2013
New Revision: 195031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031
Log:
PR fortran/42769
PR fortran/458
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45900
--- Comment #5 from Mikael Morin 2013-01-08
19:42:50 UTC ---
Author: mikael
Date: Tue Jan 8 19:42:38 2013
New Revision: 195031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031
Log:
PR fortran/42769
PR fortran/458
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #37 from Mikael Morin 2013-01-08
19:42:47 UTC ---
Author: mikael
Date: Tue Jan 8 19:42:38 2013
New Revision: 195031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031
Log:
PR fortran/42769
PR fortran/45
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #48 from Dominique d'Humieres
2013-01-08 19:52:39 UTC ---
>From comment #40:
> with -ffast-math, so for example
>
> if (x != 0)
> tem = y / x;
> else
> tem = 0.;
> ... do sth with tem ...
>
> will execute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45900
--- Comment #6 from Mikael Morin 2013-01-08
20:01:59 UTC ---
Author: mikael
Date: Tue Jan 8 20:01:49 2013
New Revision: 195032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195032
Log:
PR fortran/42769
PR fortran/458
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45836
--- Comment #5 from Mikael Morin 2013-01-08
20:02:01 UTC ---
Author: mikael
Date: Tue Jan 8 20:01:49 2013
New Revision: 195032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195032
Log:
PR fortran/42769
PR fortran/458
1 - 100 of 129 matches
Mail list logo