Re: Referencing a register in different modes

2024-08-09 Thread Stefan Schulze Frielinghaus via Gcc
On Thu, Aug 08, 2024 at 01:56:48PM -0600, Jeff Law wrote: > > I haven't tested it extensively but it triggers at least for the current > > case. > > I would have loved to also print the insn but couldn't figure out how to ICE > > and stringify an insn. I will have a look at this tomorrow. Did yo

Re: How to implement Native TLS for a specific platform?

2024-08-09 Thread Julian Waters via Gcc
Just so everyone has a better idea of what I've tried, this is my patch so far: diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index 02e28290441..a2af8325c8f 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -788,6 +788,21 @@ x86_64_elf_select_section (tree decl

Re: Spurious -Wsequence-point with auto

2024-08-09 Thread Martin Uecker via Gcc
Am Freitag, dem 09.08.2024 um 01:10 +0200 schrieb Alejandro Colomar via Gcc: > Hi, > > I've seen some bogus warning in GCC that suggests that some use of auto > may cause undefined behavior (due to double evaluation). > > $ cat auto.c > #include > > int > main(void) > { > int i = 3; >

Re: Spurious -Wsequence-point with auto

2024-08-09 Thread Alejandro Colomar via Gcc
Hi Martin, On Fri, Aug 09, 2024 at 10:31:55AM GMT, Martin Uecker wrote: > Can you file a bug if there isn't one already? > BTW: Double evaluation is not only a problem for semantics, but also because > it can cause long compile times, cf. t

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Alejandro Colomar via Gcc
Hi Martin, On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's any legitimate use sizeof() on such a para

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Jakub Jelinek via Gcc
On Fri, Aug 09, 2024 at 02:19:26PM +0200, Alejandro Colomar via Gcc wrote: > On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > > Hi Martin, > > > > > > Can we promote -Wno-sizeof-array-argument to a hard err

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Alejandro Colomar via Gcc
Hi Jakub, On Fri, Aug 09, 2024 at 02:24:48PM GMT, Jakub Jelinek wrote: > You can compile your sources with -Werror=sizeof-array-argument if you want > it to be an error, The problem with that is that the error will still be enforced _after_ GCC would change the behavior of sizeof(aparam). Admitt

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Jakub Jelinek via Gcc
On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote: > The problem with that is that the error will still be enforced _after_ > GCC would change the behavior of sizeof(aparam). I don't think it should unless C2Y requires that. > Admittedly, I could write configure checks to determin

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Joseph Myers via Gcc
On Fri, 9 Aug 2024, Alejandro Colomar via Gcc wrote: > Since I don't see any legitimate uses of sizeof(aparam) as of today, I > don't expect having any consequences on existing code. (But please > point me wrong if there are any, maybe in generic macros.) It's perfectly legitimate when the user

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Jakub Jelinek via Gcc
On Fri, Aug 09, 2024 at 03:42:06PM +0200, Jakub Jelinek via Gcc wrote: > On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote: > > The problem with that is that the error will still be enforced _after_ > > GCC would change the behavior of sizeof(aparam). > > I don't think it should un

Re: Promote -Wno-sizeof-array-argument to an error

2024-08-09 Thread Alejandro Colomar via Gcc
On Fri, Aug 09, 2024 at 04:03:53PM GMT, Jakub Jelinek wrote: > E.g. consider GCC > #define iterative_hash_object(OB,INIT) iterative_hash (&OB, sizeof (OB), INIT) > macro. > If one uses it on the function parameters declared as arrays but turned into > pointers and you know what you are doing, why n

git help: fortran_unsigned branch

2024-08-09 Thread Thomas Koenig via Gcc
Hi, I have managed to bring the fortran-unsigned branch into a state where it can no longer be rebased. When I do a $ git rebase master I get ... warning: skipped previously applied commit a6399bb27b3 hint: use --reapply-cherry-picks to include skipped commits hint: Disable this message with "

Re: git help: fortran_unsigned branch

2024-08-09 Thread Dimitar Dimitrov
On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote: > Hi, > > I have managed to bring the fortran-unsigned branch into a state where > it can no longer be rebased. When I do a > > $ git rebase master It's unknown what is the state of your local master branch. So I would advise

Re: git help: fortran_unsigned branch

2024-08-09 Thread Thomas Koenig via Gcc
Hi Dimitar, On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote: Hi, I have managed to bring the fortran-unsigned branch into a state where it can no longer be rebased. When I do a $ git rebase master It's unknown what is the state of your local master branch. So I would ad

Re: git help: fortran_unsigned branch

2024-08-09 Thread Dimitar Dimitrov
/devel/fortran_unsigned, then you > > are attempting to merge pre-rebase history with post-rebase history. > > In such case conflicts are expected. Don't pull the remote devel > > branch. > > Hmm... but I already did. And, following other people's advice, >

Re: git help: fortran_unsigned branch

2024-08-09 Thread Thomas Koenig via Gcc
# Create a new local tracking branch $ git checkout -b fortran_unsigned-20240809 origin/devel/fortran_unsigned $ git rebase origin/master $ gitk -n1000 I tried that, with te same result: warning: skipped previously applied commit a6399bb27b3 hint: use --reapply-cherry-picks to include

Re: git help: fortran_unsigned branch

2024-08-09 Thread Dimitar Dimitrov
r local branch. Example: > > > ># Just in case, see which is your old local branch. > >$ git branch > > > ># Create a new local tracking branch > >$ git checkout -b fortran_unsigned-20240809 origin/devel/fortran_unsigned > >$ git rebase

Re: git help: fortran_unsigned branch

2024-08-09 Thread Thomas Koenig via Gcc
Am 09.08.24 um 21:57 schrieb Dimitar Dimitrov: You are redoing the rebase again. So it is expected to get the same warnings. I need to get the changes from master into my branch, or else things will not compile due to changes in master. But it seems that this is no longer possible, thanks to

gcc-13-20240809 is now available

2024-08-09 Thread GCC Administrator via Gcc
Snapshot gcc-13-20240809 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20240809/ 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