https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #14 from Joshua Kinard ---
(In reply to Andrew Pinski from comment #13)
> What is the kernel version? There has been some recent (this year) fixes
> inside the kernel for futex.
>
> Though I admit I have seen this just recently when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #7 from Janne Blomqvist ---
(In reply to Rich Townsend from comment #6)
> This change introduces a dependency on strndup -- which, alas, is absent
> from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X
> include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #13 from Andrew Pinski ---
What is the kernel version? There has been some recent (this year) fixes
inside the kernel for futex.
Though I admit I have seen this just recently when debugging a program where I
did next over a pthread_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61720
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Tue Jul 15 04:28:51 2014
New Revision: 212539
URL: https://gcc.gnu.org/viewcvs?rev=212539&root=gcc&view=rev
Log:
PR libstdc++/61720
* include/bits/regex_executor.tcc (_Executor<>::_M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #9 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #8)
> This symbol_ref must be wrapped inside a CONST by the middle-end.
Uh, strike that, I'm hallucinating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #8 from Hans-Peter Nilsson ---
(In reply to dhowe...@redhat.com from comment #0)
> ../../../gcc-4.9.0-20140702/libgcc/libgcc2.c: In function ‘__subvsi3’:
> ../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:122:1: error: unrecognizable
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #14 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #10)
--- snip ---
>
> Is the printing of 'YYY' supposed to happen?
Its sort of like Steve said earlier. The coder is choosing to ignore an error
condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #13 from Jerry DeLisle ---
This:
+fmt->format_string_len = strrchr (f->source, ')') - f->source + 1;
Is taking the difference between two string pointers, ie memory addresses
This:
printf("pos 0 =%x, pos ) =%x\n",strchr (f->s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to dhowe...@redhat.com from comment #0)
BTW,
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #6 from Hans-Peter Nilsson ---
Created attachment 33121
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33121&action=edit
Patch to config.gcc
Correct patch to config.gcc required to actually build the compiler proper.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
Hans-Peter Nilsson changed:
What|Removed |Added
Last reconfirmed||2014-7-15
--- Comment #5 from Hans-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61804
Bug ID: 61804
Summary: rejects-valid if parenthesized temporary is
incremented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61623
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Mon Jul 14 20:39:35 2014
New Revision: 212524
URL: https://gcc.gnu.org/viewcvs?rev=212524&root=gcc&view=rev
Log:
PR c++/61445
PR c++/56947
* pt.c (instantiate_decl): Don't che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Mon Jul 14 20:39:35 2014
New Revision: 212524
URL: https://gcc.gnu.org/viewcvs?rev=212524&root=gcc&view=rev
Log:
PR c++/61445
PR c++/56947
* pt.c (instantiate_decl): Don't che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796
--- Comment #3 from Luka Perkov ---
Hi Hans-Peter,
(In reply to Hans-Peter Nilsson from comment #1)
> I think you need to mention the options you passed to "configure". Does not
> "--with-float=hard" work? I'd also expect a target triplet
> arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796
Luka Perkov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #12 from Dominique d'Humieres ---
A little bit less clumsy
if (f != NULL)
-fmt->format_string = f->source;
+fmt->format_string_len = strrchr (f->source, ')') - f->source + 1;
I don't understand why
+fmt->format_strin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #4 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to dhowe...@redhat.com from comment #1)
> > Index: gcc/config.gcc
> > ===
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #32 from Jeffrey A. Law ---
No, we don't have that information available in any reasonable form. That's
one of the things I need to investigate.
One of the possibilities is to flip things on their side a bit. The old code
started r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #31 from rguenther at suse dot de ---
On July 14, 2014 8:57:31 PM CEST, law at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
>
>Jeffrey A. Law changed:
>
> What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #30 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #11 from Dominique d'Humieres ---
> Its not really a glitch. In this case reversion has occurred so i can only
> approximate where in the string the error occured. I can improve on it with:
>
> offset = fmt->reversion_ok ? fmt->fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #29 from Pat Haugen ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Pat Haugen from comment #19)
> > So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits
> > are '1' so r212352 returns a val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov changed:
What|Removed |Added
Attachment #32830|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
--- Comment #4 from Rich Townsend ---
Seems to work fine on 4.10 (20140710).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
Bug ID: 61803
Summary: error reports macro location first, but should not
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #2 from Daniel Santos ---
Hmm, I suppose I wasn't considering that interpretation of the language. Your
clarification helps though, and actually sounds pretty good: "always_inline
forces inlining of the function under all circumstance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
--- Comment #6 from emsr at gcc dot gnu.org ---
Created attachment 33119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33119&action=edit
Patch to pedwarn.
This doesn't have the right column pointed out.
Also, the message (and that given by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
Bug ID: 61801
Summary: sched2 miscompiles syscall sequence with -g
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
Bug ID: 61802
Summary: AArch64 execute.exp failures with LTO after r212467
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #10 from Dominique d'Humieres ---
The following code
program p
call ss0()
end program p
subroutine ss0
CHARACTER(3), save :: ZTYP(3)
DATA ZTYP /'XXX','YYY','ZZZ'/
write(*,600,IOSTAT=iosa) 'AA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61800
Markus Trippelsdorf changed:
What|Removed |Added
Target Milestone|--- |4.10.0
--- Comment #1 from Markus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Mon Jul 14 13:52:38 2014
New Revision: 212521
URL: https://gcc.gnu.org/viewcvs?rev=212521&root=gcc&view=rev
Log:
2014-07-14 Richard Biener
PR tree-optimization/61779
* tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #22 from Tobias Burnus ---
(In reply to rguent...@suse.de from comment #19)
> > Well, Bill Long of Cray seems to agree with my interpretation, cf.
> > http://mailman.j3-fortran.org/pipermail/j3/2010-February/003358.html
>
> But that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61800
Bug ID: 61800
Summary: [4.10 Regression] ICE: Segmentation fault during
Firefox build
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Dear Richie,
Thanks for doing that. I was going to do 4.8 as soon as I had a
moment and would have changed the summary then. As it happens, I was
distracted by other activities (rewir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #21 from Francois-Xavier Coudert ---
(In reply to Tobias Burnus from comment #18)
> By your argument,
> int i;
> and
> struct { int i; } a;
> are interoperable.
No. The standard only defines interoperability as a one-to-one mappi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #20 from Tobias Schlüter ---
Let's please not invent new semantics. There are two things to distinguish:
1) legacy code, where no interoperability semantics were defined
2) new code, where the semantics are defined
I don't know much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799
Richard Biener changed:
What|Removed |Added
Target||ia64-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #19 from rguenther at suse dot de ---
On Mon, 14 Jul 2014, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
>
> --- Comment #17 from Tobias Burnus ---
> (In reply to Francois-Xavier Coudert from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #18 from Tobias Burnus ---
(In reply to Francois-Xavier Coudert from comment #14)
> (In reply to rguent...@suse.de from comment #13)
> > Does it need to inter-operate with
> > extern struct { struct { int i; } a; } a;
> No, I don't re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799
Bug ID: 61799
Summary: [4.6/4.7 regression][ia64] r165240 caused GDB stops
with SIGTRAP at 0 address
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #17 from Tobias Burnus ---
(In reply to Francois-Xavier Coudert from comment #12)
> I disagree with Tobias' reading: it seems to me that the single-variable
> common block should be interoperable with both the single-common C struct
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Mon Jul 14 11:22:34 2014
New Revision: 212515
URL: https://gcc.gnu.org/viewcvs?rev=212515&root=gcc&view=rev
Log:
2014-07-14 Richard Biener
PR tree-optimization/61786
* gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #16 from Francois-Xavier Coudert ---
(In reply to Richard Biener from comment #15)
> Btw, what kind of single-elements can I expect? I suppose they can
> be arbitrary (so aggregate as well)?
>From the Fortran/C interop side, we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #15 from Richard Biener ---
Ok, the warning is implemented with checking gimple type compatibility in
lto/lto-symtab.c:
if (!types_compatible_p (TREE_TYPE (prevailing->decl),
TREE_TYPE (decl)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Mon Jul 14 10:50:46 2014
New Revision: 212513
URL: https://gcc.gnu.org/viewcvs?rev=212513&root=gcc&view=rev
Log:
2014-07-14 Richard Biener
PR tree-optimization/61757
PR tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #28 from Richard Biener ---
Author: rguenth
Date: Mon Jul 14 10:50:46 2014
New Revision: 212513
URL: https://gcc.gnu.org/viewcvs?rev=212513&root=gcc&view=rev
Log:
2014-07-14 Richard Biener
PR tree-optimization/61757
PR tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Mon Jul 14 10:50:46 2014
New Revision: 212513
URL: https://gcc.gnu.org/viewcvs?rev=212513&root=gcc&view=rev
Log:
2014-07-14 Richard Biener
PR tree-optimization/61757
PR tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
Richard Biener changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #14 from Francois-Xavier Coudert ---
(In reply to rguent...@suse.de from comment #13)
> Does it need to inter-operate with
> extern struct { struct { int i; } a; } a;
No, I don't read anything in the standard that would allow this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780
Richard Biener changed:
What|Removed |Added
Known to work||4.10.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61631
Dmitry G. Dyachenko changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #13 from rguenther at suse dot de ---
On Mon, 14 Jul 2014, fxcoudert at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
>
> --- Comment #12 from Francois-Xavier Coudert
> ---
> I disagree with Tobias' r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61790
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608
--- Comment #4 from Paolo Carlini ---
I'm going to save some debugging notes, mostly about non-variadic vs variadic.
First one: the tsubst in fn_type_unification:
fntype = tsubst (TREE_TYPE (fn), explicit_targs,
complain |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61797
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #12 from Francois-Xavier Coudert ---
I disagree with Tobias' reading: it seems to me that the single-variable common
block should be interoperable with both the single-common C struct and C
variable.
The Intel compiler makes both cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798
Bug ID: 61798
Summary: OpenMP exit code 155, profiling related?
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
Richard Biener changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #25 from Richard Biener ---
Hmm, reverting the record_equality change that is supposed to fix the unrelated
testsuite fallout fixes the testcase ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #24 from Richard Biener ---
w/o missing return:
extern void abort (void);
struct X { void *p; int res; } a[32];
int foo (unsigned i, unsigned n, void *q)
{
if (i + 1 < n && q == a[i + 1].p)
{
do {
++i;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #23 from Richard Biener ---
The first interesting difference is that for
:
_793 = ASSERT_EXPR <_73, _73 != 18>;
switch (_793) , case 0: , case 1: , case 2: ,
case 3: , case 4 ... 9: , case 10 ... 11: , case 12 ... 17:
>
:
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Mon Jul 14 07:36:39 2014
New Revision: 212510
URL: https://gcc.gnu.org/viewcvs?rev=212510&root=gcc&view=rev
Log:
PR middle-end/61294
gcc/c-family/
* c.opt (Wmemset-transposed-args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Mon Jul 14 07:31:57 2014
New Revision: 212509
URL: https://gcc.gnu.org/viewcvs?rev=212509&root=gcc&view=rev
Log:
PR target/61656
* config/i386/i386.c (classify_argument): Don't me
87 matches
Mail list logo
