在 2024-01-30 12:22, Hans-Peter Nilsson 写道:
It's #APP #NO_APP, not /APP /NO_APP, for x86_64-linux, even for
-masm=intel.
For x86_64-w64-mingw64, GCC emits `/APP`; but Clang still emits `#APP`, as other targets.
(https://gcc.godbolt.org/z/oj8vdGb78)
That said, I guess you're going to modify
by gas as well (within the
> > scope of certain divergence that cannot be changed in gas without
> > risking to break people's code). It could probably be considered to
> > introduce a "strict" mode of Intel syntax, following some / most of
> > what you prop
On 23.01.2024 10:21, LIU Hao wrote:
> 在 2024-01-23 17:03, Jan Beulich 写道:
>> Hmm, that would suggest to me that the Dwarf code abuses the interface.
>> A "name" certainly shouldn't be an expression. And hence the result of
>> the example ought to be
>>
>> .long "LXXYY"-1# "LXXYY" minus on
在 2024-01-23 17:03, Jan Beulich 写道:
Hmm, that would suggest to me that the Dwarf code abuses the interface.
A "name" certainly shouldn't be an expression. And hence the result of
the example ought to be
.long "LXXYY"-1# "LXXYY" minus one
So I shouldn't have checked for `*` right?
Th
On 23.01.2024 10:00, LIU Hao wrote:
> 在 2024-01-23 16:38, Jan Beulich 写道:
>> Right, but this is very "draft". You can't blindly assume the gas you use
>> actually can deal with quotation.
>
> Let's assume that for the time being, but there's something else; see below.
>
>
>>> .refptr.bx:
>>>
在 2024-01-23 16:38, Jan Beulich 写道:
Right, but this is very "draft". You can't blindly assume the gas you use
actually can deal with quotation.
Let's assume that for the time being, but there's something else; see below.
.refptr.bx:
.quad bx
Sure, this one needs quoting then, t
On 23.01.2024 02:27, LIU Hao wrote:
> 在 2024-01-22 16:39, Jan Beulich 写道:
>> Right, I did some work in that direction a while ago. But iirc there are
>> still cases left to be addressed.
>
> Attached is a draft patch for GCC, bootstrapped on {i686,x86_64}-w64-mingw32
> with GCC 13.2 and
> binuti
00:00 2001
From: LIU Hao
Date: Tue, 23 Jan 2024 02:20:29 +0800
Subject: [PATCH] Always quote symbols in Intel syntax
---
gcc/config/i386/i386.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 539083f2fbf8..785c6eda8d
On 20.01.2024 13:40, LIU Hao wrote:
> 在 2024-01-19 17:13, Jan Beulich 写道:
>> But I see a severe issue with your aim at confining strict mode to
>> compiler generated code only: In inline assembly (see your mentioning of
>> APP / NO_APP above) you still potentially reference C symbols. So the
>> amb
在 2024-01-19 17:13, Jan Beulich 写道:
But I see a severe issue with your aim at confining strict mode to
compiler generated code only: In inline assembly (see your mentioning of
APP / NO_APP above) you still potentially reference C symbols. So the
ambiguities don't disappear in APP / NO_APP regions
在 2024-01-19 16:19, Fangrui Song 写道:
It is also unfortunate that whether the displacement is an immediate
or not change the behavior of brackets.
mov eax, DWORD PTR 0 # mov$0x0,%eax
mov eax, DWORD PTR [0]# mov0x0,%eax
mov eax, DWORD PTR sym# mov0x0,%eax with
by gas as well (within the
>> scope of certain divergence that cannot be changed in gas without
>> risking to break people's code). It could probably be considered to
>> introduce a "strict" mode of Intel syntax, following some / most of
>> what you propose; making
On Thu, Jan 18, 2024 at 5:42 PM LIU Hao wrote:
>
> 在 2024-01-18 17:02, Fangrui Song 写道:
> > Thanks for the proposal. I hope that -masm=intel becomes more useful:)
> >
> > Do you have a list of assembly in the unambiguous cases that fail to
> > be parsed today as a gas PR?
> > For example,
>
> Not
On 19.01.2024 02:42, LIU Hao wrote:
> In addition, `as -msyntax=intel -mnaked-reg` doesn't seem to be equivalent to
> `.intel_syntax noprefix`:
>
> $ as -msyntax=intel -mnaked-reg <<< 'mov eax, DWORD PTR gs:0x48' -o a.o
> {standard input}: Assembler messages:
> {standard input}:1: Err
在 2024-01-18 17:02, Fangrui Song 写道:
Thanks for the proposal. I hope that -masm=intel becomes more useful:)
Do you have a list of assembly in the unambiguous cases that fail to
be parsed today as a gas PR?
For example,
Not really. Most of these are results from high-level languages. For exampl
ot be changed in gas without
risking to break people's code). It could probably be considered to
introduce a "strict" mode of Intel syntax, following some / most of
what you propose; making this the default cannot be an option.
Thanks for your reply.
I have attached the Markdown
On 18.01.2024 06:34, LIU Hao wrote:
> My complete proposal can be found at
> <https://github.com/lhmouse/mcfgthread/wiki/Formalized-Intel-Syntax-for-x86>.
> Some ideas actually
> reflect the AT&T syntax. I hope it helps.
I'm sorry, but most of your proposal may e
On Wed, Jan 17, 2024 at 9:34 PM LIU Hao wrote:
>
> Hello,
>
> There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a
> dozen years ago, mostly
> due to compatibility with MASM. I was told that the ambiguity of Intel syntax
> should be classified
&
Hello,
There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a dozen years ago, mostly
due to compatibility with MASM. I was told that the ambiguity of Intel syntax should be classified
as its own limitation and disrecommendation.
Notwithstanding, I am propos
ange?
I think man pages should not use any novel syntax - even syntax newly
added to the C standard or GCC, unless required to express the standard
prototype for a function. They should be written for maximal
comprehensibility to C users in general, who are often behind on knowledge
standar
's not a problem. I was foreseeing more
complex expressions, as I suggested earlier.
Here, also with the context would fully disambiguate
between other uses so I do not think there is any issue with using this
syntax. '$' is much more problematic as people use it in identifiers,
entiating parameters
> from struct members, I think going in that direction may be a good
> idea.
>
> How about '$'?
I don't see how the lookahead issue has anything to do with the choice
of the symbol. Here, also with the context would fully disambiguate
between other use
eases, so I won't be releasing
> man-pages-6.01.1. That means that all changes that I have in the project
> that I
> didn't plan to release until 2024 will be released in a few weeks, notably
> including the VLA syntax.
>
> This means that while this syntax is still an inv
idn't plan to release until 2024 will be released in a few weeks, notably
including the VLA syntax.
This means that while this syntax is still an invent, not something real that
can be used, I need to be careful about the future if I plan to make it public
so soon.
Since we've se
rally doubtful of this whole feature within C
itself.
It serves a purpose in documentation, so in man-pages it seems
fine enough
(but then still could use a different puncuator to not be
confusable with
C syntax).
In man-pages you don't need to invent syntax at all. You can write
int f(
for calling foo is fulfilled. I can see how
being able to just check half of the contract might be
useful, but if it doesn't give full checking then
any proposal for syntax should be even more obviously
orthogonal than the current one.
Your argument is not clear to me.
For
void foo(int
hin C
itself.
It serves a purpose in documentation, so in man-pages it seems
fine enough
(but then still could use a different puncuator to not be
confusable with
C syntax).
In man-pages you don't need to invent syntax at all. You can write
int f(char buf[n], int n);
and in the context of
t; > itself.
> > > It serves a purpose in documentation, so in man-pages it seems
> > > fine enough
> > > (but then still could use a different puncuator to not be
> > > confusable with
> > > C syntax).
> >
> > In man-pages you don't ne
people who
consistently use these annotations.
> The compiler has no choice than to trust the user that the pre-
> condition for calling foo is fulfilled. I can see how
> being able to just check half of the contract might be
> useful, but if it doesn't give full checking then
>
> (but then still could use a different puncuator to not be confusable with
> > C syntax).
>
> In man-pages you don't need to invent syntax at all. You can write
>
> int f(char buf[n], int n);
>
> and in the context of a man page it will be clear to readers what is
> meant,
Considerably more clear than new invented syntax IMHO.
On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
> like. But I'm generally doubtful of this whole feature within C itself.
> It serves a purpose in documentation, so in man-pages it seems fine enough
> (but then still could use a different puncuator to not be confusable with
&g
checked
is no pre-condition at all, as only then it can become a guarantee for the
body.
The compiler has no choice than to trust the user that the pre-condition
for calling foo is fulfilled. I can see how being able to just check half
of the contract might be useful, but if it doesn'
Am Dienstag, dem 29.11.2022 um 14:58 + schrieb Michael Matz:
> Hey,
>
> On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
>
> > How about the compiler parsing the parameter list twice?
>
> This _is_ unbounded look-ahead. You could avoid this by using ".&qu
Hey,
On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
> How about the compiler parsing the parameter list twice?
This _is_ unbounded look-ahead. You could avoid this by using "." for
your new syntax. Use something unambiguous that can't be confused with
other syntactic ele
On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
> I guess asking the compiler to do two passes on the param list isn't as bad as
> asking to do unbound lookahead. In this case it's bound: look ahead till the
> end of the param list; get as much info as possible, and then do it again to
> comple
best way to fix it. One
could specifiy that parameters referred to by
the .identifer syntax must of some integer type and
that the sub-expression .identifer is always
converted to a 'size_t'.
That makes sense, but then overnight some quite useful thing came to my mind
that would not be
Hi Joseph,
On 11/14/22 19:26, Joseph Myers wrote:
On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:
To quote the convenor in WG14 reflector message 18575 (17 Nov
2020) when I asked about its status, "The author asked me not to put those
on the agenda. He will supply updated versions later
Hi Joseph,
On 11/14/22 19:13, Joseph Myers wrote:
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
SYNOPSIS:
unary-operator: . identifier
That's not what you mean. See the standard syntax.
Yup; typo there.
unary-expression:
[other alternatives]
unary-operator
On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:
> > To quote the convenor in WG14 reflector message 18575 (17 Nov
> > 2020) when I asked about its status, "The author asked me not to put those
> > on the agenda. He will supply updated versions later.".
>
> Since his email is not in the pap
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
> SYNOPSIS:
>
> unary-operator: . identifier
That's not what you mean. See the standard syntax.
unary-expression:
[other alternatives]
unary-operator cast-expression
unary-operator: one of
& * + - ~ !
> -
Hi Joseph!
On 11/14/22 18:52, Joseph Myers wrote:
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
Maybe allowing integral types and pointers would be enough. However,
foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
succeed, and combining it with this one, _Lengt
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
> Maybe allowing integral types and pointers would be enough. However,
> foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
> succeed, and combining it with this one, _Lengthof(pointer) would ideally give
> the length of
On 11/13/22 17:56, Alejandro Colomar wrote:>>> On 11/13/22 17:28, Alejandro
Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say that,
On 11/13/22 17:34, Alejandro Colomar wrote:
On 11/13/22 17:31, Alejandro Colomar wrote:
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sor
On 11/13/22 17:31, Alejandro Colomar wrote:
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say tha
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say that, like sizeof() and _Lengthof(), you can't ass
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
- This prevents ambiguity with a designator in an initializer-list within a
nested braced-initializer.
- The type of a .identifier is alway
Hi Martin,
On 11/13/22 16:32, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
Hi Martin,
On 11/13/22 15:58, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
On 11/13/22 14:33, Alejandro Colomar wrote:
On 11/13/22
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 11/13/22 15:58, Martin Uecker wrote:
> > Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
> > > On 11/13/22 14:33, Alejandro Colomar wrote:
> > > > On 11/13/22 14:19, Alejandro Colomar wrote:
>
ssing that it can't.
How do you forward declare incomplete VMTs?.
I am not sure what would the best way to fix it. One
could specifiy that parameters referred to by
the .identifer syntax must of some integer type and
that the sub-expression .identifer is always
converted to a 'size_t
But note that GNU forward declarations solve this nicely.
> > >
> > > > I am not sure what would the best way to fix it. One
> > > > could specifiy that parameters referred to by
> > > > the .identifer syntax must of some integer type and
> > > &g
)[sizeof *.a]);
This seems to be a difficult stone in the road.
I am not sure what would the best way to fix it. One
could specifiy that parameters referred to by
the .identifer syntax must of some integer type and
that the sub-expression .identifer is always
converted to a 'size_t'.
stone in the road.
I am not sure what would the best way to fix it. One
could specifiy that parameters referred to by
the .identifer syntax must of some integer type and
that the sub-expression .identifer is always
converted to a 'size_t'.
That makes sense, but then overnight some qu
eric expressions, and
specify that the .identifier refers to a
parameter in
the nearest lexically enclosing parameter list or
struct/union.
Then
void foo(struct bar { int x; char c[.x] } a, int x);
would not be allowed (which is good because then we
could later use the syntax also inside structs). I
assignment-expression.
I think needing such a very special case rule tends to indicate that some
alternative syntax, not needing such a rule, would be better.
Well, by not being an lvalue, it can't be assigned to. That would be somewhat
like sizeof(identifier), which is also a unary-expr
t .initializer cannot
> appear as the left operand of an assignment-expression.
I think needing such a very special case rule tends to indicate that some
alternative syntax, not needing such a rule, would be better.
--
Joseph S. Myers
jos...@codesourcery.com
at the .identifier refers to a
parameter in
the nearest lexically enclosing parameter list or
struct/union.
Then
void foo(struct bar { int x; char c[.x] } a, int x);
would not be allowed (which is good because then we
could later use the syntax also inside structs). If
we apply scoping rules,
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
Well, I still don't know what the syntax addition you propose is. Is it
postfix-expression : . identifier
I'll try to explain it in standardeese, but I'm not sure if I'll get it right,
so I'll accompany it with plain English.
Maybe Martin can help.
Since it'
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 synta
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
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
a = 1,
.s = {
.a = ((struct s) {.a = 1}).a,
},
};
}
It is ambiguous to a human reader, but that's a subjective thing, and of course
shadowing should be avoided by programmers. However, for a compiler, scoping
and syntax rules
Am Samstag, den 12.11.2022, 01:09 + schrieb Joseph Myers:
> On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
>
> > > Even a compiler extension requires the level of detail of specification
> > > that you get with a WG14 paper (and the level of work on finding bugs in
> > > that specificatio
On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
> > Even a compiler extension requires the level of detail of specification
> > that you get with a WG14 paper (and the level of work on finding bugs in
> > that specification), to avoid the problem we've had before with too many
> > features ad
> struct s { int a; };
> void f(int a, int b[((struct s) { .a = 1 }).a]);
>
> where it's newly ambiguous whether ".a = 1" is an assignment to the
> expression ".a" or a use of a designated initializer.
If we only allowed [ . a ] then this example would not
ers and member names
struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);
where it's newly ambiguous whether ".a = 1" is an assignment to the
expression ".a" or a use of a designated initializer.
(I think that if you add any syntax for this, GNU VLA forwar
mes
struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);
where it's newly ambiguous whether ".a = 1" is an assignment to the
expression ".a" or a use of a designated initializer.
(I think that if you add any syntax for this, GNU VLA forward declarations
ships, by using enhanced VLA syntax.
> If I release that before GCC, I'm expecting to see an avalanche of
> reports about it (and I also expect that GCC and forums will receive a
> similar ammount). So yes, I expect to wait some longish time.
Hah, you rebutted my Moltke with y
ink the Linux kernel will move too fast to permit such a
leisurely cadence.
Heh, at this point, I burnt my ships, by using enhanced VLA syntax. If I
release that before GCC, I'm expecting to see an avalanche of reports about it
(and I also expect that GCC and forums will receive a simi
roblematic; for the latter, it's designated initializers where
you get complications, for example). Designing new syntax that doesn't
cause ambiguity is generally tricky, and this sort of language extension
is the kind of thing where you'd expect to so through at least five
iterations of a
Hi Alex,
At 2022-11-10T01:06:31+0100, Alejandro Colomar wrote:
> Now, I've released man-pages-6.01 very recently (just a few weeks
> ago), and I don't plan to release again in a year or two, so there's
> time to do the implementation in GCC. From my side, please consider
> this an ACK or even som
lid in certain context (each of which
> introduces its own complications; for the former, typedef names from outer
> scopes are problematic; for the latter, it's designated initializers where
> you get complications, for example). Designing new syntax that doesn't
> cau
ter '[' to have special semantics, or whether you mean to have a special
'. identifier' form of expression valid in certain context (each of which
introduces its own complications; for the former, typedef names from outer
scopes are problematic; for the latter, it's
On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
> I've shown the three kinds of prototypes that have been changed:
>
> - Normal VLA; nothing fancy except for the '.'.
> - Complex size expressions.
> - 'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).
That doesn't cover any of
man3 with hypothetical VLA syntax.
Now, I've released man-pages-6.01 very recently (just a few weeks ago), and I
don't plan to release again in a year or two, so there's time to do the
implementation in GCC. From my side, please consider this an ACK or even
somewhat of a push to get th
been ruminating these patches for some time, for
having some more time to think about them. Now, I like them enough to push.
So, after a few minor cosmetic issues detected by some linters, I've pushed the
changes to document all of man2 and man3 with hypothetical VLA syntax.
Now, I'
Hi Martin,
On 9/3/22 22:02, Alejandro Colomar wrote:
We thought about using this syntax
int foo(char buf[.n], int n);
BTW, it would be useful if this syntax was accepted for void * too,
especially since GNU C allows pointer arithmetic on void *.
void *memmove(void dest[.n], const void
t;
Maybe GCC could add Clang's _Nonnull (and maybe _Nullable and the
pragmas, but definitely not _Null_unspecified), and add some good warnings.
Only then it would make sense to try to standardize the feature.
[...]
In K&R syntax this worked for definition:
void foo(y, n)
int n;
int
ixed,
one has to push for it. Standardization is meant
to standardize existing practice, so if we want to see
this improved, we can not wait for this.
> > But I agree that 'n' without 'static' should simply imply
> > a bound and I think we should use it this way
Hi Ingo,
On 9/3/22 15:29, Ingo Schwarze wrote:
the only point i strongly care about is this one:
Manual pages should not use
* non-standard syntax
* non-portable syntax
* ambiguous syntax (i.e. syntax that might have different meanings
with different compilers or in different
ture hopefully fixes this.
But I agree that 'n' without 'static' should simply imply
a bound and I think we should use it this way even when
the standard currently does not attach a meaning to it.
Yep.
[...]
What about taking something from K&R functions for this?:
n], socklen_t hostlen,
> > > char serv[restrict servlen], socklen_t servlen,
> > > int flags);
> > >
> > >
> > > int getnameinfo(socklen_t hostlen;
> > > socklen_t servlen;
> > &g
char serv[restrict servlen], socklen_t servlen,
int flags);
(I'm not sure if I used correct GNU syntax, since I never used that
extension myself.)
The first transformation above is non-ambiguous, as concise as possible,
and its only issue is that it might complicate the i
Hi,
the only point i strongly care about is this one:
Manual pages should not use
* non-standard syntax
* non-portable syntax
* ambiguous syntax (i.e. syntax that might have different meanings
with different compilers or in different contexts)
* syntax that might be invalid or dangerous
int flags);
>
>
> int getnameinfo(socklen_t hostlen;
> socklen_t servlen;
> const struct sockaddr *restrict addr,
> socklen_t addrlen,
> char host[restrict hostlen],
Hi JeanHeyd,
Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in
function parameters
Date: Fri, 2 Sep 2022 16:56:00 -0400
From: JeanHeyd Meneide
To: Alejandro Colomar
CC: Ingo Schwarze , linux-...@vger.kernel.org
Hi Alejandro and Ingo,
Just chiming
Can we use regular expressions to do syntax operations?
thanks
andre coelho
too costly to implement.
Thanks
Mohamed
في الأربعاء، ١١ مايو، ٢٠٢٢ ١٢:٢٠ ص André Coelho via Gcc
كتب:
> Hey...if the compiler can check syntax errors...why can't it fixed them?
>
>
> thanks
>
>
> andre coelho
>
>
On Tue, May 10, 2022 at 3:19 PM André Coelho via Gcc wrote:
>
> Hey...if the compiler can check syntax errors...why can't it fixed them?
In some cases it does recommend ways of fixing it. But not all syntax
errors are fixable.
Also not all syntax errors might be the wrong behavior
Hey...if the compiler can check syntax errors...why can't it fixed them?
thanks
andre coelho
GCC supports an old, pre-C99 designated initializer syntax in C, where
array designators need not be followed by '=' and members may use
'member_name :' rather than '.member_name ='.
I hoped to obsolete that syntax more forcefully (making the pedwarns for
it
(please do cc me to preserve thread, i am subscribed digest, thank you)
https://bugs.libre-soc.org/show_bug.cgi?id=615
summary: Libre-SOC needs an assembly syntax for SVP64 which is acceptable
for all parties, gcc and binutils primarily.
background: the Libre-SOC team, funded by NLnet, is
On 2/23/20 10:47 AM, Thomas Koenig wrote:
Hi Martin,
I was able to write a sanity check for these kind of issues, but it does
not resolve all similar issues for other keywords. It's not easy to do it.
Having looked at the origina awk code, I agree. Maybe, in the long
term, a lex/yacc grammar
Hi Martin,
I was able to write a sanity check for these kind of issues, but it does
not resolve all similar issues for other keywords. It's not easy to do it.
Having looked at the origina awk code, I agree. Maybe, in the long
term, a lex/yacc grammar with a monolithic C program to write out
t
On 2/20/20 7:08 PM, Thomas Koenig wrote:
Hi Martin,
Sure, I can improve sanity checking.
Thanks!
What exactly have you screwed up?
I had, in lang.opt
EnumValue
Enum (gfc_fcoarray) String (native) Value (GFC_FCOARRAY_NATIVE)
It was a bit non-obvious to me that this led to the whole sub-op
Hi Martin,
Sure, I can improve sanity checking.
Thanks!
What exactly have you screwed up?
I had, in lang.opt
EnumValue
Enum (gfc_fcoarray) String (native) Value (GFC_FCOARRAY_NATIVE)
It was a bit non-obvious to me that this led to the whole sub-option
being ignored due to
*drum roll*
th
possible to improve the syntax checking for lang.opt?
It's a file that people touch only rarely, so it is likely that
they will have no experience or will already have forgotten the
gotchas they encountered the last time.
Fully agree with that!
Martin
Regards
Thomas
Hi,
having just lost a few hours on a space in lang.opt where
there was supposed to be none, leading to a new option
being silently ignored, a request:
Would it be possible to improve the syntax checking for lang.opt?
It's a file that people touch only rarely, so it is likely that
they
1 - 100 of 210 matches
Mail list logo
