Division by zero on A53 which does not raise an exception

[Stephen Smith via Gcc]

I am working on a project which is using an A53 core.   The core does not 
raise an exception if there is a division by zero (for either integer or 
floating point division).

The designers chose to set status bits for the floating point case but not 
raise an exception.With the integer division no status bits are set.

Does the GCC  compilers or Binutils assembler and linker have a way to deal 
with this issue on the ARM A53 processor?  

For Linux, was special support added in the kernel to help Glibc with this 
issue?  If so, I will comb the linux source tree.

My project is using GCC 7.3.0

RE: Code generation: How to define file-scope static variables?

[Robert Dubner]

David, thank you very much.  That looks very much like what I was hoping 
for.

I'll dig into it tomorrow.

Heartfelt thanks,

Bob Dubner.

-Original Message-
From: David Malcolm 
Sent: Monday, November 28, 2022 18:01
To: Robert Dubner ; gcc@gcc.gnu.org
Cc: 'Bob Dubner' 
Subject: Re: Code generation: How to define file-scope static variables?

On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
>
> By reverse engineering other front ends, I learned, some months ago,
> how to create a function_decl GENERIC node that is the root of a
> GENERIC tree describing an entire function.
>
> By calling the routine cgraph_node::finalize_function() with that
> function_decl, the assembly language for that function is created, and
> all is well.
>
> But now I need to be able to create the equivalent of a file-scope
> static variable in C.
>
> This C program file:
>
> //
> static int dubner_at_work = 123454321; int main(int argc, char **argv)
>   {
>   }
> //
>
> produces, in part, this assembly language:
>
> ###
> .file   "ccc.c"
> .text
> .data
> .align 4
> .type   dubner_at_work, @object
> .size   dubner_at_work, 4
> dubner_at_work:
> .long   123454321
> .text
> .globl  main
> .type   main, @function
> [...]
> ###
>
> In my own GENERIC generation code, I believe that I am creating a
> proper translation_unit_decl that contains the block and the vars
> nodes for specifying "dubner_at_work".
>
> But I have been unable, after several days of looking, to figure out
> the equivalent of "cgraph_node::finalize_function" for a
> translation_unit_decl.  The resulting assembly language doesn't have a
> definition for "dubner_at_work".
>
> Can anybody describe how I can tell the downstream processing that I
> need the translation_unit_decl to actually define storage?

You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as it 
tends to contain minimal code to build trees (generally 
simplified/reverse-engineered from the C frontend).

playback::context::global_new_decl makes the VAR_DECL node, and such trees 
are added to the jit playback::context's m_globals.  In 
playback::context::replay, we have:

  /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
 for a simple reference. */
  FOR_EACH_VEC_ELT (m_globals, i, global)
rest_of_decl_compilation (global, true, true);

  wrapup_global_declarations (m_globals.address(), m_globals.length());

So you'll probably want to do something similar for your globals.

Caveat: this is all reverse-engineered by me/others from the C frontend (and 
I haven't touched this code in a while), so I may be missing things here.

Dave

Help for a GCC school assignment

[throw away via Gcc]

 Hello,

For class, *I need to come up with a way to improve GCC* and then make a
quick presentation (no implementation required). Ideally, this idea isn't
being worked on already. *I'd appreciate help with coming up with an idea.*

I've thought about this and I'm having trouble coming up with anything. I'm
really stuck, so I thought I'd reach out here. (Reddit sent me here)

The best I could come up with was something along the lines of "makefile"
or *adding support for a new language. *For the new language, I was thinking*
something** like Swift.* The only reason I chose Swift was that there was a
lot of information online and it uses the Clang/LLVM framework, a sort of
competitor to GCC.

I see that Swift has its own compiler which uses a custom version of
Clang/LLVM. To add Swift to GCC, I imagine you'd have to add a new front
end for Swift. This front end would have a bunch of code (most adapted from
the open-source Swift compiler) to convert Swift code to generic. From
there, the middle end and back end can do the rest.

Welp, that's where I am at right now, if anyone has better ideas, I'd
really appreciate some help.

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

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
> complete.  Anything not yet clear after two passes is not valid.

Unbounded here means an unbounded number of tokens, as opposed to e.g. 
looking one token ahead after seeing an identifier in statement context to 
determine if it's a label.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alex Colomar via Gcc]

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:

Hi Martin,

On 11/13/22 14:19, Alejandro Colomar wrote:

But there are not only syntactical problems, because
also the type of the parameter might become relevant
and then you can get circular dependencies:

void foo(char (*a)[sizeof *.b], char (*b)[sizeof *.a]);


This seems to be a difficult stone in the road.


But note that GNU forward declarations solve this nicely.


Okay, so GNU declarations basically work by duplicating (some of) the 
declarations.


How about the compiler parsing the parameter list twice?  One for 
getting the declarations and their types (but not resolving any 
sizeof(), _Lengthof(), or typeof(), when they contain .identifier (or 
expressions containing it; in those cases, leave the type incomplete, to 
be completed in the second pass).  As if the programmer had specified 
the firward declarations, but it's the compiler that gets them 
automatically.


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 complete.  Anything not yet clear after two passes 
is not valid.


So, for

void foo(char (*a)[sizeof(*.b)], char (*b)[sizeof(*.a)]);

in the first pass, the compiler would read:

char (*a)[sizeof(*.b)];  // sizeof .identifier; incomplete type; 
continue parsing
char (*b)[sizeof(*.a)];  // sizeof .identifier; incomplete type; 
continue parsing


At the end of the first pass, the compiler only know:

char (*a)[];
char (*b)[];

At the second pass, when evaluating sizeof(), since the type of the 
arguments are yet incomplete, it can't be evaluated, and therefore, 
there's an error at the first sizeof(*.b): *.b has incomplete type.


---

Let's show a distinct case:

void foo(char (*a)[sizeof(*.b)], char (*b)[10]);

After the first pass, the compiler would know:

char (*a)[];
char (*b)[10];

At the second pass, sizeof(*.b) would be evaluated undoubtedly to 
sizeof(char[10]), and the parameter list would then be fine.


Does this 2-pass parsing make sense to you?  Did I miss any details?







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 quite useful thing came to my mind
that would not be possible with this limitation:




char *
stpecpy(char dst[.end - .dst], char *src, char end[1])


Heh, I got an off-by-one error.  It should be dst[.end - .dst + 1], of course,
and then the result of the whole expression would be 0, which is fine as size_t.

So, never mind.


.end and .dst would have pointer size though.


{
  for (/* void */; dst <= end; dst++) {
  *dst = *src++;
  if (*dst == '\0')
  return dst;
  }
  /* Truncation detected */
  *end = '\0';

#if !defined(NDEBUG)
  /* Consume the rest of the input string. */
  while (*src++) {};
#endif

  return end + 1;
}

And I forgot to say it:  Default promotions rank high (probably the highest) in
my list of most hated features^Wbugs in C.


If you replaced them with explicit conversion you then have
to add by hand all the time, I am pretty sure most people
would hate this more. (and it could also hide bugs)


I wouldn't convert it to size_t, but
rather follow normal promotion rules.


The point of making it size_t is that you then
do need to know the type of the parameter to make
sense of the expression. If the type matters, then you get
mutual dependencies as in the example above.


Since you can use anything between INTMAX_MIN and UINTMAX_MAX for accessing an
array (which took me some time to understand), I'd also allow the same here. So,
the type of the expression between [] could perfectly be signed or unsigned.

So, you could use size_t for very high indices, or e.g. ptrdiff_t if you want to
allow negative numbers.  In the function above, since dst can be a pointer to
one-past-the-end (it represents a previous truncation; that's why the test
dst<=end), forcing a size_t conversion would disallow that syntax.


Yes, this then does not work.


Cheers,

Alex

--




OpenPGP_signature
Description: OpenPGP digital signature

Re: Code generation: How to define file-scope static variables?

[David Malcolm via Gcc]

On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
> 
> By reverse engineering other front ends, I learned, some months ago,
> how
> to create a function_decl GENERIC node that is the root of a GENERIC
> tree
> describing an entire function.   
> 
> By calling the routine cgraph_node::finalize_function() with that
> function_decl, the assembly language for that function is created,
> and all
> is well.
> 
> But now I need to be able to create the equivalent of a file-scope
> static
> variable in C.
> 
> This C program file:
> 
> //
> static int dubner_at_work = 123454321;
> int main(int argc, char **argv)
>   {
>   }
> //
> 
> produces, in part, this assembly language:
> 
> ###
> .file   "ccc.c"
> .text
> .data
> .align 4
> .type   dubner_at_work, @object
> .size   dubner_at_work, 4
> dubner_at_work:
> .long   123454321
> .text
> .globl  main
> .type   main, @function
> [...]
> ###
> 
> In my own GENERIC generation code, I believe that I am creating a
> proper
> translation_unit_decl that contains the block and the vars nodes for
> specifying "dubner_at_work".
> 
> But I have been unable, after several days of looking, to figure out
> the
> equivalent of "cgraph_node::finalize_function" for a
> translation_unit_decl.  The resulting assembly language doesn't have
> a
> definition for "dubner_at_work".
> 
> Can anybody describe how I can tell the downstream processing that I
> need
> the translation_unit_decl to actually define storage?

You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as
it tends to contain minimal code to build trees (generally
simplified/reverse-engineered from the C frontend).

playback::context::global_new_decl makes the VAR_DECL node, and such
trees are added to the jit playback::context's m_globals.  In
playback::context::replay, we have:

  /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
 for a simple reference. */
  FOR_EACH_VEC_ELT (m_globals, i, global)
rest_of_decl_compilation (global, true, true);

  wrapup_global_declarations (m_globals.address(), m_globals.length());

So you'll probably want to do something similar for your globals.

Caveat: this is all reverse-engineered by me/others from the C frontend
(and I haven't touched this code in a while), so I may be missing
things here.

Dave

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alex Colomar via Gcc]

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.".


Since his email is not in the paper, would you mind forwarding him this
suggestion of mine of renaming it to avoid confusion with string lengths?  Or
maybe point him to the mailing list discussion[1]?

[1]:



I don't have his email address (I don't see any emails from him on the
reflector since I joined it in 2001).


Meh; thanks.  Would you mind commenting this issue to whoever defends 
his document, whenever you talk about it?


Thanks,

Alex





--




OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alex Colomar via Gcc]

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 cast-expression

unary-operator: one of
   & * + - ~ !


-  It is not an lvalue.

-  This means sizeof() and _Lengthof() cannot be applied to them.


sizeof can be applied to non-lvalues.


thinko there.  I fixed it in a subsequent email.




-  This prevents ambiguity with a designator in an initializer-list within
a nested braced-initializer.


No, it doesn't.  See my previous points about syntactic disambiguation
being a separate matter from "one parse would result in a constraint
violation, so choose another parse that doesn't" (necessarily, because the
constraint violation that results could in general be at an arbitrary
distance from the point where a choice of parse has to be made).  Or see
e.g. the disambiguation rule about enum type specifiers: there is an
explicit rule "If an enum type specifier is present, then the longest
possible sequence of tokens that can be interpreted as a specifier
qualifier list is interpreted as part of the enum type specifier." that
ensures that "enum e : long int;" interprets "long int" as the enum type
specifier, rather than "long" as the enum type specifier and "int" as
another type specifier in the sequence of declaration specifiers, even
though the latter parse would result in a constraint violation later.


I get it.  It's only unambiguous if there's lookahead.



Also, requiring unbounded lookahead to determine what kind of construct is
being parsed may be considered questionable for C.  (If you have an
initializer starting .a.b.c.d.e, possibly with array element access as
well, those could all be designators or .a might be a reference to a
parameter of struct or union type and .b.c.d.e a sequence of references to
members within it and disambiguation under your rule would depend on
whether an '=' follows such an unbounded sequence.)


I'm thinking of an idea for this.




-  The type of a .identifier is always an incomplete type.

-  This prevents circular dependencies involving sizeof() or _Lengthof().


We have typeof as well, which can be applied to expressions with
incomplete type.


Yes, but it would not be problematic in the two-pass parsing I have in mind.




-  Shadowing rules apply.

-  This prevents ambiguity.


"Shadowing rules apply" isn't much of a specification.  You need detailed
wording that would be added to 6.2.1 Scopes of identifiers (or equivalent
elsewhere) to make it clear exactly what scopes apply for identifiers
looked up using this construct.


Yeah, I guess.  I'm being easy for this draft.  I'll try to be more 
precise for future revisions.





-
void foo(struct bar { int x; char c[.x] } a, int x);

Explanation:
-  Because of shadowing rules, [.x] refers to the struct member.


I really don't think standardizing VLAs-in-structures would be a good
idea.  Certainly it would be a massive pain to specify meaningful
semantics for them and this outline doesn't even attempt to work through
the consequences of removing the rule that "If an identifier is declared
as having a variably modified type, it shall be an ordinary identifier (as
defined in 6.2.3), have no linkage, and have either block scope or
function prototype scope.".


Maybe.  I didn't have them in mind until Martin mentioned them.  Now 
that he mentioned them, I'd like at least to be careful so that any new 
syntax doesn't do something that impedes adding them in the future, if 
it is ever considered desirable.




The idea that .x as an expression might refer to either a member or a
parameter is also a massive change to the namespace rules, where at
present those are in completely different namespaces and so in any given
context a name only needs looking up as one or the other.

Again, proposals should be *minimal*.


Yes.  I only want to have a rough discussion about how the entire 
feature in an ideal future where everything is added would look like. 
Otherwise, adding a minimal feature without considering this future, 
might do something that prevents some part of it being implemented due 
to backwards compatibility.


So I'd like to discuss the whole idea before then going to a minimal 
proposal that will be *much* smaller than this idea that I'm discussing.


I'm happy with the Linux man-pages implementing the whole idea (even if 
it's impossible to implement it in C ever), and letting ISO C / GCC 
implement initially (and possibly ever) only the minimal stuff.




 And even when they are, many issues
may well arise in practice (see the long list of constexpr issues in my
commit message for that C2x feature, for example, which I expect to turn
into multiple NB comments and at least two accompanying documents).


Sure; I expect that.


Cheers,

Alex

Code generation: How to define file-scope static variables?

[Robert Dubner]

I am part of a team working on a COBOL front end for GCC.

By reverse engineering other front ends, I learned, some months ago, how
to create a function_decl GENERIC node that is the root of a GENERIC tree
describing an entire function.   

By calling the routine cgraph_node::finalize_function() with that
function_decl, the assembly language for that function is created, and all
is well.

But now I need to be able to create the equivalent of a file-scope static
variable in C.

This C program file:

//
static int dubner_at_work = 123454321;
int main(int argc, char **argv)
  {
  }
//

produces, in part, this assembly language:

###
.file   "ccc.c"
.text
.data
.align 4
.type   dubner_at_work, @object
.size   dubner_at_work, 4
dubner_at_work:
.long   123454321
.text
.globl  main
.type   main, @function
[...]
###

In my own GENERIC generation code, I believe that I am creating a proper
translation_unit_decl that contains the block and the vars nodes for
specifying "dubner_at_work".

But I have been unable, after several days of looking, to figure out the
equivalent of "cgraph_node::finalize_function" for a
translation_unit_decl.  The resulting assembly language doesn't have a
definition for "dubner_at_work".

Can anybody describe how I can tell the downstream processing that I need
the translation_unit_decl to actually define storage?

Thanks very much,

Bob Dubner.

Re: Triggering -save-temps from the front-end code

[Marc Glisse via Gcc]

On Mon, 28 Nov 2022, Florian Weimer via Gcc wrote:


* Arsen Arsenović:


Hi,

Florian Weimer via Gcc  writes:


Unfortunately, some build systems immediately delete the input source
files.  Is there some easy way I can dump the pre-processed and
non-preprocessed sources to my log file?  I tried to understand how
-save-temps for crash recovery works, but it seems that this runs
outside of the frontend, in the driver.


Would dumping unconditionally into some "side channel" -dumpdir be a
sufficient workaround?


Of the file names overlap, and it seems in this case, the dump files are
just overwritten.  I don't see a way to make the file names unique.

I guess for the tough cases, I can just keep running the build under
strace.


You could override unlink with LD_PRELOAD. Use a special purpose 
filesystem (gitfs? I haven't tried it yet). Wrap gcc with a command that 
calls the true gcc with a different TMPDIR / -dumpdir each time.


--
Marc Glisse

Re: Triggering -save-temps from the front-end code

[Florian Weimer via Gcc]

* Arsen Arsenović:

> Hi,
>
> Florian Weimer via Gcc  writes:
>
>> Unfortunately, some build systems immediately delete the input source
>> files.  Is there some easy way I can dump the pre-processed and
>> non-preprocessed sources to my log file?  I tried to understand how
>> -save-temps for crash recovery works, but it seems that this runs
>> outside of the frontend, in the driver.
>
> Would dumping unconditionally into some "side channel" -dumpdir be a
> sufficient workaround?

Of the file names overlap, and it seems in this case, the dump files are
just overwritten.  I don't see a way to make the file names unique.

I guess for the tough cases, I can just keep running the build under
strace.

Thanks,
Florian

Re: Triggering -save-temps from the front-end code

[Arsen Arsenović via Gcc]

Hi,

Florian Weimer via Gcc  writes:

> Unfortunately, some build systems immediately delete the input source
> files.  Is there some easy way I can dump the pre-processed and
> non-preprocessed sources to my log file?  I tried to understand how
> -save-temps for crash recovery works, but it seems that this runs
> outside of the frontend, in the driver.

Would dumping unconditionally into some "side channel" -dumpdir be a
sufficient workaround?

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Overall-Options.html#index-dumpdir

Hope that helps, have a great day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Triggering -save-temps from the front-end code

[Richard Biener via Gcc]

On Mon, Nov 28, 2022 at 12:30 PM Florian Weimer via Gcc  wrote:
>
> I've got some instrumentation for logging errors to a magic directory,
> so that I can see if a build triggered them even when it did not
> fail—and hid all compiler errors and warnings.
>
> Unfortunately, some build systems immediately delete the input source
> files.  Is there some easy way I can dump the pre-processed and
> non-preprocessed sources to my log file?  I tried to understand how
> -save-temps for crash recovery works, but it seems that this runs
> outside of the frontend, in the driver.

Yep, there's no way to trigger -save-temps behavior after-the-fact.

> Here's an example of the
> challenges this would help to solve:
>
>   Building in strict C99 mode
>   
>
> Thanks,
> Florian
>

Triggering -save-temps from the front-end code

[Florian Weimer via Gcc]

I've got some instrumentation for logging errors to a magic directory,
so that I can see if a build triggered them even when it did not
fail—and hid all compiler errors and warnings.

Unfortunately, some build systems immediately delete the input source
files.  Is there some easy way I can dump the pre-processed and
non-preprocessed sources to my log file?  I tried to understand how
-save-temps for crash recovery works, but it seems that this runs
outside of the frontend, in the driver.

Here's an example of the
challenges this would help to solve:

  Building in strict C99 mode
  

Thanks,
Florian

Re: Problems when building NT kernel drivers with GCC / LD

[Jan Beulich via Gcc]

On 28.11.2022 09:40, Jonathan Wakely wrote:
> On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc,  wrote:
> 
>> On 26.11.2022 20:04, Pali Rohár wrote:
>>> On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
 But then, with you replying to
 me specifically, perhaps you're wrongly assuming that I would be
 planning to look into addressing any or all of these? My earlier reply
 was merely to point out that _some_ work has already been done ...
>>>
>>> I added into CC also gcc, ld and mingw mailing list. If this is not
>>> enough, could you tell me who to contact about those issues?
>>
>> That's probably enough, sure. I merely tried to set expectations right,
>> since you did reply To: me (and lists were only on Cc: - it being the
>> other way around would have demonstrated that you're not asking me
>> specifically).
>>
> 
> That's just how most mailers do "Reply All", I don't think it out implies
> anything.

I know mailers behave that way. But when replying you can adjust To:
vs Cc:. That's what I'm doing all the time (or at least I'm trying to
remember to do so), because it makes a difference to me whether mail
is sent To: me vs I'm only being Cc:-ed. Otherwise - why do we have
To: and Cc: as different categories?

> Removing the Cc list and *only* replying to you would be different.

Sure - that would have meant sending private mail, which is yet worse.

Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Jonathan Wakely via Gcc]

On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc,  wrote:

> On 26.11.2022 20:04, Pali Rohár wrote:
> > On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> >> But then, with you replying to
> >> me specifically, perhaps you're wrongly assuming that I would be
> >> planning to look into addressing any or all of these? My earlier reply
> >> was merely to point out that _some_ work has already been done ...
> >
> > I added into CC also gcc, ld and mingw mailing list. If this is not
> > enough, could you tell me who to contact about those issues?
>
> That's probably enough, sure. I merely tried to set expectations right,
> since you did reply To: me (and lists were only on Cc: - it being the
> other way around would have demonstrated that you're not asking me
> specifically).
>

That's just how most mailers do "Reply All", I don't think it out implies
anything. Removing the Cc list and *only* replying to you would be
different.

Re: Problems when building NT kernel drivers with GCC / LD

[Jan Beulich via Gcc]

On 26.11.2022 20:04, Pali Rohár wrote:
> On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
>> But then, with you replying to
>> me specifically, perhaps you're wrongly assuming that I would be
>> planning to look into addressing any or all of these? My earlier reply
>> was merely to point out that _some_ work has already been done ...
> 
> I added into CC also gcc, ld and mingw mailing list. If this is not
> enough, could you tell me who to contact about those issues?

That's probably enough, sure. I merely tried to set expectations right,
since you did reply To: me (and lists were only on Cc: - it being the
other way around would have demonstrated that you're not asking me
specifically).

Jan