https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90888
--- Comment #2 from Marc Glisse ---
Dup of PR 80738 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780
--- Comment #7 from Eric Gallager ---
(In reply to Uroš Bizjak from comment #0)
> > >> It can be done ultimately, but as a prerequisite, we should have
> > >> warnings in -Wextra for all of
> > >>
> > >> ? boolvar++; ++boolvar;
> > >> ? boolvar--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88139
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780
--- Comment #12 from kargl at gcc dot gnu.org ---
*** Bug 88139 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
--- Comment #15 from Eric Gallager ---
(In reply to Bernhard Reutner-Fischer from comment #8)
> From FSFChangelog.10:
> Mon Feb 12 20:42:11 1996 Randy Smith
>
Does Randy have a Bugzilla account that could be cc-ed here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86157
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #13 from Zack Weinberg ---
Since examples of this error were observed with base 10, I think the warning
should cover 10^i for decimal literal i, too.
Relatedly, “note: ^ performs exclusive or, not exponentiation” might be a nice
addi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889
Bug ID: 90889
Summary: ada: snapshot 20190614 fails to build with LTO
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90888
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
--- Comment #4 from Dominique d'Humieres ---
> Is this PR still a problem? I get no warnings with
>
> % gfcx -o z -Wall -Wsurprising -Wextra a.f90
You need -Warray-temporaries and it is still present at revision r272311.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000
Eric Gallager changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 88000, which changed state.
Bug 88000 Summary: Warn when different local vars regs order may produce
different and so unsupported code [-Wasm-register-var]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86501
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223
--- Comment #5 from Marek Polacek ---
Still ICEs:
$ ./cc1plus -quiet 60223.C
60223.C: In substitution of ‘template void foo(A) [with T =
]’:
60223.C:7:16: required from here
60223.C:7:16: internal compiler error: in unify, at cp/pt.c:22789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90888
Bug ID: 90888
Summary: std::swap bad code gen -- alias analysis insufficient
to remove dead store
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798
Eric Gallager changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89557
--- Comment #9 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail
dot com> ---
(In reply to Richard Biener from comment #5)
> Please provide a compilable testcase.
Done some time ago. Please change the status of this bug from WAITIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
--- Comment #5 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Jun 14 18:41:20 2019
New Revision: 272309
URL: https://gcc.gnu.org/viewcvs?rev=272309&root=gcc&view=rev
Log:
2019-06-14 Harald Anlauf
PR fortran/90577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578
--- Comment #9 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Jun 14 18:41:20 2019
New Revision: 272309
URL: https://gcc.gnu.org/viewcvs?rev=272309&root=gcc&view=rev
Log:
2019-06-14 Harald Anlauf
PR fortran/90577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887
Bug ID: 90887
Summary: [10 Regression] r272186 causes -fcompare-debug failure
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646
--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jun 14 18:17:00 2019
New Revision: 272307
URL: https://gcc.gnu.org/viewcvs?rev=272307&root=gcc&view=rev
Log:
2019-06-14 Steven G. Kargl
PR fortran/89646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|9.0 |tree-ssa
--- Comment #11 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90252
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #10 from Jonathan Wakely ---
Author: redi
Date: Fri Jun 14 18:11:22 2019
New Revision: 272304
URL: https://gcc.gnu.org/viewcvs?rev=272304&root=gcc&view=rev
Log:
PR libstdc++/1 fix filesystem::symlink_status for Windows
The fix f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90770
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Fri Jun 14 18:10:57 2019
New Revision: 272299
URL: https://gcc.gnu.org/viewcvs?rev=272299&root=gcc&view=rev
Log:
PR libstdc++/90770 fix missing src/debug/Makefile
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90252
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Fri Jun 14 18:10:52 2019
New Revision: 272298
URL: https://gcc.gnu.org/viewcvs?rev=272298&root=gcc&view=rev
Log:
PR libstdc++/90252 Check TBB version and ability to link with -ltbb
Back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #12 from Jonathan Wakely ---
(In reply to David Malcolm from comment #11)
> Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
> with comment #6).
>
> Not sure what to call it: "-Wexclusive-or"???
I suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #11 from David Malcolm ---
Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
with comment #6).
Not sure what to call it: "-Wexclusive-or"???
I think we'd want to *not* warn if either of the operands are fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #10 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #9)
> * the "not from the expansion of ’s xor macro" criterion I can see
> possibly being a difficulty, due to how many other bugs there are about
> gcc's handling o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90765
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90877
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90765
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jun 14 16:24:56 2019
New Revision: 272296
URL: https://gcc.gnu.org/viewcvs?rev=272296&root=gcc&view=rev
Log:
Update preferred_stack_boundary only when expanding function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878
--- Comment #6 from H.J. Lu ---
We have
-- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int
OUTER_CODE, int OPNO, int *TOTAL, bool SPEED)
This target hook describes the relative costs of RTL expressions.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #9 from Jakub Jelinek ---
Ok, will retest the updated version and commit, defer the rest to you or
somebody else familiar with what is done there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #8 from Andrew Stubbs ---
On GCN I get the lto_priv names, but not the globalization. I think that shows
what the expected behaviour is, thanks ... I just need to find that magic.
That being so, I think I can confirm that your origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90877
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jun 14 15:41:43 2019
New Revision: 272294
URL: https://gcc.gnu.org/viewcvs?rev=272294&root=gcc&view=rev
Log:
i386: Update SSE <-> integer move costs
Since inline_secondary_mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
Jakub Jelinek changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #10 from Joe ---
probably noticed but code is always "i <" not "i =" as I stated in the previous
comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #1)
> If we make integer register store more expensive, this testcase will
> regress:
>
> [hjl@gnu-cfl-1 unroll]$ cat x.i
> void
> foo (long p2, long *diag, long d, long i)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #9 from Joe ---
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
Joe changed:
What|Removed |Added
Version|7.3.0 |7.4.0
--- Comment #8 from Joe ---
Here is assembl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #6 from Andrew Stubbs ---
There's not observable difference. I don't quite follow what the patch is
trying to achieve, but seems like adding the variable to the offload variables
does not address the issue here.
I've added a hack to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
--- Comment #6 from H.J. Lu ---
After this bug is fixed, we should revisit the workaround for
https://sourceware.org/bugzilla/show_bug.cgi?id=24603
to check if it is still necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68996
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90884
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90884
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Fri Jun 14 14:49:57 2019
New Revision: 272291
URL: https://gcc.gnu.org/viewcvs?rev=272291&root=gcc&view=rev
Log:
PR c++/90884 - stray note with -Wctor-dtor-privacy.
* c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531
--- Comment #10 from Iain Sandoe ---
(In reply to MCCCS from comment #6)
> After reading your comment, I noticed that
> there were two things I forgot to mention:
> But yes, there's no need to hurry
> to fix it. It's existed since
> October 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #6 from Joe ---
Hmmm... Maybe 7.3.0 isn't supported either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #5 from Jakub Jelinek ---
(In reply to Andrew Stubbs from comment #4)
> The problem is that the variables are added to the offload_var_table but not
> exported so that libgomp cannot find the symbol at load time. This causes a
> fatal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
Joe changed:
What|Removed |Added
Version|5.4.0 |7.3.0
--- Comment #5 from Joe ---
Tested with 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #4 from Jonathan Wakely ---
GCC 5.4 is no longer maintained or supported by the GCC project.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
--- Comment #8 from Jason Duerstock ---
(In reply to Joseph S. Myers from comment #0)
> Building an all-languages cross compiler for ia64-linux-gnu, trunk r264193,
> I see the following ICE building libgo
> bytes.go:211:1: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #3 from Joe ---
Changing i to 127 produces following assembly...
volatile unsigned char x;
int main() {
while (1) {
for (unsigned char i = 0 ; i < 127 ; i++) {
x = i;
}
}
}
0090 :
90: 80 e0 ldi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #5 from rguenther at suse dot de ---
On June 14, 2019 2:27:22 PM GMT+02:00, "jamborm at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
>
>--- Comment #4 from Martin Jambor ---
>(In reply to Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
--- Comment #2 from Joe ---
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/5.4.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/5.4.0/lto-wrapper
Target: avr
Configured with: ../gcc/configure -v --enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #27 from Wilco ---
(In reply to dave.anglin from comment #26)
> On 2019-06-10 9:51 a.m., wilco at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
> >
> > --- Comment #25 from Wilco ---
> > I believe this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
Jonathan Wakely changed:
What|Removed |Added
Target||avr-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #4 from Andrew Stubbs ---
The problem is that the variables are added to the offload_var_table but not
exported so that libgomp cannot find the symbol at load time. This causes a
fatal error in a mutex-locked section, which causes lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90886
Bug ID: 90886
Summary: loop/while/for problem
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Jun 14 13:22:33 2019
New Revision: 272287
URL: https://gcc.gnu.org/viewcvs?rev=272287&root=gcc&view=rev
Log:
PR c++/85552 - wrong instantiation of dtor for DMI.
The problem h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90875
Matthew Beliveau changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325
Christoph Hertzberg changed:
What|Removed |Added
CC||chtz at informatik dot
uni-bremen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #6 from Federico Kircheis ---
> With my patch, we wouldn't warn on this second testcase. But clang++
> doesn't warn, either.
Yes, I just wanted to point out that giving warning in unevaluated contexts has
some benefits too.
I believ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #4 from Martin Jambor ---
(In reply to Richard Biener from comment #3)
> ...I also wonder why SRA does not elide the aggregate copy.
SRA has a special condition not to attempt to totally scalarize array
of chars, so that it does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #7 from Iain Sandoe ---
(In reply to John Marshall from comment #6)
> > let's not speculate ... could you (and/or Rainer) try this (untested) patch
> > and
> > see how far it gets you?
>
> Fails in approximately the same place as wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #6 from John Marshall ---
> let's not speculate ... could you (and/or Rainer) try this (untested) patch
> and
> see how far it gets you?
Fails in approximately the same place as without:
../../gcc/configure --disable-nls --disable-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #11 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #10)
> (In reply to John Marshall from comment #9)
> > This has an unfortunate side-effect that the compiler looks in the
> > non-existent /Library/.../MacOSX.sdk/usr/loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #8 from Jonathan Wakely ---
The right heuristic for the warning isn't entirely obvious though.
I think it should only warn when both operands are integer literals. Should all
kinds of integer literals be treated equally? Is 0x11 ^ 0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #7 from Yann Droneaud ---
The issue was noted on twitter by John Regehr, in
https://twitter.com/johnregehr/status/1139295920997068800 and following
messages.
The warning was suggest again by John Regehr in
https://twitter.com/johnreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
--- Comment #7 from Eric Botcazou ---
> I don't understand how that applies in the context of Joseph's
> build-many-glibcs.py script.
This PR is about a compiler issue so I presume that build-many-glibcs.py tests
the compiler at some point? If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #6 from Jonathan Wakely ---
There's nothing wrong about implicit fallthrough, misleading indentation,
ambiguous else, or missing parentheses in nested logic expressions either. But
people get it wrong all the time.
I can't see a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #5 from Richard Biener ---
Maybe we should accept 2**32 as extension ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90884
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #5 from Marek Polacek ---
(In reply to Federico Kircheis from comment #4)
> (In reply to Jonathan Wakely from comment #1)
> > Confirmed. We shouldn't give that warning in unevaluated contexts (decltype,
> > sizeof, etc.) because uneva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
--- Comment #6 from Jason Duerstock ---
(In reply to Eric Botcazou from comment #5)
> Note that you need to test the trunk in order to get the diagnostics, or
> else to configure the 9.x compiler with --enable-checking=release,misc at
> least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #3 from Jonathan Wakely ---
read_bytes(&f, (char *) &(val),
( (n < (2 ^ 8)) ? 1 :
( (n < (2 ^ 16)) ? 2 :
( (n < (2 ^ 24)) ? 3 :
4 ) ) ) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #10 from Iain Sandoe ---
(In reply to John Marshall from comment #9)
> The Homebrew folks have been configuring with a sysroot to work around this
> on Mojave since it came out last year:
>
> --with-sysroot=/Library/Developer/Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #5 from Iain Sandoe ---
(In reply to John Marshall from comment #4)
> (In reply to comment #3)
> > > --- Comment #2 from Iain Sandoe ---
> > > * for the other things, if it's a beta, then perhaps there's some chance
> > > it
> > > w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
John Marshall changed:
What|Removed |Added
CC||John.W.Marshall at glasgow dot
ac.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #4 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #1)
> Confirmed. We shouldn't give that warning in unevaluated contexts (decltype,
> sizeof, etc.) because unevaluated operands have no effects at all, with or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
John Marshall changed:
What|Removed |Added
CC||John.W.Marshall at glasgow dot
ac.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
Jonathan Wakely changed:
What|Removed |Added
Summary|GCC should warning about|GCC should warn about 2^16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #1 from Jonathan Wakely ---
And maybe also 10^X where X is a literal.
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E&search=Search
A sample:
tp->tv_sec = attributes[0] / 10^9;
tp->tv_nsec = attributes[0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
Bug ID: 90885
Summary: GCC should warning about 2^16 and 2^32 and 2^64
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90882
--- Comment #5 from Jonathan Wakely ---
(In reply to Kevin Dewald from comment #1)
> From what I've read, modifying a boolean variable with an int pointer is
> undefined.
Yes.
> Nevertheless, this feels unexpected from a programmers point of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
--- Comment #3 from Jonathan Wakely ---
That was quick!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880
--- Comment #4 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #3)
> Sorry if linking to external bug trackers in comments is bad practice, but I
> did not saw any rule about it.
There's no rule against it, it's useful.
> S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90884
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
1 - 100 of 108 matches
Mail list logo