https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66325
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Sun Jun 14 07:05:03 2015
New Revision: 224463
URL: https://gcc.gnu.org/viewcvs?rev=224463&root=gcc&view=rev
Log:
PR middle-end/66325
* c-decl.c (start_enum): Set TYPE_PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #3 from Eric Botcazou ---
> There should be at least some flag available, such that we can set such a
> flag and have the compiler generate only a single jump for the method with
> single ampersand.
You missed the point though, the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533
Bug ID: 66533
Summary: ICE: in dependent_type_p, at cp/pt.c:21073
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65488
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from vrie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66385
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sun Jun 14 10:08:00 2015
New Revision: 224465
URL: https://gcc.gnu.org/viewcvs?rev=224465&root=gcc&view=rev
Log:
2015-06-14 Thomas Koenig
PR fortran/66385
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #4 from Fisnik ---
(In reply to Eric Botcazou from comment #3)
> > There should be at least some flag available, such that we can set such a
> > flag and have the compiler generate only a single jump for the method with
> > single amp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #5 from Eric Botcazou ---
> Compiler should not generate the same code, and should listen to the
> developer, when she/he connects predicates with single `&'. I already wrote
> that I did benchmarks, and also mentioned a paper from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #6 from Andreas Schwab ---
If a and b are side-effect-free, pure-boolean expressions then `a && b' and `a
& b' are completely equivalent and there is no reason to generate different
code for them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66534
Bug ID: 66534
Summary: Compilation error of gfortran building on YDL6.2
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #7 from Fisnik ---
(In reply to Eric Botcazou from comment #5)
> > Compiler should not generate the same code, and should listen to the
> > developer, when she/he connects predicates with single `&'. I already wrote
> > that I did ben
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66534
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #8 from Fisnik ---
(In reply to Andreas Schwab from comment #6)
> If a and b are side-effect-free, pure-boolean expressions then `a && b' and
> `a & b' are completely equivalent and there is no reason to generate
> different code for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #9 from Jonathan Wakely ---
(In reply to Fisnik from comment #8)
> To this end, the compiler should respect the code written by the developer.
As far as the C++ standard is concerned the built-in && and & operators for
type bool are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719
--- Comment #9 from Louis Dionne ---
I can confirm that my original use case now works. Thanks a bunch!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66508
--- Comment #5 from Fan You ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Fan You from comment #3)
> > (In reply to Dominique d'Humieres from comment #2)
> > > Duplicate of pr66448? Which revision are you using?
> >
> > Just updat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65102
--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> requested approval for fdl.texi part from docs co-maintainer:
> https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01056.html
Posted updated patch: https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65511
--- Comment #7 from vries at gcc dot gnu.org ---
pinged patches at:
- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00976.html
- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00977.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66535
Bug ID: 66535
Summary: segfault in gen_subprogram_die after debug-early merge
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483
Lisandro Damián Nicanor Pérez Meyer changed:
What|Removed |Added
CC||perezmeyer at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483
--- Comment #6 from Lisandro Damián Nicanor Pérez Meyer ---
FWIW, it seems fixed in the linaro branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483
Thomas Preud'homme changed:
What|Removed |Added
CC||joseph at codesourcery dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483
--- Comment #8 from joseph at codesourcery dot com ---
I have no backport plans for this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66536
Bug ID: 66536
Summary: [5/6 Regression] ICE in build_ctor_subob_ref, at
cp/tree.c:2534
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66527
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429
--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 35777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35777&action=edit
tentative patch
Using this patch, we avoid the ICE. Not sure if this is the right way to fix
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66528
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Thomas Koenig from comment #3)
> (In reply to Dominique d'Humieres from comment #2)
>
> > Usual suspect r223677 (pr66082).
>
> I don't believe that a change to trans-array.c can cause
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242
Eric Botcazou changed:
What|Removed |Added
Target|arm-eabi, |
|x86_64-apple-darwin1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66537
Bug ID: 66537
Summary: An explicit default constructor is accepted when
initializing from empty braces
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66281
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #12 from plokinom at gmail dot com ---
I can confirm this still happens with g++ 5.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
Paul Thomas changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #3 from Paul Thomas ---
Created attachment 35779
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35779&action=edit
draft patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #4 from Paul Thomas ---
Testcase:
! Test vehicle for submodules
! 14th June 2015
!
! Paul Thomas - check1406b.diff applies
!
! FIXED OR MOSTLY FIXED:
! Access in submodules to PROCEDURE COMPONENTS - FIXED 06/06/2015
! MODULE FUNCTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66537
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66537
--- Comment #2 from Ville Voutilainen ---
(In reply to Daniel Krügler from comment #1)
> Isn't that similar to bug 54835? As far as I remember Jason interprets the
> standard that the code should be valid, see his comments in above mentioned
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #19 from rusty at rustcorp dot com.au ---
I like WUR as a sanity-check, and it is useful that more and more library
authors are using it (generally quite well). As Andrew points out, this has
taken 10 years! The downside is that fals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242
--- Comment #3 from simon at pushface dot org ---
(In reply to Ramana Radhakrishnan from comment #2)
> Patches on mailing list please along with a testcase and stating how it was
> regression tested.
Done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66538
Bug ID: 66538
Summary: Parameter not in scope of generic lambda trailing
decltype
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
--- Comment #15 from Jan Hubicka ---
Author: hubicka
Date: Sun Jun 14 23:40:12 2015
New Revision: 224471
URL: https://gcc.gnu.org/viewcvs?rev=224471&root=gcc&view=rev
Log:
PR ipa/66181
* lto.c (compare_tree_sccs_1): Do not compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66539
Bug ID: 66539
Summary: Missing parentheses in jit dumps
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assi
43 matches
Mail list logo
