Re: building gcc 14 with gcc 14 ?

[David H. Lynch Jr. via Gcc]

Thanks. 

I am only building C/C++ not the rest of the suite. 
Most of my changes so far are to the c/c++ parser.  But I will have
changes to the code generation backends. 


I was having a problem with building my code - late in the build
process - I beleive when it was getting ready to run unit tests. 

But that was using gcc13 to build gcc13. 

Then my debian system updated to gcc14 and it is failing much quicker. 

I will try to post the build errors shortly.  


Again thx



On Sat, 2024-11-30 at 09:54 +, Jonathan Wakely wrote:
> 
> 
> On Sat, 30 Nov 2024, 09:01 David H. Lynch Jr. via Gcc,
>  wrote:
> > Is it possible to build gcc 13 with gcc 14 ?
> 
> Yes
> 
> > 
> > My system updated to gcc 14 and I am doing some private development
> > for
> > hardware stesting of a new memory addressing paradigm using the GCC
> > 13
> > code base. 
> > Now I can't compile. 
> > 
> > Do I need to revert my base compiler to gcc 13 ?
> 
> No, you can just build your own cot of GCC 13 and install it to a
> separate location e.g. under your home directory. Just don't install
> it to the same --prefix=DIR as the system compiler or you'll break
> things. 
> 
> 
> 

Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1

[Alexander Monakov]

On Sun, 1 Dec 2024, Gerald Pfeifer wrote:

> I tried to delete it via
> 
>   # git push origin --delete remotes/origin/python-formatting
> 
> alas just get
> 
>   error: unable to delete 'remotes/origin/python-formatting': remote ref does 
> not exist
> 
> Any idea how to drop that branch again from the main gcc.gnu.org repo?

You have to use the name of the branch in the remote repo, "python-formatting":

  git push --delete origin python-formatting

(or using the colon syntax:)

  git push origin :python-formatting

Alexander

gcc-15-20241201 is now available

[GCC Administrator via Gcc]

Snapshot gcc-15-20241201 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/15-20241201/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 90becd94cf92858555e0e538ec2091f952971453

You'll find:

 gcc-15-20241201.tar.xz   Complete GCC

  SHA256=2aba5b5e6ca78dceb016a7276e4f46b3e7c26eab778da77a6fab4069fb6159f7
  SHA1=1615f0db57fa6c19ec72f08d1763ada22d3eb579

Diffs from 15-20241124 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-15
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

New function attribute __call_push_jmp__

[Frederick Virchanza Gotham via Gcc]

Some modern CPU's now have control flow enforcement. Here's how it
works on Intel CPU's:

"The shadow stack stores a copy of the return address of each CALL. On
a RET, the processor checks if the return address stored in the normal
stack and shadow stack are equal. If the addresses are not equal, the
processor generates an INT #21 (Control Flow Protection Fault)."

So the two instructions being monitored by the central processing unit
are CALL and RET.

The CALL instruction can be broken into two instructions. The
following instruction:

call rax

can be turned into:

push rip+2
jmp rax

Similarly the RET instruction can be turned into:

pop r11
jmp r11

Therefore, if you want to compile a source file to an object file
replacing all call's with push+jmp, and all ret's with pop+jmp, then
the GNU compiler could have a new command line option:

gcc -o frog.o -c frog.c --call-push-jmp

An alternative would be to have a new function attribute called
"call_push_jmp" as follows:

extern int Func(int, double) __attribute__((call_push_jmp));

This would allow us to get around the control-flow enforcement (such
as when debugging, or when intercepting a function call).

Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1

[Gerald Pfeifer]

On Sun, 1 Dec 2024, Alexander Monakov wrote:
> You have to use the name of the branch in the remote repo, 
> "python-formatting":
> 
>   git push --delete origin python-formatting

That did the job, thank you!

On Sun, 1 Dec 2024, Mark Wielaard wrote:
> I believe the correct invocation is:
> 
> $ git push origin --delete python-formatting
> 
> against your local repo where your origin is
> ssh://ger...@gcc.gnu.org/git/gcc-wwwdocs.git
> 
> If that doesn't work we'll have to clean it up on the server.

I believe things are fine?

  % git branch -la  | cat
  * master
remotes/origin/HEAD -> origin/master
remotes/origin/master

Thanks,
Gerald

Re: Handling C2Y zero-length operations on null pointers

[Alejandro Colomar via Gcc]

Hi,

I had a discussion about this with another WG14 member when this was
voted in.  We both voted against, because this is nefarious for static
analysis.

However, I think this can be though to resemble how 'const' works in the
standard:

const char cbuf[10];

memcpy((char *)cbuf, "", 0);

The code above is legal even if it is passing a const pointer where a
non-const one is expected.  This is because memcpy(3) will not write to
it.

Nevertheless, if one does

memcpy(NULL, "", 0);

without a cast, the compiler will still diagnose.  This is important,
because if we would remove the diagnostics, it would be a footgun.

Similarly, we should allow null pointers (just like const pointers), in
the sense that there's no Undefined Behavior.  BUT there should be a
diagnostic.  Passing NULL is bad, and if one project wants to pass it,
it should do so with whatever compiler shenanigans to disable the
diagnostic (a cast, or a pragma, or whatever, not my problem).  In my
code, I want to see a diagnostic if I pass NULL to it, because in my
dialect (and in every C language before C2y), a null pointer is an
invalid pointer, and that distinction makes the code more robust.

I would either transform [[gnu::nonnull]] to be only about diagnostics
and not optimizations, or maybe add a _Optional qualifier that would
be used for this.

TL;DR:  Removing UB is nice, but removing diagnostics is NOT nice.

Have a lovely day!
Alex

P.S.:  I think it was a big mistake to vote this into C2y, and I voted
against.

-- 



signature.asc
Description: PGP signature

Re: Handling C2Y zero-length operations on null pointers

[Alejandro Colomar via Gcc]

> > And get clarified the qsort/bsearch cases whether it is about just
> > nmemb == 0 or nmemb * size == 0.
> 
> C does not support zero-sized objects, so that's something for us to
> figure out on our own.  We can treat size == 0 as invalid because the
> functions can't work, as they use pointers for the comparison function
> and not array indices.

Hi Florian,

This is not really true.  ISO C claims to not support 0-sized objects,
but then allows malloc(0) to return non-null, and

memcpy(malloc(0), malloc(0), 0);

has always been fully-complying in platforms like glibc, where malloc(0)
returns non-NULL.

Have a lovely day!
Alex


-- 



signature.asc
Description: PGP signature

Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1

[Mark Wielaard]

Hi Gerald,

On Sun, Dec 01, 2024 at 07:26:45PM +0100, Gerald Pfeifer wrote:
> On Fri, 23 Aug 2024, Eric Gallager wrote:
> >>> The branch, python-formatting has been created
> >>> at  e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1 (commit)
> >> Hmm, are you intentionally creating a branch for the wwwdocs repository
> >> (i.e., our web pages)? I don't recall us having used one before.
> > Sorry about that, I'd meant to create it just for my copy of the repo
> > that's mirrored to GitHub, but pushed it to the wrong remote by
> > accident.
> 
> I tried to delete it via
> 
>   # git push origin --delete remotes/origin/python-formatting
> 
> alas just get
> 
>   error: unable to delete 'remotes/origin/python-formatting': remote ref does 
> not exist
> 
> Any idea how to drop that branch again from the main gcc.gnu.org repo?

I believe the correct invocation is:

$ git push origin --delete python-formatting

against your local repo where your origin is
ssh://ger...@gcc.gnu.org/git/gcc-wwwdocs.git

If that doesn't work we'll have to clean it up on the server.

Cheers,

Mark

Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1

[Gerald Pfeifer]

On Fri, 23 Aug 2024, Eric Gallager wrote:
>>> The branch, python-formatting has been created
>>> at  e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1 (commit)
>> Hmm, are you intentionally creating a branch for the wwwdocs repository
>> (i.e., our web pages)? I don't recall us having used one before.
> Sorry about that, I'd meant to create it just for my copy of the repo
> that's mirrored to GitHub, but pushed it to the wrong remote by
> accident.

I tried to delete it via

  # git push origin --delete remotes/origin/python-formatting

alas just get

  error: unable to delete 'remotes/origin/python-formatting': remote ref does 
not exist

Any idea how to drop that branch again from the main gcc.gnu.org repo?

Gerald