http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Andreas Kreb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Andreas Kreb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> The following code (minus the IF condition) shows that _vptr is not set for
> the allocatable component:
> y.x._data = 0B;
> there should be - bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[OOP] _vptr not set for |[OOP] [F08] _vptr not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Andreas Kreb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399
Andreas Krebbel changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399
--- Comment #3 from Andreas Krebbel ---
Closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58035
Bug ID: 58035
Summary: LRA: S/390: Ada bootstrap fail
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58036
Bug ID: 58036
Summary: [meta-bug] alias.c:base_alias_check says stack
accesses with different base registers don't alias
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
Bug ID: 58037
Summary: sizeof... accepted only in some contexts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
--- Comment #1 from Jonathan Wakely ---
The compiler only rejects it when the member is non-static and uses = for the
initializer.
As a workaround you can use a braced-init-list as the initializer for the
member:
const int rank { sizeof...(D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887
--- Comment #4 from janus at gcc dot gnu.org ---
PR 57036 is very much related to this one ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> PR 57036 is very much related to this one ...
Sorry, that should have been: PR 57306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
Bug ID: 58038
Summary: std::this_thread::sleep_until can cause inifinite
sleep
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
--- Comment #2 from Nick Maclaren ---
Thanks. That's simpler than my workaround.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
--- Comment #1 from Jonathan Wakely ---
I think this should be fixed in not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673
Paolo Carlini changed:
What|Removed |Added
CC||nmm1 at cam dot ac.uk
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #9 from Martin Jambor ---
Created attachment 30577
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30577&action=edit
Simple x86_64 testcase
Simple x86_64 testcase triggering the ICE.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627
--- Comment #13 from Paolo Carlini ---
Jon, I have two spare minutes and if you don't mind I'm taking care of the
stupid change myself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627
--- Comment #14 from Jonathan Wakely ---
Sure, I was going to do it this evening but please go ahead, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627
--- Comment #15 from Paolo Carlini ---
Done for 4.8.2 and 4.9.0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
--- Comment #4 from Paolo Carlini ---
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
--- Comment #2 from Andrew Pinski ---
if (_setjmp (jmpbuf))
I wonder if this is due to _setjmp not being marked as return twice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
--- Comment #3 from David Edelsohn ---
> I wonder if this is due to _setjmp not being marked as return twice.
Is that a missing decoration in the GLIBC declaration?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> if (_setjmp (jmpbuf))
>
> I wonder if this is due to _setjmp not being marked as return twice.
Looking at special_function_p, it should return ECF_RETURNS_TWIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591
--- Comment #5 from acrux ---
same failure with gcc-4.8-20130725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532
Salamanderrake changed:
What|Removed |Added
CC||salamanderrake at gmail dot com
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #10 from Martin Jambor ---
The problem is that the type of the record that contains the scalar
data we are accessing has non-BLK mode despite that we are not
accessing a part of it. This is because it has a zero sized trailing
array:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #11 from Martin Jambor ---
(In reply to Bernd Edlinger from comment #8)
> (In reply to Martin Jambor from comment #7)
> > In any event, it is clear that
> > the code in expand_assignment cannot cope with unaligned tem and non-NULL
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532
--- Comment #5 from Paolo Carlini ---
Just search gcc-patches around the date of Comment #3, no?
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00372.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #2 from Oleg Endo ---
See also PR 29349.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
richard.koolhans at gmail dot com changed:
What|Removed |Added
CC||richard.koolhans at gma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Can't we do a 'static' initialization (of _vptr *and* _data) in both cases?
> As in
>
> struct t2 y = {.x={._vptr=&__vtab_m_T,._data = 0B}}
>
> For this gfc_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001
--- Comment #9 from Steve Kargl ---
The following patch causes gfortran to treat a tab within
a FORMAT statement that same as it does elsewhere for the
appearance of a nonconforming use of tab. The two tet
cases have been adjusted.
Index: gcc/fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #6 from janus at gcc dot gnu.org ---
An updated patch was posted here:
http://gcc.gnu.org/ml/fortran/2013-07/msg00135.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #7 from janus at gcc dot gnu.org ---
Here is a reduced version of the test case from
http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason
still ICEs:
type :: c
end type c
type(c), target :: x
class(c), p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #7)
> Here is a reduced version of the test case from
> http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason
> still ICEs:
>
>
> type :: c
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Giving 'x' the SAVE attribute makes both versions compile without error. I
> guess the original version is still valid, since 'x' should implicitly get
> the SAV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 55207, which changed state.
Bug 55207 Summary: Automatic deallocation of variables declared in the main
program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #65 from Oleg Endo ---
(In reply to Oleg Endo from comment #64)
>
> would be simplified to this:
>
> mov.l @(4,r4),r1
> tst r1,r1 // T = @(4,r4) == 0
> .L3:
> bt/s.L5
> mov #1,r1
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
--- Comment #29 from Paolo Carlini ---
Iain?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Alan Modra changed:
What|Removed |Added
Known to work||4.7.2
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #12 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #11)
>> Well, I believe this
>> unaligned arrays are generally broken.
>>
>> consider this example:
> With or
> without the patch? If without the patch and you are r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039
Bug ID: 58039
Summary: -ftree-vectorizer make a loop crash on non-aligned
memory
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039
--- Comment #1 from Alexander Barkov ---
The bug is known to repeat on the following operating systems:
- Fedora 17
- Ubuntu 13.04
- OpenSUSE 11.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
Bug ID: 58040
Summary: Cannot take address-of public using-declaration of
member from protected base class
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severi
58 matches
Mail list logo
