https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #25 from Daniel Lundin ---
(In reply to jos...@codesourcery.com from comment #24)
> On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
>
Regardless of how one chose to read that part of the standard, fact r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #24 from joseph at codesourcery dot com ---
On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
> In this code
>
> static const int y = 1;
> static int x = y;
>
> y is not an integer constant expression, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #23 from Daniel Lundin ---
(In reply to jos...@codesourcery.com from comment #21)
> On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
>
> > First of all, it is questionable if gcc is still conforming after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #22 from joseph at codesourcery dot com ---
I do however expect there may be cases in GCC 13 where constexpr
initializers of floating type are accepted that do not meet the definition
of arithmetic constant expressions, since GCC is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #21 from joseph at codesourcery dot com ---
On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
> First of all, it is questionable if gcc is still conforming after the change
> discussed here and implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #20 from Daniel Lundin ---
Further info about the "ARM32 port bug".
In case you write code like `(uint32_t)&function_pointer` and the port happens
to use 32 bit pointers, the non-conforming cast is let through.
In case you cast to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Daniel Lundin changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #17 from Jakub Jelinek ---
Author: jakub
Date: Sun Nov 19 17:17:01 2017
New Revision: 254930
URL: https://gcc.gnu.org/viewcvs?rev=254930&root=gcc&view=rev
Log:
PR c/66618
PR c/69960
c-family/
* c-common.h (c_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Marek Polacek changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #15 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #14)
> C++ FE's constexpr.c has bool lval argument to many recursive functions, so
> it can differentiate between cases where you don't want to fold "str"[0] to
> 's'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #13 from Bernd Schmidt ---
I actually tried this a few weeks ago, it's slightly less trivial than it seems
since you don't want to fold away the inside of &("fish"[0]).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Martin Sebor changed:
What|Removed |Added
CC||devel at fresse dot org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #10 from Jonathan Wakely ---
Martin said almost exactly what I was going to say :-)
Compilers are allowed to accept this, as Clang does, but they are not required
to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #8 from Marek Polacek ---
I don't think it is forbidden. The C standard allows some latitude for
constant expressions in initializers, so I think we could accept code as in
Comment 5, i.e. evaluate it to an arithmetic constant expres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Bernd Schmidt changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #5 from Marek Polacek ---
This is basically about
char t = "f"[0];
at the file scope. clang probably started to accept this in 3.8 or in 3.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #4 from felix-gcc at fefe dot de ---
So which part of it is not constant, you would say?
It all looks constant to me. It only operates on constants.
If 3+4 is constant, why should this not be constant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #3 from Jonathan Wakely ---
The C standard says it's not a constant, but clang accepts it as an extension.
That doesn't make it valid C though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #2 from felix-gcc at fefe dot de ---
uh, yes in C.
$ cat test.c
#define TOLOWER(x) (x&~0x20)
#define Word(s) \
s[1] ? s[2] ? s[3] ? \
(TOLOWER(s[0]) << 24) + (TOLOWER(s[1]) << 16) + (TOLOWER(s[2]) << 8) +
TOLOWER(s[3]) : \
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
26 matches
Mail list logo
