https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376
--- Comment #1 from John David Anglin ---
Breakpoint 2, _Z11fancy_abortPKciS0_ (
file=0x13180d0 "../../gcc/gcc/vec.h", line=736,
function=0x13182d8 ::operator[](unsigned int)::__FUNCTION__> "operator[]") at
../../gcc/gcc/diagnostic.c:12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63377
Bug ID: 63377
Summary: Bad diagnostic - "expected unqualified-id" instead of
"no type named __ in namespace"
Product: gcc
Version: unknown
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376
Bug ID: 63376
Summary: [5.0 Regression] ICE: in operator[], at vec.h:736
compiling team.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #39 from Kazumoto Kojima ---
(In reply to Hans-Peter Nilsson from comment #38)
> Hm, you're right, but to me that indicates the patch covering-up a bug
> elsewhere than in the sh port.
Would it be better to file an independent PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375
Pranith Kumar changed:
What|Removed |Added
CC||bobby.prani at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375
Bug ID: 63375
Summary: reordering of reads across fences
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63374
Bug ID: 63374
Summary: unhelpful diagnostics for missing initializer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
--- Comment #9 from xur at google dot com ---
Sure. I will work on this. I will have a new mode that do multi-target
value profiling and keep current single-target mode. Let me know if we
only need to have multi-garget mode.
The integration with L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #12 from Jan Hubicka ---
We still fail to fold here. After tracer we get:
# ap_2 = PHI
# prephitmp_14 = PHI <&MEM[(void *)&_ZTV1A + 16B](4)>
_19 = *prephitmp_14;
PROF_24 = [obj_type_ref] OBJ_TYPE_REF(_19;(struct A)ap_2->0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62121
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344
--- Comment #6 from Martin Liška ---
(In reply to Andi Kleen from comment #5)
> I posted a patch here
> http://permalink.gmane.org/gmane.linux.kernel/1793662
>
> BTW actually I don't agree that the bug is valid. We should probably relax
> the LT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61440
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791
--- Comment #16 from Jan Hubicka ---
With new polymorphic call code we could handle the testcase from comment 15 by
simple propagation of contextes down during early optimization. This may be
easy enough to be worth to implement.
Still general s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
davidxl changed:
What|Removed |Added
CC||xur at google dot com
--- Comment #8 from davi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
--- Comment #7 from Jan Hubicka ---
Any news on this code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61890
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61688
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #15 from camm at debian dot org ---
Created attachment 33575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33575&action=edit
setjmp saves f31, then zeroes out the result with stvxv3,0,r5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #14 from camm at debian dot org ---
Created attachment 33574
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33574&action=edit
continuation of gdb.7 showing no stfd fp31,((39)*8)(3) executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #13 from camm at debian dot org ---
Created attachment 33573
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33573&action=edit
gdb transcript shoinwg f31 is correct on entry to setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #12 from camm at debian dot org ---
Created attachment 33572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33572&action=edit
setjmp does write to jmp_buf, but not at the end of the buffer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #11 from camm at debian dot org ---
Created attachment 33571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33571&action=edit
gdb transcript showing jmp_buf is unchanged across setjmp && longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62233
Oleg Endo changed:
What|Removed |Added
Target|powerpc64le |powerpc64le sh*-*-*
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
Peter Bergner changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63364
--- Comment #4 from ncomputers.org ---
(In reply to Andrew Pinski from comment #3)
> (In reply to ncomputers.org from comment #2)
> > Can we write your name in our website?
> >
> > "Andrew Pinski taught us something new".
>
> I guess.
Ok, here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Sep 25 17:58:35 2014
New Revision: 215613
URL: https://gcc.gnu.org/viewcvs?rev=215613&root=gcc&view=rev
Log:
PR rtl-optimization/63348
* emit-rtl.c (try_split): Do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348
--- Comment #6 from baoshan ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to baoshan from comment #1)
> > I believe this regression is introduced by the code for cleanup_barriers()
> > in jump.c of patch https://gcc.gnu.org/ml/gcc-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410
--- Comment #9 from Andi Kleen ---
Should we just disable the option? If it hasn't worked since 4.5 probably noone
needs it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63372
--- Comment #2 from Andi Kleen ---
Actually don't even need the test case, the error happens with an empty file
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63372
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410
Markus Trippelsdorf changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #9 from camm at debian dot org ---
Created attachment 33570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33570&action=edit
the setjmp buffer does not appear to be clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373
Bug ID: 63373
Summary: ELF symbol sizes for variable-length objects are too
small
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63372
Bug ID: 63372
Summary: -fshort-double causes stor-layout ICE
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #8 from Peter Bergner ---
(In reply to camm from comment #6)
> Here is another transcript showing the innermost setjmp/longjmp pair
> corrupting the f31 register.
I've looked at the longjmp code and it seems fine to me. Since you sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #38 from Hans-Peter Nilsson ---
(In reply to Kazumoto Kojima from comment #34)
> For reference,
> i386.md emits a blockage (i.e. *using* and clobbering all
> registers).
> It
> looks all ports including SH emit a blockage after stori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #3 from Ville Voutilainen ---
Looks good so far. I think this is a sufficient start for implementing the
library traits. Does the patch cover template cases as well? Such as
struct B {B();};
template struct C : T
{
};
SA(__calls_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #7 from camm at debian dot org ---
Created attachment 33567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33567&action=edit
gdb transcript showing innermost setjmp/longjmp f31 clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #7 from Jonathan Wakely ---
Aha, so that's the culprit. I really think we should be outputting in an exact
format, not via conversion to/from decimal.
> BTW, I did this manually as I'm not very proficient with `runtest`, isn't
> ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #37 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #36)
> I'm not sure about the old reload. LRA makes only 3 uses of r0 and it's
> relatively easy to see what is going on there with .reload comments.
> The old reload m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #6 from camm at debian dot org ---
Here is another transcript showing the innermost setjmp/longjmp pair corrupting
the f31 register. It is a little complicated as there is an inner call to the
same code which proceeds successfully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #6 from Richard PALO ---
sorry, I meant to say M_gd2._M_saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #5 from Richard PALO ---
By the way, in gdb, here are the complete u and v variables after
serialisation:
gdb) p u
$1 = {_M_param = {_M_lambda = 2, _M_mu = 1.5, _M_nu = 3}, _M_gd1 = {
_M_param = {_M_alpha = 2, _M_beta = 0.5, _M_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #11 from Oleg Endo ---
Author: olegendo
Date: Thu Sep 25 16:00:58 2014
New Revision: 215609
URL: https://gcc.gnu.org/viewcvs?rev=215609&root=gcc&view=rev
Log:
gcc/
2014-09-25 Oleg Endo
Backport from mainline
2014-09-25 N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #10 from Oleg Endo ---
Author: olegendo
Date: Thu Sep 25 15:53:31 2014
New Revision: 215608
URL: https://gcc.gnu.org/viewcvs?rev=215608&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2014-09-25 Nick Clifton
2014-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #9 from Oleg Endo ---
Author: olegendo
Date: Thu Sep 25 15:50:38 2014
New Revision: 215607
URL: https://gcc.gnu.org/viewcvs?rev=215607&root=gcc&view=rev
Log:
gcc/
PR target/62218
* config/sh/sync.md (atomic_test_and_set_soft_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305
--- Comment #3 from H.J. Lu ---
Created attachment 33566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33566&action=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #4 from Richard PALO ---
>>Could you please add -fno-access-control to the "dg-options" flags at the top
>>of the file and replace the VERIFY check with the following:
>>std::cout << (u._M_param._M_lambda == v._M_param._M_lambda) <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371
Bug ID: 63371
Summary: kind() with function name (not call) as argument
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 25 15:15:06 2014
New Revision: 215604
URL: https://gcc.gnu.org/viewcvs?rev=215604&root=gcc&view=rev
Log:
[gcc]
2014-09-25 Bill Schmidt
PR target/63335
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 25 15:12:42 2014
New Revision: 215603
URL: https://gcc.gnu.org/viewcvs?rev=215603&root=gcc&view=rev
Log:
[gcc]
2014-09-25 Bill Schmidt
PR target/63335
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #5 from Andreas Schwab ---
Please make sure all functions are called exactly as they are defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
Jason Merrill changed:
What|Removed |Added
Attachment #33560|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #7 from Nick Clifton ---
Author: nickc
Date: Thu Sep 25 15:01:46 2014
New Revision: 215602
URL: https://gcc.gnu.org/viewcvs?rev=215602&root=gcc&view=rev
Log:
PR target/62218
* config/sh/sync.md (atomic_fetch_nand_soft_imask):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #4 from camm at debian dot org ---
Created attachment 33564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33564&action=edit
additional gdb transcript showing 0 f31 transmitted to return of Lnk23 in L2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #3 from camm at debian dot org ---
Additional transcript showing the 0 f31 value is transmitted to the return of
the original call through Lnk23 in L2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360
--- Comment #2 from camm at debian dot org ---
Created attachment 33563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33563&action=edit
gdb transcript showing longjmp clobbering of f31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
Markus Trippelsdorf changed:
What|Removed |Added
Summary|[4.8/4.9/5 Regression] |Compilation failure where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #10 from Rich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 25 14:06:09 2014
New Revision: 215599
URL: https://gcc.gnu.org/viewcvs?rev=215599&root=gcc&view=rev
Log:
[gcc]
2014-09-25 Bill Schmidt
PR target/63335
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63370
Bug ID: 63370
Summary: abi::__cxa_demangle fails when demangling globally
defined lambda (or typeid.name returns wrong value)
Product: gcc
Version: 4.9.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369
--- Comment #2 from Bernd Edlinger ---
(In reply to Maxim Ostapenko from comment #1)
> Can't reproduce this with armv7-unknown-linux-gnueabi on current GCC,
> because libsanitizer merge from upstream happened (r215527). Could you try
> to use mor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Thu Sep 25 12:56:57 2014
New Revision: 215597
URL: https://gcc.gnu.org/viewcvs?rev=215597&root=gcc&view=rev
Log:
PR c++/61945
* class.c (warn_hidden): Check for FUNCTION_DECL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63366
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #36 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #35)
> I'm just wondering ... how did/does that work without LRA (i.e. with IRA)?
I'm not sure about the old reload. LRA makes only 3 uses of r0 and it's
relatively ea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
Jonathan Wakely changed:
What|Removed |Added
Component|testsuite |libstdc++
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #2 from Jonathan Wakely ---
Yes, there must be some difference that isn't visible in the serialized output,
which would imply the values fail to do a proper round trip, so we're not
writing them with enough precision.
Maybe we should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
--- Comment #5 from Jonathan Wakely ---
ppc32 doesn't have a 64-bit CAS instruction, so this would need to be done with
a global lock, not an atomic instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #35 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #32)
> Created attachment 33557 [details]
> Patch for SH untyped_call
>
> * config/sh/sh.md (untyped_call): Clobber function value
> registers before call.
six
gcc version 5.0.0 20140925 (experimental) (GCC)
At line 36:
for (i = N; i >= 0; i--)
{
*cp++ = str;
*dp++ = str;
}
Here cp itself is char **, so we move cp on sizeof (char *) on each loop
iteration.
Since N == 128 here, we have 129 iterations, so size of array cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48850
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369
Maxim Ostapenko changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
--- Comment #4 from Mathieu Malaterre ---
As stated in my original report I am running a PowerPC/32bits machine (not an
ARM based one).
AFAIK gcc 4.9.1 does not provide such implementation [*]. Could you please
clarify what you mean by 'libatomi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Thu Sep 25 08:19:14 2014
New Revision: 215587
URL: https://gcc.gnu.org/viewcvs?rev=215587&root=gcc&view=rev
Log:
PR tree-optimization/63341
* tree-vectorizer.h (vect_create_data_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Thu Sep 25 08:17:32 2014
New Revision: 215585
URL: https://gcc.gnu.org/viewcvs?rev=215585&root=gcc&view=rev
Log:
PR tree-optimization/63341
* tree-vectorizer.h (vect_create_data_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Thu Sep 25 08:12:49 2014
New Revision: 215583
URL: https://gcc.gnu.org/viewcvs?rev=215583&root=gcc&view=rev
Log:
PR tree-optimization/63341
* tree-vectorizer.h (vect_create_data_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #4 from rguenther at suse dot de ---
On Thu, 25 Sep 2014, a...@cloudius-systems.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
>
> --- Comment #2 from Avi Kivity ---
> I managed to narrow it down to 400 lines (befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300
--- Comment #4 from Andreas Krebbel ---
Author: krebbel
Date: Thu Sep 25 07:37:36 2014
New Revision: 215582
URL: https://gcc.gnu.org/viewcvs?rev=215582&root=gcc&view=rev
Log:
2014-09-25 Andreas Arnez
PR 63300/debug
* tree.c (check_ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369
Bug ID: 63369
Summary: many asan test cases fail on ARM
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
Mathieu Malaterre changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
Markus Trippelsdorf changed:
What|Removed |Added
CC||cas43 at cs dot stanford.edu
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63367
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
1 - 100 of 104 matches
Mail list logo
