[GSoC] Conflicted Built-in Trait Name

[Ken Matsui via Gcc]

Hi,

I am working on the GSoC project, "C++: Implement compiler built-in
traits for the standard library traits".

Built-in trait naming simply adds two underscores (__) to the original
trait name. However, the same names are already in use for some
built-in traits, such as is_void, is_pointer, and is_signed.

For example, __is_void is used in the following files:

* gcc/testsuite/g++.dg/tm/pr46567.C
* libstdc++-v3/include/bits/cpp_type_traits.h

In this case, are we supposed to change the existing same name in the
code to something like is_void (four underscores)? Or is it better
to break the naming convention of built-in traits like
__is_void_builtin?

Sincerely,
Ken Matsui

Re: [GSoC] Conflicted Built-in Trait Name

[Roy Jacobson via Gcc]

Clang has been providing __is_void for a very long time now, and is
definitely compatible with libstdc++. Does defining this builtin cause a
problem? Might be that the lookup rules for builtins are different or
something.

https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives

On Sat, 25 Mar 2023 at 15:08, Ken Matsui via Gcc  wrote:

> Hi,
>
> I am working on the GSoC project, "C++: Implement compiler built-in
> traits for the standard library traits".
>
> Built-in trait naming simply adds two underscores (__) to the original
> trait name. However, the same names are already in use for some
> built-in traits, such as is_void, is_pointer, and is_signed.
>
> For example, __is_void is used in the following files:
>
> * gcc/testsuite/g++.dg/tm/pr46567.C
> * libstdc++-v3/include/bits/cpp_type_traits.h
>
> In this case, are we supposed to change the existing same name in the
> code to something like is_void (four underscores)? Or is it better
> to break the naming convention of built-in traits like
> __is_void_builtin?
>
> Sincerely,
> Ken Matsui
>

Re: [GSoC] Conflicted Built-in Trait Name

[Marc Glisse via Gcc]

On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:


Built-in trait naming simply adds two underscores (__) to the original
trait name. However, the same names are already in use for some
built-in traits, such as is_void, is_pointer, and is_signed.

For example, __is_void is used in the following files:

* gcc/testsuite/g++.dg/tm/pr46567.C


This is a testcase, you can rename __is_void to whatever in there, it 
doesn't matter.



* libstdc++-v3/include/bits/cpp_type_traits.h


This __is_void seems to be used in a single place in 
include/debug/helper_functions.h, couldn't we tweak that code so __is_void 
becomes unused and can be removed?


--
Marc Glisse

Website https://gcc.gnu.org/ down

[Damian Tometzki]

Hello together,

the website and git https://gcc.gnu.org/ is down ?

Any info about it ?

best regards
Damian

Re: The macro STACK_BOUNDARY may overflow

[Jeff Law via Gcc]

On 3/24/23 07:48, Paul Iannetta via Gcc wrote:

Hi,

Currently, the macro STACK_BOUNDARY is defined as

   Macro: STACK_BOUNDARY
  Define this macro to the minimum alignment enforced by hardware for
  the stack pointer on this machine.  The definition is a C
  expression for the desired alignment (measured in bits).  This
  value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not
  defined.  On most machines, this should be the same as
  'PARM_BOUNDARY'.

with no mentions about its type and bounds.  However, at some point, the value
of this macro gets assigned to the field "regno_pointer_align" of "struct
emit_status" which points to an "unsigned char", hence if STACK_BOUNDARY gets
bigger than 255, it will overflow...  Thankfully, the backend which defines the
highest value is microblaze with 128 < 255.

The assignment happens in "emit-rtl.c" through the REGNO_POINTER_ALIGN macro:

in function.h:
   #define REGNO_POINTER_ALIGN(REGNO) (crtl->emit.regno_pointer_align[REGNO])
in emit-rtl.cc:
   REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM) = STACK_BOUNDARY;
   [...]
   REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY;

Would it be possible to, either add an explicit bound to STACK_BOUNDARY in the
manual, and/or use an "unsigned int *" rather than and "unsigned char *" for
the field "regno_pointer_align".
Feel free to send a suitable patch to gcc-patches.  THe alignment data 
isn't held in the RTX structures, so it's not critical that it be kept 
as small as possible.  We don't want to waste space, so an unsigned 
short might be better.  A char was good for 30 years, so we don't need 
to go crazy here.


The alternative would be to change the representation to store the log2 
of the alignment.  That would be a much larger change and would trade 
off runtime for memory consumption.  I would have suggested this 
approach if the data were in the RTX structures amd space at a premium.


While I do see a trend in processor design to reduce/remove the 
misalignment penalties (thus eliminating the driver for increasing data 
alignment), that's been primarily in high end designs.


jeff

Re: Website https://gcc.gnu.org/ down

[Mark Wielaard]

Hi Damian,

On Sat, Mar 25, 2023 at 07:30:14AM +0100, Damian Tometzki wrote:
> the website and git https://gcc.gnu.org/ is down ?
> 
> Any info about it ?

The site isn't down, but there is an issue (ddos?) with the fsf dns
servers for gnu.org. The FSF tech team announces downtime and
temporary issues with their network at
https://hostux.social/@fsfstatus or
https://hostux.social/@fsfstatus.rss

gcc.gnu.org is hosted at sourceware.org so if dns doesn't resolve for
you, you might be able to add the following addresses to your
/etc/hosts file:

8.43.85.97 gcc.gnu.org
2620:52:3:1:0:246e:9693:128c gcc.gnu.org

If you need access to git then you might also be able to clone the
repository through git clone https://sourceware.org/git/gcc.git

There is also the sourceware git backups at sourcehut:
https://sr.ht/~sourceware/gcc/

Cheers,

Mark

[GSoC] Interest and initial proposal for project on reimplementing cpychecker as -fanalyzer plugin

[Eric Feng via Gcc]

Hi GCC community,

For GSoC, I am extremely interested in working on the selected project
idea with respect to extending the static analysis pass. In
particular, porting gcc-python-plugin's cpychecker to a plugin for GCC
-fanalyzer as described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646. Please find an
initial draft of my proposal below and let me know if it is a
reasonable starting point. Please also correct me if I am
misunderstanding any particular tasks and let me know what areas I
should add more information for or what else I may do in preparation.

___

Describe the project and clearly define its goals:
One pertinent use case of the gcc-python plugin is as a static
analysis tool for CPython extension modules. The main goal is to help
programmers writing extensions identify common coding errors. Broadly,
the goal of this project is to port the functionalities of cpychecker
to a -fanalyzer plugin.

Below is a brief description of the functionalities of the static
analysis tool for which I will work on porting over to a -fanalyzer
plugin. The structure of the objectives is taken from the
gcc-python-plugin documentation:

Reference count checking: Manipulation of PyObjects is done via the
CPython API and in particular with respect to the objects' reference
count. When the reference count belonging to an object drops to zero,
we should free all resources associated with it. This check helps
ensure programmers identify problems with the reference count
associated with an object. For example, memory leaks with respect to
forgetting to decrement the reference count of an object (analogous to
malloc() without corresponding free()) or perhaps object access after
the object's reference count is zero (analogous to access after
free()).

Error-handling checking: Various checks for common errors such as
dereferencing a NULL value.

Errors in exception-handling: Checks for situations in which functions
returning PyObject* that is NULL are not gracefully handled.

Format string checking: Verify that arguments to various CPython APIs
which take format strings are correct.

Associating PyTypeObject instances with compile-time-types: Verify
that the run-time type of a PyTypeObject matches its corresponding
compile-time type for inputs where both are provided.

Verification of PyMethodDef tables: Verify that the function in
PyMethodDef tables matches the calling convention of the ml_flags set.

I suspect a good starting point would be existing proof-of-concept
-fanalyzer plugins such as the CPython GIL example
(analyzer_gil_plugin). Please let me know of any additional pointers.
If there is time to spare, I think it is reasonable to extend the
capabilities of the original checker as well (more details in the
expected timeline below).

Provide an expected timeline:
I suspect the first task to take the longest since it is relatively
involved and it also includes getting the initial infrastructure of
the plugin up. From the experience of the first task, I hope the rest
of the tasks would be implemented faster. Additionally, I understand
that the current timeline outline below is too vague. I wished to
check in with the community for some feedback on whether I am in the
right ballpark before committing to more details.

Week 1 - 7: Reference counting checking
Week 8: Error-handling checking
Week 9: Errors in exception handling
Week 10: Format string checking
Week 11: Verification of PyMethodDef tables
Week 12: I am planning the last week to be safety in case any of the
above tasks take longer than initially expected. In case everything
goes smoothly and there is time to spare, I think it is reasonable to
spend the time extending the capabilities of the original pass. Some
ideas include extending the subset of CPython API that cpychecker
currently support, matching up similar traces to solve the issue of
duplicate error reports, and/or addressing any of the other caveats
currently mentioned in the cpychecker documentation. Additional ideas
are welcome of course.

Briefly introduce yourself and your skills and/or accomplishments:
I am a current Masters in Computer Science student at Columbia
University. I did my undergraduates at Bates College (B.A Math) and
Columbia University (B.S Computer Science) respectively. My interests
are primarily in systems, programming languages, and compilers.

At Columbia, I work in the group led by Professor Stephen Edwards on
the SSLANG programming language: a language built atop the Sparse
Synchronous Model. For more formal information on the Sparse
Synchronous Model, please take a look at "The Sparse Synchronous Model
on Real Hardware" (2022). Please find our repo, along with my
contributions, here: https://github.com/ssm-lang/sslang (my GitHub
handle is @efric). My main contribution to the compiler so far
involved adding a static inlining optimization pass with another
SSLANG team member. Our implementation is mostly based on the work
shown in "Secrets of the Glasgow Haskel

gcc-12-20230325 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 495bf0455b0ea55f6d7ce8d38ee3ae011af2fa96

You'll find:

 gcc-12-20230325.tar.xz   Complete GCC

  SHA256=36c0102296875e79e1bf2b1d4917e5f01ee29000ab358e7ad8b34b9667142f89
  SHA1=698421ac88737d1834ce24a0e2596ad8f58a06fc

Diffs from 12-20230318 are available in the diffs/ subdirectory.

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

Re: Building gcc-12 on MacOS Ventura (aarch64)

[Chris Johns]

On 25/3/2023 11:08 am, Stuff Received wrote:
> On 2023-03-24 19:51, Chris Johns wrote:
>> On 25/3/2023 10:07 am, Jonathan Wakely wrote:
>>> On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, >> > wrote:
>>>  On Fri, 24 Mar 2023, 23:03 Chris Johns, >>  > wrote:
>>>
>>>  Hi,
>>>
>>>  I am sorting out some issues building RTEMS on MacOS including the 
>>> M
>>>  processors.
>>>  The building gcc-12.2.1 for the few architectures I tested fail 
>>> with
>>> sig
>>>  faults
>>>  in xgcc when building the runtime. I tried arm, aarch64 and sparc. 
>>> As a
>>>  result I
>>>  wondered about bootstrapping gcc and using that to build the tools
>>>  rather than
>>>  clang from Xcode.
>>>
>>>  Is aarch64-apple-darwin supported?
>>>
>>>  No. Iain Sandoe has some personal branches with changes to support it, 
>>> but
>>>  the changes are not in the official gcc repo yet. If you search the
>>>  gcc-h...@gcc.gnu.org  list you'll find
>>> links to
>>>  his code. I think Homebrew is his patches too.
>>>
>>> *uses his patches too.
>>>
>>
>> I tried Iain's repo and it fails in the same way.
>>
>> I have been building the tools on MacOS for over a decade with just the Apple
>> base to make sure we have a clean platform without any issues. To do that I
>> avoid MacPorts and Homebrew. I am fine with our users making use of those
>> packages however knowing a build works with just the Apple support makes our
>> support simpler.
>>
>> Chris
> 
> I am able to build gcc from Iain's repo gcc-darwin-arm64 on an M1 Mini, 
> running
> macos 11.3.1, using the following configuration.  (Change your language
> preferences accordingly.)  I used make -j4.
> 
> CC=/opt/homebrew/bin/gcc-12 \
> CXX=/opt/homebrew/bin/g++-12 \
> ../../src/gcc-darwin-arm64/configure \
> --prefix=$HOME/gm2/arm64 \
> --exec-prefix=$HOME/gm2/arm64 \
> --enable-languages=c,c++,m2 \
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk \
> --with-mpc=/opt/homebrew \
> --with-gmp=/opt/homebrew \
> --with-mpfr=/opt/homebrew \
> --disable-bootstrap \
> --enable-threads=posix
> 
> However, you must first define HAVE_FCNTL_H to 1 in libiberty/config.h (that 
> is
> missed somehow by configure).

Thanks for this. It was helpful.

I installed homebrew and the `gcc` package and updated the RTEMS RSB to use
homebrew if installed. I can build RTEMS tools:

% /Users/chris/development/rtems/6/bin/sparc-rtems6-gcc --version
sparc-rtems6-gcc (GCC) 12.2.1 20230224 (RTEMS 6, RSB
f0e34eab8bf33b833a7d9d0b2bddd3b89f6d83cb-modified, Newlib 17ac400)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% file /Users/chris/development/rtems/6/bin/sparc-rtems6-gcc
/Users/chris/development/rtems/6/bin/sparc-rtems6-gcc: Mach-O 64-bit executable
arm64

This will work for us. Thanks to those who responded.

Chris

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui via Gcc]

On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse  wrote:
>
> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
>
> > Built-in trait naming simply adds two underscores (__) to the original
> > trait name. However, the same names are already in use for some
> > built-in traits, such as is_void, is_pointer, and is_signed.
> >
> > For example, __is_void is used in the following files:
> >
> > * gcc/testsuite/g++.dg/tm/pr46567.C
>
> This is a testcase, you can rename __is_void to whatever in there, it
> doesn't matter.
>
> > * libstdc++-v3/include/bits/cpp_type_traits.h
>
> This __is_void seems to be used in a single place in
> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> becomes unused and can be removed?

That worked. Thank you!

So, we can remove a code in a header as long as it is not standard and
is not used elsewhere, can't we?