https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69534
--- Comment #1 from Andrew Pinski ---
Try using -fno-delete-null-pointer-checks, a lot of C++ code violates the rule
about calling a class method with a null pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
--- Comment #6 from rguenther at suse dot de ---
On January 29, 2016 10:45:12 PM GMT+01:00, "glisse at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
>
>--- Comment #5 from Marc Glisse ---
>(In reply to rguent...@su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533
--- Comment #8 from rguenther at suse dot de ---
On January 30, 2016 4:10:12 AM GMT+01:00, law at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533
>
>--- Comment #7 from Jeffrey A. Law ---
>I haven't looked in detail, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69049
--- Comment #2 from night_ghost at ykoctpa dot ru ---
1) this is part of Arduino project so it should #include Arduino.h
2) GCC 5.3 don't has this bug so it can be closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37262
--- Comment #5 from Martin Sebor ---
To make clear what I meant by "not optimal" in comment #4, and focusing on
powepc64le output with -O2 for the test case in comment #1, trunk (6.0) emits
the code below. The first branch (to .L2) is superfluou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37262
--- Comment #4 from Martin Sebor ---
I confirm that there are no duplicated branch instructions in object code
emitted by GCC 6.0, although the branches that are there don't look quite
optimal.
I built the gcc-5-branch on powerpc64-linux and the
error (as it must) because the the THIS argument is not also an
array:
gfortran-bug-20160129.f90:46:8:
call x%sub ([1,2])
1
Error: Actual argument at (1) for INTENT(INOUT) dummy ‘this’ of ELEMENTAL
subroutine ‘sub_elem’ is a scalar, but another actual argument is an array
Here'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535
--- Comment #5 from Richard Henderson ---
Created attachment 37525
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37525&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533
--- Comment #7 from Jeffrey A. Law ---
I haven't looked in detail, but presumably we're classifying this as a bug in
Python? Do we want/need to keep this BZ open in GCC itself?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69562
David changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69562
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
Martin Sebor changed:
What|Removed |Added
Target|powerpc*-*-*|m68k-*-linux-gnu,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Sat Jan 30 01:20:27 2016
New Revision: 233007
URL: https://gcc.gnu.org/viewcvs?rev=233007&root=gcc&view=rev
Log:
2016-01-29 Bill Schmidt
PR target/65546
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #8 from David Merillat ---
(In reply to Andrew Pinski from comment #6)
> Actually bug 52023 is a better reason for the difference between __alignof__
> and _Alignof.
>
> *** This bug has been marked as a duplicate of bug 52023 ***
Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Sat Jan 30 01:18:43 2016
New Revision: 233006
URL: https://gcc.gnu.org/viewcvs?rev=233006&root=gcc&view=rev
Log:
2016-01-29 Bill Schmidt
PR target/65546
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69562
Bug ID: 69562
Summary: cow-stdexcept.cc compile errors due to __GXX_WEAK__
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #10 from Vladimir Makarov ---
(In reply to Alexandre Oliva from comment #6)
> Created attachment 37498 [details]
> Patch I'm testing to fix the bug
>
> LRA wants harder than reload to avoid creating a stack slot to satisfy insn
> con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #9 from Vladimir Makarov ---
(In reply to Alexandre Oliva from comment #6)
> Created attachment 37498 [details]
> Patch I'm testing to fix the bug
>
> LRA wants harder than reload to avoid creating a stack slot to satisfy insn
> cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #7 from Jonathan Wakely ---
(In reply to David Merillat from comment #0)
> DefaultStruct s;
> printf( "DefaultStruct: offset=%d, struct align=%d, member align=%d,
> type align=%d\n",
> offsetof(Default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023
Andrew Pinski changed:
What|Removed |Added
CC||david.merillat at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #6 from Andrew Pinski ---
Actually bug 52023 is a better reason for the difference between __alignof__
and _Alignof.
*** This bug has been marked as a duplicate of bug 52023 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
Andrew Pinski changed:
What|Removed |Added
CC||david.merillat at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69561
Bug ID: 69561
Summary: MULTILIB_EXCLUSIONS is not documented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #4 from David Merillat ---
(In reply to Jonathan Wakely from comment #2)
> See ADJUST_FIELD_ALIGN at
> https://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html#Storage-Layout
>
> unsigned long long on x86 is such a type.
Thank you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386
Michael Meissner changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
--- Comment #25 from Martin Jambor ---
Author: jamborm
Date: Fri Jan 29 23:01:54 2016
New Revision: 233001
URL: https://gcc.gnu.org/viewcvs?rev=233001&root=gcc&view=rev
Log:
[PR 69355] Correct hole detection when total_scalarization fails
2016-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #9 from Peter Bergner ---
I think we have another bug in addition to the bug where we reuse a register
that is already in use. We have the rtl below which is used to initialize a[]
before the call to foo:
(insn 5 39 40 2 (set (reg/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520
--- Comment #5 from Harald Anlauf ---
Created attachment 37524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37524&action=edit
Patch which uses prefix "no-"
Here you go.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #11 from David Malcolm ---
(In reply to David Malcolm from comment #10)
> The ultimate right fix (for both) may be to fix linemap_compare_locations to
> cope with macro locations.
...then again, Jakub's patch from comment #4 may be OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67031
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #10 from David Malcolm ---
(In reply to Jakub Jelinek from comment #3)
> Well, that one has been introduced in r232893, while this one far earlier.
They could be symptoms of the same problem though.
Quoting myself from https://gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
--- Comment #2 from David Malcolm ---
(In reply to David Malcolm from comment #1)
linemap_compare_locations does the right thing if passed a pair of ordinary
locations, or if both locations are within the same macro expansion.
It generates nonse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
--- Comment #5 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #4)
> I think there is a misunderstanding. A replacement is still allowed if it
> is a single operation as that replaces at least one other (the one we are
> simplif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69049
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #13 from Steve Ellcey ---
I have submitted a patch for this defect:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02350.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650
--- Comment #11 from Vincent ---
Just tested with 5.3.0, still there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #3 from joseph at codesourcery dot com ---
This is where C distinguishes C11 _Alignof (the minimum alignment the type
is guaranteed to have in all contexts, so 4, see min_align_of_type) from
GNU C __alignof (the normal alignment of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #11 from Mikael Morin ---
(In reply to vehre from comment #9)
> I am still wondering whether there isn't a counterexample where this is not
> working, i.e., we have lhs-rhs-dependency that is polymorphic. But because
> assignment to (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #10 from Mikael Morin ---
Here is a variant that fails similarly (even with the patch) with optional
arguments.
type :: t
integer :: c
end type t
type(t), dimension(5) :: a, b, c
a = t(1)
b = t(7)
c = t(13)
call d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69518
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336
--- Comment #14 from rguenther at suse dot de ---
On January 29, 2016 8:09:02 PM GMT+01:00, wdijkstr at arm dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336
>
>Wilco changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69518
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 29 20:37:25 2016
New Revision: 232998
URL: https://gcc.gnu.org/viewcvs?rev=232998&root=gcc&view=rev
Log:
PR debug/69518
* c-decl.c (finish_struct): Clear C_TYPE_IN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #4 from Manuel López-Ibáñez ---
Pre rich locations, it should have looked like
# [name]:[locus]:
#
# some code
# 1
# [name]:[locus2]:
#
# some other code
# 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68741
John David Anglin changed:
What|Removed |Added
Component|libstdc++ |target
--- Comment #1 from John Davi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69463
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459
--- Comment #17 from Uroš Bizjak ---
*** Bug 69463 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551
--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jan 29 19:52:30 2016
New Revision: 232996
URL: https://gcc.gnu.org/viewcvs?rev=232996&root=gcc&view=rev
Log:
Backport from mainline
2016-01-29 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305
Richard Henderson changed:
What|Removed |Added
Summary|[5/6 Regression] wrong code |[5 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
--- Comment #4 from rguenther at suse dot de ---
On January 29, 2016 6:39:07 PM GMT+01:00, "jgreenhalgh at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
>
>James Greenhalgh changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #6)
> Related to pr69544. Note that compiling the test with 5.3.0 or trunk (6.0)
> gives now an ICE, r218570 gives the error and r218658 gives the ICE.
Hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69559
amker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from amke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #8)
> then the second one doesn't work. I cannot think a way to make the above
> work properly without breaking something else.
Actually, the history check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69299
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #13 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #8 from Manuel López-Ibáñez ---
So input_location does not point to foo but to column 1, then the expansion
location of the pragmas is the closing paren because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817#c3
In terms of exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69463
--- Comment #2 from Uroš Bizjak ---
(In reply to Zdenek Sojka from comment #1)
> On trunk, this got fixed between r232939 (fails) and r232986 (OK). r232955
> fixed PR69459, so this might be a duplicate.
There are actually two bugs in the compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69559
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> If you are using a sysroot, you cannot bootstrap the compiler, you can build
> a cross compiler only.
You can use chroot to do the bootstrap though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69299
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 29 18:47:17 2016
New Revision: 232993
URL: https://gcc.gnu.org/viewcvs?rev=232993&root=gcc&view=rev
Log:
2016-01-29 Vladimir Makarov
PR target/69299
* co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69559
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553
--- Comment #5 from Markus Trippelsdorf ---
I think the real culprit is r228679.
Honza?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65795
vehre at gcc dot gnu.org changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69418
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451
vehre at gcc dot gnu.org changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69418
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459
--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jan 29 18:25:13 2016
New Revision: 232992
URL: https://gcc.gnu.org/viewcvs?rev=232992&root=gcc&view=rev
Log:
PR target/69459
* config/i386/constraints.md (C):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550
Yichao Yu changed:
What|Removed |Added
CC||yyc1992 at gmail dot com
--- Comment #17 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69463
--- Comment #1 from Zdenek Sojka ---
On trunk, this got fixed between r232939 (fails) and r232986 (OK). r232955
fixed PR69459, so this might be a duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #2 from Jonathan Wakely ---
See ADJUST_FIELD_ALIGN at
https://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html#Storage-Layout
unsigned long long on x86 is such a type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #1 from Jonathan Wakely ---
(In reply to David Merillat from comment #0)
> I checked the ISO C++ spec, section 3.11, and it says "The alignment
> requirement of a complete type can be queried using an alignof expression",
> so if alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
Bug ID: 69560
Summary: x86_64: alignof(uint64_t) produces incorrect results
with -m32
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #7 from Jakub Jelinek ---
In handle_pragma_diagnostic
(gdb) p input_location
$1 = 324032
(gdb) p expand_location (input_location)
$2 = {file = 0x7fffe472 "pr69558.c", line = 17, column = 1, data = 0x0,
sysp = false}
(gdb) p loc
$3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491
--- Comment #6 from Dominique d'Humieres ---
Related to pr69544. Note that compiling the test with 5.3.0 or trunk (6.0)
gives now an ICE, r218570 gives the error and r218658 gives the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #42 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jan 29 18:03:42 2016
New Revision: 232991
URL: https://gcc.gnu.org/viewcvs?rev=232991&root=gcc&view=rev
Log:
Revert revsion 229087 changes in lra-spills.c
r229087, which caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530
--- Comment #15 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jan 29 18:03:42 2016
New Revision: 232991
URL: https://gcc.gnu.org/viewcvs?rev=232991&root=gcc&view=rev
Log:
Revert revsion 229087 changes in lra-spills.c
r229087, which caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69559
Bug ID: 69559
Summary: incompatible system library/header other than the one
in sysroot is used to build intermediate binaries in
gcc bootstrap
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544
--- Comment #3 from Dominique d'Humieres ---
> The problem is that the location passed to %L is zero (both line and next).
> Is this desired/expected?
Related to/duplicate of pr44491.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #0)
> warns about deprecated use, while before that we didn't warn.
It would be useful to see the locations in the output (and whether the warning
uses %q+), sin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #4)
> Reverting one minor part of those changes fixes both of the PRs though:
> --- gcc/c-family/c-pragma.c.jj2016-01-15 21:57:00.0 +0100
> +++ gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544
Manuel López-Ibáñez changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Jonathan Wakely changed:
What|Removed |Added
CC||tprince at computer dot org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530
--- Comment #14 from Vladimir Makarov ---
(In reply to H.J. Lu from comment #13)
> (In reply to Vladimir Makarov from comment #12)
> > (In reply to H.J. Lu from comment #11)
> > > (In reply to H.J. Lu from comment #10)
> > > > Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550
--- Comment #16 from Jonathan Wakely ---
OK, given that using a zero-sized array for both members works I would say we
probably don't need to keep this open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266
--- Comment #9 from tprince at computer dot org ---
Trunk on 2016-01-29 is bootstrapping successfully, after dealing with the
reluctance of the build to update config.cache in several directories (gcc,
libcpp, libstdc++-v3, libgomp). Although I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #4 from Jakub Jelinek ---
Reverting one minor part of those changes fixes both of the PRs though:
--- gcc/c-family/c-pragma.c.jj 2016-01-15 21:57:00.0 +0100
+++ gcc/c-family/c-pragma.c 2016-01-29 18:34:51.743943283 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
--- Comment #9 from Martin Sebor ---
I see the difference now. Thanks for clarifying it! It makes sense that these
two are separate requests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
Jakub Jelinek changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553
--- Comment #4 from Andrew Pinski ---
We go from:
_3 = &MEM[(const struct array[2] &)t_2(D)][0];
test1 (_3);
_5 = &MEM[(const struct array[2] &)t_2(D)][1];
test1 (_5);
_7 = &MEM[(const int[2] &)t_2(D)][1];
foo (_3, _7);
_9 = &MEM[(c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #2 from Andrew Pinski ---
I think this is the same as bug 69543.
1 - 100 of 205 matches
Mail list logo
