[PATCH] doc: Fix typos for --enable-host-pie docs in install.texi

[Jonathan Wakely]

From: Heiko Eißfeldt 

gcc/ChangeLog:

* doc/install.texi (Configuration): Fix typos in documentation
for --enable-host-pie.
---

This was reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118041
with a patch attached, but I forgot to put the bug number in the commit.

Pushed to trunk. I might as well backport it too.

 gcc/doc/install.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index feabf4cbe20..9109c172039 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1119,7 +1119,7 @@ yielding a slightly slower compiler (but faster than
 at random addresses each time they are executed, therefore provide additional
 protection against Return Oriented Programming (ROP) attacks.
 
-@option{--enable-host-pie}) may be used with @option{--enable-host-shared}),
+@option{--enable-host-pie} may be used with @option{--enable-host-shared},
 in which case @option{-fPIC} is used when compiling, and @option{-pie} when
 linking.
 
-- 
2.47.1

Re: The COBOL front end, in 8 notes

[Iain Sandoe]

> On 14 Dec 2024, at 11:56, Iain Sandoe  wrote:
> 
> 
> 
>> On 14 Dec 2024, at 10:11, Sam James  wrote:
>> 
>> David Malcolm  writes:
>> 
>>> On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:
 The following 8 patches constitute the 80 files needed to build and
 document the COBOL front end.  They assume that following exist:
 
gcc/cobol/ChangeLog
libgcobol/ChangeLog
 
 The messages are grouped by files in a more or less logical order,
 but groups are somewhat arbitrary.  The primary constraint afaik is
 to
 keep them from getting too big, fsvo $too.  We have:
 
460K hdr  header files
484K par  the parser
760K gen  GENERIC interface
556K cbl  other supporting C++ files
432K cfg  libgcobol/configure
788K lib  libgcobol, all of it
 72K doc  man pages, for now
 24K bld  "meta" files, such a gcc/cobol/Make-lang.in
 
 Except for "bld", these all contain new files, can be applied in any
 order.  
 
 If you would like the patches smaller or larger, I'm happy to
 rearrange
 them.  Some of exceed the 400 KB mail limit, but I'm assured they'll
 be
 moderated through.  
 
 This patchset excludes tests.  While we do have tests, it's not clear
 how or if to add them to gcc.  They use a combination of (largely)
 3rd
 party sources and GNU Autotest.
 
 A word about C style, always a lively topic.  For any files already
 present in gcc, the existing style was followed, and any variation
 from
 it is unintentional.  Files related to the parser use K&R style.  The
 GENERIC interface and runtime library use Whitesmiths style.  All C++
 code uses spaces for indentation.  
 
 The COBOL front end has been and is being written by two guys with
 decades of experience.  We hope the code is a testament to that
 experience.  Our relatively recent experience, these last four years,
 is that it has been more productive to keep using the styles to which
 we've long become accustomed.  The position of curly braces is hardly
 any hindrance to read another's code, but it's a burden to write that
 way. We think, 83,068 lines later, the proof of the pudding is in the
 eating.  
 
 Thank you for your kind consideration of our work.
>>> 
>>> Please forgive me if you've already said this elsewhere, but is this
>>> work available in a public git repo somewhere?
>>> 
>> 
>> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
> 
> But (IIUC) this is the development branch; what would be ideal would be
> a branch with just the 8 patches.
> 
> 
> 
> NOTE0 : the decision to use different whitespace rules from the rest of GCC
> means the that patches apply only with a very large number of whitespace
> errors .. which might be fine - but, of course, you cannot now tell 
> intentional
> whitespace errors from actual mistakes ….
> 
> NOTE1 : patch 8 did not apply for me without editing - there seems to be a
> duplicate of gcc/cobol/config-lang.in in patches 4 and 8.
> 
> NOTE2 :  the top level Makefile.in needs to be regenerated.
> 
> Will try this on  Darwin - (I removed the config-lang.in from patch 8 and
> regenerated the top level Makefile.in) - hopefully the patch 4 config-lang.in
> is OK to use.
> 
> Is it intentional that this requires bison at build-time or is there a missing
> “touch” for some generated file?

OK so, unfortunately, this does not build on Darwin/macOS.

It seems 
1) to introduce new build dependencies on:
  - bison (we normally commit generated files to the repo not expect the 
end-user
   to need bison installed).
  - a version of gm4 that recognises —gnu

 perhaps this is an oversight and the generated files can be committed ?

 if not ... neither of these tools exist in the Xcode installs that most macOS 
users have,
 so that they will need to build them before they can configure GCC 
—enable-languages=all

2) the build then failed for me with … 

/src-local/gcc-master/gcc/cobol/symbols.h:66:39: error: missing binary operator 
before token ‘(’
   66 | #if ! (__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT))

** You cannot assume that all targets have glibc - e.g. Darwin has it’s own 
libc, others might
use muscl etc.

I can hack around this .. but then I get lots more errors .. 

/src-local/gcc-master/gcc/cobol/copybook.h:50:40: error: ‘ino_t’ has not been 
declared; did you mean ‘wint_t’?
   50 | bool cobol_filename( const char *name, ino_t inode );

 from /src-local/gcc-master/gcc/cobol/cdf.y:32:
/src-local/gcc-master/gcc/cobol/symbols.h:71:23: error: ‘output’ was not 
declared in this scope
   71 | static_assert( sizeof(output) == sizeof(long double), "long doubles?" );
  |   ^~
/src-local/gcc-master/gcc/cobol/symbols.h: In function ‘_Float128 
strtof128(const char*, char**)’:
/src-local/gcc-master/gcc/cobol/symbols.h:75:18:

[PATCH] install.texi --enable-languages: add rust to the list of languages

[Heiko Eißfeldt]

While comparing

```grep ^language= */config-lang.in```

with the list from the doc

I noticed that the last addition rust was missing.


diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9109c172039..1904a0e3c12 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2051,7 +2051,7 @@ grep ^language= */config-lang.in
 Currently, you can use any of the following:
 @code{all}, @code{default}, @code{ada}, @code{c}, @code{c++}, @code{d},
 @code{fortran}, @code{go}, @code{jit}, @code{lto}, @code{m2},
-@code{objc}, @code{obj-c++}.
+@code{objc}, @code{obj-c++}, @code{rust}.
 Building the Ada compiler has special requirements, see below.
 If you do not pass this flag, or specify the option @code{default}, then the
 default languages available in the @file{gcc} sub-tree will be configured.


OpenPGP_0x6C5B5E2DE9D181E2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: The COBOL front end, in 8 notes

[Richard Biener]

> Am 14.12.2024 um 14:09 schrieb Iain Sandoe :
> 
> 
> 
>>> On 14 Dec 2024, at 11:56, Iain Sandoe  wrote:
>>> 
>>> 
>>> 
 On 14 Dec 2024, at 10:11, Sam James  wrote:
>>> 
>>> David Malcolm  writes:
>>> 
 On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:
> The following 8 patches constitute the 80 files needed to build and
> document the COBOL front end.  They assume that following exist:
> 
>   gcc/cobol/ChangeLog
>   libgcobol/ChangeLog
> 
> The messages are grouped by files in a more or less logical order,
> but groups are somewhat arbitrary.  The primary constraint afaik is
> to
> keep them from getting too big, fsvo $too.  We have:
> 
>460K hdr  header files
>484K par  the parser
>760K gen  GENERIC interface
>556K cbl  other supporting C++ files
>432K cfg  libgcobol/configure
>788K lib  libgcobol, all of it
> 72K doc  man pages, for now
> 24K bld  "meta" files, such a gcc/cobol/Make-lang.in
> 
> Except for "bld", these all contain new files, can be applied in any
> order.  
> 
> If you would like the patches smaller or larger, I'm happy to
> rearrange
> them.  Some of exceed the 400 KB mail limit, but I'm assured they'll
> be
> moderated through.  
> 
> This patchset excludes tests.  While we do have tests, it's not clear
> how or if to add them to gcc.  They use a combination of (largely)
> 3rd
> party sources and GNU Autotest.
> 
> A word about C style, always a lively topic.  For any files already
> present in gcc, the existing style was followed, and any variation
> from
> it is unintentional.  Files related to the parser use K&R style.  The
> GENERIC interface and runtime library use Whitesmiths style.  All C++
> code uses spaces for indentation.  
> 
> The COBOL front end has been and is being written by two guys with
> decades of experience.  We hope the code is a testament to that
> experience.  Our relatively recent experience, these last four years,
> is that it has been more productive to keep using the styles to which
> we've long become accustomed.  The position of curly braces is hardly
> any hindrance to read another's code, but it's a burden to write that
> way. We think, 83,068 lines later, the proof of the pudding is in the
> eating.  
> 
> Thank you for your kind consideration of our work.
 
 Please forgive me if you've already said this elsewhere, but is this
 work available in a public git repo somewhere?
 
>>> 
>>> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
>> 
>> But (IIUC) this is the development branch; what would be ideal would be
>> a branch with just the 8 patches.
>> 
>> 
>> 
>> NOTE0 : the decision to use different whitespace rules from the rest of GCC
>> means the that patches apply only with a very large number of whitespace
>> errors .. which might be fine - but, of course, you cannot now tell 
>> intentional
>> whitespace errors from actual mistakes ….
>> 
>> NOTE1 : patch 8 did not apply for me without editing - there seems to be a
>> duplicate of gcc/cobol/config-lang.in in patches 4 and 8.
>> 
>> NOTE2 :  the top level Makefile.in needs to be regenerated.
>> 
>> Will try this on  Darwin - (I removed the config-lang.in from patch 8 and
>> regenerated the top level Makefile.in) - hopefully the patch 4 config-lang.in
>> is OK to use.
>> 
>> Is it intentional that this requires bison at build-time or is there a 
>> missing
>> “touch” for some generated file?
> 
> OK so, unfortunately, this does not build on Darwin/macOS.
> 
> It seems
> 1) to introduce new build dependencies on:
>  - bison (we normally commit generated files to the repo not expect the 
> end-user
>   to need bison installed).
>  - a version of gm4 that recognises —gnu
> 
> perhaps this is an oversight and the generated files can be committed ?
> 
> if not ... neither of these tools exist in the Xcode installs that most macOS 
> users have,
> so that they will need to build them before they can configure GCC 
> —enable-languages=all
> 
> 2) the build then failed for me with …
> 
> /src-local/gcc-master/gcc/cobol/symbols.h:66:39: error: missing binary 
> operator before token ‘(’
>   66 | #if ! (__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT))
> 
> ** You cannot assume that all targets have glibc - e.g. Darwin has it’s own 
> libc, others might
> use muscl etc.
> 
> I can hack around this .. but then I get lots more errors ..
> 
> /src-local/gcc-master/gcc/cobol/copybook.h:50:40: error: ‘ino_t’ has not been 
> declared; did you mean ‘wint_t’?
>   50 | bool cobol_filename( const char *name, ino_t inode );
> 
> from /src-local/gcc-master/gcc/cobol/cdf.y:32:
> /src-local/gcc-master/gcc/cobol/symbols.h:71:23: error: ‘output’ was not 
> declared in this scope
>   71 | static_assert( sizeof(output) == sizeof(long

Re: [PATCH] install.texi --enable-languages: add rust to the list of languages

[Xi Ruoyao]

On Sat, 2024-12-14 at 15:11 +0100, Heiko Eißfeldt wrote:
>  
> ```grep ^language= */config-lang.in```
> 
> with the list from the doc
> 
> I noticed that the last addition rust was missing.

I'm not sure if we want to expose it to all the users.  As at now the
rust FE is still in early development and it's not useful for compiling
any real rust programs.


-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: The COBOL front end, in 8 notes

[Matthias Klose]

I tried to use the patches to build binary packages for Debian. Found 
some issues:


gcc/cobol:

- the config-lang.in is provided in both patch 04 and patch 08.

- the installation path for the gcobc script is missing the gcc/
  subdir. Does it make sense to ship the script without the udf
  files?

- same for cobol/udf/*, also the udfdir macro is undefined, and
  the files are missing.

- the installation of the gcobol.1 man page doesn't honor the
  prefix and the suffix form the configury.

- gcobol.3 is installed in the root dir, the man3dir macro is
  undefined.

- The header files mentioned in gcobol.3 are not installed.


libgcobol:

- the patches are missing the regenerated toplevel Makefile.in

- the shared library is underlinked. There are unresolved
  symbols against libm and libstdc++.

- The build uses plain CC for the build, not the _FOR_HOST
  and _FOR_TARGET macros passed from the toplevel make.

- the library build is not ready for multilibs.

- configure.ac has reference to a GC enabled variant, however
  there's nothing in the Makefile supporting that build.


A simple hello.cob builds, is correctly linked against the shared 
library and executes fine.


Is there some cobol based open source project, which could be used for 
further testing?



Matthias

Re: The COBOL front end, in 8 notes

[Iain Sandoe]

> On 14 Dec 2024, at 10:11, Sam James  wrote:
> 
> David Malcolm  writes:
> 
>> On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:
>>> The following 8 patches constitute the 80 files needed to build and
>>> document the COBOL front end.  They assume that following exist:
>>> 
>>> gcc/cobol/ChangeLog
>>> libgcobol/ChangeLog
>>> 
>>> The messages are grouped by files in a more or less logical order,
>>> but groups are somewhat arbitrary.  The primary constraint afaik is
>>> to
>>> keep them from getting too big, fsvo $too.  We have:
>>> 
>>> 460K hdr  header files
>>> 484K par  the parser
>>> 760K gen  GENERIC interface
>>> 556K cbl  other supporting C++ files
>>> 432K cfg  libgcobol/configure
>>> 788K lib  libgcobol, all of it
>>>  72K doc  man pages, for now
>>>  24K bld  "meta" files, such a gcc/cobol/Make-lang.in
>>> 
>>> Except for "bld", these all contain new files, can be applied in any
>>> order.  
>>> 
>>> If you would like the patches smaller or larger, I'm happy to
>>> rearrange
>>> them.  Some of exceed the 400 KB mail limit, but I'm assured they'll
>>> be
>>> moderated through.  
>>> 
>>> This patchset excludes tests.  While we do have tests, it's not clear
>>> how or if to add them to gcc.  They use a combination of (largely)
>>> 3rd
>>> party sources and GNU Autotest.
>>> 
>>> A word about C style, always a lively topic.  For any files already
>>> present in gcc, the existing style was followed, and any variation
>>> from
>>> it is unintentional.  Files related to the parser use K&R style.  The
>>> GENERIC interface and runtime library use Whitesmiths style.  All C++
>>> code uses spaces for indentation.  
>>> 
>>> The COBOL front end has been and is being written by two guys with
>>> decades of experience.  We hope the code is a testament to that
>>> experience.  Our relatively recent experience, these last four years,
>>> is that it has been more productive to keep using the styles to which
>>> we've long become accustomed.  The position of curly braces is hardly
>>> any hindrance to read another's code, but it's a burden to write that
>>> way. We think, 83,068 lines later, the proof of the pudding is in the
>>> eating.  
>>> 
>>> Thank you for your kind consideration of our work.
>> 
>> Please forgive me if you've already said this elsewhere, but is this
>> work available in a public git repo somewhere?
>> 
> 
> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/

But (IIUC) this is the development branch; what would be ideal would be
a branch with just the 8 patches.



NOTE0 : the decision to use different whitespace rules from the rest of GCC
means the that patches apply only with a very large number of whitespace
errors .. which might be fine - but, of course, you cannot now tell intentional
whitespace errors from actual mistakes ….

NOTE1 : patch 8 did not apply for me without editing - there seems to be a
duplicate of gcc/cobol/config-lang.in in patches 4 and 8.

NOTE2 :  the top level Makefile.in needs to be regenerated.

Will try this on  Darwin - (I removed the config-lang.in from patch 8 and
regenerated the top level Makefile.in) - hopefully the patch 4 config-lang.in
is OK to use.

Is it intentional that this requires bison at build-time or is there a missing
“touch” for some generated file?

thanks
Iain

> 
>> Thanks
>> Dave

Re: [PATCH] Add fancy pointer support in std::map/set

[François Dumont]

Hi

Here is an update with the alloc ptr specific tests and so fixes.

PR updated:

https://forge.sourceware.org/gcc/gcc-TEST/pulls/27

François


On 09/12/2024 07:05, François Dumont wrote:


On 04/12/2024 22:48, Jonathan Wakely wrote:

On 04/12/24 19:27 +0100, François Dumont wrote:

Hi

I've completed the synchronization with your equivalent PR for 
std::list so here is the updated patch.


PR updated a couple of days ago.

Note that I've started to rework the patch for the same in _Hashtable.


Great, thanks.



#if __cplusplus < 201103L
  void
-  _M_construct_node(_Link_type __node, const value_type& __x)
+  _M_construct_node(_Base_ptr __p, const value_type& __x)


And can this be left as _Node_ptr instead of changed to _Base_ptr?
Then it wouldn't need the static_cast, and the callers wouldn't need
to use _M_base_ptr().

Logically, it has to be a _Node_ptr or the cast isn't valid anyway.

There seem to be several places like this where we're giving up
valuable type information by using _base_ptr instead of _Node_ptr.

Is that really necessary? If we have a _Node_ptr we can always get a
_Base_ptr easily by calling _M_base_ptr().

Is it a constness thing, because _M_begin() const was changed to
return _Base_ptr instead of _Const_link_ptr?

No, just me being lazy and considering that as we store _Base_ptr we 
can also use it everywhere.


In this new version I've preserved _Node_ptr almost everywhere.

But _M_begin() is still returning a _Base_ptr and I've introduced 
_M_begin_node() for rare occasions when a _Node_ptr is needed.


Note that I've hesitated to add a _S_nullptr() to get a _Base_ptr null 
pointer. Is default constructor on fancy pointer type mandatory ? I 
fear that only constructor from nullptr is mandatory.


I've forced push on:

https://forge.sourceware.org/gcc/gcc-TEST/pulls/27

François
diff --git a/libstdc++-v3/include/bits/stl_tree.h 
b/libstdc++-v3/include/bits/stl_tree.h
index bc27e191e8b..c87591757e8 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -66,6 +66,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #if __cplusplus >= 201103L
 # include 
@@ -74,6 +75,13 @@
 # include 
 #endif
 
+#if __cplusplus < 201103L
+# undef _GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE
+# define _GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE 0
+#elif ! defined _GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE
+# define _GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE 1
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -99,7 +107,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   struct _Rb_tree_node_base
   {
 typedef _Rb_tree_node_base* _Base_ptr;
-typedef const _Rb_tree_node_base* _Const_Base_ptr;
 
 _Rb_tree_color _M_color;
 _Base_ptr  _M_parent;
@@ -113,13 +120,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __x;
 }
 
-static _Const_Base_ptr
-_S_minimum(_Const_Base_ptr __x) _GLIBCXX_NOEXCEPT
-{
-  while (__x->_M_left != 0) __x = __x->_M_left;
-  return __x;
-}
-
 static _Base_ptr
 _S_maximum(_Base_ptr __x) _GLIBCXX_NOEXCEPT
 {
@@ -127,12 +127,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __x;
 }
 
-static _Const_Base_ptr
-_S_maximum(_Const_Base_ptr __x) _GLIBCXX_NOEXCEPT
-{
-  while (__x->_M_right != 0) __x = __x->_M_right;
-  return __x;
-}
+// This is not const-correct, but it's only used in a const access path
+// by std::_Rb_tree::_M_end() where the pointer is used to initialize a
+// const_iterator and so constness is restored.
+_Base_ptr
+_M_base_ptr() const _GLIBCXX_NOEXCEPT
+{ return const_cast<_Rb_tree_node_base*>(this); }
   };
 
   // Helper type offering value initialization guarantee on the compare 
functor.
@@ -213,8 +213,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct _Rb_tree_node : public _Rb_tree_node_base
 {
-  typedef _Rb_tree_node<_Val>* _Link_type;
-
 #if __cplusplus < 201103L
   _Val _M_value_field;
 
@@ -236,20 +234,140 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_valptr() const
   { return _M_storage._M_ptr(); }
 #endif
+
+  _Rb_tree_node*
+  _M_node_ptr() _GLIBCXX_NOEXCEPT
+  { return this; }
+};
+
+#if _GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE
+namespace __rb_tree
+{
+  template
+struct _Node_base
+{
+  using _Base_ptr = __ptr_rebind<_VoidPtr, _Node_base>;
+
+  _Rb_tree_color   _M_color;
+  _Base_ptr_M_parent;
+  _Base_ptr_M_left;
+  _Base_ptr_M_right;
+
+  static _Base_ptr
+  _S_minimum(_Base_ptr __x) _GLIBCXX_NOEXCEPT
+  {
+   while (__x->_M_left) __x = __x->_M_left;
+   return __x;
+  }
+
+  static _Base_ptr
+  _S_maximum(_Base_ptr __x) _GLIBCXX_NOEXCEPT
+  {
+   while (__x->_M_right) __x = __x->_M_right;
+   return __x;
+  }
+
+  // This is not const-correct, but it's only used in a const access path
+  // by std::_

Re: [PATCH] Add fancy pointer support in std::map/set

[Jonathan Wakely]

On Mon, 9 Dec 2024, 06:05 François Dumont,  wrote:

>
> On 04/12/2024 22:48, Jonathan Wakely wrote:
> > On 04/12/24 19:27 +0100, François Dumont wrote:
> >> Hi
> >>
> >> I've completed the synchronization with your equivalent PR for
> >> std::list so here is the updated patch.
> >>
> >> PR updated a couple of days ago.
> >>
> >> Note that I've started to rework the patch for the same in _Hashtable.
> >
> > Great, thanks.
> >
> >>
> >> #if __cplusplus < 201103L
> >>   void
> >> -  _M_construct_node(_Link_type __node, const value_type& __x)
> >> +  _M_construct_node(_Base_ptr __p, const value_type& __x)
> >
> > And can this be left as _Node_ptr instead of changed to _Base_ptr?
> > Then it wouldn't need the static_cast, and the callers wouldn't need
> > to use _M_base_ptr().
> >
> > Logically, it has to be a _Node_ptr or the cast isn't valid anyway.
> >
> > There seem to be several places like this where we're giving up
> > valuable type information by using _base_ptr instead of _Node_ptr.
> >
> > Is that really necessary? If we have a _Node_ptr we can always get a
> > _Base_ptr easily by calling _M_base_ptr().
> >
> > Is it a constness thing, because _M_begin() const was changed to
> > return _Base_ptr instead of _Const_link_ptr?
> >
> No, just me being lazy and considering that as we store _Base_ptr we can
> also use it everywhere.
>
> In this new version I've preserved _Node_ptr almost everywhere.
>
> But _M_begin() is still returning a _Base_ptr and I've introduced
> _M_begin_node() for rare occasions when a _Node_ptr is needed.
>
> Note that I've hesitated to add a _S_nullptr() to get a _Base_ptr null
> pointer. Is default constructor on fancy pointer type mandatory ?


Yes, but default construction can give a singular value (like an
uninitialized int*) so you want to use value initialization.

So:

pointer p = pointer();

Or in C++11:
pointer p{};

And not just:
pointer p;


I fear
> that only constructor from nullptr is mandatory.
>

Value init is required to work by the Cpp17NullablePointer requirements.



> I've forced push on:
>
> https://forge.sourceware.org/gcc/gcc-TEST/pulls/27


Thanks, I'll take another look.

Re: [PATCH] RISC-V: Add Tenstorrent Ascalon 8 wide architecture

[Jeff Law]

On 12/14/24 1:09 AM, Anton Blanchard wrote:

This adds the Tenstorrent Ascalon 8 wide architecture (tt-ascalon-d8)
to the list of known cores.

gcc/ChangeLog:

* config/riscv/riscv-cores.def: Add tt-ascalon-d8.
* config/riscv/riscv.cc (tt_ascalon_d8_tune_info): New.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/mcpu-tt-ascalon-d8.c: New test.
Generally looks pretty good.  You know the uarch far better than I, so 
the questions below are just that -- questions that might lead you to 
different conclusions about tuning.




+/* Costs to use when optimizing for Tenstorrent Ascalon 8 wide.  */
+static const struct riscv_tune_param tt_ascalon_d8_tune_info = {
+  {COSTS_N_INSNS (2), COSTS_N_INSNS (2)},  /* fp_add */
+  {COSTS_N_INSNS (3), COSTS_N_INSNS (3)},  /* fp_mul */
+  {COSTS_N_INSNS (9), COSTS_N_INSNS (16)}, /* fp_div */
+  {COSTS_N_INSNS (3), COSTS_N_INSNS (3)},  /* int_mul */
+  {COSTS_N_INSNS (15), COSTS_N_INSNS (15)},/* int_div */
If your integer divider has early exit paths you may want to reduce the 
int_div costs a bit.I found that ~75% of the actual latency as the 
cost worked pretty well for our uarch.  Obviously this is a heuristic 
and there's no perfect value.






+  false,   /* use_divmod_expansion */
+  true,/* overlap_op_by_pieces 
*/
+  RISCV_FUSE_NOTHING,   /* fusible_ops */
So you've marked as not having any fusion capability.  That would 
suggest to me quite strongly that you should be using divmod expansion.


Essentially divmod expansion exposes a pattern which produces the 
quotient & remainder outputs using a single div + mult + sub which is 
almost always going to be faster than a div and a mod instruction.


In the case where you don't need the remainder the mult/sub will get 
trivially removed as dead code.  In the case where you don't need the 
quotient the sequenece will be transformed back into a single rem 
instruction later in the RTL passes (probably combine).


If your processor has fusion capabilities, you might want to look at if 
they map to the ones currently supported and if so set the right bits 
for fusible ops.  If there's cases missing that your processor supports, 
then we should probably work together as I've got an engineer that's 
expanded the set of fusible cases in our internal gcc tree that I can 
make available (just haven't had the time to work through the internal 
review process yet).


jeff

Re: [PATCH] RISC-V: Fix compress shuffle pattern [PR117383].

[Jeff Law]

On 12/11/24 10:40 PM, Robin Dapp wrote:

This one also has a comment saying "but use ta" with TDEFAULT_POLICY_P,
IIUC one of those must be wrong too?


Yea, I didn't update the comment, thanks for catching.

OK with that change.
jeff

Re: [PATCH] RISC-V: optimization by converting LUI operands with SMALL_AFTER_COMMON_TRAILING_SHIFT

[Jeff Law]

On 12/11/24 3:40 AM, Oliver Kozul wrote:

The patch optimizes code generation for comparisons of the form
X & C1 == C2. When the bitwise AND mask could fit in a 12-bit immediate
operand of RISC-V "andi" instruction with help of right shifting.
For example, C1 = 0x5550 and C2 = 0x1450.
These numbers can be stored using 12 bits, which is advantageous in RISC-V,
since instructions such as ANDI exist. By shifting all used values
by 20 bits to the right, we can make use of the “and immediate” instruction,
thus improving performance.

2024-12-11  Oliver Kozul  

  PR target/114087

gcc/ChangeLog:

  * config/riscv/riscv.md (*lui_constraint_lshiftrt): New 
pattern.


gcc/testsuite/ChangeLog:

  * gcc.target/riscv/pr114087-2.c: New test.
As Oliver and I have discussed privately, he thinks this may be missing 
a final shift, similar to another related patch.   That is likely the 
cause of the pre-commit test failures:



https://github.com/ewlu/gcc-precommit-ci/issues/2728#issuecomment-2535517333



I'm going to assume Oliver will update the patch or drop it if it's not 
profitable after fixing the missing shift.


Oliver -- this case may also be worth looking at in the gimple or 
gimple->rtl phases as well since the trailing shift can be eliminated 
when the result is used exclusively in an equality test and that's 
easier to see in gimple or at the gimple->rtl phase.


jeff

Re: [PATCH 1/3] testsuite: RISC-V: Explicitly specify ABI when adding V and Zvbb options

[Jeff Law]

On 12/10/24 12:48 PM, Dimitar Dimitrov wrote:

On Mon, Dec 09, 2024 at 06:05:10PM +0100, Robin Dapp wrote:

+/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */
+/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */


Wouldn't skipping those tests also be reasonable?
I.e. adding a target to the compile directive instead.  I'd find that a bit
more intuitive than overriding the ABI.
The same might apply to the other cases you touched.  In the end it's probably
a question of taste but why if your test target mandates an ABI that cannot
compile vector tests, why compile them at all?


Yes, it's perfectly reasonable to skip such tests for ILP32E default
ABI.  I can prepare a patch to filter with "check_effective_target_riscv_e".
I'd say let's go with the original or this proposal.  I lean slightly 
towards this proposal as I can easily see us having tests that are 
specific to to 32E and having the target selector in place will make 
that easier.





But instead of adding a new effective_target filter to hundreds of test
cases, we could simply prune the test results.  Would the bellow
approach be acceptable?

Let's avoid the pruning approach.

jeff

Re: [PATCH 0/5] New Asm Constraints and Modifiers - RVC, Raw Encodings, Pairs

[Jeff Law]

On 12/9/24 1:56 AM, Kito Cheng wrote:

This patch set implements the proposal from riscv-c-api-doc[1].
It adds two constraints and one modifier with the goal of improving the user
experience for `.insn`, making it easier for users to experiment with new ISA
extensions.

A quick summary of this patch set:

- Add R constraint for even-odd pairs of general-purpose registers.
- Add cr and cf constraints for RVC-compatible registers.
- Add N modifier for the raw encoding of a register.

The c constraint and N modifier were already in use before, but only internally.
Therefore, I believe it is safe to rename them for broader use.

[1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/92

Kito Cheng (5):
   RISC-V: Rename constraint c0* to k0*
   RISC-V: Add cr and cf constraint
   RISC-V Rename internal operand modifier N to n
   RISC-V: Implment N modifier for printing the register number rather
 than the register name
   RISC-V: Add new constraint R for register even-odd pairs
ps.  I think it's pretty unlikely the xtreme-header failures from 
pre-commit CI  are related to this change.  But I'd do a quick check 
before committing.


jeff

Re: [PATCH] middle-end/117932 - speed up DF solver

[Jeff Law]

On 12/6/24 8:55 AM, Richard Biener wrote:

The following addresses slow bitmap operations for maintaining the
iteration order of df_worklist_dataflow_doublequeue for large number
of basic-blocks.  One change is switching the worklist and pending
bitmaps to tree view, another change is avoiding the fully populated
initial bitmap for the first iteration and instead special-casing that
plus avoiding all forward worklist bitmap sets in that iteration.
Usually second or later iterations are sparse, so optimizing the first
iteration is worthwhile.  In fact both changes in isolation achieve
the speedup below already, the combination accounts for a minor
additional speedup.

For PR117932 when isolating from ext-dce and fold-mem-offset issues
this results in a 10% compile-time reduction.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.  I plan
to push this in the next days unless there are comments suggesting
otherwise.
Sounds good.  I haven't forgotten those compile-time issues, just been a 
busier than usual couple weeks.


jeff

Re: [PATCH 0/5] New Asm Constraints and Modifiers - RVC, Raw Encodings, Pairs

[Jeff Law]

On 12/9/24 1:56 AM, Kito Cheng wrote:

This patch set implements the proposal from riscv-c-api-doc[1].
It adds two constraints and one modifier with the goal of improving the user
experience for `.insn`, making it easier for users to experiment with new ISA
extensions.

A quick summary of this patch set:

- Add R constraint for even-odd pairs of general-purpose registers.
- Add cr and cf constraints for RVC-compatible registers.
- Add N modifier for the raw encoding of a register.

The c constraint and N modifier were already in use before, but only internally.
Therefore, I believe it is safe to rename them for broader use.

[1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/92

Kito Cheng (5):
   RISC-V: Rename constraint c0* to k0*
   RISC-V: Add cr and cf constraint
   RISC-V Rename internal operand modifier N to n
   RISC-V: Implment N modifier for printing the register number rather
 than the register name
   RISC-V: Add new constraint R for register even-odd pairs

If this had been posted a month ago it would be a no-brainer OK.

My worry at this stage is about renaming the existing constraints/output 
modifiers and the possibility missing a case where they need to be changed.


I won't object as I think the risk is relatively slow, but I really wish 
we'd done this a month ago or didn't do the renaming of existing 
constraints and output modifiers.


jeff

Re: [PING][PATCH 00/15] Fix data races with sub-longword accesses on Alpha

[Jeff Law]

On 12/3/24 2:02 PM, Maciej W. Rozycki wrote:

On Mon, 18 Nov 2024, Maciej W. Rozycki wrote:


  As it happens these data races also apply to BWX Alpha systems, as I have
discovered in the course of this effort, although owing to how the Alpha
backend of GCC has implemented block copy and clear operations rather than
actual hardware limitations, for example GCC will happily produce code
such as:

ldbu $1,0($3)
stw $31,8($3)
stq $1,0($3)

to zero a 9-byte member at the byte offset of 1 of a quadword-aligned
struct, happily clobbering a 1-byte member at the beginning of said struct
if there is a concurrent or parallel write to that member in the middle of
the unprotected RMW sequence.


  Ping for:



(this will presumably need tweaks similar to ones made to __builtin_memcpy
tests, to exclude for AVR targets and to mark as expensive)


These are OK.I know it's not a review of the complete set, but the 
others require more time/brainpower than I've got right now.


jeff

Re: [patch,avr] Skip some tests that don't work on avr

[Jeff Law]

On 12/3/24 7:45 AM, Georg-Johann Lay wrote:

Am 03.12.24 um 15:36 schrieb Jeff Law:


On 12/3/24 3:57 AM, Georg-Johann Lay wrote:

This patch skips some tests that don't work on avr.

Ok for trunk?

Johann

--

AVR: Skip some test cases that don't work for it.

gcc/testsuite/
 * gcc.c-torture/execute/ieee/cdivchkd.x: New file.
 * gcc.c-torture/execute/ieee/cdivchkf.x: New file.
 * gcc.dg/flex-array-counted-by.c: Skip on avr.
 * gcc.dg/fold-copysign-1.c [avr]: Add -mdouble=64.
Do you think there's more of these likely to pop up?  If so, then I'd 
recommend some kind of a test in target-supports.exp and isolate the 
avr-isms there.  If this is about it, then it's OK.


jeff


Yes, there are likely to be more.

Though there's not one single reason for why some tests are failing
on avr.  For example, one of the above tests failed because wchar_t
support is incomplete, an other one failed because ilogb is missing,
etc.

Got it.  So it's really about missing things in the target environment.



So I don't see what exactly such a dg-require test should test for.

Probably not a good one that would cover all of what you're trying to do.



But flex-array-counted-by.c would better do dg-require wchar which
is already there.

So let's go with the dg-require wchar for that.

When you see commonality between reasons to skip, try to create a 
suitable target-support.exp test.  But when there isn't any obvious 
commonality, go ahead with your skip approach.


Thanks and sorry for the delays.

jeff

[COMMITED] bpf: fix build adding new required arg to RESOLVE_OVERLOADED_BUILTIN

[Jose E. Marchesi]

gcc/ChangeLog

* config/bpf/bpf.cc (bpf_resolve_overloaded_builtin): Add argument
`complain'.
---
 gcc/config/bpf/bpf.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
index fd913ecdb65..9a927e3a6ff 100644
--- a/gcc/config/bpf/bpf.cc
+++ b/gcc/config/bpf/bpf.cc
@@ -1084,7 +1084,8 @@ bpf_expand_builtin (tree exp, rtx target ATTRIBUTE_UNUSED,
 #define TARGET_EXPAND_BUILTIN bpf_expand_builtin
 
 static tree
-bpf_resolve_overloaded_builtin (location_t loc, tree fndecl, void *arglist)
+bpf_resolve_overloaded_builtin (location_t loc, tree fndecl, void *arglist,
+   bool complain ATTRIBUTE_UNUSED)
 {
   int code = DECL_MD_FUNCTION_CODE (fndecl);
   if (code > BPF_CORE_BUILTINS_MARKER)
-- 
2.30.2

[PATCH] RISC-V: Add Tenstorrent Ascalon 8 wide architecture

[Anton Blanchard]

This adds the Tenstorrent Ascalon 8 wide architecture (tt-ascalon-d8)
to the list of known cores.

gcc/ChangeLog:

* config/riscv/riscv-cores.def: Add tt-ascalon-d8.
* config/riscv/riscv.cc (tt_ascalon_d8_tune_info): New.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/mcpu-tt-ascalon-d8.c: New test.

Signed-off-by: Anton Blanchard 
---
 gcc/config/riscv/riscv-cores.def  |  8 ++
 gcc/config/riscv/riscv.cc | 22 ++
 .../gcc.target/riscv/mcpu-tt-ascalon-d8.c | 76 +++
 3 files changed, 106 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-tt-ascalon-d8.c

diff --git a/gcc/config/riscv/riscv-cores.def b/gcc/config/riscv/riscv-cores.def
index 2f5efe3be86..4fd09e653d2 100644
--- a/gcc/config/riscv/riscv-cores.def
+++ b/gcc/config/riscv/riscv-cores.def
@@ -39,6 +39,7 @@ RISCV_TUNE("sifive-5-series", generic, rocket_tune_info)
 RISCV_TUNE("sifive-7-series", sifive_7, sifive_7_tune_info)
 RISCV_TUNE("sifive-p400-series", sifive_p400, sifive_p400_tune_info)
 RISCV_TUNE("sifive-p600-series", sifive_p600, sifive_p600_tune_info)
+RISCV_TUNE("tt-ascalon-d8", generic_ooo, tt_ascalon_d8_tune_info)
 RISCV_TUNE("thead-c906", generic, thead_c906_tune_info)
 RISCV_TUNE("xiangshan-nanhu", xiangshan, xiangshan_nanhu_tune_info)
 RISCV_TUNE("generic-ooo", generic_ooo, generic_ooo_tune_info)
@@ -92,6 +93,13 @@ RISCV_CORE("thead-c906",  
"rv64imafdc_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
  "xtheadmemidx_xtheadmempair_xtheadsync",
  "thead-c906")
 
+RISCV_CORE("tt-ascalon-d8",   "rv64imafdcv_zic64b_zicbom_zicbop_zicboz_"
+ "ziccamoa_ziccif_zicclsm_ziccrse_zicond_zicsr_"
+ "zifencei_zihintntl_zihintpause_zimop_za64rs_"
+ "zawrs_zfa_zfbfmin_zfh_zcb_zcmop_zba_zbb_zbs_"
+ "zvbb_zvbc_zvfbfwma_zvfh_zvkng_zvl256b",
+ "tt-ascalon-d8")
+
 RISCV_CORE("xiangshan-nanhu",  "rv64imafdc_zba_zbb_zbc_zbs_"
  "zbkb_zbkc_zbkx_zknd_zkne_zknh_zksed_zksh_"
  "svinval_zicbom_zicboz",
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7860e5fbc23..cc0a18250d2 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -598,6 +598,28 @@ static const struct riscv_tune_param generic_ooo_tune_info 
= {
   NULL,/* loop_align */
 };
 
+/* Costs to use when optimizing for Tenstorrent Ascalon 8 wide.  */
+static const struct riscv_tune_param tt_ascalon_d8_tune_info = {
+  {COSTS_N_INSNS (2), COSTS_N_INSNS (2)},  /* fp_add */
+  {COSTS_N_INSNS (3), COSTS_N_INSNS (3)},  /* fp_mul */
+  {COSTS_N_INSNS (9), COSTS_N_INSNS (16)}, /* fp_div */
+  {COSTS_N_INSNS (3), COSTS_N_INSNS (3)},  /* int_mul */
+  {COSTS_N_INSNS (15), COSTS_N_INSNS (15)},/* int_div */
+  8,   /* issue_rate */
+  3,   /* branch_cost */
+  4,   /* memory_cost */
+  4,   /* fmv_cost */
+  false,   /* slow_unaligned_access */
+  true,/* 
vector_unaligned_access */
+  false,   /* use_divmod_expansion */
+  true,/* overlap_op_by_pieces 
*/
+  RISCV_FUSE_NOTHING,   /* fusible_ops */
+  &generic_vector_cost,/* vector cost */
+  NULL,/* function_align */
+  NULL,/* jump_align */
+  NULL,/* loop_align */
+};
+
 /* Costs to use when optimizing for size.  */
 static const struct riscv_tune_param optimize_size_tune_info = {
   {COSTS_N_INSNS (1), COSTS_N_INSNS (1)},  /* fp_add */
diff --git a/gcc/testsuite/gcc.target/riscv/mcpu-tt-ascalon-d8.c 
b/gcc/testsuite/gcc.target/riscv/mcpu-tt-ascalon-d8.c
new file mode 100644
index 000..4c9e13ee4b4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/mcpu-tt-ascalon-d8.c
@@ -0,0 +1,76 @@
+/* { dg-do compile } */
+/* { dg-skip-if "-march given" { *-*-* } { "-march=*" } } */
+/* { dg-options "-mcpu=tt-ascalon-d8 -mabi=lp64d" } */
+/* Tenstorrent tt-ascalon-d8 => 
rv64imafdcv_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_zicond_zicsr_zifencei_zihintntl_zihintpause_zimop_za64rs_zawrs_zfa_zfbfmin_zfh_zcb_zcmop_zba_zbb_zbs_zvbb_zvbc_zvfbfwma_zvfh_zvkng_zvl256b
 */
+
+#if !((__riscv_xlen == 64) \
+  && !defined(__riscv_32e) \
+  && (__riscv_flen == 64)  \
+  && defined(__riscv_i)\
+  && defined(__riscv_m)\
+  &&

[PATCH] opts: Use OPTION_SET_P instead of magic value 2 for -fshort-enums default [PR118011]

[Jakub Jelinek]

Hi!

The magic values for default (usually -1 or sometimes 2) for some options
are from times we haven't global_options_set, I think we should eventually
get rid of all of those.

The PR is about gcc -Q --help=optimizers reporting -fshort-enums as
[enabled] when it is disabled.
For this the following patch is just partial fix; with explicit
gcc -Q --help=optimizers -fshort-enums
or
gcc -Q --help=optimizers -fno-short-enums
it already worked correctly before, with this patch it will report
even with just
gcc -Q --help=optimizers
correct value on most targets, except 32-bit arm with some options or
defaults, so I think it is a step in the right direction.

But, as I wrote in the PR, process_options isn't done before --help=
and even shouldn't be in its current form where it warns on some option
combinations or errors or emits sorry on others, so I think ideally
process_options should have some bool argument whether it is done for
--help= purposes or not, if yes, not emit warnings and just adjust the
options, otherwise do what it currently does.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-12-14  Jakub Jelinek  

PR c/118011
gcc/
* opts.cc (init_options_struct): Don't set opts->x_flag_short_enums to
2.
* toplev.cc (process_options): Test !OPTION_SET_P (flag_short_enums)
rather than flag_short_enums == 2.
gcc/ada/
* gcc-interface/misc.cc (gnat_post_options): Test
!OPTION_SET_P (flag_short_enums) rather than flag_short_enums == 2.

--- gcc/opts.cc.jj  2024-12-02 11:08:52.080134376 +0100
+++ gcc/opts.cc 2024-12-13 10:33:55.433900989 +0100
@@ -444,9 +444,6 @@ init_options_struct (struct gcc_options
 
   /* Initialize whether `char' is signed.  */
   opts->x_flag_signed_char = DEFAULT_SIGNED_CHAR;
-  /* Set this to a special "uninitialized" value.  The actual default
- is set after target options have been processed.  */
-  opts->x_flag_short_enums = 2;
 
   /* Initialize target_flags before default_options_optimization
  so the latter can modify it.  */
--- gcc/toplev.cc.jj2024-12-09 11:37:50.452216272 +0100
+++ gcc/toplev.cc   2024-12-13 10:35:29.396546654 +0100
@@ -1300,7 +1300,7 @@ process_options ()
   flag_section_anchors = 0;
 }
 
-  if (flag_short_enums == 2)
+  if (!OPTION_SET_P (flag_short_enums))
 flag_short_enums = targetm.default_short_enums ();
 
   /* Set aux_base_name if not already set.  */
--- gcc/ada/gcc-interface/misc.cc.jj2024-11-23 13:00:27.748036611 +0100
+++ gcc/ada/gcc-interface/misc.cc   2024-12-13 10:36:49.658389809 +0100
@@ -283,7 +283,7 @@ gnat_post_options (const char **pfilenam
   /* Unfortunately the post_options hook is called before the value of
  flag_short_enums is autodetected, if need be.  Mimic the process
  for our private flag_short_enums.  */
-  if (flag_short_enums == 2)
+  if (!OPTION_SET_P (flag_short_enums))
 flag_short_enums = targetm.default_short_enums ();
 
   return false;

Jakub

[PATCH] warn-access: Fix up matching_alloc_calls_p [PR118024]

[Jakub Jelinek]

Hi!

The following testcase ICEs because of a bug in matching_alloc_calls_p.
The loop was apparently meant to be walking the two attribute chains
in lock-step, but doesn't really do that.  If the first lookup_attribute
returns non-NULL, the second one is not done, so rmats in that case can
be some random unrelated attribute rather than "malloc" attribute; the
body assumes even rmats if non-NULL is "malloc" attribute and relies
on its argument to be a "malloc" argument and if it is some other
attribute with incompatible attribute, it just crashes.

Now, fixing that in the obvious way, instead of doing
(amats = lookup_attribute ("malloc", amats))
 || (rmats = lookup_attribute ("malloc", rmats))
in the condition do
((amats = lookup_attribute ("malloc", amats)),
 (rmats = lookup_attribute ("malloc", rmats)),
 (amats || rmats))
fixes the testcase but regresses Wmismatched-dealloc-{2,3}.c tests.
The problem is that walking the attribute lists in a lock-step is obviously
a very bad idea, there is no requirement that the same deallocators are
present in the same order on both decls, e.g. there could be an extra malloc
attribute without argument in just one of the lists, or the order of say
free/realloc could be swapped, etc.  We don't generally document nor enforce
any particular ordering of attributes (even when for some attributes we just
handle the first one rather than all).

So, this patch instead simply splits it into two loops, the first one walks
alloc_decl attributes, the second one walks dealloc_decl attributes.
If the malloc attribute argument is a built-in, that doesn't change
anything, and otherwise we have the chance to populate the whole
common_deallocs hash_set in the first loop and then can check it in the
second one (and don't need to use more expensive add method on it, can just
check contains there).  Not to mention that it also fixes the case when
the function would incorrectly return true if there wasn't a common
deallocator between the two, but dealloc_decl had 2 malloc attributes with
the same deallocator.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-12-14  Jakub Jelinek  

PR middle-end/118024
* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Walk malloc
attributes of alloc_decl and dealloc_decl in separate loops rather
than in lock-step.  Use common_deallocs.contains rather than
common_deallocs.add in the second loop.

* gcc.dg/pr118024.c: New test.

--- gcc/gimple-ssa-warn-access.cc.jj2024-12-07 11:35:49.467439817 +0100
+++ gcc/gimple-ssa-warn-access.cc   2024-12-13 13:03:13.626700818 +0100
@@ -1935,52 +1935,49 @@ matching_alloc_calls_p (tree alloc_decl,
  headers.
  With AMATS set to the Allocator's Malloc ATtributes,
  and  RMATS set to Reallocator's Malloc ATtributes...  */
-  for (tree amats = DECL_ATTRIBUTES (alloc_decl),
-rmats = DECL_ATTRIBUTES (dealloc_decl);
-   (amats = lookup_attribute ("malloc", amats))
-|| (rmats = lookup_attribute ("malloc", rmats));
-   amats = amats ? TREE_CHAIN (amats) : NULL_TREE,
-rmats = rmats ? TREE_CHAIN (rmats) : NULL_TREE)
-{
-  if (tree args = amats ? TREE_VALUE (amats) : NULL_TREE)
-   if (tree adealloc = TREE_VALUE (args))
- {
-   if (DECL_P (adealloc)
-   && fndecl_built_in_p (adealloc, BUILT_IN_NORMAL))
- {
-   built_in_function fncode = DECL_FUNCTION_CODE (adealloc);
-   if (fncode == BUILT_IN_FREE || fncode == BUILT_IN_REALLOC)
- {
-   if (realloc_kind == alloc_kind_t::builtin)
- return true;
-   alloc_dealloc_kind = alloc_kind_t::builtin;
- }
-   continue;
- }
+  for (tree amats = DECL_ATTRIBUTES (alloc_decl);
+   (amats = lookup_attribute ("malloc", amats));
+   amats = amats ? TREE_CHAIN (amats) : NULL_TREE)
+if (tree args = amats ? TREE_VALUE (amats) : NULL_TREE)
+  if (tree adealloc = TREE_VALUE (args))
+   {
+ if (DECL_P (adealloc)
+ && fndecl_built_in_p (adealloc, BUILT_IN_NORMAL))
+   {
+ built_in_function fncode = DECL_FUNCTION_CODE (adealloc);
+ if (fncode == BUILT_IN_FREE || fncode == BUILT_IN_REALLOC)
+   {
+ if (realloc_kind == alloc_kind_t::builtin)
+   return true;
+ alloc_dealloc_kind = alloc_kind_t::builtin;
+   }
+ continue;
+   }
 
-   common_deallocs.add (adealloc);
- }
+ common_deallocs.add (adealloc);
+   }
+  for (tree rmats = DECL_ATTRIBUTES (dealloc_decl);
+   (rmats = lookup_attribute ("malloc", rmats));
+   rmats = rmats ? TREE_CHAIN (rmats) : NULL_TREE)
+if (tree args = rmats ? TREE_VALUE (rmats) : NULL_TREE)
+  if (tree ddealloc = TREE_VALUE (args))
+   {
+ if (DECL_P (ddealloc)
+   

Re: [PATCH] opts: Use OPTION_SET_P instead of magic value 2 for -fshort-enums default [PR118011]

[Richard Biener]

> Am 14.12.2024 um 09:08 schrieb Jakub Jelinek :
> 
> Hi!
> 
> The magic values for default (usually -1 or sometimes 2) for some options
> are from times we haven't global_options_set, I think we should eventually
> get rid of all of those.
> 
> The PR is about gcc -Q --help=optimizers reporting -fshort-enums as
> [enabled] when it is disabled.
> For this the following patch is just partial fix; with explicit
> gcc -Q --help=optimizers -fshort-enums
> or
> gcc -Q --help=optimizers -fno-short-enums
> it already worked correctly before, with this patch it will report
> even with just
> gcc -Q --help=optimizers
> correct value on most targets, except 32-bit arm with some options or
> defaults, so I think it is a step in the right direction.
> 
> But, as I wrote in the PR, process_options isn't done before --help=
> and even shouldn't be in its current form where it warns on some option
> combinations or errors or emits sorry on others, so I think ideally
> process_options should have some bool argument whether it is done for
> --help= purposes or not, if yes, not emit warnings and just adjust the
> options, otherwise do what it currently does.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Thanks,

Richard 

> 2024-12-14  Jakub Jelinek  
> 
>PR c/118011
> gcc/
>* opts.cc (init_options_struct): Don't set opts->x_flag_short_enums to
>2.
>* toplev.cc (process_options): Test !OPTION_SET_P (flag_short_enums)
>rather than flag_short_enums == 2.
> gcc/ada/
>* gcc-interface/misc.cc (gnat_post_options): Test
>!OPTION_SET_P (flag_short_enums) rather than flag_short_enums == 2.
> 
> --- gcc/opts.cc.jj2024-12-02 11:08:52.080134376 +0100
> +++ gcc/opts.cc2024-12-13 10:33:55.433900989 +0100
> @@ -444,9 +444,6 @@ init_options_struct (struct gcc_options
> 
>   /* Initialize whether `char' is signed.  */
>   opts->x_flag_signed_char = DEFAULT_SIGNED_CHAR;
> -  /* Set this to a special "uninitialized" value.  The actual default
> - is set after target options have been processed.  */
> -  opts->x_flag_short_enums = 2;
> 
>   /* Initialize target_flags before default_options_optimization
>  so the latter can modify it.  */
> --- gcc/toplev.cc.jj2024-12-09 11:37:50.452216272 +0100
> +++ gcc/toplev.cc2024-12-13 10:35:29.396546654 +0100
> @@ -1300,7 +1300,7 @@ process_options ()
>   flag_section_anchors = 0;
> }
> 
> -  if (flag_short_enums == 2)
> +  if (!OPTION_SET_P (flag_short_enums))
> flag_short_enums = targetm.default_short_enums ();
> 
>   /* Set aux_base_name if not already set.  */
> --- gcc/ada/gcc-interface/misc.cc.jj2024-11-23 13:00:27.748036611 +0100
> +++ gcc/ada/gcc-interface/misc.cc2024-12-13 10:36:49.658389809 +0100
> @@ -283,7 +283,7 @@ gnat_post_options (const char **pfilenam
>   /* Unfortunately the post_options hook is called before the value of
>  flag_short_enums is autodetected, if need be.  Mimic the process
>  for our private flag_short_enums.  */
> -  if (flag_short_enums == 2)
> +  if (!OPTION_SET_P (flag_short_enums))
> flag_short_enums = targetm.default_short_enums ();
> 
>   return false;
> 
>Jakub
> 

Re: [PATCH] warn-access: Fix up matching_alloc_calls_p [PR118024]

[Richard Biener]

> Am 14.12.2024 um 09:20 schrieb Jakub Jelinek :
> 
> Hi!
> 
> The following testcase ICEs because of a bug in matching_alloc_calls_p.
> The loop was apparently meant to be walking the two attribute chains
> in lock-step, but doesn't really do that.  If the first lookup_attribute
> returns non-NULL, the second one is not done, so rmats in that case can
> be some random unrelated attribute rather than "malloc" attribute; the
> body assumes even rmats if non-NULL is "malloc" attribute and relies
> on its argument to be a "malloc" argument and if it is some other
> attribute with incompatible attribute, it just crashes.
> 
> Now, fixing that in the obvious way, instead of doing
> (amats = lookup_attribute ("malloc", amats))
> || (rmats = lookup_attribute ("malloc", rmats))
> in the condition do
> ((amats = lookup_attribute ("malloc", amats)),
> (rmats = lookup_attribute ("malloc", rmats)),
> (amats || rmats))
> fixes the testcase but regresses Wmismatched-dealloc-{2,3}.c tests.
> The problem is that walking the attribute lists in a lock-step is obviously
> a very bad idea, there is no requirement that the same deallocators are
> present in the same order on both decls, e.g. there could be an extra malloc
> attribute without argument in just one of the lists, or the order of say
> free/realloc could be swapped, etc.  We don't generally document nor enforce
> any particular ordering of attributes (even when for some attributes we just
> handle the first one rather than all).
> 
> So, this patch instead simply splits it into two loops, the first one walks
> alloc_decl attributes, the second one walks dealloc_decl attributes.
> If the malloc attribute argument is a built-in, that doesn't change
> anything, and otherwise we have the chance to populate the whole
> common_deallocs hash_set in the first loop and then can check it in the
> second one (and don't need to use more expensive add method on it, can just
> check contains there).  Not to mention that it also fixes the case when
> the function would incorrectly return true if there wasn't a common
> deallocator between the two, but dealloc_decl had 2 malloc attributes with
> the same deallocator.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Thanks,
Richard 

> 2024-12-14  Jakub Jelinek  
> 
>PR middle-end/118024
>* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Walk malloc
>attributes of alloc_decl and dealloc_decl in separate loops rather
>than in lock-step.  Use common_deallocs.contains rather than
>common_deallocs.add in the second loop.
> 
>* gcc.dg/pr118024.c: New test.
> 
> --- gcc/gimple-ssa-warn-access.cc.jj2024-12-07 11:35:49.467439817 +0100
> +++ gcc/gimple-ssa-warn-access.cc2024-12-13 13:03:13.626700818 +0100
> @@ -1935,52 +1935,49 @@ matching_alloc_calls_p (tree alloc_decl,
>  headers.
>  With AMATS set to the Allocator's Malloc ATtributes,
>  and  RMATS set to Reallocator's Malloc ATtributes...  */
> -  for (tree amats = DECL_ATTRIBUTES (alloc_decl),
> - rmats = DECL_ATTRIBUTES (dealloc_decl);
> -   (amats = lookup_attribute ("malloc", amats))
> - || (rmats = lookup_attribute ("malloc", rmats));
> -   amats = amats ? TREE_CHAIN (amats) : NULL_TREE,
> - rmats = rmats ? TREE_CHAIN (rmats) : NULL_TREE)
> -{
> -  if (tree args = amats ? TREE_VALUE (amats) : NULL_TREE)
> -if (tree adealloc = TREE_VALUE (args))
> -  {
> -if (DECL_P (adealloc)
> -&& fndecl_built_in_p (adealloc, BUILT_IN_NORMAL))
> -  {
> -built_in_function fncode = DECL_FUNCTION_CODE (adealloc);
> -if (fncode == BUILT_IN_FREE || fncode == BUILT_IN_REALLOC)
> -  {
> -if (realloc_kind == alloc_kind_t::builtin)
> -  return true;
> -alloc_dealloc_kind = alloc_kind_t::builtin;
> -  }
> -continue;
> -  }
> +  for (tree amats = DECL_ATTRIBUTES (alloc_decl);
> +   (amats = lookup_attribute ("malloc", amats));
> +   amats = amats ? TREE_CHAIN (amats) : NULL_TREE)
> +if (tree args = amats ? TREE_VALUE (amats) : NULL_TREE)
> +  if (tree adealloc = TREE_VALUE (args))
> +{
> +  if (DECL_P (adealloc)
> +  && fndecl_built_in_p (adealloc, BUILT_IN_NORMAL))
> +{
> +  built_in_function fncode = DECL_FUNCTION_CODE (adealloc);
> +  if (fncode == BUILT_IN_FREE || fncode == BUILT_IN_REALLOC)
> +{
> +  if (realloc_kind == alloc_kind_t::builtin)
> +return true;
> +  alloc_dealloc_kind = alloc_kind_t::builtin;
> +}
> +  continue;
> +}
> 
> -common_deallocs.add (adealloc);
> -  }
> +  common_deallocs.add (adealloc);
> +}
> +  for (tree rmats = DECL_ATTRIBUTES (dealloc_decl);
> +   (rmats = lookup_attribute ("malloc", rmats));
> +   rmats = rmats ? TREE_CHAIN (rmats) : NULL_TREE)
> +if (tree args = rmats ? TREE_VALUE (rmats) : NULL_TREE)
> + 

[PATCH] gimple-fold: Fix the recent ifcombine optimization for _BitInt [PR118023]

[Jakub Jelinek]

Hi!

The BIT_FIELD_REF verifier has:
  if (INTEGRAL_TYPE_P (TREE_TYPE (op))
  && !type_has_mode_precision_p (TREE_TYPE (op)))
{
  error ("%qs of non-mode-precision operand", code_name);
  return true;
}
check among other things, so one can't extract something out of say
_BitInt(63) or _BitInt(4096).
The new ifcombine optimization happily creates such BIT_FIELD_REFs
and ICEs during their verification.

The following patch fixes that by rejecting those in decode_field_reference.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-12-14  Jakub Jelinek  

PR tree-optimization/118023
* gimple-fold.cc (decode_field_reference): Return NULL_TREE if
inner has non-type_has_mode_precision_p integral type.

* gcc.dg/bitint-119.c: New test.

--- gcc/gimple-fold.cc.jj   2024-12-12 19:46:59.0 +0100
+++ gcc/gimple-fold.cc  2024-12-13 14:50:16.575652767 +0100
@@ -7643,7 +7643,9 @@ decode_field_reference (tree *pexp, HOST
   /* Reject out-of-bound accesses (PR79731).  */
   || (! AGGREGATE_TYPE_P (TREE_TYPE (inner))
  && compare_tree_int (TYPE_SIZE (TREE_TYPE (inner)),
-  bp + bs) < 0))
+  bp + bs) < 0)
+  || (INTEGRAL_TYPE_P (TREE_TYPE (inner))
+ && !type_has_mode_precision_p (TREE_TYPE (inner
 return NULL_TREE;
 
   *pbitsize = bs;
--- gcc/testsuite/gcc.dg/bitint-119.c.jj2024-12-13 15:44:22.507548292 
+0100
+++ gcc/testsuite/gcc.dg/bitint-119.c   2024-12-13 15:43:44.608086854 +0100
@@ -0,0 +1,11 @@
+/* PR tree-optimization/118023 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O2" } */
+
+_BitInt(63) b;
+
+int
+foo (void)
+{
+  return !*(_Complex char *) &b;
+}

Jakub

[PATCH] c++: Diagnose earlier non-static data members with cv containing class type [PR116108]

[Jakub Jelinek]

Hi!

In r10-6457 aka PR92593 fix a check has been added to reject
earlier non-static data members with current_class_type in templates,
as the deduction then can result in endless recursion in reshape_init.
It fixed the
template 
struct S { S s = 1; };
S t{2};
crashes, but as the following testcase shows, didn't catch when there
are cv qualifiers on the non-static data member.

Fixed by using TYPE_MAIN_VARIANT.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-12-14  Jakub Jelinek  

PR c++/116108
gcc/cp/
* decl.cc (grokdeclarator): Pass TYYPE_MAIN_VARIANT (type)
rather than type to same_type_p when checking if the non-static
data member doesn't have current class type.
gcc/testsuite/
* g++.dg/cpp1z/class-deduction117.C: New test.

--- gcc/cp/decl.cc.jj   2024-12-11 17:27:52.484221268 +0100
+++ gcc/cp/decl.cc  2024-12-13 17:05:24.445418705 +0100
@@ -15124,7 +15124,8 @@ grokdeclarator (const cp_declarator *dec
  }
else if (!staticp
 && ((current_class_type
- && same_type_p (type, current_class_type))
+ && same_type_p (TYPE_MAIN_VARIANT (type),
+ current_class_type))
 || (!dependent_type_p (type)
 && !COMPLETE_TYPE_P (complete_type (type))
 && (!complete_or_array_type_p (type)
--- gcc/testsuite/g++.dg/cpp1z/class-deduction117.C.jj  2024-12-13 
17:17:38.493973975 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction117.C 2024-12-13 
17:16:15.233158656 +0100
@@ -0,0 +1,7 @@
+// PR c++/116108
+// { dg-do compile { target c++11 } }
+template 
+struct S { const S s = 1; };   // { dg-error "field 's' has incomplete type 
'const S'" }
+S t{2};// { dg-error "invalid use of 
template-name 'S' without an argument list" "" { target c++14_down } }
+// { dg-error "class template argument deduction failed" "" { target c++17 } 
.-1 }
+// { dg-error "no matching function for call to 'S\\\(int\\\)'" "" { target 
c++17 } .-2 }

Jakub

Re: [RFC][PATCH] AArch64: Remove AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS

[Richard Biener]

> Am 13.12.2024 um 18:00 schrieb Jennifer Schmitz :
> 
> 
> 
>> On 13 Dec 2024, at 13:40, Richard Biener  wrote:
>> 
>> External email: Use caution opening links or attachments
>> 
>> 
>>> On Thu, Dec 12, 2024 at 5:27 PM Jennifer Schmitz  
>>> wrote:
>>> 
>>> 
>>> 
 On 6 Dec 2024, at 08:41, Jennifer Schmitz  wrote:
 
 
 
> On 5 Dec 2024, at 20:07, Richard Sandiford  
> wrote:
> 
> External email: Use caution opening links or attachments
> 
> 
> Jennifer Schmitz  writes:
>>> On 5 Dec 2024, at 11:44, Richard Biener  wrote:
>>> 
>>> External email: Use caution opening links or attachments
>>> 
>>> 
>>> On Thu, 5 Dec 2024, Jennifer Schmitz wrote:
>>> 
 
 
> On 17 Oct 2024, at 19:23, Richard Sandiford 
>  wrote:
> 
> External email: Use caution opening links or attachments
> 
> 
> Jennifer Schmitz  writes:
>> [...]
>> Looking at the diff of the vect dumps (below is a section of the 
>> diff for strided_store_2.c), it seemed odd that vec_to_scalar 
>> operations cost 0 now, instead of the previous cost of 2:
>> 
>> +strided_store_1.c:38:151: note:=== vectorizable_operation ===
>> +strided_store_1.c:38:151: note:vect_model_simple_cost: 
>> inside_cost = 1, prologue_cost  = 0 .
>> +strided_store_1.c:38:151: note:   ==> examining statement: *_6 = _7;
>> +strided_store_1.c:38:151: note:   vect_is_simple_use: operand _3 + 
>> 1.0e+0, type of def:internal
>> +strided_store_1.c:38:151: note:   Vectorizing an unaligned access.
>> +Applying pattern match.pd:236, generic-match-9.cc:4128
>> +Applying pattern match.pd:5285, generic-match-10.cc:4234
>> +strided_store_1.c:38:151: note:   vect_model_store_cost: 
>> inside_cost = 12, prologue_cost = 0 .
>> *_2 1 times unaligned_load (misalign -1) costs 1 in body
>> -_3 + 1.0e+0 1 times scalar_to_vec costs 1 in prologue
>> _3 + 1.0e+0 1 times vector_stmt costs 1 in body
>> -_7 1 times vec_to_scalar costs 2 in body
>> + 1 times vector_load costs 1 in prologue
>> +_7 1 times vec_to_scalar costs 0 in body
>> _7 1 times scalar_store costs 1 in body
>> -_7 1 times vec_to_scalar costs 2 in body
>> +_7 1 times vec_to_scalar costs 0 in body
>> _7 1 times scalar_store costs 1 in body
>> -_7 1 times vec_to_scalar costs 2 in body
>> +_7 1 times vec_to_scalar costs 0 in body
>> _7 1 times scalar_store costs 1 in body
>> -_7 1 times vec_to_scalar costs 2 in body
>> +_7 1 times vec_to_scalar costs 0 in body
>> _7 1 times scalar_store costs 1 in body
>> 
>> Although the aarch64_use_new_vector_costs_p flag was used in 
>> multiple places in aarch64.cc, the location that causes this 
>> behavior is this one:
>> unsigned
>> aarch64_vector_costs::add_stmt_cost (int count, vect_cost_for_stmt 
>> kind,
>>stmt_vec_info stmt_info, slp_tree,
>>tree vectype, int misalign,
>>vect_cost_model_location where)
>> {
>> [...]
>> /* Try to get a more accurate cost by looking at STMT_INFO instead
>> of just looking at KIND.  */
>> -  if (stmt_info && aarch64_use_new_vector_costs_p ())
>> +  if (stmt_info)
>> {
>> /* If we scalarize a strided store, the vectorizer costs one
>>vec_to_scalar for each element.  However, we can store the first
>>element using an FP store without a separate extract step.  */
>> if (vect_is_store_elt_extraction (kind, stmt_info))
>>   count -= 1;
>> 
>> stmt_cost = aarch64_detect_scalar_stmt_subtype (m_vinfo, kind,
>> stmt_info, 
>> stmt_cost);
>> 
>> if (vectype && m_vec_flags)
>>   stmt_cost = aarch64_detect_vector_stmt_subtype (m_vinfo, kind,
>>   stmt_info, vectype,
>>   where, stmt_cost);
>> }
>> [...]
>> return record_stmt_cost (stmt_info, where, (count * stmt_cost).ceil 
>> ());
>> }
>> 
>> Previously, for mtune=generic, this function returned a cost of 2 
>> for a vec_to_scalar operation in the vect body. Now "if (stmt_info)" 
>> is entered and "if (vect_is_store_elt_extraction (kind, stmt_info))" 
>> evaluates to true, which sets the count to 0 and leads to a return 
>> value of 0.
> 
> At the time the code was written, a scalarised store would be costed
> using one vec_to

Re: [PATCH] gimple-fold: Fix the recent ifcombine optimization for _BitInt [PR118023]

[Richard Biener]

> Am 14.12.2024 um 09:26 schrieb Jakub Jelinek :
> 
> Hi!
> 
> The BIT_FIELD_REF verifier has:
>  if (INTEGRAL_TYPE_P (TREE_TYPE (op))
>  && !type_has_mode_precision_p (TREE_TYPE (op)))
>{
>  error ("%qs of non-mode-precision operand", code_name);
>  return true;
>}
> check among other things, so one can't extract something out of say
> _BitInt(63) or _BitInt(4096).
> The new ifcombine optimization happily creates such BIT_FIELD_REFs
> and ICEs during their verification.
> 
> The following patch fixes that by rejecting those in decode_field_reference.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Richard 

> 2024-12-14  Jakub Jelinek  
> 
>PR tree-optimization/118023
>* gimple-fold.cc (decode_field_reference): Return NULL_TREE if
>inner has non-type_has_mode_precision_p integral type.
> 
>* gcc.dg/bitint-119.c: New test.
> 
> --- gcc/gimple-fold.cc.jj2024-12-12 19:46:59.0 +0100
> +++ gcc/gimple-fold.cc2024-12-13 14:50:16.575652767 +0100
> @@ -7643,7 +7643,9 @@ decode_field_reference (tree *pexp, HOST
>   /* Reject out-of-bound accesses (PR79731).  */
>   || (! AGGREGATE_TYPE_P (TREE_TYPE (inner))
>  && compare_tree_int (TYPE_SIZE (TREE_TYPE (inner)),
> -   bp + bs) < 0))
> +   bp + bs) < 0)
> +  || (INTEGRAL_TYPE_P (TREE_TYPE (inner))
> +  && !type_has_mode_precision_p (TREE_TYPE (inner
> return NULL_TREE;
> 
>   *pbitsize = bs;
> --- gcc/testsuite/gcc.dg/bitint-119.c.jj2024-12-13 15:44:22.507548292 
> +0100
> +++ gcc/testsuite/gcc.dg/bitint-119.c2024-12-13 15:43:44.608086854 +0100
> @@ -0,0 +1,11 @@
> +/* PR tree-optimization/118023 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-O2" } */
> +
> +_BitInt(63) b;
> +
> +int
> +foo (void)
> +{
> +  return !*(_Complex char *) &b;
> +}
> 
>Jakub
> 

Re: The COBOL front end, in 8 notes

[Sam James]

"James K. Lowden"  writes:

> The following 8 patches constitute the 80 files needed to build and
> document the COBOL front end.  They assume that following exist:
>
> gcc/cobol/ChangeLog
> libgcobol/ChangeLog
>
> The messages are grouped by files in a more or less logical order,
> but groups are somewhat arbitrary.  The primary constraint afaik is to
> keep them from getting too big, fsvo $too.  We have:
>
>   460K hdr  header files
>   484K par  the parser
>   760K gen  GENERIC interface
>   556K cbl  other supporting C++ files
>   432K cfg  libgcobol/configure
>   788K lib  libgcobol, all of it
>72K doc  man pages, for now
>24K bld  "meta" files, such a gcc/cobol/Make-lang.in
>
> Except for "bld", these all contain new files, can be applied in any
> order.  
>
> If you would like the patches smaller or larger, I'm happy to rearrange
> them.  Some of exceed the 400 KB mail limit, but I'm assured they'll be
> moderated through.  
>

Please use `git send-email` with threading.

> This patchset excludes tests.  While we do have tests, it's not clear
> how or if to add them to gcc.  They use a combination of (largely) 3rd
> party sources and GNU Autotest.

"if" is definitely a yes, as long as licencing for the 3rd party sources
is clear. We already have a mix of different testing frameworks in
there, see e.g. Ada and Go, although ideally you'd have dejagnu wrapping
for it.

Re: The COBOL front end, in 8 notes

[Sam James]

David Malcolm  writes:

> On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:
>> The following 8 patches constitute the 80 files needed to build and
>> document the COBOL front end.  They assume that following exist:
>> 
>>     gcc/cobol/ChangeLog
>>     libgcobol/ChangeLog
>> 
>> The messages are grouped by files in a more or less logical order,
>> but groups are somewhat arbitrary.  The primary constraint afaik is
>> to
>> keep them from getting too big, fsvo $too.  We have:
>> 
>>  460K hdr  header files
>>  484K par  the parser
>>  760K gen  GENERIC interface
>>  556K cbl  other supporting C++ files
>>  432K cfg  libgcobol/configure
>>  788K lib  libgcobol, all of it
>>   72K doc  man pages, for now
>>   24K bld  "meta" files, such a gcc/cobol/Make-lang.in
>> 
>> Except for "bld", these all contain new files, can be applied in any
>> order.  
>> 
>> If you would like the patches smaller or larger, I'm happy to
>> rearrange
>> them.  Some of exceed the 400 KB mail limit, but I'm assured they'll
>> be
>> moderated through.  
>> 
>> This patchset excludes tests.  While we do have tests, it's not clear
>> how or if to add them to gcc.  They use a combination of (largely)
>> 3rd
>> party sources and GNU Autotest.
>> 
>> A word about C style, always a lively topic.  For any files already
>> present in gcc, the existing style was followed, and any variation
>> from
>> it is unintentional.  Files related to the parser use K&R style.  The
>> GENERIC interface and runtime library use Whitesmiths style.  All C++
>> code uses spaces for indentation.  
>> 
>> The COBOL front end has been and is being written by two guys with
>> decades of experience.  We hope the code is a testament to that
>> experience.  Our relatively recent experience, these last four years,
>> is that it has been more productive to keep using the styles to which
>> we've long become accustomed.  The position of curly braces is hardly
>> any hindrance to read another's code, but it's a burden to write that
>> way. We think, 83,068 lines later, the proof of the pudding is in the
>> eating.  
>> 
>> Thank you for your kind consideration of our work.
>
> Please forgive me if you've already said this elsewhere, but is this
> work available in a public git repo somewhere?
>

https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/

> Thanks
> Dave

Re: [PATCH 1/2] middle-end/116083 - vectorizer slowness

[Jeff Law]

On 12/3/24 10:07 AM, Richard Biener wrote:

Turns out SLP discovery can end up doing a lot of vector type
builds from scalar types.  Those are all ultimatively cached but
end up built and layouted first.  The latter is particularly
expensive because it does tree node arithmetic to compute TYPE_SIZE
and TYPE_SIZE_UNIT.  The following replaces this with the appropriate
poly-int arithmetic which speeds up the testcase by 50%.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

Even after 2/2 this speeds up compilation by 5%.

PR middle-end/116083
* stor-layout.cc (layout_type): Compute TYPE_SIZE and
TYPE_SIZE_UNIT for vector types from the component mode
sizes.

OK
jeff

Re: [PATCH] COBOL 6/8 lib: libgcobol, all of it

[Jakub Jelinek]

On Thu, Dec 12, 2024 at 12:58:23PM -0500, James K. Lowden wrote:
> >From 64bcb34e12371f61a8958645e1668e0ac2704391lib.patch 4 Oct 2024 12:01:22 
> >-0400
> From: "James K. Lowden" 
> Date: Thu 12 Dec 2024 06:28:08 PM EST
> Subject: [PATCH]  Add 'cobol' to 12 files
> 
> libgcobol/ChangeLog
>   * libgcobol/Makefile.in: Add libgcobol module and cobol language.
>   * libgcobol/README: New file.
>   * libgcobol/acinclude.m4: New file.
>   * libgcobol/aclocal.m4: New file.
>   * libgcobol/config.h.in: Add libgcobol module and cobol language.
>   * libgcobol/configure.ac: Add libgcobol module and cobol language.

For new files just say New file. too (with the exception of the generated
ones, those can say Generate. or so).

Could the shared library be symbol versioned on targets which do support it?
Or is the plan to instead bump the soname each year (or whenever it
changes)?

>   * libgcobol/constants.cc: New file.
>   * libgcobol/gfileio.cc: New file.
>   * libgcobol/gmath.cc: New file.
>   * libgcobol/intrinsic.cc: New file.
>   * libgcobol/io.cc: New file.
>   * libgcobol/libgcobol.cc: New file.

Jakub

[PATCH] Shrink back size of tree_exp from 40 bytes to 32

[Jakub Jelinek]

Hi!

The following patch implements what I've mentioned in the 64-bit
location_t thread.
struct tree_exp had unsigned condition_uid member added for something
rarely used (-fcondition-coverage) and even there used only on very small
subset of trees only for the duration of the gimplification.

The following patch uses a hash_map instead, which allows shrinking
tree_exp to its previous size (32 bytes + (number of operands - 1) * sizeof
(tree)).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-12-14  Jakub Jelinek  

* tree-core.h (struct tree_exp): Remove condition_uid member.
* tree.h (SET_EXPR_UID, EXPR_COND_UID): Remove.
* gimplify.cc (nextuid): Rename to ...
(nextconduid): ... this.
(cond_uids): New static variable.
(next_cond_uid, reset_cond_uid): Adjust for the renaming,
formatting fix.
(tree_associate_condition_with_expr): New function.
(shortcut_cond_r, tag_shortcut_cond, shortcut_cond_expr): Use it
instead of SET_EXPR_UID.
(gimplify_cond_expr): Look up cond_uid in cond_uids hash map if
non-NULL instead of using EXPR_COND_UID.
(gimplify_function_tree): Delete cond_uids and set it to NULL.

--- gcc/tree-core.h.jj  2024-12-11 17:27:52.686218415 +0100
+++ gcc/tree-core.h 2024-12-14 11:35:37.474933446 +0100
@@ -1670,9 +1670,6 @@ enum omp_clause_linear_kind
 struct GTY(()) tree_exp {
   struct tree_typed typed;
   location_t locus;
-  /* Discriminator for basic conditions in a Boolean expressions.  Trees that
- are operands of the same Boolean expression should have the same uid.  */
-  unsigned condition_uid;
   tree GTY ((length ("TREE_OPERAND_LENGTH ((tree)&%h)"))) operands[1];
 };
 
--- gcc/tree.h.jj   2024-12-06 09:08:20.940872922 +0100
+++ gcc/tree.h  2024-12-14 11:36:26.610255103 +0100
@@ -1373,10 +1373,6 @@ class auto_suppress_location_wrappers
   ~auto_suppress_location_wrappers () { --suppress_location_wrappers; }
 };
 
-/* COND_EXPR identificer/discriminator accessors.  */
-#define SET_EXPR_UID(t, v) EXPR_CHECK ((t))->exp.condition_uid = (v)
-#define EXPR_COND_UID(t) EXPR_CHECK ((t))->exp.condition_uid
-
 /* In a TARGET_EXPR node.  */
 #define TARGET_EXPR_SLOT(NODE) TREE_OPERAND_CHECK_CODE (NODE, TARGET_EXPR, 0)
 #define TARGET_EXPR_INITIAL(NODE) TREE_OPERAND_CHECK_CODE (NODE, TARGET_EXPR, 
1)
--- gcc/gimplify.cc.jj  2024-12-12 19:46:59.723178720 +0100
+++ gcc/gimplify.cc 2024-12-14 15:02:53.588744025 +0100
@@ -76,14 +76,20 @@ along with GCC; see the file COPYING3.
its Boolean expression.  Basic conditions given the same uid (in the same
function) are parts of the same ANDIF/ORIF expression.  Used for condition
coverage.  */
-static unsigned nextuid = 1;
+static unsigned nextconduid = 1;
+
+/* Annotated gconds so that basic conditions in the same expression map to
+   the same uid.  This is used for condition coverage.  */
+static hash_map  *cond_uids;
+
 /* Get a fresh identifier for a new condition expression.  This is used for
condition coverage.  */
 static unsigned
 next_cond_uid ()
 {
-return nextuid++;
+  return nextconduid++;
 }
+
 /* Reset the condition uid to the value it should have when compiling a new
function.  0 is already the default/untouched value, so start at non-zero.
A valid and set id should always be > 0.  This is used for condition
@@ -91,7 +97,24 @@ next_cond_uid ()
 static void
 reset_cond_uid ()
 {
-nextuid = 1;
+  nextconduid = 1;
+}
+
+/* Associate the condition STMT with the discriminator UID.  STMTs that are
+   broken down with ANDIF/ORIF from the same Boolean expression should be given
+   the same UID; 'if (a && b && c) { if (d || e) ... } ...' should yield the
+   { a: 1, b: 1, c: 1, d: 2, e: 2 } when gimplification is done.  This is used
+   for condition coverage.  */
+static void
+tree_associate_condition_with_expr (tree stmt, unsigned uid)
+{
+  if (!condition_coverage_flag)
+return;
+
+  if (!cond_uids)
+cond_uids = new hash_map  ();
+
+  cond_uids->put (stmt, uid);
 }
 
 /* Hash set of poisoned variables in a bind expr.  */
@@ -4443,7 +4466,7 @@ shortcut_cond_r (tree pred, tree *true_l
 shortcut_cond_r (TREE_OPERAND (pred, 2), true_label_p,
  false_label_p, new_locus,
  condition_uid));
-  SET_EXPR_UID (expr, condition_uid);
+  tree_associate_condition_with_expr (expr, condition_uid);
 }
   else
 {
@@ -4451,7 +4474,7 @@ shortcut_cond_r (tree pred, tree *true_l
 build_and_jump (true_label_p),
 build_and_jump (false_label_p));
   SET_EXPR_LOCATION (expr, locus);
-  SET_EXPR_UID (expr, condition_uid);
+  tree_associate_condition_with_expr (expr, condition_uid);
 }
 
   if (local_label)
@@ -4523,13 +4546,13 @@ tag_shortcut_cond (tree pred, unsigned c
  || TREE_CODE (fst) == TRUTH_ORIF_EXPR)
tag_sh

Re: [PATCH] RISC-V: optimization on checking certain bits set ((x & mask) == val)

[Jeff Law]

On 12/6/24 6:12 AM, Oliver Kozul wrote:

The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.

2024-12-06  Oliver Kozul  

  PR target/114087

gcc/ChangeLog:

  * config/riscv/riscv.md (*lui_constraint_and_to_or): 
New pattern.


gcc/testsuite/ChangeLog:

  * gcc.target/riscv/pr114087-1.c: New test.

A few comments:



  
+(define_insn_and_split "*lui_constraint_and_to_or"

+  [(set (match_operand:ANYI 0 "register_operand" "=r")
+(plus:ANYI (and:ANYI (match_operand:ANYI 1 "register_operand" "r")
+(match_operand 2 "const_int_operand"))
+(match_operand 3 "const_int_operand")))
+(clobber (match_scratch:X 4 "=&r"))]
Similar formatting comment as I had on the other patch.  Easily fixed. 
Just for giggles I asked chatgpt to format it and it came up with:



(define_insn_and_split "*lui_constraint_and_to_or"
  [(set (match_operand:ANYI 0 "register_operand" "=r")
(plus:ANYI (and:ANYI (match_operand:ANYI 1 "register_operand" "r")
 (match_operand 2 "const_int_operand"))
   (match_operand 3 "const_int_operand")))
   (clobber (match_scratch:X 4 "=&r"))]
  "LUI_OPERAND (INTVAL (operands[2]) + 1)
   && (INTVAL (operands[2]) & (-INTVAL (operands[3]))) == (-INTVAL 
(operands[3]))"
  "#"
  "&& reload_completed"
  [(set (match_dup 4) (match_dup 5))
   (set (match_dup 0) (ior:X (match_dup 1) (match_dup 4)))
   (set (match_dup 4) (match_dup 6))
   (set (match_dup 0) (minus:X (match_dup 0) (match_dup 4)))]
  {
operands[5] = GEN_INT (~INTVAL (operands[2]));
operands[6] = GEN_INT ((~INTVAL (operands[2])) | (-INTVAL (operands[3])));
  }
  [(set_attr "type" "arith")])


Which looks basically correct.




More importantly we probably want a comment on what this pattern is 
actually doing.  Perhaps something like:


;; Transform (X & C1) + C2 into (X | ~C1) - (-C2 | ~C1)
;; Where C1 is not a LUI operand, but ~C1 is a LUI operand

Did I get that correct?




+  "LUI_OPERAND (INTVAL (operands[2]) + 1)
So shouldn't this have been LUI_OPERAND (~INTVAL (operands[2]))?  I can 
kind-of see why you used +1, but given the C fragment in the pattern 
uses ~operands[2], let's use the same here for the test if we can.






+  && (INTVAL (operands[2]) & (-INTVAL (operands[3])))
+  == (-INTVAL (operands[3]))"
Does it make sense to verify that operands[3] is a constant that 
requires synthesis and that ~INTVAL (operands[2]) | -INTVAL 
(operands[3]) is no more expensive to synthesize than operands[3]?


ie, saving the addi on the first constant isn't a win if the second 
constant gets more complex to synthesize.  The API isn't great, but you 
can use riscv_const_insns to find out how many instructions are 
necessary to synthesize a constant.



Overall it looks good.  Just needs a bit of polishing.

jeff

[PATCH] cobol: set SARIF "artifact.sourceLanguage" property

[David Malcolm]

With this patch, -fdiagnostics-format=sarif-stderr emits:

   "sourceLanguage": "cobol"

for its artifacts, as per Appendix J of the SARIF spec.

gcc/ChangeLog:
* cobol/cobol1.cc (cobol_get_sarif_source_language): New.
(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Set it to the above.

Signed-off-by: David Malcolm 
---
 gcc/cobol/cobol1.cc | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/cobol/cobol1.cc b/gcc/cobol/cobol1.cc
index 3819411edd3..5938c9a2c09 100644
--- a/gcc/cobol/cobol1.cc
+++ b/gcc/cobol/cobol1.cc
@@ -703,6 +703,14 @@ cobol_set_decl_assembler_name (tree decl)
 SET_DECL_ASSEMBLER_NAME (decl, id);
 }
 
+/* Get a value for the SARIF v2.1.0 "artifact.sourceLanguage" property,
+   based on the list in SARIF v2.1.0 Appendix J.  */
+
+const char *
+cobol_get_sarif_source_language(const char *)
+{
+return "cobol";
+}
 
 #undef LANG_HOOKS_BUILTIN_FUNCTION
 #undef LANG_HOOKS_GETDECLS
@@ -717,6 +725,7 @@ cobol_set_decl_assembler_name (tree decl)
 #undef LANG_HOOKS_TYPE_FOR_MODE
 #undef LANG_HOOKS_TYPE_FOR_SIZE
 #undef LANG_HOOKS_SET_DECL_ASSEMBLER_NAME
+#undef LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE
 
 #define LANG_HOOKS_NAME "Cobol"
 
@@ -737,6 +746,8 @@ cobol_set_decl_assembler_name (tree decl)
 
 #define LANG_HOOKS_SET_DECL_ASSEMBLER_NAME cobol_set_decl_assembler_name
 
+#define LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE cobol_get_sarif_source_language
+
 struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
 #include "gt-cobol-cobol1.h"
-- 
2.26.3

Re: [PATCH] RSIC-V: Fix ICE for unrecognizable insn `UNSPEC_VSETVL` for XTheadVector

[Jeff Law]

On 12/2/24 11:28 PM, Jin Ma wrote:

HI, Jeff

I am very sorry that I took so long to reply because I was ill and hospitalized.

So sorry to hear that, I hope you're feeling better.





+{
+  rtx tmp = gen_reg_rtx (Pmode);
+  /* Use UNSPEC to avoid being optimized before vsetvl pass.  */
+  emit_insn (gen_th_pred_vl_mov (Pmode, tmp, x));

Pmode seems wrong.  word_mode would likely be better.  That would mean
some adjustment to your new insn.

Additionally, I'd like to understand better why you can't just
   tmp = force_reg (word_mode, x);

Can you explain in more detail what you're trying to avoid?  ie, RTL
before/after the problematical optimization?  It feels like you're
papering over a bigger problem using the UNSPEC.


In fact, we inserted the vsetvl instruction in the "vsetvl" pass. Before it,
there will be many opportunities to eliminate the mov instruction we need,
such as "combine" pass or "reload" pass(curr_insn_transform), which will
eventually lead to vl in the vector pattern being an immediate instead of
a register. This will lead to only "vsetivli" being generated in the "vsetvl"
pass, which is obviously inconsistent with expectations. So we need a special
mov with UNSPEC to avoid it being optimized before the "vsetvl" pass.
I don't really follow.  The problem you've described above really should 
be fixed by making sure the vsetvl patterns reject constants for thead 
and we never try to directly generate a vsetvl with immediate operands. 
I don't see anything above which indicates why an UNSPEC would be needed.


jeff

Re: [PATCH v2] RISC-V: Fix ICE for unrecognizable insn `UNSPEC_VSETVL` for XTheadVector

[Jeff Law]

On 12/2/24 11:34 PM, Jin Ma wrote:

Since XTheadvector does not support vsetivli, vl needs to be put into
registers during the expand phase.

PR 116593

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins.cc 
(function_expander::add_input_operand):
Put const to GPR for vl.
* config/riscv/thead-vector.md (@th_pred_vl_mov): New.

gcc/testsuite/ChangeLog:

* g++.target/riscv/xtheadvector/pr116593.C: New test.
* g++.target/riscv/xtheadvector/xtheadvector.exp: New test.

Reported-by: nihui 
---
  gcc/config/riscv/riscv-vector-builtins.cc | 18 +++-
  gcc/config/riscv/thead-vector.md  | 13 ++
  .../g++.target/riscv/xtheadvector/pr116593.C  | 45 +++
  .../riscv/xtheadvector/xtheadvector.exp   | 37 +++
  4 files changed, 112 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.target/riscv/xtheadvector/pr116593.C
  create mode 100644 
gcc/testsuite/g++.target/riscv/xtheadvector/xtheadvector.exp

diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc
index b9b9d33adab6..cced0461a7bb 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -4089,7 +4089,23 @@ function_expander::add_input_operand (unsigned argno)
  {
tree arg = CALL_EXPR_ARG (exp, argno);
rtx x = expand_normal (arg);
-  add_input_operand (TYPE_MODE (TREE_TYPE (arg)), x);
+
+  /* Since the parameter vl of XTheadVector does not support
+ immediate numbers, we need to put it in the register
+ in advance.  */
+  if (TARGET_XTHEADVECTOR
+  && CONST_INT_P (x)
+  && base->apply_vl_p ()
+  && argno == (unsigned) (call_expr_nargs (exp) - 1)
+  && x != CONST0_RTX (GET_MODE (x)))
+{
+  rtx tmp = gen_reg_rtx (word_mode);
+  /* Use UNSPEC to avoid being optimized before vsetvl pass.  */
+  emit_insn (gen_th_pred_vl_mov (word_mode, tmp, x));
+  add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);
+}
+  else
+add_input_operand (TYPE_MODE (TREE_TYPE (arg)), x);
  }

So I would just do:


tmp = force_reg (word_mode, x);
add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);

In the thead specific code.  That generates the initial code correctly. 
At that point we just need to make sure nothing like combine, cprop, etc 
propagates the constant into the vsetvl.  The way to prevent that is 
with the operand predicates on the vsetvl insns.



jeff

libbacktrace patch committed: Avoid ZSTD_CLEVEL_DEFAULT

[Ian Lance Taylor]

PR 117812 reports a libbacktrace test failure when building with a
2018 version of zstd, because ZSTD_CLEVEL_DEFAULT is not defined.
This patch avoids using it, replacing it with the default value 3.
The test doesn't really care what compression level is used anyhow.
Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu.
Committed to mainline.

Ian

PR libbacktrace/117812
* zstdtest.c (test_large): Use 3 rather than ZSTD_CLEVEL_DEFAULT
3e343ef7f0ac0eb9e526b4f6d3bf3f69be3f0684
diff --git a/libbacktrace/zstdtest.c b/libbacktrace/zstdtest.c
index b9552ab1b88..eb572a24e52 100644
--- a/libbacktrace/zstdtest.c
+++ b/libbacktrace/zstdtest.c
@@ -379,8 +379,7 @@ test_large (struct backtrace_state *state ATTRIBUTE_UNUSED)
 }
 
   r = ZSTD_compress (compressed_buf, compressed_bufsize,
-orig_buf, orig_bufsize,
-ZSTD_CLEVEL_DEFAULT);
+orig_buf, orig_bufsize, 3);
   if (ZSTD_isError (r))
 {
   fprintf (stderr, "zstd compress failed: %s\n", ZSTD_getErrorName (r));

Re: [PATCH] cobol: set SARIF "artifact.sourceLanguage" property

[David Malcolm]

On Sat, 2024-12-14 at 19:20 -0500, David Malcolm wrote:
> With this patch, -fdiagnostics-format=sarif-stderr emits:
> 
>    "sourceLanguage": "cobol"
> 
> for its artifacts, as per Appendix J of the SARIF spec.
> 
> gcc/ChangeLog:
>   * cobol/cobol1.cc (cobol_get_sarif_source_language): New.
>   (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Set it to the above.
> 
> Signed-off-by: David Malcolm 
> 

That said, I hacked up one of the examples to get a syntax error, and
it looks like at least some (or all?) of the error-handling is going
through yyerror and some similar functions in parse_ante.h, which
bypasses gcc's diagnostic subsystem and instead uses fprintf.  Hence
none of this would make it into SARIF output.

Are the functions in parse_ante.h the only places where you're doing
errors and warnings, or are there any other internal APIs?  I could
take a look at porting them to gcc's diagnostic-core.h, I suppose.

Dave

[PATCH, part4] Fortran: fix passing of NULL() to assumed-rank, derived type dummy [PR104819]

[Harald Anlauf]

Dear all,

this patch is the 4th part of a series on the passing of NULL() to
assumed-rank dummies.  This one handles the case of a derived type
dummy and is mostly straightforward.

There was one particular problem I encountered: passing NULL() to
an allocatable dummy with no intent given.  This lead to an ICE
I could not resolve other than treating this the same as if an
intent(in) were given.  If someone has a better idea, I'd love
to learn about it...

Testcase cross-checked with Intel's ifx.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

P.S.: if someone would like to assist with the case of class
dummies, please let me know.

From bef5e605ee14c4db85c96a3b30a765669570cac0 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 14 Dec 2024 20:26:47 +0100
Subject: [PATCH] Fortran: fix passing of NULL() to assumed-rank, derived type
 dummy [PR104819]

	PR fortran/104819

gcc/fortran/ChangeLog:

	* interface.cc (compare_parameter): For the rank check, NULL()
	inherits the rank of a provided MOLD argument.
	(gfc_compare_actual_formal): Adjust check of NULL() actual argument
	against formal to accept F2008 enhancements (allocatable dummy).
	NULL() with MOLD argument retains a pointer/allocatable attribute.
	* trans-expr.cc (conv_null_actual): Implement passing NULL() to
	derived-type dummy with pointer/allocatable attribute, and ensure
	that the actual rank is passed to an assumed-rank dummy.
	(gfc_conv_procedure_call): Use it.

gcc/testsuite/ChangeLog:

	* gfortran.dg/null_actual_7.f90: New test.
---
 gcc/fortran/interface.cc|  42 +--
 gcc/fortran/trans-expr.cc   |  49 +++-
 gcc/testsuite/gfortran.dg/null_actual_7.f90 | 123 
 3 files changed, 203 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/null_actual_7.f90

diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index fd39c01653e..8730269b251 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2756,7 +2756,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   rank_check = where != NULL && !is_elemental && formal_as
 && (formal_as->type == AS_ASSUMED_SHAPE
 	|| formal_as->type == AS_DEFERRED)
-&& actual->expr_type != EXPR_NULL;
+&& !(actual->expr_type == EXPR_NULL
+	 && actual->ts.type == BT_UNKNOWN);

   /* Skip rank checks for NO_ARG_CHECK.  */
   if (formal->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
@@ -3230,6 +3231,7 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
   gfc_array_ref *actual_arr_ref;
   gfc_array_spec *fas, *aas;
   bool pointer_dummy, pointer_arg, allocatable_arg;
+  bool procptr_dummy, optional_dummy, allocatable_dummy;

   bool ok = true;

@@ -3382,15 +3384,33 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
 	  goto match;
 	}

+  /* Allow passing of NULL() as disassociated pointer, procedure
+	 pointer, or unallocated allocatable (F2008+) to a respective dummy
+	 argument.  */
+  pointer_dummy = ((f->sym->ts.type != BT_CLASS
+			&& f->sym->attr.pointer)
+		   || (f->sym->ts.type == BT_CLASS
+			   && CLASS_DATA (f->sym)->attr.class_pointer));
+
+  procptr_dummy = ((f->sym->ts.type != BT_CLASS
+			&& f->sym->attr.proc_pointer)
+		   || (f->sym->ts.type == BT_CLASS
+			   && CLASS_DATA (f->sym)->attr.proc_pointer));
+
+  optional_dummy = f->sym->attr.optional;
+
+  allocatable_dummy = ((f->sym->ts.type != BT_CLASS
+			&& f->sym->attr.allocatable)
+			   || (f->sym->ts.type == BT_CLASS
+			   && CLASS_DATA (f->sym)->attr.allocatable));
+
   if (a->expr->expr_type == EXPR_NULL
-	  && ((f->sym->ts.type != BT_CLASS && !f->sym->attr.pointer
-	   && (f->sym->attr.allocatable || !f->sym->attr.optional
-		   || (gfc_option.allow_std & GFC_STD_F2008) == 0))
-	  || (f->sym->ts.type == BT_CLASS
-		  && !CLASS_DATA (f->sym)->attr.class_pointer
-		  && (CLASS_DATA (f->sym)->attr.allocatable
-		  || !f->sym->attr.optional
-		  || (gfc_option.allow_std & GFC_STD_F2008) == 0
+	  && !pointer_dummy
+	  && !procptr_dummy
+	  && !(optional_dummy
+	   && (gfc_option.allow_std & GFC_STD_F2008) != 0)
+	  && !(allocatable_dummy
+	   && (gfc_option.allow_std & GFC_STD_F2008) != 0))
 	{
 	  if (where
 	  && (!f->sym->attr.optional
@@ -3589,7 +3609,9 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
 	  pointer_dummy = f->sym->attr.pointer;
 	}

-  if (a->expr->expr_type != EXPR_VARIABLE)
+  if (a->expr->expr_type != EXPR_VARIABLE
+	  && !(a->expr->expr_type == EXPR_NULL
+	   && a->expr->ts.type != BT_UNKNOWN))
 	{
 	  aas = NULL;
 	  pointer_arg = false;
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 3718b0e645b..21dfc167bd7 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6398,7 +6398,7 @@ conv_dummy_value (gfc_se * parmse, gfc_expr * e, gfc_symbol * f

Re: [PATCH] install.texi --enable-languages: add rust to the list of languages

[Arsen Arsenović]

Xi Ruoyao  writes:

> On Sat, 2024-12-14 at 15:11 +0100, Heiko Eißfeldt wrote:
>>  
>> ```grep ^language= */config-lang.in```
>> 
>> with the list from the doc
>> 
>> I noticed that the last addition rust was missing.
>
> I'm not sure if we want to expose it to all the users.  As at now the
> rust FE is still in early development and it's not useful for compiling
> any real rust programs.

That might've been why it was omitted in the first place - CCing in
gcc-rust@ to see if anyone knows (in either case, it'd be worth adding a
comment so that in future it is easy to tell).
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: The COBOL front end, in 8 notes

[Eric Gallager]

On Sat, Dec 14, 2024 at 8:09 AM Iain Sandoe  wrote:
>
>
>
> > On 14 Dec 2024, at 11:56, Iain Sandoe  wrote:
> >
> >
> >
> >> On 14 Dec 2024, at 10:11, Sam James  wrote:
> >>
> >> David Malcolm  writes:
> >>
> >>> On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:
>  The following 8 patches constitute the 80 files needed to build and
>  document the COBOL front end.  They assume that following exist:
> 
> gcc/cobol/ChangeLog
> libgcobol/ChangeLog
> 
>  The messages are grouped by files in a more or less logical order,
>  but groups are somewhat arbitrary.  The primary constraint afaik is
>  to
>  keep them from getting too big, fsvo $too.  We have:
> 
> 460K hdr  header files
> 484K par  the parser
> 760K gen  GENERIC interface
> 556K cbl  other supporting C++ files
> 432K cfg  libgcobol/configure
> 788K lib  libgcobol, all of it
>  72K doc  man pages, for now
>  24K bld  "meta" files, such a gcc/cobol/Make-lang.in
> 
>  Except for "bld", these all contain new files, can be applied in any
>  order.
> 
>  If you would like the patches smaller or larger, I'm happy to
>  rearrange
>  them.  Some of exceed the 400 KB mail limit, but I'm assured they'll
>  be
>  moderated through.
> 
>  This patchset excludes tests.  While we do have tests, it's not clear
>  how or if to add them to gcc.  They use a combination of (largely)
>  3rd
>  party sources and GNU Autotest.
> 
>  A word about C style, always a lively topic.  For any files already
>  present in gcc, the existing style was followed, and any variation
>  from
>  it is unintentional.  Files related to the parser use K&R style.  The
>  GENERIC interface and runtime library use Whitesmiths style.  All C++
>  code uses spaces for indentation.
> 
>  The COBOL front end has been and is being written by two guys with
>  decades of experience.  We hope the code is a testament to that
>  experience.  Our relatively recent experience, these last four years,
>  is that it has been more productive to keep using the styles to which
>  we've long become accustomed.  The position of curly braces is hardly
>  any hindrance to read another's code, but it's a burden to write that
>  way. We think, 83,068 lines later, the proof of the pudding is in the
>  eating.
> 
>  Thank you for your kind consideration of our work.
> >>>
> >>> Please forgive me if you've already said this elsewhere, but is this
> >>> work available in a public git repo somewhere?
> >>>
> >>
> >> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
> >
> > But (IIUC) this is the development branch; what would be ideal would be
> > a branch with just the 8 patches.
> >
> > 
> >
> > NOTE0 : the decision to use different whitespace rules from the rest of GCC
> > means the that patches apply only with a very large number of whitespace
> > errors .. which might be fine - but, of course, you cannot now tell 
> > intentional
> > whitespace errors from actual mistakes ….
> >
> > NOTE1 : patch 8 did not apply for me without editing - there seems to be a
> > duplicate of gcc/cobol/config-lang.in in patches 4 and 8.
> >
> > NOTE2 :  the top level Makefile.in needs to be regenerated.
> >
> > Will try this on  Darwin - (I removed the config-lang.in from patch 8 and
> > regenerated the top level Makefile.in) - hopefully the patch 4 
> > config-lang.in
> > is OK to use.
> >
> > Is it intentional that this requires bison at build-time or is there a 
> > missing
> > “touch” for some generated file?
>
> OK so, unfortunately, this does not build on Darwin/macOS.
>
> It seems
> 1) to introduce new build dependencies on:
>   - bison (we normally commit generated files to the repo not expect the 
> end-user
>to need bison installed).
>   - a version of gm4 that recognises —gnu
>

Note that if this is due to what I think it is, it corresponds to this
bug in upstream autoconf: https://savannah.gnu.org/support/?39

>  perhaps this is an oversight and the generated files can be committed ?
>
>  if not ... neither of these tools exist in the Xcode installs that most 
> macOS users have,
>  so that they will need to build them before they can configure GCC 
> —enable-languages=all
>
> 2) the build then failed for me with …
>
> /src-local/gcc-master/gcc/cobol/symbols.h:66:39: error: missing binary 
> operator before token ‘(’
>66 | #if ! (__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT))
>
> ** You cannot assume that all targets have glibc - e.g. Darwin has it’s own 
> libc, others might
> use muscl etc.
>
> I can hack around this .. but then I get lots more errors ..
>
> /src-local/gcc-master/gcc/cobol/copybook.h:50:40: error: ‘ino_t’ has not been 
> declared; did you mean ‘wint_t’?
>50 | bool cobol_filename( const char *name, ino_t inode );
>
>  from

Re: [PATCH v3] match.pd: Add pattern to simplify `(a - 1) & -a` to `0`

[Jeff Law]

On 12/3/24 3:28 AM, Jovan Vukic wrote:

Thank you for the feedback. I have made the minor changes that were requested.
Additionally, I extracted the repetitive code into a reusable helper function,
match_plus_neg_pattern, making the code much more readable. Furthermore, the
logic, code, and tests remain the same as in version 2 of the patch.

2024-12-03  Jovan Vukic

gcc/ChangeLog:

 * match.pd: New pattern.
 * simplify-rtx.cc (match_plus_neg_pattern): New helper function.
 (simplify_context::simplify_binary_operation_1): New
 code to handle (a - 1) & -a, (a - 1) | -a and (a - 1) ^ -a.

gcc/testsuite/ChangeLog:

 * gcc.dg/tree-ssa/bitops-11.c: New test.
Thanks.  I didn't see any note about testing, so I did the usual 
bootstrap & regression test on x86_64 without any issues.


Pushed to the trunk..  Thanks again!

jeff

Re: [PATCH] Fix non-aligned CodeView symbols

[Jeff Law]

On 12/1/24 3:30 PM, Mark Harmstone wrote:

CodeView symbols in PDB files are aligned to four-byte boundaries. It's
not really clear what logic MSVC uses to enforce this; sometimes the
symbols are padded in the object file, sometimes the linker seems to do
the work.

It makes more sense to do this in the compiler, so fix the two instances
where we can write symbols with a non-aligned length. S_FRAMEPROC is
unusually not a multiple of 4, so will always have 2 bytes padding.
S_INLINESITE is followed by variable-length "binary annotations", so
will also usually have padding.

gcc/
* dwarf2codeview.cc (write_s_frameproc): Align output.
(write_s_inlinesite): Align output.

OK
jeff

Re: The COBOL front end, in 8 notes

[David Malcolm]

On Sat, 2024-12-14 at 18:34 -0500, David Malcolm wrote:
> On Sat, 2024-12-14 at 10:11 +, Sam James wrote:
> > David Malcolm  writes:
> > 
> > > On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:
> 
> [...]
> 
> > > > 
> > > > Thank you for your kind consideration of our work.
> > > 
> > > Please forgive me if you've already said this elsewhere, but is
> > > this
> > > work available in a public git repo somewhere?
> > > 
> > 
> > https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
> > 
> > 
> 
> Thanks Sam.  I was able to clone and build from that repo on x86_64-
> pc-
> linux-gnu (building with gcc 10) and have now compiled my first ever
> COBOL program!
> 

[...snip...]

> Taking it for a test-drive; thanks!
> Dave


James:

Looking at
  ./gcobol --version
I see:
  gcobol (GCC) 15.0.0 20240828 (experimental)
which makes it look like the last time you refreshed your branch from
master was 3.5 months ago.

Looking in your git repo here:
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/commit/6fc49cbd858adfbd689ebe45eb631a4eacbc9288
I see:

Merge remote-tracking branch 'gnu-gcc/trunk' into bobdev
parents 5d165a3d 898f013e

so it looks like
  898f013e195fa828bb30ae6ba4ad50abbd804fbd
aka:
  r15-3264-g898f013e195fa8
is the most recent commit on master that this work is based on top of,
unless I missed a later merge.

Is that the baseline that the patches you sent was based on?  It's
probably a good idea to do a refresh before the next iteration of the
patches, given that we're now on r15-6258-g3e343ef7f0ac0e i.e. almost
3000 commits later (this is the output of ./contrib/git-descr.sh , in
case you're not familiar with this tool, which gives us nice sequential
numbering for commits).

Hope this is helpful
Dave

Re: The COBOL front end, in 8 notes

[David Malcolm]

On Sat, 2024-12-14 at 10:11 +, Sam James wrote:
> David Malcolm  writes:
> 
> > On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote:

[...]

> > > 
> > > Thank you for your kind consideration of our work.
> > 
> > Please forgive me if you've already said this elsewhere, but is
> > this
> > work available in a public git repo somewhere?
> > 
> 
> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
> 
> 

Thanks Sam.  I was able to clone and build from that repo on x86_64-pc-
linux-gnu (building with gcc 10) and have now compiled my first ever
COBOL program!

Caveat: I had to hack up the %require in parse.y since I only have
bison 3.5 (not 3.5.1) on the machine I'm testing it on.

James: does your testing include bootstrap builds?

I got this false positive in the build:

../../src/gcc/cobol/genapi.cc: In function ‘void move_helper(tree,
cbl_refer_t, cbl_refer_t, TREEPLET&, cbl_round_t, bool, bool)’:
../../src/gcc/cobol/genapi.cc:15332:16: warning: ‘st_size’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
15332 |   gg_memcpy(st_data,
  |   ~^
15333 | stash,
  | ~~
15334 | st_size);
  | 
../../src/gcc/cobol/genapi.cc:15332:16: warning: ‘st_data’ may be used
uninitialized in this function [-Wmaybe-uninitialized]

due to my gcc not being smart enough to see that the usage of st_data
and st_size there is guarded by restore_on_error, which also guards the
initialization above.

You may want to apply this trivial fix to placate older C++ compilers:

diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index c9f146df41f..af4efcecebb 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -15077,8 +15077,8 @@ move_helper(tree size_error,// This is an INT
 
   static tree stash = gg_define_variable(UCHAR_P, "..mh_stash", 
vs_file_static);
 
-  tree st_data;
-  tree st_size;
+  tree st_data = NULL_TREE;
+  tree st_size = NULL_TREE;
 
   if( restore_on_error )
 {

...since otherwise the build might fail on a bootstrap build (which
IIRC uses -Werror on the later stages).


Taking it for a test-drive; thanks!
Dave

[PATCH] cobol: regenerate lang.opt.urls

[David Malcolm]

I went ahead and ran regenerate-opt-urls.py on a clone
of the cobol repo; here's the resulting change.

gcc/ChangeLog:
* cobol/lang.opt.urls: Regenerate.

Signed-off-by: David Malcolm 
---
 gcc/cobol/lang.opt.urls | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/gcc/cobol/lang.opt.urls b/gcc/cobol/lang.opt.urls
index 40ee30e725e..7f527d73564 100644
--- a/gcc/cobol/lang.opt.urls
+++ b/gcc/cobol/lang.opt.urls
@@ -1,30 +1,30 @@
-; Copied by Dubner from gcc/rust/ so that compilation could proceed
-; Autogenerated by regenerate-opt-urls.py from gcc/rust/lang.opt and generated 
HTML
+; Autogenerated by regenerate-opt-urls.py from gcc/cobol/lang.opt and 
generated HTML
+
+D
+UrlSuffix(gcc/Preprocessor-Options.html#index-D-1)
+
+; skipping UrlSuffix for 'E' due to multiple URLs:
+;   duplicate: 'gcc/Link-Options.html#index-E-1'
+;   duplicate: 'gcc/Overall-Options.html#index-E'
 
 I
 UrlSuffix(gcc/Directory-Options.html#index-I) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-I)
 
-L
-UrlSuffix(gcc/Directory-Options.html#index-L) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-L)
-
-; skipping UrlSuffix for 'Wall' due to multiple URLs:
-;   duplicate: 'gcc/Standard-Libraries.html#index-Wall-1'
-;   duplicate: 'gcc/Warning-Options.html#index-Wall'
-Wall
-LangUrlSuffix_D(gdc/Warnings.html#index-Wall)
+fsyntax-only
+UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only)
 
-Wunused-variable
-UrlSuffix(gcc/Warning-Options.html#index-Wno-unused-variable)
+fmax-errors
+UrlSuffix(gcc/Warning-Options.html#index-fmax-errors) 
LangUrlSuffix_D(gdc/Warnings.html#index-fmax-errors)
 
-Wunused-const-variable
-UrlSuffix(gcc/Warning-Options.html#index-Wno-unused-const-variable)
+iprefix
+UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
 
-Wunused-const-variable=
-UrlSuffix(gcc/Warning-Options.html#index-Wno-unused-const-variable)
+include
+UrlSuffix(gcc/Preprocessor-Options.html#index-include)
 
-Wunused-result
-UrlSuffix(gcc/Warning-Options.html#index-Wno-unused-result)
+isysroot
+UrlSuffix(gcc/Directory-Options.html#index-isysroot)
 
-o
-UrlSuffix(gcc/Overall-Options.html#index-o)
+isystem
+UrlSuffix(gcc/Directory-Options.html#index-isystem)
 
-- 
2.26.3

Re: [PATCH] Shrink back size of tree_exp from 40 bytes to 32

[Jeff Law]

On 12/14/24 5:16 PM, Jakub Jelinek wrote:

Hi!

The following patch implements what I've mentioned in the 64-bit
location_t thread.
struct tree_exp had unsigned condition_uid member added for something
rarely used (-fcondition-coverage) and even there used only on very small
subset of trees only for the duration of the gimplification.

The following patch uses a hash_map instead, which allows shrinking
tree_exp to its previous size (32 bytes + (number of operands - 1) * sizeof
(tree)).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-12-14  Jakub Jelinek  

* tree-core.h (struct tree_exp): Remove condition_uid member.
* tree.h (SET_EXPR_UID, EXPR_COND_UID): Remove.
* gimplify.cc (nextuid): Rename to ...
(nextconduid): ... this.
(cond_uids): New static variable.
(next_cond_uid, reset_cond_uid): Adjust for the renaming,
formatting fix.
(tree_associate_condition_with_expr): New function.
(shortcut_cond_r, tag_shortcut_cond, shortcut_cond_expr): Use it
instead of SET_EXPR_UID.
(gimplify_cond_expr): Look up cond_uid in cond_uids hash map if
non-NULL instead of using EXPR_COND_UID.
(gimplify_function_tree): Delete cond_uids and set it to NULL.
OK.  I didn't even realize we'd put something specific to condition 
coverage into tree_exp.


Naturally I wonder if there are other items in the tree or RTL 
structures that we could handle in a similar manner.  Future work obviously.


jeff