Re: alloca (0) in include/libiberty.h
On 6/10/19 1:54 PM, Andrew Haley wrote: > On 6/10/19 8:24 AM, Martin Liška wrote: > >> I've just noticed that we have couple of alloca (0) in libiberty: >> >> #ifndef REGEX_MALLOC >> # ifdef C_ALLOCA >> alloca (0); >> # endif >> #endif >> >> If I'm correct the value 0 has a special meaning that tells a C library >> to clean up all previous alloca allocations. >> >> man alloca does not document the behavior > > I'm sure it doesn't. This alloca(0) behaviour is a libiberty-internal > thing. > >> Question is how legacy is alloca call from a standard library? > > alloca(3) is implemented by GCC as a builtin. It's fast, simple, and > widely used. These days you might use variable-length arrays instead, > which are at least portable. > > Is there some problem that you want to solve? > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are properly guarded within: # ifdef C_ALLOCA alloca (0); # endif and then I noticed 2 more occurrences in gdb that break build right now: gdb/regcache.c: alloca (0); gdb/top.c: alloca (0); Is it the right approach to remove these 2 in gdb? Martin
Re: alloca (0) in include/libiberty.h
On 6/11/19 9:49 AM, Martin Liška wrote: > gdb/regcache.c: alloca (0); > gdb/top.c: alloca (0); There's a PR for these: https://sourceware.org/bugzilla/show_bug.cgi?id=24653 Martin
Re: On-Demand range technology [6/5] - Integration
On Fri, Jun 7, 2019 at 4:54 PM Andrew MacLeod wrote: > > On 6/7/19 8:25 AM, Richard Biener wrote: > > On Wed, Jun 5, 2019 at 10:56 PM Andrew MacLeod wrote: > >> After the various discussions, I've evaluated how I think everything can > >> fit together, so this is my proposal for integration with trunk. > >> > >> > >> The complete Ranger prototype consists of 5 major components, one of > >> which is missing/un-implemented as yet :-) > >> > >> 1 - irange - This is the non-symbolic range implementation we've > >> been using which represents ranges as groups of ordered sub-ranges. > >> 2 - range-ops - This is the component which extracts ranges from > >> statements, and so performs the functionality of extract_range_from_*, > >> except it operates on the irange API and also allows for solving of > >> operands other than just the LHS of the expression. > >> 3 - GORI-computes - This is the component which utilizes range-ops to > >> compute a range on an outgoing edge for any ssa-name in the definition > >> chain of the branch > >> a_3 = b_6 * 2 > >> d_8 = a_3 - 20 > >>if (d_8 < 30) > >> the GORI-compute component can generate ranges for d_8, a_3 and b_6. > >> 4 - GORI-Cache and the Ranger. Working together, this provides the > >> on-demand range functionality to resolve ranges > >> 5 - relational/equivalency tracker - This is the sketched out but > >> unimplemented bit which tracks the symbolic relationships, and remove > >> the need for ranges to support symbolics. ( <,<=, >, >=, ==, != and none). > >> > >> The consensus appears to be that range-ops and gori-computes are good > >> candidates to replace aspects of vr-values and assert generation. > >> > >> A) > >> Until I get to (5) (relational tracker), using (1) (irange) is a > >> non-starter since it doesn't handle symbolics. > >> > >> To eliminate the range issue from the equation, Aldy is currently > >> working on unifying the irange and value_range APIs. This will allow > >> the rest of the ranger code base to use the value_range implementation > >> transparently. We can talk about irange or some alternate > >> implementation of ranges at some later point, but there'll be an API > >> that works for all clients. > >> > >> The existing value_range API gets a few tweaks/cleanups, but mostly > >> there is an additional set of calls to query sub-ranges which the ranger > >> and range-ops require. These routines basically translate the various > >> value ranges formats into discrete sub-ranges. Thru these rotuines, > >> ANTI_RANGE will appear as 2 sub-ranges, VARYING as a [MIN, MAX] range, > >> and UNDEFINED as an empty range []. These additions should allow > >> value_range to function as the range implementation for both the ranger > >> and VRP. > >> > >> I suspect he will have patches coming shortly that will help to unify > >> the 2 range implementations, we can discuss details over those patches.. > >> > >> B) > >> A Unified range API then allows us to work on integrating the range-ops > >> and GORI-computes component into the code base. Range ops would > >> replace the various extract_range_from_*_ routines in vr_values for > >> statement level ranges. GORI-computes would then replace the assert > >> building code for calculating outgoing ranges on edges. In theory EVRP > >> then simply calls range_on_edge() from gori_compute instead of > >> register_edge_assert() . > >> > >> The range ops code is designed to perform all evaluations assuming an > >> arbitrary number of sub-ranges. Aldy spent a lot of time last year > >> unifying the VRP code and the range-ops code to get the identical > >> results, and they frequently share a common base. He has gone thru > >> excruciating care to ensure the calculations are identical and verifies > >> it by calculating everything using both code bases, comparing them, and > >> aborting if the results ever get diverge. > >> > >> We will need to adjust the range-ops code to work with symbolics in > >> certain place. This means PLUS, MINUS, all the relations (<,>, etc), and > >> copy. Probably something else as it is encountered. This is un-sized as > >> yet, but I'm hoping won't be too bad assuming we can utilize some of the > >> existing code for those bits.. More details when we actually start > >> doing this and find the lurking dragons. > >> > >> we'll worry about bitmasks and equivalencies when we get closer to > >> functioning, but I don't foresee too much problem since value_range_base > >> is still being used. > >> > >> > >> C) That will keep us busy for a while, and should result in the core > >> integration. Meanwhile, we'll try to figure out the relational code > >> design. I'll go back to my original design, adjust that, then we can > >> figure out how best to proceed to address the various needs. > >> > >> D) Finally, the GORI-cache and on-demand ranger are blocked until the > >> above work is finished. > >> > >> > >> One additional thing I would like to
Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
Hi! We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', r272156) would correspond to Git commit 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version files for release", but the Git 'gcc-9_1_0-release' tag points one commit further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER: Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is indeed the only difference.) The Git tag can't be corrected now (would it make sense to push a Git 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get it into the mighty Internet archives; may this note help others who stumble over the same thing. Grüße Thomas
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote: > > Hi! > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > r272156) would correspond to Git commit > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version > files for release", but the Git 'gcc-9_1_0-release' tag points one commit > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER: > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is > indeed the only difference.) That's probably my fault, I think I created the tag. > The Git tag can't be corrected now (would it make sense to push a Git > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get it > into the mighty Internet archives; may this note help others who stumble > over the same thing. Can't we just delete the tag and add it at the right commit?
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Tue, 11 Jun 2019 at 16:18, Jonathan Wakely wrote: > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote: > > > > Hi! > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > > r272156) would correspond to Git commit > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version > > files for release", but the Git 'gcc-9_1_0-release' tag points one commit > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER: > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is > > indeed the only difference.) > > That's probably my fault, I think I created the tag. > > > The Git tag can't be corrected now (would it make sense to push a Git > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get it > > into the mighty Internet archives; may this note help others who stumble > > over the same thing. > > Can't we just delete the tag and add it at the right commit? I don't think I can do that by pushing a new tag to the repo, but somebody with the right privs could do it locally on sourceware.org. I think Jason and Joseph should be able to, maybe others too. Changing a tag isn't like rebasing history of a branch, it's not going to mess things up for anybody.
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
Hi! On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely wrote: > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote: > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > > r272156) (Eh, at the end of that 'svn co [...]', it printed that it "Checked out revision 272156", but the GCC 9.1 release actually is r270840, and r272156 is GCC trunk from a moment ago.) > > would correspond to Git commit > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version > > files for release", but the Git 'gcc-9_1_0-release' tag points one commit > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER: > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is > > indeed the only difference.) > > That's probably my fault, I think I created the tag. > > > The Git tag can't be corrected now (would it make sense to push a Git > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get it > > into the mighty Internet archives; may this note help others who stumble > > over the same thing. > > Can't we just delete the tag and add it at the right commit? I don't think that'll be useful: as far as I remember (but please correct me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so different clones might then have different 'gcc-9_1_0-release' tags. Grüße Thomas
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge wrote: > > Hi! > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely > wrote: > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge > > wrote: > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > > > r272156) > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked out > revision 272156", but the GCC 9.1 release actually is r270840, and > r272156 is GCC trunk from a moment ago.) > > > > would correspond to Git commit > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version > > > files for release", but the Git 'gcc-9_1_0-release' tag points one commit > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER: > > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is > > > indeed the only difference.) > > > > That's probably my fault, I think I created the tag. > > > > > The Git tag can't be corrected now (would it make sense to push a Git > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get it > > > into the mighty Internet archives; may this note help others who stumble > > > over the same thing. > > > > Can't we just delete the tag and add it at the right commit? > > I don't think that'll be useful: as far as I remember (but please correct > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so I think that's right, but 'git fetch --tags' would update it. > different clones might then have different 'gcc-9_1_0-release' tags. Which doesn't seem like a problem to me. I could create a local tag with that name for any arbitrary revision. It wouldn't match what's in everybody else's clone, but that's fine.
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote: > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge wrote: > > > > Hi! > > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely > > wrote: > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge > > > wrote: > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > > > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > > > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > > > > r272156) > > > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked out > > revision 272156", but the GCC 9.1 release actually is r270840, and > > r272156 is GCC trunk from a moment ago.) > > > > > > would correspond to Git commit > > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version > > > > files for release", but the Git 'gcc-9_1_0-release' tag points one > > > > commit > > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER: > > > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is > > > > indeed the only difference.) > > > > > > That's probably my fault, I think I created the tag. > > > > > > > The Git tag can't be corrected now (would it make sense to push a Git > > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get > > > > it > > > > into the mighty Internet archives; may this note help others who stumble > > > > over the same thing. > > > > > > Can't we just delete the tag and add it at the right commit? > > > > I don't think that'll be useful: as far as I remember (but please correct > > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so > > I think that's right, but 'git fetch --tags' would update it. > > > different clones might then have different 'gcc-9_1_0-release' tags. > > Which doesn't seem like a problem to me. > > I could create a local tag with that name for any arbitrary revision. > It wouldn't match what's in everybody else's clone, but that's fine. It seems to me that having the master repo have the correct tag is more valuable than everybody having the same tag. And because, as you say, the difference is just one commit, it's not like doing diffs or other commands using the old value of the tag would look at a completely wrong branch or completely different histories.
Re: alloca (0) in include/libiberty.h
Hi, On Tue, 11 Jun 2019, Martin Liška wrote: > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > properly > guarded within: > > # ifdef C_ALLOCA > alloca (0); > # endif > > and then I noticed 2 more occurrences in gdb that break build right now: > > gdb/regcache.c: alloca (0); > gdb/top.c: alloca (0); > > Is it the right approach to remove these 2 in gdb? It's more an indication that the annotation requesting the warning for unused results is simply overeager (aka wrong) for alloca. (sure, the uses in gdb probably could be cleaned up as well, but that doesn't affect the wrongness of the warning). Ciao, Michael.
Re: alloca (0) in include/libiberty.h
On Tue, Jun 11, 2019 at 03:58:27PM +, Michael Matz wrote: > On Tue, 11 Jun 2019, Martin Liška wrote: > > > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > > properly > > guarded within: > > > > # ifdef C_ALLOCA > > alloca (0); > > # endif > > > > and then I noticed 2 more occurrences in gdb that break build right now: > > > > gdb/regcache.c: alloca (0); > > gdb/top.c: alloca (0); > > > > Is it the right approach to remove these 2 in gdb? > > It's more an indication that the annotation requesting the warning for > unused results is simply overeager (aka wrong) for alloca. (sure, the > uses in gdb probably could be cleaned up as well, but that doesn't affect > the wrongness of the warning). Yeah. Either we special-case alloca in the warn_unused_result code - if the call flags include ECF_MAY_BE_ALLOCA and argument is 0, don't warn, or don't add the attribute to alloca, or add yet another attribute that will be used for alloca only. Jakub
The 7th HelloLLVM / HelloGCC social in China: Shanghai, June 22, 2019
Hi all, The 7th HelloLLVM / HelloGCC social in China will happen on June 22, 2019. The location is at Shanghai. Everyone interested in LLVM/GCC/Toolchain related projects is invited to join. Event details is at https://mp.weixin.qq.com/s/ErxD4BwSRgTYRuErHCPMJQ BoF style. Presentations are welcome too :-) Current Topics: 1. MLIR introduction. 2. New progresses in compiler area. 3. TVM related discussions. 4. The shortage of new GCC developers and how to help. 5. Lighting talks. Looking forward to meet you ! -- Best wishes, Wei Wu (吴伟)
Re: Preventing ISO C errors when using macros for builtin types
On Mon, 10 Jun 2019 17:09:10 -0500
Segher Boessenkool wrote:
> On Mon, Jun 10, 2019 at 08:58:00PM +0100, Jozef Lawrynowicz wrote:
> > On Mon, 10 Jun 2019 13:32:42 -0500
> > Segher Boessenkool wrote:
> > > That is not a fix, that is sweeping the problem under the rug.
> > >
> > > As a somewhat dirty hack I added
> > >
> > > #if __MSP430X_LARGE__
> > > #undef __SIZE_TYPE__
> > > __extension__ typedef unsigned __int20 __SIZE_TYPE__;
> > > #endif
> > >
> > > to the start of the installed stddef.h, and that fixes the problem fine,
> > > for correct programs that do not forget to include (directly
> > > or indirectly), anyway.
>
> > But we have some 850 generic tests in gcc/testsuite that use __SIZE_TYPE__
> > without including stddef.h. They just rely on the preprocessor to expand
> > this
> > using the builtin macro definition.
>
> I did say it is a dirty hack, right?
>
> You could call lang_hooks.types.register_builtin_type defining the type
> __SIZE_TYPE__ as the int20 partial int type, and then define SIZE_TYPE as
> just __SIZE_TYPE__. That is the same effectively, just not using the
> header file.
>
> So something like
>
> tree type_node = builtin_type_for_size (20, 1);
> lang_hooks.types.register_builtin_type (type_node, "__SIZE_TYPE__");
>
> or maybe
>
> tree type_node = builtin_type_for_size (POINTER_SIZE, 1);
> lang_hooks.types.register_builtin_type (type_node, "__SIZE_TYPE__");
>
> in msp430.c, and
>
> #define SIZE_TYPE "__SIZE_TYPE__"
>
> in msp430.h?
>
>
> Segher
Thanks for the pointers, they've put me on the right track I think.
It doesn't look like we can create the new type in the msp430 backend - the
SIZE_TYPE macro is examined quite early and only a couple of basic backend
initialization functions are called before SIZE_TYPE is needed in
c_common_nodes_and_builtins(). TARGET_INIT_BUILTINS seemed most appropriate,
but by then it's too late to create the type and use it in msp430.h.
Instead I fixed it by creating a new type "__int20__" in the middle-end,
which can then be used for SIZE_TYPE in msp430.h.
__int20__ is not really a proper type - it shares it's "RID" values with
__int20, but it means we can gate the ISO C pedwarn so it only is emitted for
__int20 and not __int20__. It's ok for __int20 and __int20__ to have identical
behavior, aside from the pedwarn, which is why sharing the RIDs should be ok.
I think this solution fits ok with the existing behavior related to "pedantic"
warnings, since alternate keywords beginning and ending
with "__" are considered GNU Extensions and don't pedwarn. I guess "__int20"
isn't technically a "keyword" in the same sense as "asm" for example. But
its a "reserved word" and this fix fits this pattern of surrounding with
double-underscores.
Any thoughts on this approach in my attached (rough) patch? So far I regtested
it fine with the GCC C testsuite for msp430-elf.
Also need to do the same for PTRDIFF_TYPE and make that use __int20__.
I initially implemented this by giving the __intN__ types their own new set of
RIDs so they are completely distinct from __intN, but it requires quite a lot
of duplicated code whenever RID_INT_N_* or RID_{FIRST,LAST}_INT_N are used,
just to handle the new RIDs. This patch is at least quite concise and gets the
job done.
Of course, if the __intN__ types really should have their own unique RIDs
then I can do it that way instead.
Thanks,
Jozef
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4057be3aaed..57e84b84f07 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -4024,8 +4024,14 @@ c_common_nodes_and_builtins (void)
sprintf (name, "__int%d", int_n_data[i].bitsize);
record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), name,
int_n_trees[i].signed_type);
+ sprintf (name, "__int%d__", int_n_data[i].bitsize);
+ record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), name,
+ int_n_trees[i].signed_type);
+
sprintf (name, "__int%d unsigned", int_n_data[i].bitsize);
record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type);
+ sprintf (name, "__int%d__ unsigned", int_n_data[i].bitsize);
+ record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type);
}
if (c_dialect_cxx ())
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 87ce853d4b7..cb2f49fa5a2 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -10637,7 +10637,11 @@ declspecs_add_type (location_t loc, struct c_declspecs *specs,
case RID_INT_N_2:
case RID_INT_N_3:
specs->int_n_idx = i - RID_INT_N_0;
- if (!in_system_header_at (input_location))
+ if (!in_system_header_at (input_location)
+ /* If the INT_N type ends in "__", and so is of the format
+ "__intN__", don't pedwarn. */
+ && (strncmp (IDENTIFIER_POINTER (type)
+ + (IDENTIFIER_LENGTH (type) - 2), "__", 2) != 0))
pedwarn (loc, OPT_Wpedantic,
"ISO C does not support %<__int%d%> types",
int_n_data[spec
Re: Preventing ISO C errors when using macros for builtin types
Hi Jozef,
On Tue, Jun 11, 2019 at 09:44:30PM +0100, Jozef Lawrynowicz wrote:
> Thanks for the pointers, they've put me on the right track I think.
>
> It doesn't look like we can create the new type in the msp430 backend - the
> SIZE_TYPE macro is examined quite early and only a couple of basic backend
> initialization functions are called before SIZE_TYPE is needed in
> c_common_nodes_and_builtins(). TARGET_INIT_BUILTINS seemed most appropriate,
> but by then it's too late to create the type and use it in msp430.h.
>
> Instead I fixed it by creating a new type "__int20__" in the middle-end,
> which can then be used for SIZE_TYPE in msp430.h.
> __int20__ is not really a proper type - it shares it's "RID" values with
> __int20, but it means we can gate the ISO C pedwarn so it only is emitted for
> __int20 and not __int20__.
Ooh I like this :-) Fits in well everywhere, and it's nicely generic, too.
> It's ok for __int20 and __int20__ to have identical
> behavior, aside from the pedwarn, which is why sharing the RIDs should be ok.
Many other keywords do the same, see asm/__asm/__asm__ for example.
> I think this solution fits ok with the existing behavior related to "pedantic"
> warnings, since alternate keywords beginning and ending
> with "__" are considered GNU Extensions and don't pedwarn. I guess "__int20"
> isn't technically a "keyword" in the same sense as "asm" for example. But
> its a "reserved word" and this fix fits this pattern of surrounding with
> double-underscores.
> Any thoughts on this approach in my attached (rough) patch? So far I regtested
> it fine with the GCC C testsuite for msp430-elf.
> Also need to do the same for PTRDIFF_TYPE and make that use __int20__.
> --- a/gcc/lto/lto-lang.c
> +++ b/gcc/lto/lto-lang.c
> @@ -1260,9 +1260,9 @@ lto_build_c_type_nodes (void)
> if (int_n_enabled_p[i])
> {
> char name[50];
> - sprintf (name, "__int%d unsigned", int_n_data[i].bitsize);
> + sprintf (name, "int%d", int_n_data[i].bitsize);
>
> - if (strcmp (name, SIZE_TYPE) == 0)
> + if (strstr (SIZE_TYPE, name) != NULL)
> {
> intmax_type_node = int_n_trees[i].signed_type;
> uintmax_type_node = int_n_trees[i].unsigned_type;
I don't think that is correct, strstr allows too much? If you want to
allow some variants, you should test for all those variants exactly?
It looks great otherwise :-)
Segher
Can we vectorize the code below ?
Hi,
I recently did some analysis on the automatic vectorization of gcc, I
found that singed char can not be vectorized in the following code.
---
#define ITERATIONS 100
#if defined(do_reduce_signed_char)
#define TYPE signed char
#elif defined(do_reduce_unsigned_char)
#define TYPE unsigned char
#else
#error bad define
#endif
#define SIZE (16384/sizeof(TYPE))
static TYPE x[SIZE] __attribute__ ((aligned (16)));
void obfuscate(void *a, ...);
static void __attribute__((noinline)) do_one(void)
{
unsigned long i;
TYPE a = 0;
obfuscate(x);
for (i = 0; i < SIZE; i++)
a += x[i];
obfuscate(x, a);
}
int main(void)
{
unsigned long i;
for (i = 0; i < ITERATIONS; i++)
do_one();
return 0;
}
---
If we use the following command line
gcc reduce.c -Ddo_reduce_unsigned_char -Ofast -c -S -fdump-tree-vect-details
We can see that this code can be vectorized under the unsigned char data
type.
If we use the following command
gcc reduce.c -Ddo_reduce_signed_char -Ofast -c -S -fdump-tree-vect-details
We can see that this code cannot be vectorized under the singed char
data type.
I found in the below code for singed char
---
a += x[i];
---
Will do something like the following conversion.
---
a = (signed char) ((unsigned char) x[i] + (unsigned char) a);
---
As a result, the reduction in the code cannot be effectively identified.
Can we vectorize the code like the above when the data type is signed char ?
Thanks,
Lijia He
