Re: Referencing a register in different modes

[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 you have 
> > any
> > place in mind where to put/call something like this?
> I didn't have anywhere specific in mind.   As I suspected the
> verify_rtl_sharing isn't a great fit from an implementation standpoint, but
> it seems right conceptually.

Right and since we are walking over all insns there anyway we could also
check pseudos on the go.  I didn't want to rename verify_rtl_sharing()
since this is publicly visible but renamed verify_insn_sharing() into
verify_insn_sharing_and_pseudo_references() to reflect the additional
work---although the name is bit of a mouthful.

> If you want to throw a patch over the wall for testing, happy to put it into
> my tester and see what comes out the other side.  I wouldn't be at all
> surprised if it tripped on other targets.

Having more testing would be great.  I've attached a new patch.

Cheers,
Stefan
>From 0199088d2877c9c840ce984f61365816879818bc Mon Sep 17 00:00:00 2001
From: Stefan Schulze Frielinghaus 
Date: Fri, 9 Aug 2024 09:45:57 +0200
Subject: [PATCH] rtl: Verify pseudo register references

Ensure that each pseudo register referenced in an insn equals its
definition.  In particular this means that we error out if a pseudo
register is referenced in a different mode.
---
 gcc/emit-rtl.cc | 37 +
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
index cb04aa1a8c6..00af73ca219 100644
--- a/gcc/emit-rtl.cc
+++ b/gcc/emit-rtl.cc
@@ -3122,16 +3122,45 @@ reset_all_used_flags (void)
   }
 }
 
-/* Verify sharing in INSN.  */
+/* Verify that each pseudo register referenced in INSN equals its definition.
+   For example, error out if modes do not coincide. */
 
 static void
-verify_insn_sharing (rtx insn)
+verify_rtl_pseudo_references (rtx insn)
+{
+  subrtx_iterator::array_type array;
+  FOR_EACH_SUBRTX (iter, array, PATTERN (insn), NONCONST)
+{
+  const_rtx reg = *iter;
+  if (!reg || !REG_P (reg))
+   continue;
+  int regno = REGNO (reg);
+  /* Hard registers may be referenced in different modes.  */
+  if (HARD_REGISTER_NUM_P (regno))
+   continue;
+  const_rtx orig_reg = regno_reg_rtx[regno];
+  if (!rtx_equal_p (reg, orig_reg))
+   {
+ error ("pseudo register");
+ debug_rtx (orig_reg);
+ error ("does not coincide with its reference in insn");
+ debug_rtx (insn);
+ internal_error ("internal consistency failure");
+   }
+}
+}
+
+/* Verify sharing and pseudo references in INSN.  */
+
+static void
+verify_insn_sharing_and_pseudo_references (rtx insn)
 {
   gcc_assert (INSN_P (insn));
   verify_rtx_sharing (PATTERN (insn), insn);
   verify_rtx_sharing (REG_NOTES (insn), insn);
   if (CALL_P (insn))
 verify_rtx_sharing (CALL_INSN_FUNCTION_USAGE (insn), insn);
+  verify_rtl_pseudo_references (insn);
 }
 
 /* Go through all the RTL insn bodies and check that there is no unexpected
@@ -3151,13 +3180,13 @@ verify_rtl_sharing (void)
   {
rtx pat = PATTERN (p);
if (GET_CODE (pat) != SEQUENCE)
- verify_insn_sharing (p);
+ verify_insn_sharing_and_pseudo_references (p);
else
  for (int i = 0; i < XVECLEN (pat, 0); i++)
  {
rtx insn = XVECEXP (pat, 0, i);
if (INSN_P (insn))
- verify_insn_sharing (insn);
+ verify_insn_sharing_and_pseudo_references (insn);
  }
   }
 
-- 
2.45.2

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

[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, int reloc,
   return default_elf_select_section (decl, reloc, align);
 }

+ATTRIBUTE_UNUSED static section *
+mingw_w64_pe_select_section (tree decl, int reloc,
+  unsigned HOST_WIDE_INT align)
+{
+  if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
+{
+  if (!DECL_P (decl))
+   decl = NULL_TREE;
+
+  return get_named_section (decl, ".tls$", reloc);
+}
+  else
+return default_select_section (decl, reloc, align);
+}
+
 /* Select a set of attributes for section NAME based on the properties
of DECL and whether or not RELOC indicates that DECL's initializer
might contain runtime relocations.  */
@@ -12151,6 +12166,26 @@ legitimize_tls_address (rtx x, enum tls_model
model, bool for_mov)
   machine_mode tp_mode = Pmode;
   int type;

+#if TARGET_WIN32_TLS
+  rtx scratch = gen_rtx_SCRATCH (Pmode);
+
+  rtx basereg = gen_reg_rtx (Pmode);
+  rtx thread = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const0_rtx),
UNSPEC_TP);
+
+  rtx insn = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, gen_rtx_SET
(basereg, thread), gen_rtx_CLOBBER (VOIDmode, scratch)));
+  emit_insn (insn);
+
+  // Only 64-bit is supported
+  rtx offset = gen_rtx_UNSPEC (SImode, gen_rtvec (1, x), UNSPEC_TPOFF);
+  offset = gen_rtx_CONST (SImode, offset);
+
+  rtx reg = gen_reg_rtx (Pmode);
+  insn = gen_rtx_SET (gen_rtx_SUBREG (SImode, reg, 0), offset);
+  emit_insn (insn);
+
+  return gen_rtx_PLUS (Pmode, basereg, reg);
+#endif
+
   /* Fall back to global dynamic model if tool chain cannot support local
  dynamic.  */
   if (TARGET_SUN_TLS && !TARGET_64BIT
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index eabb3248ea0..aa88fc50ea0 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -504,6 +504,7 @@ extern unsigned char ix86_prefetch_sse;
 #define TARGET_GNU2_TLS(ix86_tls_dialect ==
TLS_DIALECT_GNU2)
 #define TARGET_ANY_GNU_TLS (TARGET_GNU_TLS || TARGET_GNU2_TLS)
 #define TARGET_SUN_TLS 0
+#define TARGET_WIN32_TLS   0

 #ifndef TARGET_64BIT_DEFAULT
 #define TARGET_64BIT_DEFAULT 0
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 0a9986c44d4..47c76eb85a2 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -135,3 +135,9 @@ along with GCC; see the file COPYING3.  If not see
original mingw32.  */
 #undef TARGET_LIBC_HAS_FUNCTION
 #define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
+
+#undef TARGET_ASM_SELECT_SECTION
+#define TARGET_ASM_SELECT_SECTION mingw_w64_pe_select_section
+
+#undef TARGET_WIN32_TLS
+#define TARGET_WIN32_TLS 1
diff --git a/gcc/config/mingw/winnt.cc b/gcc/config/mingw/winnt.cc
index 803e5f5ec85..5721298b224 100644
--- a/gcc/config/mingw/winnt.cc
+++ b/gcc/config/mingw/winnt.cc
@@ -415,6 +415,8 @@ mingw_pe_unique_section (tree decl, int reloc)
 prefix = ".text$";
   else if (decl_readonly_section (decl, reloc))
 prefix = ".rdata$";
+  else if (DECL_THREAD_LOCAL_P (decl))
+prefix = ".tls$";
   else
 prefix = ".data$";
   len = strlen (name) + strlen (prefix);

This obviously does not work, and when compiling the simple program on
Windows below:

_Thread_local int local = 2;

int get(void) {
return local;
}

Results in the following error during one of the many RTL passes

# gcc -S -std=c11 -pedantic -Wpedantic tls.c
tls.c: In function 'get':
tls.c:5:1: error: unrecognizable insn:
5 | }
  | ^
(insn 5 2 6 2 (parallel [
(set (reg:DI 100)
(unspec:DI [
(const_int 0 [0])
] UNSPEC_TP))
(clobber (scratch:DI))
]) "tls.c":4:12 -1
 (nil))
during RTL pass: vregs
tls.c:5:1: internal compiler error: in extract_insn, at recog.cc:2812
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

I can vaguely see how the RTL resembles the code I wrote in
legitimize_tls_address, but I can't quite tell what is actually wrong with
the erroneous RTL, and probably need help in deciphering this mess, as well
as how to actually emit RTL that properly lowers into the required assembly

best regards,
Julian

On Thu, Aug 8, 2024 at 8:58 PM Julian Waters 
wrote:

> Hi Claudiu,
>
> Thanks a lot for the clarifications! Unfortunately, though I have looked
> at what you suggested, I still can't quite understand how to emit and work
> with RTL that will ultimately lower into the assembly required for TLS on
> Windows in legitimize_tls_address :( I shall not test your patience and
> bother you any more by bombarding you with repeated questions over and
> over, but once again, 

Re: Spurious -Wsequence-point with auto

[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;
>   int  a[2 * i];
>   int  (*p)[2 * i];
> 
>   i = 1;
>   p = &a;
>   auto q = p + i++; 
> }
> $ gcc -Wsequence-point -std=c23 auto.c 
> auto.c: In function ‘main’:
> auto.c:12:23: warning: operation on ‘i’ may be undefined [-Wsequence-point]
>12 | auto q = p + i++;
>   |  ~^~
> 
> 
> I originally found this problem here:
> 
> 
> And I suspect the warning is confusing auto with typeof().  If typeof()
> was used, this would indeed cause double evaluation, once before the =
> and once after the =, causing UB.
> 
> Maybe it's due to how auto is implemented?  I suspect it's doing
> internally:
> 
>   typeof(p + i++) q = p + i++;
> 
> and that would be problematic.  I can reproduce it with both gcc-13 and
> gcc-14.
> 

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. the 45 MB macro expansion example
in Linux...

Martin

Re: Spurious -Wsequence-point with auto

[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. the 45 MB macro expansion example
> in Linux...

Huh, what's that one?  I didn't know it.  :)

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

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

[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 parameter.
> 
> I am a bit worried that it might prevent people from adding size information
> to arguments, by transforming later use of sizeof on such a pointer argument
> into a hard error.

I've been thinking about it, and I'm not convinced.


If we don't have an error, at some point, sizeof(array_param) would
change meaning without prior notice.  If a program uses that new
feature, it will silently compile in older compiler versions, producing
bogus results.  To prevent that, the configure scripts would need to
test the compiler and reject compilers that have the old behavior.

However, if we introduce a mandatory compiler error, programs won't need
to be careful about the feature.  If the compiler supports it, it will
compile, and if it doesn't, it will fail.


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.)


What do you think?

> 
> So I would not do this at this time, until we have fully evolved the
> size checking and the benefits are clear.
> 
> > 
> > It would be an incompatible extension to ISO C, which would make sure
> > that there are no remaining uses of sizeof(array_param), which would
> > itself allow in the future --if n2906 or something similar is accepted--
> > repurposing sizeof() to return the size in bytes of the array (instead
> > of the size of a pointer) without worrying about breaking existing code.
> 
> I agree with this goal, but this is a long term goal.  
> 
> 
> Martin

Cheers,
Alex

-- 



signature.asc
Description: PGP signature

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

[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 error?  I don't
> > > think there's any legitimate use sizeof() on such a parameter.
> > 
> > I am a bit worried that it might prevent people from adding size information
> > to arguments, by transforming later use of sizeof on such a pointer argument
> > into a hard error.
> 
> I've been thinking about it, and I'm not convinced.
> 
> 
> If we don't have an error, at some point, sizeof(array_param) would
> change meaning without prior notice.  If a program uses that new
> feature, it will silently compile in older compiler versions, producing
> bogus results.  To prevent that, the configure scripts would need to
> test the compiler and reject compilers that have the old behavior.
> 
> However, if we introduce a mandatory compiler error, programs won't need
> to be careful about the feature.  If the compiler supports it, it will
> compile, and if it doesn't, it will fail.
> 
> 
> 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.)
> 
> 
> What do you think?

You can compile your sources with -Werror=sizeof-array-argument if you want
it to be an error, but there is nothing wrong about using sizeof on function
argument with array type if you know what you're doing, and sizeof should be
usable on anything that has a size, not on everything except this special
case, so please don't enforce it on others.

Jakub

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

[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).

Admittedly, I could write configure checks to determine if I have a
version of GCC where sizeof(aparam) is bad and only enable the error
there.

> but there is nothing wrong about using sizeof on function
> argument with array type if you know what you're doing,

I have doubts here.  Does anyone have an idea of what kind of program
would be interested in that value?

> and sizeof should be
> usable on anything that has a size, not on everything except this special
> case, so please don't enforce it on others.

I don't want to enforce it if there's a single line of code that's using
sizeof(aparam) for a legitimate purpose.  But is there?  Or can it be?


Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

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

[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 determine if I have a
> version of GCC where sizeof(aparam) is bad and only enable the error
> there.
> 
> > but there is nothing wrong about using sizeof on function
> > argument with array type if you know what you're doing,
> 
> I have doubts here.  Does anyone have an idea of what kind of program
> would be interested in that value?

Any time you use some macro on such parameters where the macro internals use
sizeof for whatever reason.
E.g. if it wants to cast the pointer to some integer type and decides based
on sizeof what integer type that would be, ...
I mean, what you are suggesting is similar to making an error from
sizeof (char), that is by definition 1, so there is no point for users to
use it.  It makes sense in macros...

Jakub

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

[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 knows what they are doing - i.e., 
when they know the argument is a pointer and write a sizeof call with that 
in mind (rather than under the misapprehension that they would get the 
size of an array) but have written it as an array because that is also 
useful for some reason (e.g. writing as an array to use [static]).

I repeat what I said yesterday: GCC should not be opinionated about 
promoting personal ideas of what is or is not good style or what might or 
might not be a future language feature.

(Yes, I disagree with various choices made in man-pages to promote 
particular ideas about possible future language features.  I don't want 
GCC to go in such an opinionated direction.)

-- 
Joseph S. Myers
josmy...@redhat.com

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

[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 unless C2Y requires that.
> 
> > Admittedly, I could write configure checks to determine if I have a
> > version of GCC where sizeof(aparam) is bad and only enable the error
> > there.
> > 
> > > but there is nothing wrong about using sizeof on function
> > > argument with array type if you know what you're doing,
> > 
> > I have doubts here.  Does anyone have an idea of what kind of program
> > would be interested in that value?
> 
> Any time you use some macro on such parameters where the macro internals use
> sizeof for whatever reason.
> E.g. if it wants to cast the pointer to some integer type and decides based
> on sizeof what integer type that would be, ...
> I mean, what you are suggesting is similar to making an error from
> sizeof (char), that is by definition 1, so there is no point for users to
> use it.  It makes sense in macros...

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 not.
If using sizeof in that case is an error, you'd need to know, I can use this
macro on everything except this special case.

Jakub

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

[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 not.
> If using sizeof in that case is an error, you'd need to know, I can use this
> macro on everything except this special case.

Hmmm, I guess the array updates of
 and
__lengthof__ supporting array parameters don't need to come with a
change to sizeof.  If one wants to learn the size of an array parameter,
it's easy to define

#define sizeof_array(a)  (__lengthof__(a) * sizeof(*(a)))

So, please ignore my proposal.

Cheers,
Alex

-- 



signature.asc
Description: PGP signature

git help: fortran_unsigned branch

[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 "git config advice.skippedCherryPicks false"
Successfully rebased and updated refs/heads/fortran_unsigned.

and

$ git status
On branch fortran_unsigned
Your branch and 'origin/devel/fortran_unsigned' have diverged,
and have 688 and 198 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

and when I do "git pull" I get a lot of conflicts, basically having
to redo each commit by hand, as a conflict.

I have no idea what happened, or why, and despite the help of some
nice people on #gcc I have not made any progress on how to resolve it.

Does anybody have any idea how to fix this?

If not, I will just have to abandon the devel branch and work locally.
Not that I want to, but I guess it's better than not doing anything...

Best regards

Thomas

Re: git help: fortran_unsigned branch

[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 to rebase against master branch on the server:

 $ git fetch origin
 $ git rebase origin/master

With the above I get the following result, which looks reasonably ok to
me:

 $ git log --oneline --decorate
 7bc60bc184f (HEAD) Add merge_bits.
 ae4b29f34c9 Min, MAX and ishft(c).
 e7a3c1f7841 Add test case for B, Z and O descriptors.
 61b3f21a44b Add some rudimentary documentation.
 4589ae45088 Implement dshift[lr], ibclr, ibset and ibits.
 d1cf578cb2a Add bit_size, btest and bgt plus friends.
 b285c13323b Bit functions, HUGE and DIGITS.
 c39c316ae8b Added BOZ support to UINT.
 95927079ebc Added UINT intrinsic.
 70a309048fe Iplement conversions from unsigned to different data types.
 c1e596f32f8 Add decimal formatted I/O for unsigneds.
 65c571ffe65 A few fixes, add unsigned truncation warning.
 b84ec7f0242 Implement decimal list-directed I/O.
 f63906c5ff0 Add compile-time version of selected_unsigned_kind.
 c8e2ea0c39d Got some basic arithmetic working, test case now run-time.
 dd626ce9863 Very first program compiles.
 1f93f691ff2 Initial version - add do-nothing -funsigned option and BT_UNSIGNED.
 d0bc1cbf6a8 (origin/trunk, origin/master, origin/HEAD) btf: Protect 
BTF_KIND_INFO against invalid kind


> 
> I get
> ...
> 
> warning: skipped previously applied commit a6399bb27b3
> hint: use --reapply-cherry-picks to include skipped commits
> hint: Disable this message with "git config advice.skippedCherryPicks false"

Your origin/devel/fortran_unsigned has manually cherry-picked patches,
which meanwhile got merged in "origin/master".  I suspect those
cherry-picked patches got sneaked in when a stale base was used for a
git rebase (i.e. your local master branch).

Warnings seem benign to me, but I would use the "gitk" tool to check the
rebased branch.  Just in case.

> Successfully rebased and updated refs/heads/fortran_unsigned.
> 
> and
> 
> $ git status
> On branch fortran_unsigned
> Your branch and 'origin/devel/fortran_unsigned' have diverged,
> and have 688 and 198 different commits each, respectively.
>   (use "git pull" to merge the remote branch into yours)
> 
> nothing to commit, working tree clean
> 
> and when I do "git pull" I get a lot of conflicts, basically having
> to redo each commit by hand, as a conflict.

If your local branch is tracking origin/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.

To visualise the histories of your local and the remote branch:
  $ gitk -n1 HEAD origin/devel/fortran_unsigned


Regards,
Dimitar
> 
> I have no idea what happened, or why, and despite the help of some
> nice people on #gcc I have not made any progress on how to resolve it.
> 
> Does anybody have any idea how to fix this?
> 
> If not, I will just have to abandon the devel branch and work locally.
> Not that I want to, but I guess it's better than not doing anything...
> 
> Best regards
> 
>   Thomas

Re: git help: fortran_unsigned branch

[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
advise to rebase against master branch on the server:

  $ git fetch origin
  $ git rebase origin/master


OK, I did that.


With the above I get the following result, which looks reasonably ok to
me:

  $ git log --oneline --decorate
  7bc60bc184f (HEAD) Add merge_bits.
  ae4b29f34c9 Min, MAX and ishft(c).
  e7a3c1f7841 Add test case for B, Z and O descriptors.
  61b3f21a44b Add some rudimentary documentation.
  4589ae45088 Implement dshift[lr], ibclr, ibset and ibits.
  d1cf578cb2a Add bit_size, btest and bgt plus friends.
  b285c13323b Bit functions, HUGE and DIGITS.
  c39c316ae8b Added BOZ support to UINT.
  95927079ebc Added UINT intrinsic.
  70a309048fe Iplement conversions from unsigned to different data types.
  c1e596f32f8 Add decimal formatted I/O for unsigneds.
  65c571ffe65 A few fixes, add unsigned truncation warning.
  b84ec7f0242 Implement decimal list-directed I/O.
  f63906c5ff0 Add compile-time version of selected_unsigned_kind.
  c8e2ea0c39d Got some basic arithmetic working, test case now run-time.
  dd626ce9863 Very first program compiles.
  1f93f691ff2 Initial version - add do-nothing -funsigned option and 
BT_UNSIGNED.
  d0bc1cbf6a8 (origin/trunk, origin/master, origin/HEAD) btf: Protect 
BTF_KIND_INFO against invalid kind


I get the same.





I get
...

warning: skipped previously applied commit a6399bb27b3
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config advice.skippedCherryPicks false"


Your origin/devel/fortran_unsigned has manually cherry-picked patches,
which meanwhile got merged in "origin/master".  I suspect those
cherry-picked patches got sneaked in when a stale base was used for a
git rebase (i.e. your local master branch).


That actually sounds like a reasonable explanation of what could have
happened.  Of course, it would have been nice to have known that
beforehand, or maybe even a warning from git...


Warnings seem benign to me, but I would use the "gitk" tool to check the
rebased branch.  Just in case.


I've looked at it a bit and seen nothing untoward.




Successfully rebased and updated refs/heads/fortran_unsigned.

and

$ git status
On branch fortran_unsigned
Your branch and 'origin/devel/fortran_unsigned' have diverged,
and have 688 and 198 different commits each, respectively.
   (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

and when I do "git pull" I get a lot of conflicts, basically having
to redo each commit by hand, as a conflict.


If your local branch is tracking origin/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,
have reset the branch to upstream already (which may have been
another mistake).

So, anything I can do about this, or have I messed up the
branch beyond repair?



To visualise the histories of your local and the remote branch:
   $ gitk -n1 HEAD origin/devel/fortran_unsigned


Looks like a nice tool.

Best regards

Thomas

Re: git help: fortran_unsigned branch

[Dimitar Dimitrov]

On Fri, Aug 09, 2024 at 08:43:38PM +0200, Thomas Koenig wrote:
> 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
> > advise to rebase against master branch on the server:
> > 
> >   $ git fetch origin
> >   $ git rebase origin/master
> 
> OK, I did that.
> 
> > With the above I get the following result, which looks reasonably ok to
> > me:
> > 
> >   $ git log --oneline --decorate
> >   7bc60bc184f (HEAD) Add merge_bits.
> >   ae4b29f34c9 Min, MAX and ishft(c).
> >   e7a3c1f7841 Add test case for B, Z and O descriptors.
> >   61b3f21a44b Add some rudimentary documentation.
> >   4589ae45088 Implement dshift[lr], ibclr, ibset and ibits.
> >   d1cf578cb2a Add bit_size, btest and bgt plus friends.
> >   b285c13323b Bit functions, HUGE and DIGITS.
> >   c39c316ae8b Added BOZ support to UINT.
> >   95927079ebc Added UINT intrinsic.
> >   70a309048fe Iplement conversions from unsigned to different data types.
> >   c1e596f32f8 Add decimal formatted I/O for unsigneds.
> >   65c571ffe65 A few fixes, add unsigned truncation warning.
> >   b84ec7f0242 Implement decimal list-directed I/O.
> >   f63906c5ff0 Add compile-time version of selected_unsigned_kind.
> >   c8e2ea0c39d Got some basic arithmetic working, test case now run-time.
> >   dd626ce9863 Very first program compiles.
> >   1f93f691ff2 Initial version - add do-nothing -funsigned option and 
> > BT_UNSIGNED.
> >   d0bc1cbf6a8 (origin/trunk, origin/master, origin/HEAD) btf: Protect 
> > BTF_KIND_INFO against invalid kind
> 
> I get the same.
> 
> > 
> > > 
> > > I get
> > > ...
> > > 
> > > warning: skipped previously applied commit a6399bb27b3
> > > hint: use --reapply-cherry-picks to include skipped commits
> > > hint: Disable this message with "git config advice.skippedCherryPicks 
> > > false"
> > 
> > Your origin/devel/fortran_unsigned has manually cherry-picked patches,
> > which meanwhile got merged in "origin/master".  I suspect those
> > cherry-picked patches got sneaked in when a stale base was used for a
> > git rebase (i.e. your local master branch).
> 
> That actually sounds like a reasonable explanation of what could have
> happened.  Of course, it would have been nice to have known that
> beforehand, or maybe even a warning from git...
> 
> > Warnings seem benign to me, but I would use the "gitk" tool to check the
> > rebased branch.  Just in case.
> 
> I've looked at it a bit and seen nothing untoward.
> 
> > 
> > > Successfully rebased and updated refs/heads/fortran_unsigned.
> > > 
> > > and
> > > 
> > > $ git status
> > > On branch fortran_unsigned
> > > Your branch and 'origin/devel/fortran_unsigned' have diverged,
> > > and have 688 and 198 different commits each, respectively.
> > >(use "git pull" to merge the remote branch into yours)
> > > 
> > > nothing to commit, working tree clean
> > > 
> > > and when I do "git pull" I get a lot of conflicts, basically having
> > > to redo each commit by hand, as a conflict.
> > 
> > If your local branch is tracking origin/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,
> have reset the branch to upstream already (which may have been
> another mistake).
> 
> So, anything I can do about this, or have I messed up the
> branch beyond repair?

I assume you reset your local branch?  The branch on the server does not
seem to be affected.  I suggest to rebase the remote branch using
another 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 origin/master
  $ gitk -n1000

Once you have verified that local history looks good, you can upload it
to the server.  Notice that you override the history, which is a natural
consequence of the rebase.
  $ git push --force origin HEAD:refs/heads/devel/fortran_unsigned

Regards,
Dimitar
> 
> 
> > To visualise the histories of your local and the remote branch:
> >$ gitk -n1 HEAD origin/devel/fortran_unsigned
> 
> Looks like a nice tool.
> 
> Best regards
> 
>   Thomas

Re: git help: fortran_unsigned branch

[Thomas Koenig via Gcc]

Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:


I assume you reset your local branch?  The branch on the server does not
seem to be affected.  I suggest to rebase the remote branch using
another 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 origin/master
   $ gitk -n1000



I tried that, with te same result:

warning: skipped previously applied commit a6399bb27b3
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config advice.skippedCherryPicks false"
Successfully rebased and updated refs/heads/fortran_unsigned-20240809.

$ git status
On branch fortran_unsigned-20240809
Your branch and 'origin/devel/fortran_unsigned' have diverged,
and have 690 and 198 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

So, it seems I already pushed something dubious previously.

Any other ideas?



Once you have verified that local history looks good, you can upload it
to the server.  Notice that you override the history, which is a natural
consequence of the rebase.
   $ git push --force origin HEAD:refs/heads/devel/fortran_unsigned


Not so long ago, I pushed to that branch, which led to a looong time
for checking. It got there eventually, but I do not want to repeat
that (and with more than ~40 times the number of commits, too).

Best regards

Thomas

Re: git help: fortran_unsigned branch

[Dimitar Dimitrov]

On Fri, Aug 09, 2024 at 09:40:08PM +0200, Thomas Koenig wrote:
> Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:
> 
> > I assume you reset your local branch?  The branch on the server does not
> > seem to be affected.  I suggest to rebase the remote branch using
> > another 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 origin/master
> >$ gitk -n1000
> > 
> 
> I tried that, with te same result:
> 
> warning: skipped previously applied commit a6399bb27b3
> hint: use --reapply-cherry-picks to include skipped commits
> hint: Disable this message with "git config advice.skippedCherryPicks false"
> Successfully rebased and updated refs/heads/fortran_unsigned-20240809.
> 
> $ git status
> On branch fortran_unsigned-20240809
> Your branch and 'origin/devel/fortran_unsigned' have diverged,
> and have 690 and 198 different commits each, respectively.
>   (use "git pull" to merge the remote branch into yours)

You are redoing the rebase again.  So it is expected to get the same
warnings.

> 
> So, it seems I already pushed something dubious previously.
Yes, that seems to be the case.

> 
> Any other ideas?
No, sorry.  I thought that getting to a cleanly rebased tree would be
sufficient.

> 
> 
> > Once you have verified that local history looks good, you can upload it
> > to the server.  Notice that you override the history, which is a natural
> > consequence of the rebase.
> >$ git push --force origin HEAD:refs/heads/devel/fortran_unsigned
> 
> Not so long ago, I pushed to that branch, which led to a looong time
> for checking. It got there eventually, but I do not want to repeat
> that (and with more than ~40 times the number of commits, too).
Is "checking" referring to regression testing of the development branch?

Regards,
Dimitar

> 
> Best regards
> 
>   Thomas
> 

Re: git help: fortran_unsigned branch

[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 git.


So, it seems I already pushed something dubious previously.

Yes, that seems to be the case.


Oh well... seems like it is possible, with something quite reasonable,
to hose up a branch. I thought that wasn't supposed to be possible in
git, and that ease of development with branches was the reason for
the git switchover.  Oh well... is there a version control system
around which does not have as many traps for the casual user?


Any other ideas?

No, sorry.  I thought that getting to a cleanly rebased tree would be
sufficient.


Unfortunately it's not.


Not so long ago, I pushed to that branch, which led to a looong time
for checking. It got there eventually, but I do not want to repeat
that (and with more than ~40 times the number of commits, too).

Is "checking" referring to regression testing of the development branch?


No, the checks that are run for a commit.  That checking took quite a
few minutes.  I think that, should I actually try to push my branch,
I might end up blocking other people's access to git for a considerably
longer time, so that is definitely out.

Unless somebody has any better ideas, I'll switch to a local branch.
This is not an experience I want to repeat.

Best regards (and thanks!)

Thomas

gcc-13-20240809 is now available

[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 
releases/gcc-13 revision 12ba140ee93adc56a3426f0c6c05f4d6c6a3d08e

You'll find:

 gcc-13-20240809.tar.xz   Complete GCC

  SHA256=e27f3f7f496fe7a11e5e513e7d26f8aab696c2e77c3cedbd55dda2c3fb67319f
  SHA1=547e126edd996368e5bed76386bf32695cd2d400

Diffs from 13-20240802 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
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.