Re: [PATCH] libgcc: Update 'gthr-mcf.h' to include a dedicated header for libobjc

[Jonathan Yong via Gcc-patches]

On 10/22/22 11:54, LIU Hao wrote:
This allows building libobjc and enabling Objective-C. Tested against 
GCC 12 branch on i686-w64-mingw32.





Done, pushed to master branch.

Re: Adding a new thread model to GCC

[NightStrike via Gcc-patches]

On Fri, Oct 21, 2022 at 8:33 AM Jacek Caban via Gcc-patches
 wrote:
>
> On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
> >>>/How does this compare with Eric B's proposal at 
> >>>/>>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? 
> >>>/>>//>>/My proposal was to reimplement (and extend) the native thread 
> >>>model />>/(win32) />>/instead of adding a new one, the advantage being 
> >>>that you don't need an />>/extra />/> threading layer between GCC and 
> >>>Windows. />
> > I agree!
>
> I agree as well and I expressed that on mingw-w64 ML when the patch was 
> introduced [1]. My main concern with the new threading model is that instead 
> of solving root of the problem, it introduces more fragmentation with no 
> clear benefit.
>
> On top of that, mcfgthread library is way more invasive than it needs to be. 
> It requires maintaining per-thread struct and reimplements a number of things 
> instead of leveraging OS capabilities. Author also plans to make invasive 
> changes to mingw-w64-crt, which go against it current approach of being 
> agnostic to threading model.
>
> Jacek
>
> [1] https://sourceforge.net/p/mingw-w64/mailman/message/37719727/

FWIW, Eric's proposal makes more practical sense.  Right now, people
ship many permutations of the compiler:
x86, x64, x86+x64
dw2, sjlj (rarely), seh
win32, posix+winpthread

This is not sustainable, and certain combinations are largely
incompatible (which makes for instance providing a windows release of
MySpecialLibrary.dll confusing).  We used to have a matrix of
combinations on the website, but I see that that's no longer present.
In any case, it took a long time for sjlj to fall out of vogue (maybe
old habits die hard?).  That implies, to me, that winpthreads
similarly won't be deprecated, it'll just be yet another set of
archives to download and confuse people with.

[committed] wwwdocs: index: Rotate news from 2018-08 to 2020-12

[Gerald Pfeifer]

Pushed.

Gerald

---
 htdocs/index.html | 68 ---
 htdocs/news.html  | 68 +++
 2 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/htdocs/index.html b/htdocs/index.html
index 39060016..f45b9664 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -103,74 +103,6 @@ mission statement.
 [2021-04-08] wwwdocs:
 
 
-GCC 10.2 released
-[2020-07-23] wwwdocs:
-
-
-https://gcc.gnu.org/wiki/linuxplumbers2020;>GNU Tools @ 
Linux Plumbers Conference 2020
-[2020-07-17] wwwdocs:
-Will be held online, August 24-28 2020
-
-GCC 10.1 released
-[2020-05-07] wwwdocs:
-
-
-GCC 9.3 released
-[2020-03-12] wwwdocs:
-
-
-GCC 8.4 released
-[2020-03-04] wwwdocs:
-
-
-GCC source repository converted to git.
-[2020-01-13] wwwdocs:
-See the https://gcc.gnu.org/ml/gcc/2020-01/msg00204.html;>announcement.
-
-GCC 7.5 released
-[2019-11-14] wwwdocs:
-
-
-eBPF support
- [2019-10-23] wwwdocs:
-GCC support for the Linux eBPF has been added.  This back end was
-  contributed by Jose E. Marchesi on behalf of Oracle.
-
-GCC 9.2 released
-[2019-08-12] wwwdocs:
-
-
-PRU support
- [2019-06-12] wwwdocs:
- GCC support for TI PRU I/O processors has been added.
-
-GCC 9.1 released
-[2019-05-03] wwwdocs:
-
-
-https://gcc.gnu.org/wiki/cauldron2019;>GNU Tools Cauldron 
2019
-[2019-04-15] wwwdocs:
-Will be held in Montr??al, Canada, September 12-15 2019
-
-GCC 8.3 released
-[2019-02-22] wwwdocs:
-
-
-AMD GCN support
-[2019-01-17] wwwdocs:
-GCC support for AMD GCN Fiji and Vega GPUs has been added.  This back
-  end was contributed by Mentor Graphics.
-
-GCC 7.4 released
-[2018-12-06] wwwdocs:
-
-
-D front end added
- [2018-10-29] wwwdocs:
- The https://dlang.org;>D programming language front end
-   has been added to GCC.
-   This front end was contributed by Iain Buclaw.
-
 
 
 
diff --git a/htdocs/news.html b/htdocs/news.html
index fb27c64f..e1384852 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -17,6 +17,74 @@
 
 
 
+GCC 10.2 released
+[2020-07-23] wwwdocs:
+
+
+https://gcc.gnu.org/wiki/linuxplumbers2020;>GNU Tools @ 
Linux Plumbers Conference 2020
+[2020-07-17] wwwdocs:
+Will be held online, August 24-28 2020
+
+GCC 10.1 released
+[2020-05-07] wwwdocs:
+
+
+GCC 9.3 released
+[2020-03-12] wwwdocs:
+
+
+GCC 8.4 released
+[2020-03-04] wwwdocs:
+
+
+GCC source repository converted to git.
+[2020-01-13] wwwdocs:
+See the https://gcc.gnu.org/ml/gcc/2020-01/msg00204.html;>announcement.
+
+GCC 7.5 released
+[2019-11-14] wwwdocs:
+
+
+eBPF support
+ [2019-10-23] wwwdocs:
+GCC support for the Linux eBPF has been added.  This back end was
+  contributed by Jose E. Marchesi on behalf of Oracle.
+
+GCC 9.2 released
+[2019-08-12] wwwdocs:
+
+
+PRU support
+ [2019-06-12] wwwdocs:
+ GCC support for TI PRU I/O processors has been added.
+
+GCC 9.1 released
+[2019-05-03] wwwdocs:
+
+
+https://gcc.gnu.org/wiki/cauldron2019;>GNU Tools Cauldron 
2019
+[2019-04-15] wwwdocs:
+Will be held in Montr??al, Canada, September 12-15 2019
+
+GCC 8.3 released
+[2019-02-22] wwwdocs:
+
+
+AMD GCN support
+[2019-01-17] wwwdocs:
+GCC support for AMD GCN Fiji and Vega GPUs has been added.  This back
+  end was contributed by Mentor Graphics.
+
+GCC 7.4 released
+[2018-12-06] wwwdocs:
+
+
+D front end added
+ [2018-10-29] wwwdocs:
+ The https://dlang.org;>D programming language front end
+   has been added to GCC.
+   This front end was contributed by Iain Buclaw.
+
 GCC 6.5 released
 [2018-10-26] wwwdocs:
 
-- 
2.38.0

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

[Jakub Jelinek via Gcc-patches]

On Fri, Oct 21, 2022 at 01:51:55PM +0200, Richard Biener via Gcc-patches wrote:
> > > > BTW: Perhaps znver1.md is not the right filename anymore, since it hosts
> > > all four Zen schedulers.
> > >
> > > I have renamed the file to znver.md in this revision, PFA.
> > > Thank you for the review, we will push it for trunk if we don't get any
> > > further comments.
> >
> > I have pushed the patch on behalf of Tejas.
> 
> This grew insn-automata.cc from 201502 lines to 639968 lines and the build
> of the automata (genautomata) to several minutes in my dev tree.

Yeah, in my unoptimized non-bootstrapped development tree genautomata
now takes over 12 minutes on a fast box, that is simply not acceptable.

Jakub

Re: [RFC] how to handle the combination of -fstrict-flex-arrays + -Warray-bounds

[Martin Sebor via Gcc-patches]

On 10/21/22 09:29, Qing Zhao wrote:

Hi,

(FAM below refers to Flexible Array Members):

I need inputs on  how to handle the combination of -fstrict-flex-arrays + 
-Warray-bounds.

Our initial goal is to update -Warray-bounds with multiple levels of 
-fstrict-flex-arrays=N
to issue warnings according to the different levels of “N”.
However, after detailed study, I found that this goal was very hard to be 
achieved.

1. -fstrict-flex-arrays and its levels

The new option -fstrict-flex-arrays has 4 levels:

level   trailing arrays
 treated as FAM

   0 [],[0],[1],[n] the default without option
   1 [],[0],[1]
   2 [],[0]
   3 [] the default when option specified 
without value

2. -Warray-bounds and its levels

The option -Warray-bounds currently has 2 levels:

level   trailing arrays
 treated as FAM

   1 [],[0],[1]  the default when option specified 
without value
   2 [] 

i.e,
When -Warray-bounds=1, it treats [],[0],[1] as FAM, the same level as 
-fstrict-flex-arrays=1;
When -Warray-bounds=2, it only treat [] as FAM, the same level as 
-fstrict-flex-arrays=3;

3. How to handle the combination of  -fstrict-flex-arrays and -Warray-bounds?

Question 1:  when -fstrict-flex-arrays does not present, the default is 
-strict-flex-arrays=0,
 which treats [],[0],[1],[n] as FAM, so should we update 
the default behavior
 of -Warray-bounds to treat any trailing array [n] as FAMs?

My immediate answer to Q1 is NO, we shouldn’t, that will be a big regression on 
-Warray-bounds, right?


Yes, it would disable -Warray-bounds in the cases where it warns
for past-the-end accesses to trailing arrays with two or more
elements.  Diagnosing those has historically (i.e., before recent
changes) been a design goal.



Question 2:  when -fstrict-flex-arrays=N1 and -Warray-bounds=N2 present at the 
same time,
  Which one has higher priority? N1 or N2?

-fstrict-flex-arrays=N1 controls how the compiler code generation treats the 
trailing arrays as FAMs, it seems
reasonable to give higher priority to N1,


I tend to agree.  In other words, set N2' = min(N1, N2).


However, then should we completely disable the level of -Warray-bounds
N2 under such situation?

I really don’t know what’s the best way to handle the conflict  between N1 and 
N2.

Can we completely cancel the 2 levels of -Warray-bounds, and always honor the 
level of -fstrict-flex-arrays?

Any comments or suggestion will be helpful.


The recent -fstrict-flex-array changes aside, IIRC, there's only
a subtle distinction between the two -Warray-bounds levels (since
level 1 started warning on a number of instances that only level
2 used to diagnose a few releases ago).  I think that subset of
level 2 could be merged into level 1 without increasing the rate
of false positives.  Then level 2 could be assigned a new set of
potential problems to detect (such as past-the-end accesses to
trailing one-element arrays).

Martin

Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796]

[Gerald Pfeifer]

On Wed, 30 Mar 2022, Jakub Jelinek via Gcc-patches wrote:
> Thanks, changed and committed.

This (commit 3be1a28f58d6063258407b0751e8fb55df4749c8) introduced a new
 which is deprecated HTML.

Below is the straightforward adjustment I just pushed.

Gerald


commit 95e5070662283453db934dee37203ce9db6e342c
Author: Gerald Pfeifer 
Date:   Sat Oct 22 18:41:14 2022 +0200

gcc-12: Replace an  by an id=

The name attribute for the  tag has been obsoleted. Use an id= on
the nearest container instead, as we already do everywhere else.

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 0e56aba0..30fa4d6e 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -25,8 +25,7 @@ You may also want to check out our
 
 Caveats
 
-  
-An ABI incompatibility between C and
+  An ABI incompatibility between C and
 C++ when passing or returning by value certain aggregates containing zero
 width bit-fields has been discovered on various targets.
 As mentioned in https://gcc.gnu.org/PR102024;>PR102024,

[COMMITTED] Update selftest such that [-Inf, +Inf] is always VARYING for -ffinite-math-only.

[Aldy Hernandez via Gcc-patches]

[-Inf, +Inf] +-NAN gets normalized as VARYING.  There is a test that
drops the NAN possibility, and tests that the range is no longer
VARYING but [-Inf, +Inf].  However, for -ffinite-math-only targets
(Vax, RX, etc) the range would still be VARYING because the VARYING
range never had a NAN to begin with.  This fixes the test.

I have a precommit hook that does self-tests with
-fno-finite-math-only, -ffinite-math-only, and -ffast-math as a sanity
check, but my precommit hook last week was disabled because there was
a tree-ssa.exp in mainline failing which was throwing off my scripts.
My apologies.

gcc/ChangeLog:

* value-range.cc (range_tests_floats): Predicate [-Inf, +Inf] test
with !flag_finite_math_only.
---
 gcc/value-range.cc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index bcda4987307..d779e9819e2 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -3960,8 +3960,11 @@ range_tests_floats ()
   if (r0.maybe_isnan ())
 ASSERT_TRUE (r0.varying_p ());
   // ...unless it has some special property...
-  r0.clear_nan ();
-  ASSERT_FALSE (r0.varying_p ());
+  if (!flag_finite_math_only)
+{
+  r0.clear_nan ();
+  ASSERT_FALSE (r0.varying_p ());
+}
 
   // For most architectures, where float and double are different
   // sizes, having the same endpoints does not necessarily mean the
-- 
2.37.3

Re: [PATCH] libgo: use _off_t for mmap offset argument

[Sören Tempel via Gcc-patches]

PING.

soe...@soeren-tempel.net wrote:
> From: Sören Tempel 
> 
> On glibc-based systems, off_t is a 32-bit type on 32-bit systems and a
> 64-bit type on 64-bit systems by default. However, on systems using musl
> libc off_t is unconditionally a 64-bit type. As such, it is insufficient
> to use a uintptr type for the mmap offset parameter.
> 
> Presently, the (incorrect) mmap declaration causes a libgo run-time
> failure on 32-bit musl systems (fatal error: runtime: cannot allocate
> memory). This commit fixes this run-time error.
> 
> Signed-off-by: Sören Tempel 
> ---
> This implements what has been proposed by Ian in a GitHub comment
> https://github.com/golang/go/issues/51280#issuecomment-1046322011
> 
> I don't have access to a 32-bit glibc system to test this on but
> this does seem to work fine on 32-bit and 64-bit musl systems.
> 
>  libgo/go/runtime/mem_gccgo.go | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libgo/go/runtime/mem_gccgo.go b/libgo/go/runtime/mem_gccgo.go
> index fa3389d8..07bf325a 100644
> --- a/libgo/go/runtime/mem_gccgo.go
> +++ b/libgo/go/runtime/mem_gccgo.go
> @@ -15,7 +15,7 @@ import (
>  //go:linkname sysFree
>  
>  //extern mmap
> -func sysMmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off 
> uintptr) unsafe.Pointer
> +func sysMmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off 
> _off_t) unsafe.Pointer
>  
>  //extern munmap
>  func munmap(addr unsafe.Pointer, length uintptr) int32
> @@ -38,7 +38,7 @@ func init() {
>  }
>  
>  func mmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off 
> uintptr) (unsafe.Pointer, int) {
> - p := sysMmap(addr, n, prot, flags, fd, off)
> + p := sysMmap(addr, n, prot, flags, fd, _off_t(off))
>   if uintptr(p) == _MAP_FAILED {
>   return nil, errno()
>   }

[PATCH] libgcc: Update 'gthr-mcf.h' to include a dedicated header for libobjc

[LIU Hao via Gcc-patches]

This allows building libobjc and enabling Objective-C. Tested against GCC 12 
branch on i686-w64-mingw32.


--
Best regards,
LIU Hao
From c05cceb2f3baa96c9381be38717bdf6f1f3adb76 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sat, 22 Oct 2022 17:31:46 +0800
Subject: [PATCH] libgcc: Update 'gthr-mcf.h' to include a dedicated header for
 libobjc

'libobjc/thr.c' includes 'gthr.h'. While all the other gthread headers
have `#ifdef _LIBOBJC` checks, and provide a different set of inline
functions, I think having one header provide two completely unrelated
set of APIs is unsatisfactory, complicates maintenance, and hinders
further development.

This commit references a new header for libobjc, and adds a copyright
notice, as in other headers.

libgcc/ChangeLog:
* config/i386/gthr-mcf.h: Include 'gthr_libobjc.h' when building
libobjc, instead of 'gthr.h'
---
 libgcc/config/i386/gthr-mcf.h | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/libgcc/config/i386/gthr-mcf.h b/libgcc/config/i386/gthr-mcf.h
index 58131bb7ca9..40da86802b6 100644
--- a/libgcc/config/i386/gthr-mcf.h
+++ b/libgcc/config/i386/gthr-mcf.h
@@ -1 +1,36 @@
+/* Threads compatibility routines for libgcc and libobjc.  */
+/* Copyright (C) 2022 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#ifdef _LIBOBJC
+
+/* libobjc references some internal structures and requires a
+ * dedicated set of functions.  */
+#include 
+
+#else  /* _LIBOBJC  */
+
+/* This is for libgcc and libstdc++.  */
 #include 
+
+#endif  /* _LIBOBJC  */
-- 
2.38.1



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2] xtensa: Make register A0 allocable for the CALL0 ABI

[Max Filippov via Gcc-patches]

On Fri, Oct 21, 2022 at 3:46 PM Takayuki 'January June' Suwa
 wrote:
>
> This patch offers an additional allocable register by RA for the CALL0
> ABI.
>
> > Register a0 holds the return address upon entry to a function, but
> > unlike the windowed register ABI, it is not reserved for this purpose
> > and may hold other values after the return address has been saved.
>   - Xtensa ISA Reference Manual,
>8.1.2 "CALL0 Register Usage and Stack Layout" [p.589]
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_conditional_register_usage):
> Remove register A0 from FIXED_REGS if the CALL0 ABI.
> (xtensa_expand_epilogue): Change to emit '(use (reg:SI A0_REG))'
> unconditionally after restoring callee-saved registers for
> sibling-call functions, in order to prevent misleading that
> register A0 is free to use.
> ---
>  gcc/config/xtensa/xtensa.cc | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.

-- 
Thanks.
-- Max