Re: GNU Mes 0.20 released
Hello, > We are pleased to announce the release of GNU Mes 0.20, representing > 147 commits over 38 weeks. > > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap > a GNU/Linux system without binary GNU toolchain or equivalent). It > should land in Guix master any day now: a big thank you to everyone who > helped, notably Ludovic and Mark. > > This release is a step towards the upcoming Scheme-only bootstrap and > bringing Mes into NixOS and Debian. This effort is now sponsored by > NLnet[12]. > > Next targets: > > - ARM support > - Reduced Binary Seed bootstrap for ARM > - Scheme-only bootstrap: use Guile and Gash to remove bash, >coreutils&co, grep, sed, etc. from the Guix bootstrap binaries > - mes-m2: port Mes.c to M2-Planet > - Introduce Reduced Binaries Seed bootstrap to NixOS > - Debian? > - Hurd Thanks for the update, Jan! I'm really thrilled to see this effort moving forward. Congratulations for the release! Maxim
Re: Enabling Ctags Tree Wide for GCC
On Wed, 11 Sep 2019 at 09:55, Nicholas Krause wrote: > > > On 9/11/19 2:30 AM, Andreas Schwab wrote: > > On Sep 11 2019, Nicholas Krause wrote: > > > >> I was wondering what is the easiest way to allow source tree wide > >> ctags. > > There is make TAGS, which uses etags. Note: over time on the internet appeared quite a few different "ctags" projects (exuberant ctags universal ctags, anjuta-ctags, you named it), AFAIK the currently maintained and developed project with the most number of supported languages is universal ctags, so I recommend using it. > Is there no way to build it for vim as thats what I would prefer to stay > with. (disclaimer: I'm just a random reader of the ML) Using ctags with any project is as simple as `ctags -R` in base directory of sources (add -e option if you use Emacs). There's no need for any complex setup, because the "tags" format is very dumb. It's just "tag name" (e.g. name of a function, struct, macro), line number, and the whole line where that name is defined. So, in particular, if you have 2 functions foo() defined, and you jump to a tag "foo()", there's no way a text editor can figure out which one "foo()" is that you wanted, so it would either jump to the first occurrence (vim does that, you need to use :tn :tp to navigate further) or present you with a list of occurences (Emacs does this). So, I doubt there's a "make tags" command, because it's one symbol bigger than "ctags -R" ;-)
Re: [testsuite] Effective-target depending on current compiler flags?
Christophe Lyon writes:
> Hi,
>
> While looking at GCC validation results when configured for ARM
> cortex-m33 by default, I noticed that
> FAIL: gcc.target/arm/cmse/mainline/soft/cmse-5.c -march=armv8-m.main
> -mthumb -mfloat-abi=soft -O0 scan-assembler msr\tAPSR_nzcvqg, lr
>
> The corresponding line in the testcase is (are):
> /* { dg-final { scan-assembler "msr\tAPSR_nzcvq, lr" { target { !
> arm_dsp } } } } */
> /* { dg-final { scan-assembler "msr\tAPSR_nzcvqg, lr" { target arm_dsp } } }
> */
>
> So the arm_dsp effective target is true and the test tries to match
> APSR_nzcvqg, while APSR_nzcvq is generated, as expected.
>
> There is an inconsistency because the testcase is compiled with
> -march=armv8-m.main, while arm_dsp is not: like most effective
> targets, it does not take the current cflags into account.
> In the present case, the -march flag is added by cmse.exp in the
> arguments to gcc-dg-runtest.
>
> I tried to add [current_compiler_flags] to all arm effective targets
> (for consistency, it wouldn't make sense to add it to arm_dsp only),
> but then I noticed further problems...
Yeah, effective targets shouldn't depend on the compiler flags.
They're supposed to be properties of the testing target (what it
supports, what it enables by default, etc.) and are cached between
tests that run with different options.
CMSE isn't my area, so I don't know why the scan-assembler lines
were written this way. Is the { target arm_dsp } line there for
cases in which a user-specified -march flag manages to override
-march=armv8-m.main?
Thanks,
Richard
> For instance, in my configuration, when advsimd-intrinsics.exp is
> executed, it tries
> check_effective_target_arm_v8_2a_fp16_neon_hw
> which fails, and then tries check_effective_target_arm_neon_fp16_ok
> which succeeds and thus adds -mfloat-abi=softfp -mfp16-format=ieee to
> additional_flags.
>
> Since $additional_flags is passed to gcc-dg-runtest, these flags are
> visible by current_compiler_flags and taken into account when
> computing effective_targets (since I modified them).
>
> So... when computing arm_v8_2a_fp16_scalar_ok, it uses
> -mfloat-abi=softfp -mfp16-format=ieee and doesn't need to add any flag
> beyond -march=armv8.2-a+fp16.
> So et_arm_v8_2a_fp16_scalar_flags contains -march=armv8.2-a+fp16 only.
>
> Later on, while executing arm.exp, -mfloat-abi=softfp
> -mfp16-format=ieee are not part of $DEFAULT_CFLAGS as used by
> dg-runtest, but et_arm_v8_2a_fp16_scalar_flags is still in the cache
> and it's not valid anymore.
>
> So. before burying myself, is there already a way to make
> effective-targets take the current compiler flags into account as
> needed in gcc.target/arm/cmse/mainline/soft/cmse-5.c ?
>
> Not sure my explanation is clear enough :-)
>
> Thanks,
>
> Christophe
Re: Enabling Ctags Tree Wide for GCC
On Wed, 11 Sep 2019 at 12:50, Hi-Angel wrote: > > On Wed, 11 Sep 2019 at 09:55, Nicholas Krause wrote: > > > > > > On 9/11/19 2:30 AM, Andreas Schwab wrote: > > > On Sep 11 2019, Nicholas Krause wrote: > > > > > >> I was wondering what is the easiest way to allow source tree wide > > >> ctags. > > > There is make TAGS, which uses etags. > > Note: over time on the internet appeared quite a few different "ctags" > projects (exuberant ctags universal ctags, anjuta-ctags, you named > it), AFAIK the currently maintained and developed project with the > most number of supported languages is universal ctags, so I recommend > using it. > > > Is there no way to build it for vim as thats what I would prefer to stay > > with. > > (disclaimer: I'm just a random reader of the ML) > > Using ctags with any project is as simple as `ctags -R` in base > directory of sources (add -e option if you use Emacs). > > There's no need for any complex setup, because the "tags" format is > very dumb. It's just "tag name" (e.g. name of a function, struct, > macro), line number, and the whole line where that name is defined. > So, in particular, if you have 2 functions foo() defined, and you jump > to a tag "foo()", there's no way a text editor can figure out which > one "foo()" is that you wanted, so it would either jump to the first > occurrence (vim does that, you need to use :tn :tp to navigate > further) or present you with a list of occurences (Emacs does this). > > So, I doubt there's a "make tags" command, because it's one symbol > bigger than "ctags -R" ;-) Worth noting btw, that ctags are a great thing if you want to quickly dive in to a project, and you're okay with their downsides, such as not being able to resolve foo() as in example. This even especially emphasized by the fact my local Universal Ctags support 100 (!!!) languages (`ctags --list-languages | wc -l`) But in the long run, if you work with a project a lot, I'd recommend looking at setting up an LSP server. All modern editors support it, including vim and emacs (some natively, some through extensions). It doesn't have the downsides of tags format, and can also provide you with things like completion or error highlighting as you type.
Re: Enabling Ctags Tree Wide for GCC
On 9/11/19 7:02 AM, Nicholas Krause wrote: > Greetings, > > I was wondering what is the easiest way to allow source tree wide ctags. > There doesn't > > seem to be a make x command for it nor any real documentation online and it > would > > be nice to have. > > > Thanks, > > Nick > Hi. Please do not use ctags. It has very poor coverage for any C++ codebase. I prefer to use clangd (with -background-index) instead with vim-lsp (Language Server Protocol for VIM). https://clang.llvm.org/extra/clangd/Installation.html Martin
Re: [testsuite] Effective-target depending on current compiler flags?
On Wed, 11 Sep 2019 at 11:56, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > Hi,
> >
> > While looking at GCC validation results when configured for ARM
> > cortex-m33 by default, I noticed that
> > FAIL: gcc.target/arm/cmse/mainline/soft/cmse-5.c -march=armv8-m.main
> > -mthumb -mfloat-abi=soft -O0 scan-assembler msr\tAPSR_nzcvqg, lr
> >
> > The corresponding line in the testcase is (are):
> > /* { dg-final { scan-assembler "msr\tAPSR_nzcvq, lr" { target { !
> > arm_dsp } } } } */
> > /* { dg-final { scan-assembler "msr\tAPSR_nzcvqg, lr" { target arm_dsp } }
> > } */
> >
> > So the arm_dsp effective target is true and the test tries to match
> > APSR_nzcvqg, while APSR_nzcvq is generated, as expected.
> >
> > There is an inconsistency because the testcase is compiled with
> > -march=armv8-m.main, while arm_dsp is not: like most effective
> > targets, it does not take the current cflags into account.
> > In the present case, the -march flag is added by cmse.exp in the
> > arguments to gcc-dg-runtest.
> >
> > I tried to add [current_compiler_flags] to all arm effective targets
> > (for consistency, it wouldn't make sense to add it to arm_dsp only),
> > but then I noticed further problems...
>
> Yeah, effective targets shouldn't depend on the compiler flags.
> They're supposed to be properties of the testing target (what it
> supports, what it enables by default, etc.) and are cached between
> tests that run with different options.
>
Thanks for the clarification/confirmation it currently works as intended.
> CMSE isn't my area, so I don't know why the scan-assembler lines
> were written this way. Is the { target arm_dsp } line there for
> cases in which a user-specified -march flag manages to override
> -march=armv8-m.main?
>
I've added Andre in cc:, as he originally wrote that test.
Thanks,
Christophe
> Thanks,
> Richard
>
> > For instance, in my configuration, when advsimd-intrinsics.exp is
> > executed, it tries
> > check_effective_target_arm_v8_2a_fp16_neon_hw
> > which fails, and then tries check_effective_target_arm_neon_fp16_ok
> > which succeeds and thus adds -mfloat-abi=softfp -mfp16-format=ieee to
> > additional_flags.
> >
> > Since $additional_flags is passed to gcc-dg-runtest, these flags are
> > visible by current_compiler_flags and taken into account when
> > computing effective_targets (since I modified them).
> >
> > So... when computing arm_v8_2a_fp16_scalar_ok, it uses
> > -mfloat-abi=softfp -mfp16-format=ieee and doesn't need to add any flag
> > beyond -march=armv8.2-a+fp16.
> > So et_arm_v8_2a_fp16_scalar_flags contains -march=armv8.2-a+fp16 only.
> >
> > Later on, while executing arm.exp, -mfloat-abi=softfp
> > -mfp16-format=ieee are not part of $DEFAULT_CFLAGS as used by
> > dg-runtest, but et_arm_v8_2a_fp16_scalar_flags is still in the cache
> > and it's not valid anymore.
> >
> > So. before burying myself, is there already a way to make
> > effective-targets take the current compiler flags into account as
> > needed in gcc.target/arm/cmse/mainline/soft/cmse-5.c ?
> >
> > Not sure my explanation is clear enough :-)
> >
> > Thanks,
> >
> > Christophe
Re: Enabling Ctags Tree Wide for GCC
On 9/11/19, Nicholas Krause wrote: > Greetings, > > I was wondering what is the easiest way to allow source tree wide ctags. > There doesn't > > seem to be a make x command for it nor any real documentation online and > it would > > be nice to have. > ISTR this topic coming up 2 years ago: https://gcc.gnu.org/ml/gcc/2017-09/msg00266.html > > Thanks, > > Nick > >
Questions about initialization data during LTO
I'm trying to do a set of optimizations that drastically transform the layout of arrays of structures. For obvious reasons they will need to run at LTO time. I'm running into some difficulties comprehending how the initialization data is stored. Also, I'm seeing DECL_INITIALs being set to NULL and that is worrisome since it would throw a monkey wrench into what I'm doing. That is, because for my optimizations to work they will need to either disqualify an array with initialization data or transform said data. So, is the initialization data being hidden at LTO time? If not what's its format and how do I best manipulate it? Any insight into how to deal with these problem would be most helpful. These are some really interesting optimizations and will greatly speed up code that uses large arrays of structures. Thanks, Gary Oblock
A wide variety of PCB is provided
Hi, We are a UL/ISO/TS16949 certified High-tech PCB manufacturer in China. We offering prototype and mass production for all customers. If need a reference quote, please kindly let me know. Thanks. Our service covering below. FR4, High Tg170, Rogers material, 1-36 layers, 0.4-5.0mm board thickness, 0.5-8oz copper, 4/4mil track width/spacing, 0.2mm hole size, buried/blind vias, Immersion silver/tin/gold, HAL RoHS, OSP, plated gold finger, IPC-II/III quality standard, UL/ISO/TS16949 certified. 48hour fast turn prototype service, laser solder paste stencil.vv Best regards, Eva Company name：Shenzhen ZDCL Trade Co., Ltd. Mail：18475635...@163.com Skype：+8618475635876 Wechat：18475635876
