Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146432 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-09-30 14:02 +0200 |
| Last post | 2019-10-05 14:08 -0700 |
| Articles | 20 on this page of 109 — 21 participants |
Back to article view | Back to comp.lang.c
alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 14:02 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:09 +0200
Re: alloca()-support Bo Persson <bo@bo-persson.se> - 2019-09-30 17:29 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:33 +0200
Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:12 +0300
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:16 +0200
Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:30 +0300
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:44 +0200
Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 00:36 +0300
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:08 +0300
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:42 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 14:30 +0000
Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:33 +0300
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-09-30 16:56 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-30 15:29 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:31 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 07:03 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 10:57 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:49 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:20 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:39 +0000
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:15 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:29 +0000
Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:14 -0700
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:04 +0200
Re: alloca()-support William Ahern <william@25thandClement.com> - 2019-09-30 11:01 -0700
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:19 +0200
Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-30 22:26 +0300
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:46 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:32 +0200
Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-01 09:08 +0300
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 08:35 +0200
Re: alloca()-support gazelle@shell.xmission.com (Kenny McCormack) - 2019-09-30 16:26 +0000
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:48 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:51 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:55 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:58 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:53 +0200
Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:13 -0700
Re: alloca()-support Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 06:16 -0700
Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:22 +0300
Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-06 12:58 -0700
Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-06 13:16 -0700
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:38 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:41 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 15:19 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 17:31 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:58 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:24 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:28 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:30 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:36 +0000
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:01 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:42 +0000
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:10 +0200
Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:13 +0200
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 21:10 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:25 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:44 +0000
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 23:26 +0200
Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-01 21:08 -0600
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:19 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:39 +0200
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:34 +0200
Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:14 +0200
Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:18 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:21 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 04:09 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:48 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 05:49 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:52 +0200
Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 06:46 +0000
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 10:59 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 13:39 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 13:23 +0000
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-03 15:38 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 14:51 +0000
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:49 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:47 +0200
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:53 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:52 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:39 +0200
Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-30 21:36 -0400
Re: alloca()-support Philipp Klaus Krause <pkk@spth.de> - 2019-09-30 19:14 +0200
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:16 +0200
Re: alloca()-support Robert Wessel <robertwessel2@yahoo.com> - 2019-10-01 00:18 -0500
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:43 +0200
Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-01 02:42 -0700
Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-01 08:11 -0400
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 14:53 +0200
Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 17:52 +0000
Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 11:20 -0600
Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:42 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:02 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:54 +0200
Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 14:28 -0600
Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 09:38 +0200
Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:01 +0200
Re: alloca()-support Manfred <noname@add.invalid> - 2019-10-01 17:45 +0200
Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 02:35 -0700
Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:26 +0300
Re: alloca()-support jadill33@gmail.com - 2019-10-02 08:00 -0700
Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 02:38 +0300
Re: alloca()-support jadill33@gmail.com - 2019-10-03 08:42 -0700
Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 12:33 -0700
Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 01:47 +0300
Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-05 14:08 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-10-03 21:47 +0200 |
| Message-ID | <qn5j9d$au$1@dont-email.me> |
| In reply to | #146549 |
On 03/10/2019 15:38, David Brown wrote:
> On 03/10/2019 13:39, Soviet_Mario wrote:
>
>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>> ACTIVE) was
>>
>
> Examining generated assembly code with no optimisation is usually
> pointless. If you care about the efficiency of the assembly, you will
> have optimisation enabled on the compiler. Looking at the assembly
> generated with optimisation off tells you practically nothing.
>
> The tool you want here is the webpage <https://godbolt.org>. It is an
> online compiler site, letting you type small bits of code and compile it
> with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
> not the only choice) and using whatever options you want (like "-x c
> -std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).
amazing ! Didn't know that
>
> Use that site to see the generated code, and perhaps these newsgroups to
> ask /why/ you get particular code. It's better than asking people in
> these groups to compile code snippets for you, at least for standard
> compilers.
sorry but I was not aware of that site. Thanks
TNX also to Scott Lurndall who got me the code.
I'm trying to understand sth out of it but I'm very rusty
with asm
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-04 09:53 +0200 |
| Message-ID | <qn6tpp$grd$1@dont-email.me> |
| In reply to | #146559 |
On 03/10/2019 21:47, Soviet_Mario wrote:
> On 03/10/2019 15:38, David Brown wrote:
>> On 03/10/2019 13:39, Soviet_Mario wrote:
>>
>>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>>> ACTIVE) was
>>>
>>
>> Examining generated assembly code with no optimisation is usually
>> pointless. If you care about the efficiency of the assembly, you will
>> have optimisation enabled on the compiler. Looking at the assembly
>> generated with optimisation off tells you practically nothing.
>>
>> The tool you want here is the webpage <https://godbolt.org>. It is an
>> online compiler site, letting you type small bits of code and compile it
>> with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
>> not the only choice) and using whatever options you want (like "-x c
>> -std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).
>
> amazing ! Didn't know that
>
>>
>> Use that site to see the generated code, and perhaps these newsgroups to
>> ask /why/ you get particular code. It's better than asking people in
>> these groups to compile code snippets for you, at least for standard
>> compilers.
>
> sorry but I was not aware of that site. Thanks
I'm glad to help. Once you start using that site, you will quickly get
addicted.
>
> TNX also to Scott Lurndall who got me the code.
>
> I'm trying to understand sth out of it but I'm very rusty with asm
>
The more you play with godbolt.org, the more you'll get used to it.
One tip when generating x86 assembly on the site - there is a checkbox
labelled "Intel" that lets you choose between Intel format assembly, and
AT&T format assembly. People with *nix backgrounds often find the AT&T
format more familiar, people with Windows backgrounds often prefer the
Intel format. Some people get /really/ worked up about it and think
anyone who doesn't agree with their personal opinions on the choice, are
clearly insane. I recommend trying both and using the one that looks
clearer to you.
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-10-03 21:52 +0200 |
| Message-ID | <qn5jhq$3jg$1@dont-email.me> |
| In reply to | #146549 |
On 03/10/2019 15:38, David Brown wrote:
> On 03/10/2019 13:39, Soviet_Mario wrote:
>
>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>> ACTIVE) was
>>
>
> Examining generated assembly code with no optimisation is usually
> pointless. If you care about the efficiency of the assembly, you will
> have optimisation enabled on the compiler. Looking at the assembly
> generated with optimisation off tells you practically nothing.
>
> The tool you want here is the webpage <https://godbolt.org>. It is an
> online compiler site, letting you type small bits of code and compile it
> with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
> not the only choice) and using whatever options you want (like "-x c
> -std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).
wow it does also colorize the output and flashes the areas
corresponding to the cursor ! Very invaluable feature. Molto
obbligato !
Ciao
>
> Use that site to see the generated code, and perhaps these newsgroups to
> ask /why/ you get particular code. It's better than asking people in
> these groups to compile code snippets for you, at least for standard
> compilers.
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-10-01 07:39 +0200 |
| Message-ID | <qmuoqm$n71$1@news.albasani.net> |
| In reply to | #146457 |
> uhm, I didn't mean THAT kind of risk (unavoidable), but the possible > difficulties in defining variables beyond the point of declaration of > the variable-size array. The compiler usually collects the size of all the "static" variables in the stack and reserves the space for them at the function-prolog. The VLA-spaces are handled within the function at the point where they are reserved (coudln't be handled differently because their size is only known at the point where they are reserved).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-09-30 21:36 -0400 |
| Message-ID | <qmuail$50k$1@dont-email.me> |
| In reply to | #146449 |
On 9/30/19 12:55 PM, Soviet_Mario wrote: > On 30/09/2019 18:51, Bonita Montero wrote: >>> Since when (if at any time) was variable size automatic >>> array supported ? >> >> Since C99. >> > > for curiosity, this feature has one or more of the > limitations I feared ... or even none of them ? There are several limitations on VLAs: They were not part of standard C until C99, and became optional in C2011. A C2011 implementation that does not support them will pre#define __STDC_NO_VLA__ with a value of 1. They have never yet been part of standard C++. The type name in a compound literal is not allowed ot be a VLA (6.5.2.5p1). A VLA can be declared with a size that is unspecified - this is specified by using "*" for the size, and can only be done in the declaration of a function parameter that is NOT part of the definition of that function (6.7.2p4). The expression for the size of a VLA must be an integer expression with a value greater than 0 (6.7.2p5). "Where a size expression is part of the operand of a sizeof operator and changing the value of the size expression would not affect the result of the operator, it is unspecified whether or not the size expression is evaluated." (6.7.2p5) Thus, portable code cannot rely upon the value of being changed (or unchanged) by evaluation of sizeof(int[n++]) - as a general rule, that would make it a bad idea to write such an expression. "If, in the nested sequence of declarators in a full declarator, there is a declarator specifying a variable length array type, the type specified by the full declarator is said to be variably modified. Furthermore, any type derived by declarator type derivation from a variably modified type is itself variably modified." (6.7.6p3) For instance, int (*vla)[n] declares a pointer to a VLA, but is not itself a VLA. But it is a variably modified type . A typedef for a VM type cannot be redefined, not even to the same type (6.7p3). "A member of a structure or union may have any complete object type other than a variably modified type." (6.7.2.1p9) "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. If an identifier is declared to be an object with static or thread storage duration, it shall not have a variable length array type." (6.7.6.2p2) "If a typedef name specifies a variably modified type then it shall have block scope." (6.7.8p2) "If a switch statement has an associated case or default label within the scope of an identifier with a variably modified type, the entire switch statement shall be within the scope of that identifier." (6.8.4.2p2) "A goto statement shall not jump from outside the scope of an identifier having a variably modified type to inside the scope of that identifier." (6.8.6.1) "... if the invocation of the setjmp macro was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior [of longjmp()] is undefined." (7.13.2.1p2)
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2019-09-30 19:14 +0200 |
| Message-ID | <qmtd54$5em$2@solani.org> |
| In reply to | #146448 |
Am 30.09.19 um 18:51 schrieb Bonita Montero: >> Since when (if at any time) was variable size automatic array supported ? > > Since C99. > And C99 is the only version where support for them is mandatory. As of C11, they are optional.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-30 19:16 +0200 |
| Message-ID | <qmtd94$rr0$1@news.albasani.net> |
| In reply to | #146452 |
>> Since C99. > And C99 is the only version where support for them is mandatory. > As of C11, they are optional. And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs are not supported.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-10-01 00:18 -0500 |
| Message-ID | <qbo5pe5igq5pfsf0pnh3tb4pkmgsqh5lnf@4ax.com> |
| In reply to | #146453 |
On Mon, 30 Sep 2019 19:16:19 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Since C99. > >> And C99 is the only version where support for them is mandatory. > >> As of C11, they are optional. > >And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs >are not supported. Are C++ compilers actually obligated to define _STDC_NO_VLA_?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-10-01 07:43 +0200 |
| Message-ID | <qmup1e$n71$3@news.albasani.net> |
| In reply to | #146482 |
>> And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs >> are not supported. > Are C++ compilers actually obligated to define _STDC_NO_VLA_? It's at least not part of the C++17-standard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-01 02:42 -0700 |
| Message-ID | <ln5zl83iph.fsf@kst-u.example.com> |
| In reply to | #146482 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> Are C++ compilers actually obligated to define _STDC_NO_VLA_?
No, __STDC_NO_VLA__ (note the double underscores) is specific to C11 and
later. C++ doesn't support VLAs at all, so there's no need for a C++
compiler to indicate its lack of support, and the C++ standard doesn't
require it to do so.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-01 08:11 -0400 |
| Message-ID | <qmvfpu$6ih$1@dont-email.me> |
| In reply to | #146495 |
On 10/1/19 5:42 AM, Keith Thompson wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > [...] >> Are C++ compilers actually obligated to define _STDC_NO_VLA_? > > No, __STDC_NO_VLA__ (note the double underscores) is specific to C11 and > later. C++ doesn't support VLAs at all, so there's no need for a C++ > compiler to indicate its lack of support, and the C++ standard doesn't > require it to do so. I'm sure you know this, but for the sake of other readers, I'd like to point out that the fact that __STDC_NO_VLA__ is a C-specific macro does not, in itself, prevent the C++ standard from saying anything about it. The C++ standard simply failed to do so. It has said things about other C pre#defined macros. The C++ standard mandates the setting of __STDC_HOSTED__ to either 0 or 1, as appropriate, and allows the setting of __STDC_MB_MIGHT_NEQ_WC__, __STDC__, __STDC_VERSION__, and __STDC_ISO_10646__. If __STDC_MB_MIGHT_NEQ_WC__ is pre#defined, it's required expand to the integer literal 1, and if __STDC_ISO_10646__ is pre#defined, it's required to expand to "An integer literal of the form yyyymmL".
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-10-01 14:53 +0200 |
| Message-ID | <qmvi7s$l84$1@news.albasani.net> |
| In reply to | #146495 |
> No, __STDC_NO_VLA__ (note the double underscores) is specific to C11 and > later. C++ doesn't support VLAs at all, so there's no need for a C++ > compiler to indicate its lack of support, and the C++ standard doesn't > require it to do so. It might help to port C99-code to C++ when C++ would define this macro appropriately. Code could conditionally disable VLA-dependent parts.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-09-30 17:52 +0000 |
| Message-ID | <nhrkF.2722$_T2.608@fx14.iad> |
| In reply to | #146448 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> Since when (if at any time) was variable size automatic array supported ? > >Since C99. > Albeit available pre-C99 standardization in several compilers.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2019-09-30 11:20 -0600 |
| Message-ID | <1bd0fhvgys.fsf@pfeifferfamily.net> |
| In reply to | #146447 |
Soviet_Mario <SovietMario@CCCP.MIR> writes: > On 30/09/2019 14:02, Bonita Montero wrote: >> I know alloca() neither is an official part of the C nor C++ >> program- >> ming-language. But I use it for performance-reasons. Can anyone name >> compilers that don't support alloca()? > > > sorry, mine is not an answer but a related question > > Since when (if at any time) was variable size automatic array > supported ? > > I mean a temporary array local to a function whose size becomes known > only at runtime (seems to me a generalization of variadic functions, > which, too, does not know at compile time how much stack space will > consume). > > If implemented, It seems equivalent to alloca () ... is it there some > limitation then in ORDER of automatic variable creations ? There is no such limitation on your C program. The VLA can be first, last, or in the middle. And you can have more than one of them. Where in the activation record a compiler chooses to put it is, AFAIK, not specified.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-30 19:42 +0200 |
| Message-ID | <qmtepc$ik9$1@news.albasani.net> |
| In reply to | #146454 |
>> If implemented, It seems equivalent to alloca () ... is it there some >> limitation then in ORDER of automatic variable creations ? > There is no such limitation on your C program. The VLA can be first, > last, or in the middle. And you can have more than one of them. alloca() can be called at almost any point in a function (with some compilers not within a function-call).
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-09-30 20:02 +0200 |
| Message-ID | <qmtfut$khj$2@dont-email.me> |
| In reply to | #146455 |
On 30/09/2019 19:42, Bonita Montero wrote: >>> If implemented, It seems equivalent to alloca () ... is >>> it there some >>> limitation then in ORDER of automatic variable creations ? > >> There is no such limitation on your C program. The VLA >> can be first, >> last, or in the middle. And you can have more than one of >> them. > > alloca() can be called at almost any point in a function > (with some > compilers not within a function-call). I've not clear what differences there are in alloca () usage vs plain declaration, then .... -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-09-30 19:54 +0200 |
| Message-ID | <qmtfha$gno$2@dont-email.me> |
| In reply to | #146454 |
On 30/09/2019 19:20, Joe Pfeiffer wrote: > Soviet_Mario <SovietMario@CCCP.MIR> writes: > >> On 30/09/2019 14:02, Bonita Montero wrote: >>> I know alloca() neither is an official part of the C nor C++ >>> program- >>> ming-language. But I use it for performance-reasons. Can anyone name >>> compilers that don't support alloca()? >> >> >> sorry, mine is not an answer but a related question >> >> Since when (if at any time) was variable size automatic array >> supported ? >> >> I mean a temporary array local to a function whose size becomes known >> only at runtime (seems to me a generalization of variadic functions, >> which, too, does not know at compile time how much stack space will >> consume). >> >> If implemented, It seems equivalent to alloca () ... is it there some >> limitation then in ORDER of automatic variable creations ? > > There is no such limitation on your C program. The VLA can be first, > last, or in the middle. And you can have more than one of them. > > Where in the activation record a compiler chooses to put it is, AFAIK, > not specified. ah ! So you are suggestion sort of internal reordering on the stack (like : all known types before, then the var-sized) ? > -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2019-09-30 14:28 -0600 |
| Message-ID | <1b8sq5v88v.fsf@pfeifferfamily.net> |
| In reply to | #146459 |
Soviet_Mario <SovietMario@CCCP.MIR> writes: > On 30/09/2019 19:20, Joe Pfeiffer wrote: >> Soviet_Mario <SovietMario@CCCP.MIR> writes: >> >>> On 30/09/2019 14:02, Bonita Montero wrote: >>>> I know alloca() neither is an official part of the C nor C++ >>>> program- >>>> ming-language. But I use it for performance-reasons. Can anyone name >>>> compilers that don't support alloca()? >>> >>> >>> sorry, mine is not an answer but a related question >>> >>> Since when (if at any time) was variable size automatic array >>> supported ? >>> >>> I mean a temporary array local to a function whose size becomes known >>> only at runtime (seems to me a generalization of variadic functions, >>> which, too, does not know at compile time how much stack space will >>> consume). >>> >>> If implemented, It seems equivalent to alloca () ... is it there some >>> limitation then in ORDER of automatic variable creations ? >> >> There is no such limitation on your C program. The VLA can be first, >> last, or in the middle. And you can have more than one of them. >> >> Where in the activation record a compiler chooses to put it is, AFAIK, >> not specified. > > ah ! So you are suggestion sort of internal reordering on the stack > (like : all known types before, then the var-sized) ? I'm saying there is nothing (I know of) prohibiting a compiler from doing that; without thinking too deeply about it, I suspect that if I were writing the compiler that would be my first approach (since, as you suggest, that would permit the other variables to be accessed through constant offsets).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-01 09:38 +0200 |
| Message-ID | <qmuvps$5eu$1@dont-email.me> |
| In reply to | #146473 |
On 30/09/2019 22:28, Joe Pfeiffer wrote: > Soviet_Mario <SovietMario@CCCP.MIR> writes: > >> On 30/09/2019 19:20, Joe Pfeiffer wrote: >>> Soviet_Mario <SovietMario@CCCP.MIR> writes: >>> >>>> On 30/09/2019 14:02, Bonita Montero wrote: >>>>> I know alloca() neither is an official part of the C nor C++ >>>>> program- >>>>> ming-language. But I use it for performance-reasons. Can anyone name >>>>> compilers that don't support alloca()? >>>> >>>> >>>> sorry, mine is not an answer but a related question >>>> >>>> Since when (if at any time) was variable size automatic array >>>> supported ? >>>> >>>> I mean a temporary array local to a function whose size becomes known >>>> only at runtime (seems to me a generalization of variadic functions, >>>> which, too, does not know at compile time how much stack space will >>>> consume). >>>> >>>> If implemented, It seems equivalent to alloca () ... is it there some >>>> limitation then in ORDER of automatic variable creations ? >>> >>> There is no such limitation on your C program. The VLA can be first, >>> last, or in the middle. And you can have more than one of them. >>> >>> Where in the activation record a compiler chooses to put it is, AFAIK, >>> not specified. >> >> ah ! So you are suggestion sort of internal reordering on the stack >> (like : all known types before, then the var-sized) ? > > I'm saying there is nothing (I know of) prohibiting a compiler from > doing that; without thinking too deeply about it, I suspect that if I > were writing the compiler that would be my first approach (since, as you > suggest, that would permit the other variables to be accessed through > constant offsets). > Exactly. It is a likely that the allocation would be handled something like that. But the compiler can arrange the details in any way it deems best. Alternatives include allocating some fixed frame variables first, then copying the stack pointer to a frame pointer (call it "fp"). Then the alloca() or VLA adds to the stack, then there is some more stack data (maybe another VLA or alloca() ). The first data can be accessed as "fp + offset", later data as "sp + offset". Intermediary anchor points can be saved as necessary. Mixing multiple VLA's and alloca's in the same function is likely to give you inefficient code and wasted stack space (alloca data lives until the end of the function, VLA's live until the end of the block). But the compiler's prime job is to give you correct object code, and it should handle that okay.
[toc] | [prev] | [next] | [standalone]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-09-30 20:01 +0200 |
| Message-ID | <qmtft6$khj$1@dont-email.me> |
| In reply to | #146454 |
On 30/09/2019 19:20, Joe Pfeiffer wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>
>> On 30/09/2019 14:02, Bonita Montero wrote:
>>> I know alloca() neither is an official part of the C nor C++
>>> program-
>>> ming-language. But I use it for performance-reasons. Can anyone name
>>> compilers that don't support alloca()?
>>
>>
>> sorry, mine is not an answer but a related question
>>
>> Since when (if at any time) was variable size automatic array
>> supported ?
>>
>> I mean a temporary array local to a function whose size becomes known
>> only at runtime (seems to me a generalization of variadic functions,
>> which, too, does not know at compile time how much stack space will
>> consume).
>>
>> If implemented, It seems equivalent to alloca () ... is it there some
>> limitation then in ORDER of automatic variable creations ?
>
> There is no such limitation on your C program. The VLA can be first,
> last, or in the middle. And you can have more than one of them.
>
> Where in the activation record a compiler chooses to put it is, AFAIK,
> not specified.
>
I have QT that does not supports them, but, if sb would be
so kind to copy a minimal asm generated code for some
int Funz (int A, int B)
{
int C = 3;
int Buf [A];
int D = 2;
Buf [A-1] = B;
return (A + B * D - C);
}
int main (void)
{
return Funz (4, 3);
}
I'd like to examine the assembler generated in order to
figure out how Buf (and D, beyond it apparently) are addressed
ah, if not to annoying, TURNING OFF most if not all
optimizationz (maybe the example is too minimal to be sort
of resolved at compile time :\)
tnx in advance
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web