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
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,
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
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)_pointer` and the port happens
to use 32 bit pointers, the non-conforming cast is let through.
In case you cast to an
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=gcc=rev
Log:
PR c/66618
PR c/69960
c-family/
* c-common.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Marek Polacek changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
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
