https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858
--- Comment #3 from Jakub Jelinek ---
Please also make sure to test stuff like:
!$OMP PARALLEL &
!$ACC& COPYIN(ARGS)
and vice versa (and for free form too). Of course that is invalid, but it
should have testcases and should be properly diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858
--- Comment #2 from Cesar Philippidis ---
Created attachment 33967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33967&action=edit
fixed-form ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
--- Comment #7 from tejohnson at gcc dot gnu.org ---
Author: tejohnson
Date: Fri Nov 14 06:35:35 2014
New Revision: 217537
URL: https://gcc.gnu.org/viewcvs?rev=217537&root=gcc&view=rev
Log:
2014-11-13 Teresa Johnson
gcc:
PR tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63812
--- Comment #4 from Tatsushi Inagaki ---
Ian,
Thank you very much for your helpful clarification. I confirmed that the unit
test passes with both of GC and GCCGO, when we modify the test from:
assertEquals(t, "2.22 PB", HumanSize(2.22*PB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #2 from Yohei Ueda ---
I tested this issue with the latest GC trunk again, and noticed that GC always
compiles programs that contains DNS lookups with dynamic linking even if
-static is specified.
$ go version
go version devel +ae495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #1 from Yohei Ueda ---
Created attachment 33966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33966&action=edit
Fix the DNS lookup problem for statically linked binaries
I created a patch file that fixes this problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #18 from howarth at bromo dot med.uc.edu ---
Another interesting section of code in gcc/config/i386/i386.c
else
{
/* For TARGET_64BIT and MS_ABI, force pic on, in order to enable the
use of rip-relative addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860
--- Comment #3 from Jonathan Wakely ---
Created attachment 33965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33965&action=edit
untested patch
I think this makes the code valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #17 from howarth at bromo dot med.uc.edu ---
The only other place that looks promising is...
case UNSPEC_GOTOFF:
/* Refuse GOTOFF in 64bit mode since it is always 64bit when used.
While ABI specify also 32bit reloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #16 from howarth at bromo dot med.uc.edu ---
I guess we should also consider the instances of UNSPEC_GOTOFF, no? However I
didn't see anything obvious which was conditional against Mach-O where it was
used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #15 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #12)
The question arises if this section...
else if (TARGET_MACHO)
{
fprintf (file, ASM_LONG "%s%d-", LPREFIX, value);
machopic_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855
--- Comment #2 from H.J. Lu ---
It is caused by r213406.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861
Bug ID: 63861
Summary: OpenACC coarray ICE
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860
--- Comment #1 from Andrew Pinski ---
Most likely because 4.8.3 did not fully implement C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860
Bug ID: 63860
Summary: Ill-formed std::pair::swap implementation?
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671
--- Comment #11 from Jan Hubicka ---
>
> I think using sreal is fine - I expect that to be faster than using
> wide_int (and smaller).
>
> Random inlining decisions are bad :/ (and hard to debug)
Yep, this was hitting us from time to time and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859
Bug ID: 63859
Summary: OpenACC DEVICE_RESIDENT clause
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858
Bug ID: 63858
Summary: fixed form OpenACC directive ICE with -fopenacc
-fopenmp
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63857
Bug ID: 63857
Summary: fixed form OpenACC directive ICE with -fopenacc
-fopenmp
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #14 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #12)
> caveat: I have not examined this bug…
>
> .. but I have the following patch in my Q (solves a problem when GAS is the
> assembler). This shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #13 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #11)
> FYI, the darwin linker developer had the following comments on @GOTOFF..
>
> > This may be a red herring.
> >
> > @GOTOFF is a different concept.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #12 from Iain Sandoe ---
caveat: I have not examined this bug…
.. but I have the following patch in my Q (solves a problem when GAS is the
assembler). This should not fire unless the configuration says that the
assembler supports g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63581
--- Comment #2 from xur at gcc dot gnu.org ---
Author: xur
Date: Fri Nov 14 00:30:31 2014
New Revision: 217530
URL: https://gcc.gnu.org/viewcvs?rev=217530&root=gcc&view=rev
Log:
2014-11-13 Rong Xu
gcc:
PR debug/63581
* cfgrtl.c (emit_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #11 from howarth at bromo dot med.uc.edu ---
FYI, the darwin linker developer had the following comments on @GOTOFF..
> This may be a red herring.
>
> @GOTOFF is a different concept. IIRC, the ELF runtime sets of RBX to point
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984
--- Comment #12 from Stupachenko Evgeny ---
Created attachment 33963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33963&action=edit
test case where pragma simd disable vectorization
The following test case compiled with "-Ofast" vectoriz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #12 from iverbin at gcc dot gnu.org ---
Author: iverbin
Date: Thu Nov 13 22:06:15 2014
New Revision: 217524
URL: https://gcc.gnu.org/viewcvs?rev=217524&root=gcc&view=rev
Log:
2014-11-13 Dominique Dhumieres
PR bootstrap/63853
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
--- Comment #6 from tejohnson at gcc dot gnu.org ---
Author: tejohnson
Date: Thu Nov 13 21:51:11 2014
New Revision: 217522
URL: https://gcc.gnu.org/viewcvs?rev=217522&root=gcc&view=rev
Log:
2014-11-13 Teresa Johnson
gcc:
PR tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #10 from howarth at bromo dot med.uc.edu ---
Jakub, Do you have any insights on where the code generation for darwin would
fork from linux to use %rip rather than @GOTOFF. The darwin linker developer
says for large code (which I assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #9 from howarth at bromo dot med.uc.edu ---
Created attachment 33962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33962&action=edit
assembly file for convex_kfeta.s on x86_64 linux
Generated with
gfortran -c -I/home/howarth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831
--- Comment #11 from Iain Sandoe ---
unfortunaely, not quite (yet) complete.
I tried 217505 + c#10 - on x86_64-darwin12 all langs bootstrap proceeds up to
the build of Ada lib.
I reverted r217292 and re-tried - bootstrap passed, so still some g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856
Bug ID: 63856
Summary: [5 Regression] ICE: verify_gimple failed: invalid
argument to gimple call with -O2 -fPIC
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855
Bug ID: 63855
Summary: [5 Regression] ICE: SIGSEGV in ipa_comdats with
-fsanitize=null
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #11 from Jakub Jelinek ---
(In reply to Dominique d'Humieres from comment #9)
> I just completed a clean bootstrap of r217511 with the following patch
This is ok for trunk so that we don't have bootstrap breakages for too long.
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #10 from Andreas Schwab ---
How about using strcspn?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #9 from Dominique d'Humieres ---
I just completed a clean bootstrap of r217511 with the following patch
--- ../_clean/gcc/gcc.c2014-11-13 15:29:00.0 +0100
+++ gcc/gcc.c2014-11-13 17:59:47.0 +0100
@@ -3375,12 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #8 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #4)
> That is not what strchrnul does though.
> If is char *p = strchr (s, c); if (p) return p; else return strchr (s, '\0');
fair enough, if that's preferred
.. was ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #8 from howarth at bromo dot med.uc.edu ---
It appears the two instances of the use of HAVE_AS_GOTOFF_IN_DATA are in
gcc/config/i386/i386.c
void
ix86_output_addr_diff_elt (FILE *file, int value, int rel)
{
const char *directive = AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #7 from Jakub Jelinek ---
I think it is more work than just changing the few spots.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #7 from howarth at bromo dot med.uc.edu ---
This seems to be due to the fact that on x86_64 linux, auto-host.h contains...
/* Define true if the assembler supports '.long foo@GOTOFF'. */
#ifndef USED_FOR_TARGET
#define HAVE_AS_GOTOFF_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854
--- Comment #1 from dmalcolm at gcc dot gnu.org ---
Note to self: this was with r217427.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854
Bug ID: 63854
Summary: Fix memory leaks seen in JIT
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
Ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #5 from Ilya Verbin ---
So, I'll implement strchrnul in libiberty, ok?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63365
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #4 from Jakub Jelinek ---
That is not what strchrnul does though.
If is char *p = strchr (s, c); if (p) return p; else return strchr (s, '\0');
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #3 from Iain Sandoe ---
… does libiberty want an implementation?
const char *
strchrnul (const char *s, int c)
{
char *snew = strrchr(s, c);
if (snew != NULL)
return snew;
return (s + strlen (s));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
Ilya Verbin changed:
What|Removed |Added
CC||iverbin at gmail dot com
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63828
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802
--- Comment #3 from Yury Gribov ---
Agreed, I'll cook a patch for tomorrow then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #6 from howarth at bromo dot med.uc.edu ---
This may be where the usage of @GOTOFF was introduced for -mcmodel=medium...
https://gcc.gnu.org/ml/gcc-patches/2005-07/msg00046.html
https://gcc.gnu.org/ml/gcc-patches/2005-07/msg01134.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802
--- Comment #2 from Jakub Jelinek ---
Supposedly for TYPE_USER_ALIGN we could use TYPE_ALIGN_UNIT, but for other
types we need to use min_align_of_type, otherwise we mishandle e.g. long long
on i?86, which has TYPE_ALIGN_UNIT of 8, but when in st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
Bug ID: 63853
Summary: [5.0 Regression] The use of strchrnul breaks bootstrap
on x86_64-apple-darwin14.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802
Yury Gribov changed:
What|Removed |Added
CC||y.gribov at samsung dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622
--- Comment #36 from Dominique d'Humieres ---
> Please file test suite failures as new PR (one new PR per test failure
> with a different backtrace, ideally). It's very hard to track as such
> (the subject is not accurate any more, the discussion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823
--- Comment #8 from Robert Suchanek ---
Yes, the patch works. Glibc built fine on mips64-linux-gnu target. Thanks Vlad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762
--- Comment #4 from Ramana Radhakrishnan ---
(In reply to Renlin Li from comment #2)
> r278 is derived from r224 which is a VFP_LO_REGS.
>
> find_cost_and_classes assigns r278's class as GENERAL_REGS, and assign it
> hard_reg 2. Another new pseu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63852
Bug ID: 63852
Summary: acats failures On x86_64-apple-darwin14
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #5 from howarth at bromo dot med.uc.edu ---
Checking this issue with current gcc trunk on x86_64 linux, I see differently
handling of sumpartgrid in the emitted assembly...
$ grep sumpartgrid convmix_kfeta.s
movabsq$sumpartgri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
Bug ID: 63851
Summary: ipa-icf miscompiles
gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
--- Comment #5 from tejohnson at gcc dot gnu.org ---
Author: tejohnson
Date: Thu Nov 13 15:36:48 2014
New Revision: 217505
URL: https://gcc.gnu.org/viewcvs?rev=217505&root=gcc&view=rev
Log:
2014-11-13 Teresa Johnson
gcc:
PR tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831
emsr at gcc dot gnu.org changed:
What|Removed |Added
Attachment #33949|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762
--- Comment #3 from Renlin Li ---
Created attachment 33957
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33957&action=edit
ira dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762
--- Comment #2 from Renlin Li ---
r278 is derived from r224 which is a VFP_LO_REGS.
find_cost_and_classes assigns r278's class as GENERAL_REGS, and assign it
hard_reg 2. Another new pseudo register r290 is created from r278, and assigned
to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831
--- Comment #9 from emsr at gcc dot gnu.org ---
This problem exists also with my baby __has_cpp_attribute. I have to actually
solve this.
The real answer to this is to also give c-family/c-ppoutput.c a callback to
pretty print these built-in mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823
--- Comment #7 from Vladimir Makarov ---
Created attachment 33956
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33956&action=edit
The proposed patch
Here is the proposed patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823
--- Comment #6 from Vladimir Makarov ---
(In reply to Robert Suchanek from comment #5)
> It appears that enabling the debug info can trigger the ICE. In the
> testcase, after the patch, an instruction 1136 gets deleted and all
> references to pse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #3 from Dmitry Vyukov ---
Sure, you can do local experimentation in gcc.
Yes, gcc Makefile will need to be updated as well.
But I am more concerned about shadow memory layout. Tsan mapping is somewhat
different from asan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
--- Comment #4 from Teresa Johnson ---
On Thu, Nov 13, 2014 at 1:27 AM, jakub at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721
--- Comment #36 from Yvan Roux ---
Author: yroux
Date: Thu Nov 13 14:00:48 2014
New Revision: 217497
URL: https://gcc.gnu.org/viewcvs?rev=217497&root=gcc&view=rev
Log:
2014-11-13 Yvan Roux
Backport from trunk r216229, r216230.
2014-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823
--- Comment #5 from Robert Suchanek ---
It appears that enabling the debug info can trigger the ICE. In the testcase,
after the patch, an instruction 1136 gets deleted and all references to pseudo
704 meant to be updated.
The following change in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Manuel López-Ibáñez from comment #6)
> Thanks for the testcase. It seems that the GCC_COMPARE_DEBUG=0 uses a
> temporary file
>
> ./cc1 -quiet -iprefix
> /home/manuel/test1/217394M/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63365
clyon at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837
--- Comment #6 from Manuel López-Ibáñez ---
Thanks for the testcase. It seems that the GCC_COMPARE_DEBUG=0 uses a temporary
file
./cc1 -quiet -iprefix
/home/manuel/test1/217394M/build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/
-isystem ./i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
clyon at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63828
--- Comment #6 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Nov 13 13:08:12 2014
New Revision: 217483
URL: https://gcc.gnu.org/viewcvs?rev=217483&root=gcc&view=rev
Log:
Use POINTER_SIZE to check for pointer size
PR tree-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63817
--- Comment #5 from Jan-Benedict Glaw ---
Bug seems to be gone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
Bug ID: 63850
Summary: Building TSAN for Aarch64 results in assembler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Janne Blomqvist changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63846
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #8 from Janne Blomqvist ---
Author: jb
Date: Thu Nov 13 12:05:01 2014
New Revision: 217480
URL: https://gcc.gnu.org/viewcvs?rev=217480&root=gcc&view=rev
Log:
PR 60324 Unbounded stack allocations in libgfortran.
2014-11-13 Janne Blo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63806
--- Comment #5 from Yury Gribov ---
I've posted feature request upstream:
http://llvm.org/bugs/show_bug.cgi?id=21530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63849
Bug ID: 63849
Summary: [4.9/5.0 Regression] ICE on variadic alias template
with wrappers
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Markus Tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839
--- Comment #3 from Richard Biener ---
Ok, so inlining introduces __builtin_unreachable () during inlining of a
noreturn call. Then at some point somebody folds that statement (forwprop) and
ubsan
instrumentation triggers via fold_builtin_0.
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814
--- Comment #11 from Igor Zamyatin ---
Will take a look. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63800
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Igor Zamyatin from comment #7)
> > So, is this compile time failure or runtime failure (or both for two tests)?
>
> You can run the testsuite with "-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
1 - 100 of 115 matches
Mail list logo
