On 2022-11-11 07:11, Aaron Ballman wrote:
Clang doesn't require such a linker (we work with various system linkers).
As long as the system linkers continue to work as they have
traditionally worked, we're fine.
the frontend perspective, we can't tell the difference between
"trust me this is
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some f
Snapshot gcc-12-20221112 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20221112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 11/12/22 18:02, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
No, assigning to a function parameter from within another parameter
declaration wouldn't make sense. They should be readonly. Side effects
should be forbidden, I think.
Such assignments are alread
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> > > No, assigning to a function parameter from within another parameter
> > > declaration wouldn't make sense. They should be readonly. Side effects
> > > should be forbidden, I think.
> >
> > Such assignments are already allowed. In a fu
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that as
On 2022-11-10 19:08 +0100, Florian Weimer wrote:
> * Zack Weinberg via Gcc:
>
> > It’s come to my attention (via https://lwn.net/Articles/913505/ and
> > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> > Clang both plan to disable several “legacy” C language features by
> >
Am Samstag, den 12.11.2022, 14:54 + schrieb Joseph Myers:
> On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
>
> > Since it's to be used as an rvalue, not as a lvalue, I guess a
> > postfix-expression wouldn't be the right one.
>
> Several forms of postfix-expression are only rvalues.
>
Hi Joseph,
On 11/12/22 15:54, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
Since it's to be used as an rvalue, not as a lvalue, I guess a
postfix-expression wouldn't be the right one.
Several forms of postfix-expression are only rvalues.
(with a special rule ab
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> Since it's to be used as an rvalue, not as a lvalue, I guess a
> postfix-expression wouldn't be the right one.
Several forms of postfix-expression are only rvalues.
> > (with a special rule about how the identifier is interpreted, different
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>> also
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn't_ do that?
>
> I don't have anyth
On 11/12/22 14:40, Alejandro Colomar wrote:
Hi Joseph,
On 11/12/22 14:03, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);
Is it really ambiguous? Let's show some currently-valid code:
Well,
Hi Joseph,
On 11/12/22 14:03, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);
Is it really ambiguous? Let's show some currently-valid code:
Well, I still don't know what the syntax addition you
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> > struct s { int a; };
> > void f(int a, int b[((struct s) { .a = 1 }).a]);
>
> Is it really ambiguous? Let's show some currently-valid code:
Well, I still don't know what the syntax addition you propose is. Is it
postfix-expression : .
On 11/12/22 13:34, Alejandro Colomar wrote:
struct s {
int a;
};
struct t {
struct s s;
int a;
};
void f(void)
{
struct t x = {
.a = 1,
.s = {
.a = ((struct s) {.a = 1}).a,
},
};
}
From here, a demonstration of what I understood
Hi Joseph,
On 11/11/22 00:19, Joseph Myers wrote:
On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:
One problem with WG14 papers is that people put in too much,
because the overhead is so high and the standard is not updated
very often. It would be better to build such feature more
incrementa
Sent from my iPhone
18 matches
Mail list logo
