Hello.
I have a mainframe operating system called z/PDOS-generic
available from https://pdos.org
I have ported a slightly modified gcc 3.2.3 (called
gccmvs) to it, and when run under Hercules/380
(mainframe emulator) it works fine and gccmvs is
able to reproduce itself byte-exact.
But I have a n
On Sat, Mar 01, 2025 at 20:01:21 +, vspefs wrote:
> Supporting C++ modules is easy, but I don't think "properly" is possible for
> any
> build system under current circumstances. Industrial consensus needed for many
> subjects:
I believe CMake is the furthest in this regard (though I haven't
Snapshot gcc-14-20250301 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20250301/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Sunday, March 2nd, 2025 at 02:13, Ben Boeckel via Gcc
wrote:
> On Sat, Mar 01, 2025 at 16:15:12 +, vspefs wrote:
>
> > I read a few mails from the autoconf thread. I'll try to read all now.
> > However,
> > a maybe-off-topic-but-could-be-on-topic question: what exactly is the state
> >
On Sat, Mar 01, 2025 at 16:15:12 +, vspefs wrote:
> I read a few mails from the autoconf thread. I'll try to read all now.
> However,
> a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of
> Autotools now? The whole Autotools build system seems to be on a very slow
>
> Am 01.03.2025 um 15:24 schrieb Martin Uecker :
>
> Am Samstag, dem 01.03.2025 um 16:52 +0300 schrieb Alexander Monakov:
>>> On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
>>>
>>> Sorry for being a bit slow. This is still not clear to me.
>>>
>>> In vect/pr65206.c the following loop can
I read a few mails from the autoconf thread. I'll try to read all now. However,
a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of
Autotools now? The whole Autotools build system seems to be on a very slow
release cycle. They seem to lack enough contributors/maintainers
On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
> > > What was the reason to disallow those optimizations that
> > > could be allowed by default?
> >
> > -fallow-store-data-races guards transforms that we know to be incorrect
> > for source code that may become a part of a multithreaded progr
GCC conjures up both .o file and .gcm file in one invocation when possible, too.
And yes, that can be managed well with grouped target - but a rule with grouped
target must have a recipe, which I think is a little beyond `gcc -M`'s scope.
Thanks for bringing up the pattern rule workaround, though.
Am Samstag, dem 01.03.2025 um 16:52 +0300 schrieb Alexander Monakov:
> On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
>
> > Sorry for being a bit slow. This is still not clear to me.
> >
> > In vect/pr65206.c the following loop can be vectorized
> > with -fallow-store-data-races.
> >
> > #def
On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
> Sorry for being a bit slow. This is still not clear to me.
>
> In vect/pr65206.c the following loop can be vectorized
> with -fallow-store-data-races.
>
> #define N 1024
>
> double a[N], b[N];
>
> void foo ()
> {
> for (int i = 0; i < N;
Snapshot gcc-13-20250301 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20250301/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
> On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>
> >
> > I have one follow-up question: What is the reason
> > that we have stronger semantics for stores by default (i.e.
> > when not using -fallow-store-data-races) than f
13 matches
Mail list logo
