Snapshot gcc-12-20240718 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20240718/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
> Am 18.07.2024 um 16:20 schrieb Joern Wolfgang Rennecke
> :
>
> The tsvc tests take just too long on simulators, particularly if there is
> little or no vectorization of the test because of compiler limitations,
> target limitations, or the chosen options. Having
> 151 tests time out at a
The tsvc tests take just too long on simulators, particularly if there
is little or no vectorization of the test because of compiler
limitations, target limitations, or the chosen options. Having
151 tests time out at a quarter of an hour is not fun, and making the
time out go away by upping th
I guess I'll just say what platform I want to implement this for, since the
roundabout way of talking about it is probably confusing to everyone. It's
Windows, and hopefully implementing TLS for it should be relatively easier
since there is only 1 TLS model on Windows
best regards,
Julian
On Thu,
Hi Claudiu,
Thanks for the tip, I've since looked at and drawn inspiration from arc.cc.
The main issue I have now is how to implement the code in
legitimize_tls_address under i386.cc and the corresponding i386.md machine
description file to get the following assembly for a TLS read (Assuming
that
Am 17.07.24 um 20:49 schrieb Richard Sandiford:
Georg-Johann Lay writes:
[...]
Am 13.07.24 um 13:44 schrieb Richard Sandiford:
It shouldn't be necessary to emit the enum tag these days. If removing
Hi Richard,
I am not familiar with the gensupport policies, which is the reason why
the feat
> -Original Message-
> From: Jiang, Haochen
> Sent: Thursday, July 18, 2024 3:46 PM
> To: 'Sam James'
> Cc: 'gcc-regress...@gcc.gnu.org' ; 'gcc-
> testresu...@gcc.gnu.org' ; gcc@gcc.gnu.org
> Subject: gcc-regression script build fail info
>
> > > For future reports, would it be possibl
> > For future reports, would it be possible to change the grep to
> > something
> > like:
> >
> > grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
> >
> > This would allow catching the actual compile error in libbacktrace if
> > it's not going to fit in the last N lines from ma
