https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231
--- Comment #3 from David Edelsohn ---
(gdb) where
#0 _Z11fancy_abortPKciS0_ (
file=0x1259d104 "/nasfarm/edelsohn/src/src/gcc/tree.c",
line=7297, function=0x125a1140 "tree_to_shwi")
at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231
--- Comment #2 from David Edelsohn ---
Success: [trunk revision 229809]
Fail: [trunk revision 229830]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231
David Edelsohn changed:
What|Removed |Added
Target||powerpc-ibm-aix*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68231
Bug ID: 68231
Summary: AIX bootstrap failure after GOMP 4.5 merge
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68230
Bug ID: 68230
Summary: Unused function parameters not reported by
-Wunused-parameter when only used recursively.
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67942
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Fri Nov 6 01:08:53 2015
New Revision: 229831
URL: https://gcc.gnu.org/viewcvs?rev=229831&root=gcc&view=rev
Log:
PR c++/67942 - diagnose placement new buffer overflow
gcc/cp/
* c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68229
--- Comment #2 from Todd Allen ---
Yeah, the patch code is clumsy. I wrote it that way to mirror the use of a
continue in output_pubnames().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68229
--- Comment #1 from Todd Allen ---
Created attachment 36660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36660&action=edit
Patch to correct gcc 4.8.2
This patch was against gcc-4.8.2-16.2.el7_0 from RHEL 7.0. But it should be
pretty cle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68229
Bug ID: 68229
Summary: .debug_pubnames length field is too large
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228
--- Comment #2 from Micha³ Miros³aw ---
Created attachment 36658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36658&action=edit
gcc assembler output for -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228
--- Comment #1 from Micha³ Miros³aw ---
Created attachment 36657
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36657&action=edit
gcc assembler output for -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057
--- Comment #10 from Jan Hubicka ---
Hmm, the patch does not fix this testcase. I will analyze it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228
Bug ID: 68228
Summary: __builtin_ia32_pbroadcastd256 generates wrong insn at
>= -O1
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #7 from Eric Botcazou ---
> Contrary to the rationale for closing this bug, the option
> -freg-struct-return seems to be supported and does work fine in some cases,
> see below. What do I miss?
That it works in some cases doesn't mea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66324
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67942
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67942
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Thu Nov 5 21:42:10 2015
New Revision: 229827
URL: https://gcc.gnu.org/viewcvs?rev=229827&root=gcc&view=rev
Log:
PR c++/67942 - diagnose placement new buffer overflow
gcc/
* invo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68227
--- Comment #1 from Gerhard Steinmetz
---
Of course, above code works with :
forall (i=1:n) y(i)%a => x
But it works too, if above n is replaced with literal value 2 :
$ cat y3.f90
program p
type t
end type
type t2
type(t),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68227
Bug ID: 68227
Summary: ICE on using variable limit in forall header
(gfc_do_allocate)
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226
--- Comment #1 from Gerhard Steinmetz
---
As a note, a correct code compiles and works :
$ cat z1ok.f90
program p
type t
integer :: n
end type
type(t), pointer :: a(:)
a => f()
print *, a
contains
function f() result(r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226
Bug ID: 68226
Summary: ICE on wrong assignment of function pointer to
allocatable
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68225
--- Comment #2 from Gerhard Steinmetz
---
Here, one or both components are initialized :
$ cat z1.f90
program p
type t
integer, allocatable :: a
end type
type, extends(t) :: t2
integer, allocatable :: b
end type
type(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68225
Bug ID: 68225
Summary: ICE with -Wrealloc-lhs-all on structure constructor
with allocatable components
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68225
--- Comment #1 from Gerhard Steinmetz
---
Adding one type extension :
$ cat z0.f90
program p
type t
integer, allocatable :: a
end type
type, extends(t) :: t2
integer, allocatable :: b
end type
type(t2) :: x
x = t2(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #6 from Sergey Organov ---
Contrary to the rationale for closing this bug, the option -freg-struct-return
seems to be supported and does work fine in some cases, see below. What do I
miss?
$ cat struct.c
typedef struct { int i; } T;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68224
--- Comment #1 from Gerhard Steinmetz
---
Detected when assignment is separated from declaration :
$ cat z6.f90
program p
integer, parameter :: c(null()) = [1, 2]
integer :: a, b
a = c(1)
b = c(2)
end
$ gfortran -g -O0 -Wall -fchec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68224
Bug ID: 68224
Summary: ICE on referencing parameter array with dimension null
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68223
Michael Collison changed:
What|Removed |Added
Target||armeb-none-linux-gnueabihf
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68223
Bug ID: 68223
Summary: [arm] arm_[su]min_cmp pattern fails
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057
--- Comment #9 from Jan Hubicka ---
Patch posted to PR68220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
--- Comment #5 from Jan Hubicka ---
I am testing the following. This bug crept in when adding the dynamic types:
Index: ipa-polymorphic-call.c
===
--- ipa-polymorphic-call.c (re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963
--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Thu Nov 5 18:39:38 2015
New Revision: 229825
URL: https://gcc.gnu.org/viewcvs?rev=229825&root=gcc&view=rev
Log:
[PATCH] tree-scalar-evolution.c: Handle LSHIFT by constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68090
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Thu Nov 5 18:21:30 2015
New Revision: 229823
URL: https://gcc.gnu.org/viewcvs?rev=229823&root=gcc&view=rev
Log:
PR c/68090
* c-parser.c (c_parser_postfix_expression_af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68090
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
--- Comment #4 from Jan Hubicka ---
OK, we have:
(gdb) p context
$4 = {offset = 0, speculative_offset = 96, outer_type = 0x76c77c78,
speculative_outer_type = 0x76cd5348, maybe_in_construction = 1,
maybe_derived_type = 1,
speculative_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68035
--- Comment #2 from Martin Liška ---
Created attachment 36655
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36655&action=edit
Suggested patch
Hello.
Following patch should correctly force calculation of hash values that are
different for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #8 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67846
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67846
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Nov 5 16:47:40 2015
New Revision: 229819
URL: https://gcc.gnu.org/viewcvs?rev=229819&root=gcc&view=rev
Log:
/cp
2015-11-05 Paolo Carlini
PR c++/67846
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192
David Edelsohn changed:
What|Removed |Added
CC||bonzini at gnu dot org
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
Eric Botcazou changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
--- Comment #8 from joseph at codesourcery dot com ---
I don't know what DWARF semantics are meant to be, but the language
semantics are definitely that in C array types are always unqualified,
whereas in C++, while the qualifiers still apply t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
--- Comment #2 from Markus Trippelsdorf ---
Created attachment 36654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36654&action=edit
somewhat reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222
Bug ID: 68222
Summary: _Safe_iterator provides operators the wrapped iterator
can't actually support
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215
--- Comment #1 from Ilya Enkovich ---
It is reproducible without vector comparison on older compilers. Here is a
smaller reproducer:
long double v __attribute__((vector_size(16)));
__typeof((v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #4 from Sergey Organov ---
"WONTFIX: The problem described is a bug which will never be fixed." sounds
very different from "nobody is interested in fixing it but but patches are
welcome". No?
Anyway, setting RESOLVED WONTFIX on an I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68090
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68221
Jakub Jelinek changed:
What|Removed |Added
Keywords||openmp
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68221
Bug ID: 68221
Summary: libgomp reduction-11/12 failures
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.3
Summary|[5.2.1 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68220
Bug ID: 68220
Summary: [5.2.1 Regression] Devirtualization ICE in
record_target_from_binfo, at ipa-devirt.c:2389
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68219
Bug ID: 68219
Summary: ICF could fold functions called via a table of
function pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099
--- Comment #12 from Jonathan Ben-Avraham ---
(In reply to Jonathan Ben-Avraham from comment #10)
> (In reply to Marek Polacek from comment #9)
> > I've built a cross-compiler for arm-linux-gnueabihf target and can't
> > reproduce the issue with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099
--- Comment #11 from Jonathan Ben-Avraham ---
Created attachment 36652
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36652&action=edit
tail -500 of build log for trunk rev 229474 showing build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099
--- Comment #10 from Jonathan Ben-Avraham ---
(In reply to Marek Polacek from comment #9)
> I've built a cross-compiler for arm-linux-gnueabihf target and can't
> reproduce the issue with GCC trunk:
>
> $ ./cc1plus -I. /tmp/test.i -quiet -O3 -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
Eric Botcazou changed:
What|Removed |Added
Summary|ICE with|ICE with
|-freg-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
Sergey Organov changed:
What|Removed |Added
CC||sorganov at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68198
--- Comment #5 from Jeffrey A. Law ---
I've reproduced this issue. We've got a reasonably sized switch statement that
the FSM threader is able to optimize. The problem is we go from something 2k
edges and 1k blocks to 70k edges and 35k blocks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
--- Comment #7 from Richard Biener ---
With the latest patch we again get the broken
<1><50>: Abbrev Number: 8 (DW_TAG_variable)
<51> DW_AT_name: (indirect string, offset: 0x73): harry
<55> DW_AT_decl_file : 1
<56> D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145
Ilya Enkovich changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65148
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 5 Nov 2015, mpolacek at gcc dot gnu.org wrote:
> Started with r218985.
That's what I expected, but my analysis says that that change was OK and
the underlying cause is incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68100
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099
Marek Polacek changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
--- Comment #2 from Vittorio Zecca ---
Traveling now, I cannot check it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #22 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #21)
> Our "column numbers" are also simply a byte-count, I believe, so a tab
> character is treated by us as simply an increment of 1 right now.
>
> I guess th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68218
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #21 from David Malcolm ---
One other issue is that column numbering is rather a mess right now. From my
rich-location patch:
/* Both gcc and emacs number source *lines* starting at 1, but
they have differing conventions for *colu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #20 from David Malcolm ---
(In reply to Teodor Petrov from comment #15)
> I'm speaking as one of Code::Blocks' developers:
> If you implement this we'll for sure use it, because we have many complaints
> similar to the one Eclipse's d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #19 from David Malcolm ---
Parsing textual gcc diagnostics is non-trivial.
FWIW, as noted on the gcc list, I had a go at creating an interchange format
for static analysis results (which includes compiler diagnostics). The aim was
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123
Bug 67123 depends on bug 66927, which changed state.
Bug 66927 Summary: [6 Regression] ICE in gfc_conf_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54262
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53320
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216
--- Comment #3 from Dominique d'Humieres ---
Oops! read pr55735 instead of pr57735.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216
--- Comment #2 from Dominique d'Humieres ---
If this help, I have found the following PRs related to deferred-length:
pr49630, pr49954, pr50221, pr54070, pr55735, pr57735, pr57910, pr63932,
pr65677, pr66408, and pr67674. Will it worth opening a "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217
Richard Biener changed:
What|Removed |Added
Known to fail||4.1.2, 4.3.5
--- Comment #2 from Richar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68205
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68218
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2 from
86 matches
Mail list logo
