https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086
Richard Biener changed:
What|Removed |Added
CC||seurer at linux dot
vnet.ibm.com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69656
--- Comment #13 from Markus Trippelsdorf ---
Ah, clang only takes over 11 minutes when I use the -S switch.
Without it, clang finishes in only 1:30 minutes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #24 from Dominique d'Humieres ---
FIXED??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Keywords||ra
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #25 from Richard Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371
James Greenhalgh changed:
What|Removed |Added
Target|arm-none-eabi |arm-none-eabi,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69656
--- Comment #14 from Markus Trippelsdorf ---
> A good start would be to try individual ubsan sanitizers to spot the "worst"
> one
> (I guess overflow or maybe null/alignment).
Most individual ubsan sanitizers are in the noise. Here's a list of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69673
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #5 from Richard Biener ---
Samples: 2M of event 'cycles', Event count (approx.): 1928893785632
36.40% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1130_
28.60% gromacs_peak.am gromacs_peak.amd64-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #6 from Richard Biener ---
Created attachment 37580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37580&action=edit
preprocessed source
source for the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639
--- Comment #3 from dave.anglin at bell dot net ---
On 2016-02-04 7:04 AM, rguenth at gcc dot gnu.org wrote:
> I think this is "known" to be an issue, so did you confirm the required stack
> space grow or so? And whether that's target specific?
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #8 from Richard Biener ---
Ok, it's if in the old code operand zero didn't match we didn't process further
operands which may have had the '%'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #7 from Richard Biener ---
So the main question remains - why's the patch not a no-op on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #9 from Richard Biener ---
Slowdown also reproduces with -fno-schedule-insns2 which makes reading the
assembly difference easier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
--- Comment #16 from Dominique d'Humieres ---
See also pr53086 and pr69368.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69673
--- Comment #2 from petschy at gmail dot com ---
Is this an accidental omission in the std, or allowing member access would
cause some trouble?
Thanks, Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69674
Bug ID: 69674
Summary: hsa offloading, -m32: "internal compiler error: in
hsa_build_append_simple_mov"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
Bug ID: 69675
Summary: [6 Regression] [graphite] ICE: verify_ssa failed
(definition in block 42 does not dominate use in block
34)
Product: gcc
Version: 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #2 from Segher Boessenkool ---
Does not fail on gcc110 (P7 BE).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #5 from vries at gcc dot gnu.org ---
The -O0 test passes with -ftoplevel-reorder.
With -fno-toplevel-reorder, the failure shows up for the other levels:
...
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #3 from Segher Boessenkool ---
... but fails with -mcpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Segher Boessenkool from comment #3)
> ... but fails with -mcpu=power8.
Yeah. I forgot to mention that I configure gcc with --with-cpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #4 from Markus Trippelsdorf ---
(In reply to Segher Boessenkool from comment #3)
> ... but fails with -mcpu=power8.
Yeah. I forgot to mention that I configure gcc with --with-cpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #6 from Segher Boessenkool ---
Choosing alt 3 in insn 9: (0) ws (1) j {*movtf_64bit_dm}
Creating newreg=229 from oldreg=171, assigning class VSX_REGS to r229
9: r229:TF=0.0
REG_EQUAL 0.0
Inserting insn r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
--- Comment #3 from David Malcolm ---
Issue appears to be with rich_location::override_column, it's called by
cpp_diagnostic_with_line, but it doesn't seem to be working. Am investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69658
--- Comment #3 from Paolo Carlini ---
Hi Jakub and thanks. I'm looking at your patchlet and putting it together my
notes at the time, and IMO it makes a lot of sense: I even remember briefly
wondering if calling reshape_init redundantly could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67922
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |SUSPENDED
Summary|std::unor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
ryan.burn at gmail dot com changed:
What|Removed |Added
CC||ryan.burn at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
Jakub Jelinek changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #9 from amker at gcc dot gnu.org ---
Sorry for missing this. I will study the case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #3 from Gerhard Steinmetz
---
Thank you for commenting.
A few comments will follow with melt down (simplified) test cases.
Hopefully, nothing gets lost.
It might have been better to post a handful of separate problem reports
inste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #4 from Gerhard Steinmetz
---
Applying same operations as in comment 1 to derived_external_function_1.f90 :
$ cat z2.f90
module m
private
type t
integer g
end type
end
type(t) function f() result(ff)
use m
ff%g = 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #5 from Gerhard Steinmetz
---
The ICE with associate_6.f03 and -fmodule-private
depends on including "implicit none" in main program :
$ cat z3.f90
module m
private
contains
pure function func (n) result (f)
integer, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69636
--- Comment #6 from Gerhard Steinmetz
---
And for visibility of functions etc., a reduced and modified entry_16.f90 :
$ cat z4.f90
module complex
private :: cx_cadr, cx_radc
type cx
integer :: re
integer :: im
end type
interfac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659
--- Comment #3 from Gerhard Steinmetz
---
Responsible is the class declaration of "x" :
$ cat z1.f90
program p
type t
integer :: a
end type
contains
subroutine s (x)
class(t), intent(inout) :: x(:)
print *, x(1)%a
end
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659
--- Comment #4 from Gerhard Steinmetz
---
Another test scheme :
$ cat z4.f90
module m
type t
class(*), allocatable :: z(:)
end type
contains
subroutine s (x)
class(*), intent(in) :: x(:)
print *, size(x)
end subrou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
--- Comment #4 from Gerhard Steinmetz
---
As known, causative is the class declaration of "a", when using size(a).
Some variants, replacing "class" with "type" :
$ cat z2.f90
module m
type t
end type
contains
function foo(a, b) result(ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
--- Comment #6 from wilco at gcc dot gnu.org ---
Author: wilco
Date: Thu Feb 4 18:23:35 2016
New Revision: 233145
URL: https://gcc.gnu.org/viewcvs?rev=233145&root=gcc&view=rev
Log:
This patch fixes an exponential issue in ccmp.c. When deciding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||openmp
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #7 from iverbin at gcc dot gnu.org ---
I believe we should drop support of offloading without linker plugin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to iverbin from comment #7)
> I believe we should drop support of offloading without linker plugin.
Same failures occur with -fuse-linker-plugin though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
Michael Meissner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69676
Bug ID: 69676
Summary: [4.9 Regression] Many AVX512 test failures
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69676
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|[4.9 Regression] Many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Bug ID: 69677
Summary: [6 Regression] bootstrap failed with
--with-arch=corei7 --with-cpu=corei7
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #1 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #0)
...
>0x086ffe29 <+25>: mov%ecx,(%esp)
>0x086ffe2c <+28>: mov%ebx,0x4(%esp)
...
> => 0x086ffe63 <+83>: movdqa (%esp),%xmm2
...
> (gdb) p $esp
> $1 = (vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #8 from Vladimir Makarov ---
(In reply to Michael Meissner from comment #7)
> The error is LRA requires that every register that a constraint targets be a
> valid register for the mode. In this case, the 3 move insns that target
> TF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Uroš Bizjak changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #10 from Michael Meissner ---
I agree it is better to use the right constraints, but it can be easy to
overlook things, especially since reload didn't raise an error.
Particularly when you are using the various iterators and attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #10 from amker at gcc dot gnu.org ---
This is an ivopt bug all the time. As designed, ivopt tries to identify and
reuse induction variables in the original input. Apparently we don't need to
compute such original biv with new code be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #9 from Michael Meissner ---
Created attachment 37582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37582&action=edit
Proposed patch to fix the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #4 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #3)
> x86_64 gcc doesn't ICE on this with -m32 -O2 -march=corei7 -mtune=corei7
> -mfpmath=sse, nor i686-linux one.
x86_64 gcc doesn't use STV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69676
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69662
--- Comment #2 from Martin Sebor ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00355.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
--- Comment #4 from Bernd Edlinger ---
it is pretty much completely broken also long before gcc-5:
typedef enum __attribute__((mode(QI))) e
{
e1 = 1,
e2 = 2
} ee;
ee x;
int y;
int test()
{
y=sizeof(x);
return x == e1;
}
in "C" sizeof(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69678
Bug ID: 69678
Summary: Missed function specialization + partial
devirtualization opportunity
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #5 from Jakub Jelinek ---
Ah, I see, simplify-rtx.c is miscompiled.
So, it could be just the
convert_scalars_to_vector
hunk of the patch, because STV is clearly enabled in there.
If we have guaranteed that both preferred and incoming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #11 from Michael Meissner ---
Author: meissner
Date: Thu Feb 4 21:05:14 2016
New Revision: 233147
URL: https://gcc.gnu.org/viewcvs?rev=233147&root=gcc&view=rev
Log:
[gcc]
2016-02-04 Michael Meissner
PR target/69667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #6 from H.J. Lu ---
STV turns:
insn 21 19 23 4 (parallel [
(set (reg:DI 102 [ val ])
(and:DI (reg/v:DI 97 [ val ])
(mem/u:DI (plus:SI (mult:SI (reg/v:SI 96 [ mode ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611
Andreas Tobler changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51837
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #8 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 37584 [details]
> gcc6-pr69677.patch
>
> I'm currently bootstrapping/regtesting --with-arch=corei7 --with-cpu=corei7
> --with-fpmath=sse i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69582
Jeffrey A. Law changed:
What|Removed |Added
Depends on||69024, 69021, 69017
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb 4 22:10:56 2016
New Revision: 233152
URL: https://gcc.gnu.org/viewcvs?rev=233152&root=gcc&view=rev
Log:
PR rtl-optimization/69577
Revert:
2015-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68124
--- Comment #13 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb 4 22:10:56 2016
New Revision: 233152
URL: https://gcc.gnu.org/viewcvs?rev=233152&root=gcc&view=rev
Log:
PR rtl-optimization/69577
Revert:
2015-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #45 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb 4 22:10:56 2016
New Revision: 233152
URL: https://gcc.gnu.org/viewcvs?rev=233152&root=gcc&view=rev
Log:
PR rtl-optimization/69577
Revert:
2015-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #26 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 4 22:15:33 2016
New Revision: 233153
URL: https://gcc.gnu.org/viewcvs?rev=233153&root=gcc&view=rev
Log:
PR fortran/69368
* tree-dfa.c (get_ref_base_and_extent):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 4 22:17:05 2016
New Revision: 233154
URL: https://gcc.gnu.org/viewcvs?rev=233154&root=gcc&view=rev
Log:
PR c/69669
* c-decl.c (finish_enum): When honoring mode at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6 Regression] ICE with |[5 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29815
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
--- Comment #4 from David Malcolm ---
Candidate patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00372.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 37585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37585&action=edit
tentative patch
(In reply to iverbin from comment #9)
> (In reply to vries from comment #8)
> > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:09:51 2016
New Revision: 233159
URL: https://gcc.gnu.org/viewcvs?rev=233159&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:09:51 2016
New Revision: 233159
URL: https://gcc.gnu.org/viewcvs?rev=233159&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:16:44 2016
New Revision: 233160
URL: https://gcc.gnu.org/viewcvs?rev=233160&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 4 23:16:44 2016
New Revision: 233160
URL: https://gcc.gnu.org/viewcvs?rev=233160&root=gcc&view=rev
Log:
combine: distribute_notes again (PR69567, PR64682)
As it happens th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69680
Bug ID: 69680
Summary: stdlib.h does not declare aligned_alloc
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69680
--- Comment #1 from Jonathan Wakely ---
(In reply to Jeff Hammond from comment #0)
> It seems that none of the GCC 5.3.0 headers declare this function...
Because GCC doesn't provide a C library, it uses the one from your OS.
Presumably it doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69680
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Thu Feb 4 23:47:21 2016
New Revision: 233161
URL: https://gcc.gnu.org/viewcvs?rev=233161&root=gcc&view=rev
Log:
Test for C99 stdlib.h functions with -std=c++98
PR libstdc++/696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69350
--- Comment #1 from Jonathan Wakely ---
The simplest solution might be something like:
--- a/libstdc++-v3/include/c_global/cmath
+++ b/libstdc++-v3/include/c_global/cmath
@@ -840,7 +840,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3920
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
Bug ID: 69681
Summary: C/C++ FEs do not consider comparisons of distinct
function pointers to be constant expressions
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #1 from Patrick Palka ---
(Sorry about the typos in the original comment. To fix them,
s/since both foo and bar/since both foo and bar are/
s/when comparing and pointers/when comparing pointers/
s/the subsequent declarations/then su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #2 from Andrew Pinski ---
I don't think "(int)(&foo != &bar)" is a valid constant integer expression in
either C or C++. (definitely not in C). This is why GCC rejects it.
101 - 200 of 210 matches
Mail list logo
