Re: [committed] libstdc++: Implement C++23 header [PR107760]

2023-12-16 Thread David Edelsohn
Hi, Jonathan Unfortunately this patch broke bootstrap on AIX. In file included from /tmp/GCC/gcc/include-fixed/wchar.h:64, from /tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/cwchar:44, from

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

2023-12-05 Thread David Edelsohn
, 2023 at 11:10 AM David Edelsohn wrote: > Alex, > > This patch broke bootstrap on AIX. The stage1 compiler is not able to > build a program and stage2 configure fails. > > Thanks, David > >

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

2023-12-05 Thread David Edelsohn
Alex, This patch broke bootstrap on AIX. The stage1 compiler is not able to build a program and stage2 configure fails. Thanks, David

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-21 Thread David Edelsohn
On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović wrote: > > Arsen Arsenović writes: > > > Bruno Haible writes: > > > >> Arsen Arsenović wrote: > >>> Comparing stages 2 and 3 > >>> Bootstrap comparison failure! > >>> gettext/libasprintf/autosprintf.o differs > >>> make[2]: ***

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-20 Thread David Edelsohn
itself with the different stages of the compiler, so the appended random number changes. Thanks, David On Mon, Nov 20, 2023 at 4:23 PM Arsen Arsenović wrote: > > David Edelsohn writes: > > > On Sun, Nov 19, 2023 at 5:15 PM Bruno Haible wrote: > > > >> David Ed

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-19 Thread David Edelsohn
On Sun, Nov 19, 2023 at 5:15 PM Bruno Haible wrote: > David Edelsohn wrote: > > --disable-threads currently does not completely disable threads. Bruno > is > > suggesting --enable-threads=isoc that relies on mtx mutex functions in > libc. > > Unfortunately, as s

Re:

2023-11-18 Thread David Edelsohn via Gcc
On Sat, Nov 18, 2023 at 4:23 PM Zebediah Beck via Gcc wrote: > I would like that contribute technical documentation to the community. > Hi, Zebediah Thanks for your interest in GCC. Welcome! Improvements to the GCC technical documentation would be a wonderful contribution. We also would be

Re: Recordings of cauldron 2023 talks

2023-11-18 Thread David Edelsohn via Gcc
On Sat, Nov 18, 2023 at 4:34 PM Heiko wrote: > Hello, > > according to https://gcc.gnu.org/wiki/cauldron2023 it was planned to > make the talk recordings available afterwards. > I would be interested to follow them, but have not been able to find > them anywhere. > > My first guess was to look

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-17 Thread David Edelsohn
On Fri, Nov 17, 2023 at 10:17 AM Arsen Arsenović wrote: > > David Edelsohn writes: > > > On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote: > > > >> > >> David Edelsohn writes: > >> > >> > On Thu, Nov 16, 2023 at 5:52 PM Arsen A

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-17 Thread David Edelsohn
On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote: > > David Edelsohn writes: > > > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote: > > > > [snip] > >> Sure, but my patch does insert --disable-shared: > >> > >> --8<-

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
On Thu, Nov 16, 2023 at 7:07 PM Bruno Haible wrote: > David Edelsohn wrote: > > > ibm-clang links against libpthread.a as well: > > > $ ldd /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig > > > /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig needs: > &g

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-16 Thread David Edelsohn
On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote: > > David Edelsohn writes: > > > On Thu, Nov 16, 2023 at 5:22 PM Arsen Arsenović wrote: > > > >> > >> David Edelsohn writes: > >> > >> > Don't build with the dependent li

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
On Thu, Nov 16, 2023 at 5:47 PM Bruno Haible wrote: > Hi David, > > > the default, distributed libintl library will not allow GCC to be built > > with NLS enabled. > > The problem is this configure test from gettext.m4 > > checking for GNU gettext in libintl... no > > It should say > >

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-16 Thread David Edelsohn
On Thu, Nov 16, 2023 at 5:22 PM Arsen Arsenović wrote: > > David Edelsohn writes: > > > Don't build with the dependent libraries in tree. Don't build the > > dependent libraries as shared libraries. The libraries are already built > > and in /opt/cfarm, as mention

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
On Thu, Nov 16, 2023 at 1:52 PM Bruno Haible wrote: > David Edelsohn wrote: > > I manually commented out HAVE_PTHREAD_API from config.h and produced a > > libintl.a without references to pthreads. > > Good finding! > > Commenting out HAVE_PTHREAD_API from config.h is a

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-16 Thread David Edelsohn
ntoo Developer UID) (trust ultimate) created at > 2023-11-16T19:47:16+0100 using EDDSA]] > > > > David Edelsohn writes: > > > >> On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović > wrote: > >> > >>> > >>> David Edelsohn writes:

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
distributed. Thanks, David On Thu, Nov 16, 2023 at 1:01 PM David Edelsohn wrote: > Bruno, > > The issue appears to be that intl/gnulib-lib/{mbrtowc.c,setlocale_null.c} > include pthread.h based on HAVE_PTHREAD_API, which is defined as 1 in > intl/config.h build directory des

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
Bruno, The issue appears to be that intl/gnulib-lib/{mbrtowc.c,setlocale_null.c} include pthread.h based on HAVE_PTHREAD_API, which is defined as 1 in intl/config.h build directory despite requesting --disable-pthreads. Thanks, David On Thu, Nov 16, 2023 at 11:35 AM David Edelsohn wrote: >

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
On Thu, Nov 16, 2023 at 11:58 AM Richard Biener wrote: > > > Am 16.11.2023 um 17:00 schrieb David Edelsohn : > >  > Bruno, > > I have been able to tweak the environment and build gettext and libintl. > With the updated libintl and environment, GCC reliably does

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
812 D _libintl_setlocale_null_r 824 D _libintl_setlocale_null On Thu, Nov 16, 2023 at 11:00 AM David Edelsohn wrote: > Bruno, > > I have been able to tweak the environment and build gettext and libintl. > With the updated libintl and environment, GCC reliably does

Re: building GNU gettext on AIX

2023-11-16 Thread David Edelsohn
. This is a regression in NLS support in GCC. Thanks, David On Wed, Nov 15, 2023 at 5:39 PM Bruno Haible wrote: > David Edelsohn wrote: > > I am using my own install of GCC for a reason. > > I have built GNU gettext 0.22.3 in various configurations on the AIX 7.1 > and 7.3 machines in the compil

Re: building GNU gettext on AIX

2023-11-15 Thread David Edelsohn
On Wed, Nov 15, 2023 at 4:22 PM Bruno Haible wrote: > David Edelsohn wrote: > > When I try to configure gettext-0.22.3, I receive the following error: > > > > checking for socklen_t equivalent... configure: error: Cannot find a type > > to use in place of socklen

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-15 Thread David Edelsohn
On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović wrote: > > David Edelsohn writes: > > > GCC had been working on AIX with NLS, using "--with-included-gettext". > > --disable-nls gets past the breakage, but GCC does not build for me on > AIX > > with

Re: building GNU gettext on AIX

2023-11-15 Thread David Edelsohn
wrote: > [CCing bug-gettext] > > David Edelsohn wrote in > <https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636558.html>: > > The current gettext-0.22.3 fails to build for me on AIX. > > Here are some hints to get a successful build of GNU gettext on AIX: &

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-15 Thread David Edelsohn
On Wed, Nov 15, 2023 at 9:22 AM Arsen Arsenović wrote: > > David Edelsohn writes: > > > GCC had been working on AIX with NLS, using "--with-included-gettext". > > --disable-nls gets past the breakage, but GCC does not build for me on > AIX > > with

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-14 Thread David Edelsohn
On Tue, Nov 14, 2023 at 6:09 PM Arsen Arsenović wrote: > Hi David, > > David Edelsohn writes: > > > Arsen, > > > > Unfortunately this broke bootstrap on AIX. > > > > I had not seen this series of patches. > > I've added Bruno to CC as the libin

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-14 Thread David Edelsohn
Arsen, Unfortunately this broke bootstrap on AIX. I had not seen this series of patches. David

Re: [PATCH v3] Control flow redundancy hardening

2023-10-20 Thread David Edelsohn
/gimple-harden-control-flow.cc* @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see #include "system.h" #include "coretypes.h" #include "backend.h" +#include "memmodel.h" #include "tm_p.h" #include "tree.h" #i

Re: [PATCH v3] Control flow redundancy hardening

2023-10-20 Thread David Edelsohn
This patch broke bootstrap on AIX because ASM_GENERATE_INTERNAL_LABEL can embed target-specific functions. Fixed by including tm_p.h. Thanks, David * gimple-harden-control-flow.cc: Include tm_p.h. *diff --git a/gcc/gimple-harden-control-flow.cc b/gcc/gimple-harden-control-flow.cc*

Re: [PATCH v2] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

2023-10-18 Thread David Edelsohn
[Resending from correct email.] Hi, Surya Thanks for working on this issue and creating a patch. It helps if you explicitly send patches to Segher and me, and copy gcc-patches. +/* Return true if insn is a non-permuting load/store. */ +static bool +non_permuting_mem_insn (swap_web_entry

Re: [PATCH v2] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

2023-10-18 Thread David Edelsohn
Hi, Surya Thanks for working on this issue and creating a patch. It helps if you explicitly send patches to Segher and me, and copy gcc-patches. +/* Return true if insn is a non-permuting load/store. */ +static bool +non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i) +{ +

Re: [PATCH] PR target/111778 - Fix undefined shifts in PowerPC compiler

2023-10-12 Thread David Edelsohn
On Thu, Oct 12, 2023 at 4:24 AM Michael Meissner wrote: > I was building a cross compiler to PowerPC on my x86_86 workstation with > the > latest version of GCC on October 11th. I could not build the compiler on > the > x86_64 system as it died in building libgcc. I looked into it, and I >

Re: [PATCH] early outs for functions in rs6000.cc

2023-10-11 Thread David Edelsohn
On Tue, Oct 10, 2023 at 9:29 PM Jiufu Guo wrote: > Hi, > > There are some piece of code like below in rs6000.cc: > > ... > if (xx) >return x; > else if (yy) >return y; > ... //else if chain > else >return d; > > Using early outs would be more preferable for this kind of code. >

Re: [PATCH-2, rs6000] Enable vector mode for memory equality compare [PR111449]

2023-10-10 Thread David Edelsohn
On Tue, Oct 10, 2023 at 4:23 AM HAO CHEN GUI wrote: > Hi David, > > Thanks for your review comments. > > 在 2023/10/9 23:42, David Edelsohn 写道: > > #define MOVE_MAX (! TARGET_POWERPC64 ? 4 : 8) > > #define MAX_MOVE_MAX 8 > > +#define MOVE_MAX_P

Re: [PATCH-2, rs6000] Enable vector mode for memory equality compare [PR111449]

2023-10-09 Thread David Edelsohn
On Sun, Oct 8, 2023 at 10:30 PM HAO CHEN GUI wrote: > Hi, > This patch enables vector mode for memory equality compare by adding > a new expand cbranchv16qi4 and implementing it. Also the corresponding > CC reg and compare code is set in rs6000_generate_compare. With the > patch, 16-byte

Re: Code size explosion with -O2

2023-10-06 Thread David Edelsohn via Gcc
On Fri, Oct 6, 2023 at 6:49 PM Jakub Svojgr via Gcc wrote: > Hello, > this is an extremely specific scenario - however while compiling > computer-generated code for a fibonnacci function which looks like this: > > I32 GF_fib_I_I(I32 L_0_0) > { > I32 L_2_0; I32 L_5_0; I32 L_6_0; > bb0:; >

Re: [PATCH V5 2/2] rs6000: use mtvsrws to move sf from si p9

2023-10-05 Thread David Edelsohn
On Thu, Oct 5, 2023 at 12:14 AM Jiufu Guo wrote: > Hi, > > As mentioned in PR108338, on p9, we could use mtvsrws to implement > the bitcast from SI to SF (or lowpart DI to SF). > > For example: > *(long long*)buff = di; > float f = *(float*)(buff); > > "sldi 9,3,32 ; mtvsrd 1,9 ; xscvspdpn

Re: [PATCH V5 1/2] rs6000: optimize moving to sf from highpart di

2023-10-05 Thread David Edelsohn
On Thu, Oct 5, 2023 at 12:50 AM Jiufu Guo wrote: > Hi, > > Currently, we have the pattern "movsf_from_si2" which was trying > to support moving high part DI to SF. > > But current pattern only accepts "ashiftrt": > XX:SF=bitcast:SF(subreg(YY:DI>>32),0), but actually "lshiftrt" should > also be

Re: [PATCH v2] Add a GCC Security policy

2023-10-04 Thread David Edelsohn
Hi, Siddhesh Thanks for working on this and fine-tuning the original proposed text. It looks good to me. Minor grammatical nit below. Thanks, David On Thu, Sep 28, 2023 at 7:59 AM Siddhesh Poyarekar wrote: > On 2023-09-28 12:55, Siddhesh Poyarekar wrote: > > Define a security process and

Re: [COMMITTED] Return TRUE only when a global value is updated.

2023-10-03 Thread David Edelsohn
le > pointer ranges different. > > Andrew > > On 10/3/23 11:47, David Edelsohn wrote: > > This patch caused a bootstrap failure on AIX. > > > > during GIMPLE pass: evrp > > > > /nasfarm/edelsohn/src/src/libgcc/libgcc2.c: In function '__gcc_bcmp': > >

Re: [COMMITTED] Return TRUE only when a global value is updated.

2023-10-03 Thread David Edelsohn
This patch caused a bootstrap failure on AIX. during GIMPLE pass: evrp /nasfarm/edelsohn/src/src/libgcc/libgcc2.c: In function '__gcc_bcmp': /nasfarm/edelsohn/src/src/libgcc/libgcc2.c:2910:1: internal compiler error: in get_irange, at value-range-storage.cc:343 2910 | } | ^

Re: [PATCH] rs6000: Make 32 bit stack_protect support prefixed insn [PR111367]

2023-10-03 Thread David Edelsohn
On Wed, Sep 27, 2023 at 1:38 AM Kewen.Lin wrote: > Hi, > > As PR111367 shows, with prefixed insn supported, some of > checkings consider it's able to leverage prefixed insn > for stack protect related load/store, but since we don't > actually change the emitted assembly for 32 bit, it can >

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-03 Thread David Edelsohn
ode) on my linux also some other report it work on freebsd, just wait > review :) > > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html > > On Tue, Oct 3, 2023 at 2:07 AM Jeff Law wrote: > > > > > > > > On 10/2/23 12:03, Da

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread David Edelsohn
On Mon, Oct 2, 2023 at 1:59 PM Jeff Law wrote: > > > On 10/2/23 11:20, David Edelsohn wrote: > > Wang, > > > > The AWK portions of this patch broke bootstrap on AIX. > > > > Also, the AWK portions are common code, not RISC-V specific. I don't &g

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread David Edelsohn
Wang, The AWK portions of this patch broke bootstrap on AIX. Also, the AWK portions are common code, not RISC-V specific. I don't see anywhere that the common portions of the patch were reviewed or approved by anyone with authority to approve the changes to the AWK files. This patch should not

Re: Ping^2 [PATCH V5 1/4] rs6000: build constant via li;rotldi

2023-09-30 Thread David Edelsohn
On Mon, Sep 25, 2023 at 10:52 PM Jiufu Guo wrote: > Hi, > > Gentle ping... > > BR, > Jeff (Jiufu Guo) > This is okay. Thanks, David > > Jiufu Guo via Gcc-patches writes: > > > Hi, > > > > Gentle ping... > > > > BR, > > Jeff (Jiufu Guo) > > > > Jiufu Guo writes: > > > >> Hi, > >> > >> If a

Re: [PATCH] Cleanup: Replace UNSPEC_COPYSIGN with copysign RTL

2023-09-29 Thread David Edelsohn
On Fri, Sep 29, 2023 at 2:09 PM Michael Meissner wrote: > When I first implemented COPYSIGN support in the power7 days, we did not > have a > copysign RTL insn, so I had to use UNSPEC to represent the copysign > instruction. This patch removes those UNSPECs, and it uses the native RTL >

Re: Test with an lto-build of libgfortran.

2023-09-28 Thread David Edelsohn via Gcc
On Thu, Sep 28, 2023 at 4:00 PM Toon Moene wrote: > On 9/28/23 21:26, Jakub Jelinek wrote: > > > It is worse than that, usually the LTO format changes e.g. any time any > > option or parameter is added on a release branch (several times a year) > and > > at other times as well. > > Though,

Re: Unexpected behavior of gcc on pointer dereference & increment

2023-09-01 Thread David Edelsohn via Gcc
On Fri, Sep 1, 2023 at 12:37 PM Tomas Bortoli via Gcc wrote: > Hi, > > I recently discovered that the following C statement: > > pointer++; > > is semantically equivalent to the following: > > *pointer++; > > Is this due to operators' priority? To me, that looks weird. > Equivalent in the

Re: How can I run xg++ from its build location?

2023-08-25 Thread David Edelsohn via Gcc
On Fri, Aug 25, 2023 at 4:16 PM Michael Welsh Duggan via Gcc < gcc@gcc.gnu.org> wrote: > I am attempting to debug an issue in gcc (PR 110827, if curious). In > order to do this I have built a stage 1 compiler with debugging and > without optimization as discussed here: > >

Re: [PATCH v2 1/2] libstdc++: Implement more maintainable header

2023-08-16 Thread David Edelsohn via Gcc-patches
g 2023 at 22:39, David Edelsohn wrote: > > > > > > Hi, Arsen > > > > > > This patch broke bootstrap because it has introduced a new GCC build > requirement for autogen that is not a previous requirement to build GCC. > Previously the repository has inc

Re: [PATCH v2 1/2] libstdc++: Implement more maintainable header

2023-08-16 Thread David Edelsohn via Gcc-patches
Hi, Arsen This patch broke bootstrap because it has introduced a new GCC build requirement for autogen that is not a previous requirement to build GCC. Previously the repository has included post-processed files. +# AutoGen . +.PHONY: update-version +update-version: + cd ${bits_srcdir} &&

Re: [RFC] GCC Security policy

2023-08-15 Thread David Edelsohn via Gcc-patches
On Tue, Aug 15, 2023 at 7:07 PM Alexander Monakov wrote: > > On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: > > > > Thanks, this is nicer (see notes below). My main concern is that we > > > shouldn't pretend there's some method of verifying that arbitrary > source > > > code is "safe" to pass to

Re: [RFC] GCC Security policy

2023-08-11 Thread David Edelsohn via Gcc-patches
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar wrote: > On 2023-08-08 10:30, Siddhesh Poyarekar wrote: > >> Do you have a suggestion for the language to address libgcc, > >> libstdc++, etc. and libiberty, libbacktrace, etc.? > > > > I'll work on this a bit and share a draft. > > Hi David, > >

Re: [RFC] GCC Security policy

2023-08-09 Thread David Edelsohn via Gcc-patches
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar wrote: > On 2023-08-08 10:30, Siddhesh Poyarekar wrote: > >> Do you have a suggestion for the language to address libgcc, > >> libstdc++, etc. and libiberty, libbacktrace, etc.? > > > > I'll work on this a bit and share a draft. > > Hi David, > >

Re: [RFC] GCC Security policy

2023-08-08 Thread David Edelsohn via Gcc-patches
On Tue, Aug 8, 2023 at 1:36 PM Ian Lance Taylor wrote: > On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > > > BTW, I think we should perhaps differentiate between production ready > > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > > libssp) vs. e.g.

Re: [RFC] GCC Security policy

2023-08-08 Thread David Edelsohn via Gcc-patches
On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar wrote: > On 2023-08-08 10:04, Richard Biener wrote: > > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > >> > >> On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > >> wrote: > >>> > >>> On Tue, Aug 08, 2023 at 02:52:57PM

[RFC] GCC Security policy

2023-08-07 Thread David Edelsohn via Gcc-patches
FOSS Best Practices recommends that projects have an official Security policy stated in a SECURITY.md or SECURITY.txt file at the root of the repository. GLIBC and Binutils have added such documents. Appended is a prototype for a Security policy file for GCC based on the Binutils document

David Faust appointed BPF backend reviewer

2023-08-04 Thread David Edelsohn via Gcc
I am pleased to announce that the GCC Steering Committee has appointed David Faust as BPF backend reviewer. Please join me in congratulating David on his new role. David, please update your listings in the MAINTAINERS file. Happy hacking! David

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

2023-07-25 Thread David Edelsohn via Gcc-patches
Hi, Drew Thanks for addressing this missed optimization. The testcase includes an incorrect assumption: signed char, which causes the testcase to fail on PowerPC. Should the testcase be updated to specify signed char in the function signatures or should -fsigned-char be added to the command

Re: Beginner Looking for Mentors to Get Started

2023-07-20 Thread David Edelsohn via Gcc
Hi, Veera Thanks for your interest in GCC. Welcome! A good place to start is the GCC Wiki Getting Started page: https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development David Malcolm has written a wonderful introduction to GCC for newcomers:

Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie

2023-06-13 Thread David Edelsohn via Gcc-patches
On Tue, Jun 13, 2023 at 2:16 PM Segher Boessenkool wrote: > > Hi! > > On Tue, Jun 13, 2023 at 10:15:49AM +0800, Jiufu Guo wrote: > > David Edelsohn writes: > > > > > > This definitely seems to be a better solution. > > > > > > The TARGE

Re: [PATCH 1/4] rs6000: build constant via li;rotldi

2023-06-13 Thread David Edelsohn via Gcc-patches
On Mon, Jun 12, 2023 at 11:30 PM Jiufu Guo wrote: > > > Hi David, > > David Edelsohn writes: > > On Wed, Jun 7, 2023 at 9:55 PM Jiufu Guo wrote: > > > > Hi, > > > > This patch checks if a constant is possible to be rotated to/from a > > p

Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie

2023-06-12 Thread David Edelsohn via Gcc-patches
Hi, Jiufu This definitely seems to be a better solution. The TARGET_CONST_ANCHOR change should not be part of this patch. Also there is no ChangeLog for the patch. This generally looks correct and consistent with other ports. I want to give Segher a chance to double check it, if he wishes.

[PATCH, AIX] Debugging does not require a stack frame.

2023-06-11 Thread David Edelsohn via Gcc-patches
The rs6000 port has allocated a stack frame when debugging is enabled on AIX since the earliest versions of the port. Apparently the earliest versions of the debuggers for AIX had difficulty with stackless frames. Both AIX DBX and GDB support stackless frames on AIX, and IBM XLC, OpenXL and LLVM

Re: [PATCH] rs6000: Guard __builtin_{un, }pack_vector_int128 with vsx [PR109932]

2023-06-11 Thread David Edelsohn via Gcc-patches
On Tue, Jun 6, 2023 at 5:19 AM Kewen.Lin wrote: > Hi, > > As PR109932 shows, builtins __builtin_{un,}pack_vector_int128 > should be guarded under vsx rather than power7, as their > corresponding bif patterns have the conditions TARGET_VSX > and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode). This patch

Re: [PATCH] rs6000: Don't use TFmode for 128 bits fp constant in toc [PR110011]

2023-06-10 Thread David Edelsohn via Gcc-patches
On Tue, Jun 6, 2023 at 5:20 AM Kewen.Lin wrote: > Hi, > > As PR110011 shows, when encoding 128 bits fp constant into > toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is > to find the first float mode with LONG_DOUBLE_TYPE_SIZE > bits of precision, it would be TFmode here. But the 128 >

Re: [PATCH 4/4] rs6000: build constant via li/lis;rldic

2023-06-10 Thread David Edelsohn via Gcc-patches
On Wed, Jun 7, 2023 at 9:56 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible to be built by "li;rldic". > We only need to take care of "negative li", other forms do not need to > check. > For example, "negative lis" is just a "negative li" with an additional > shift. > >

Re: [PATCH 3/4] rs6000: build constant via li/lis;rldicl/rldicr

2023-06-10 Thread David Edelsohn via Gcc-patches
On Wed, Jun 7, 2023 at 9:56 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible left/right cleaned on a rotated > value from a negative value of "li/lis". If so, we can build the constant > through "li/lis ; rldicl/rldicr". > > Bootstrap and regtest pass on ppc64{,le}. >

Re: [PATCH 2/4] rs6000: build constant via lis;rotldi

2023-06-10 Thread David Edelsohn via Gcc-patches
On Wed, Jun 7, 2023 at 9:55 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible to be rotated to/from a > negative > value from "lis". If so, we could use "lis;rotldi" to build it. > The positive value of "lis" does not need to be analyzed. Because if a > constant can be

Re: [PATCH 1/4] rs6000: build constant via li;rotldi

2023-06-10 Thread David Edelsohn via Gcc-patches
On Wed, Jun 7, 2023 at 9:55 PM Jiufu Guo wrote: > Hi, > > This patch checks if a constant is possible to be rotated to/from a > positive > or negative value from "li". If so, we could use "li;rotldi" to build it. > > Bootstrap and regtest pass on ppc64{,le}. > Is this ok for trunk? > > BR, >

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

2023-06-06 Thread David Edelsohn via Gcc
On Tue, Jun 6, 2023 at 11:38 AM David Brown via Gcc wrote: > On 06/06/2023 14:53, Paul Smith wrote: > > On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote: > >> Sorry for my outburst, to the rest of this list. I can no longer stay > >> silent and watch these little shits bully people

Re: Passing the complex args in the GPR's

2023-06-06 Thread David Edelsohn via Gcc
On Tue, Jun 6, 2023 at 1:08 PM Umesh Kalappa via Gcc wrote: > Hi Segher , > > >>What did you expect, what happened instead? > For example the complex args are passed in GPR's for cexp in the case > GCC and Clang uses caller memory . > > for reference : https://godbolt.org/z/MfMz3cTe7 > > We

Re: [PATCH 1/4] rs6000: build constant via li;rotldi

2023-06-02 Thread David Edelsohn via Gcc-patches
Hi, Jiufu * config/rs6000/rs6000.cc (can_be_rotated_to_possitive_li): New function. (can_be_rotated_to_negative_li): New function. (can_be_built_by_li_and_rotldi): New function. (rs6000_emit_set_long_const): Call can_be_built_by_li_and_rotldi. In English the word

YunQiang Su appointed MIPS maintainer

2023-06-01 Thread David Edelsohn via Gcc
I am pleased to announce that the GCC Steering Committee has appointed YunQiang Su as MIPS maintainer. Please note that this is somewhat provisional because MIPS needs a full-time maintainer, but you do not have a long history of experience in the GCC Community. Please continue to be vigilant

Re: ping^^: [PATCH] rs6000: Enable const_anchor for 'addi'

2023-05-31 Thread David Edelsohn via Gcc-patches
On Tue, May 30, 2023 at 11:00 PM Jiufu Guo wrote: > > Gentle ping... > > Jiufu Guo via Gcc-patches writes: > > > Gentle ping... > > > > Jiufu Guo via Gcc-patches writes: > > > >> Hi, > >> > >> I'm thinking that we may enable this patch for stage1, so ping it. > >>

Re: [PATCH 7/7] Expand directly for single bit test

2023-05-21 Thread David Edelsohn via Gcc-patches
On Sun, May 21, 2023 at 11:25 AM Andrew Pinski wrote: > On Sun, May 21, 2023 at 11:17 AM David Edelsohn via Gcc-patches > wrote: > > > > Hi, Andrew > > > > Thanks for this series of patches to improve do_store_flag. > Unfortunately > > this specific pat

Re: [PATCH 7/7] Expand directly for single bit test

2023-05-21 Thread David Edelsohn via Gcc-patches
Hi, Andrew Thanks for this series of patches to improve do_store_flag. Unfortunately this specific patch in the series has caused a bootstrap failure on powerpc-aix. I bisected this failure to this specific patch. Note that I am building as 32 bit, so this could be a specific issue about bit

Re: More C type errors by default for GCC 14

2023-05-09 Thread David Edelsohn via Gcc
On Tue, May 9, 2023 at 4:40 PM Jonathan Wakely wrote: > > > On Tue, 9 May 2023, 21:13 David Edelsohn, wrote: > >> On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc >> wrote: >> >>> > Date: Tue, 9 May 2023 21:07:07 +0200 >>> > From: Jaku

Re: More C type errors by default for GCC 14

2023-05-09 Thread David Edelsohn via Gcc
On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc wrote: > > Date: Tue, 9 May 2023 21:07:07 +0200 > > From: Jakub Jelinek > > Cc: Jonathan Wakely , ar...@aarsen.me, > gcc@gcc.gnu.org > > > > On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote: > > > > From: Jonathan Wakely

Re: More C type errors by default for GCC 14

2023-05-09 Thread David Edelsohn via Gcc
On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc wrote: > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote: > > > > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc >: > > > > > > TL;DR: This message is about turning implicit-int, > > >

Re: More C type errors by default for GCC 14

2023-05-09 Thread David Edelsohn via Gcc
On Tue, May 9, 2023 at 11:14 AM Jonathan Wakely wrote: > On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc > wrote: > > Yes, GCC has two, distinct user groups / use cases, but GCC also has a > very > > unique and crucial role, as the foundation for a large portion

Re: More C type errors by default for GCC 14

2023-05-09 Thread David Edelsohn via Gcc
On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc wrote: > TL;DR: This message is about turning implicit-int, > implicit-function-declaration, and possibly int-conversion into errors > for GCC 14. > > A few of you might remember that I've been looking into turning some > type errors from

Re: [PATCH 5/5] match.pd: Use splits in makefile and make configurable.

2023-05-05 Thread David Edelsohn via Gcc-patches
On Fri, May 5, 2023 at 11:38 AM Tamar Christina wrote: > > -Original Message- > > From: Jakub Jelinek > > Sent: Friday, May 5, 2023 4:33 PM > > To: Tamar Christina > > Cc: Jeff Law ; David Edelsohn >; > > GCC Patches > > Subject: Re:

Re: [PATCH 5/5] match.pd: Use splits in makefile and make configurable.

2023-05-05 Thread David Edelsohn via Gcc-patches
This patch has broken GCC bootstrap on AIX. It appears to rely upon, or complain about, the command "seq": /nasfarm/edelsohn/install/GCC12/bin/g++ -std=c++11 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format

Re: #include cobol

2023-03-18 Thread David Edelsohn via Gcc
On Mon, Feb 27, 2023 at 10:13 AM James K. Lowden wrote: > To the GCC community and GCC Steering Committee: Greetings! > > We at COBOLworx would like GCC to consider our gcobol front-end for > inclusion in the GCC project. We would like to contribute it to the > GNU Toolchain and have it merged

Re: Stepping down as gcov maintainer and callgraph reviewer

2023-02-16 Thread David Edelsohn via Gcc
On Thu, Feb 16, 2023 at 10:54 AM Martin Liška wrote: > Hello GCC community. > > After spending last decade (including my diploma thesis even more) > of my life working on GCC, I decided to leave the project and try > a different job. I would like to thank all the community members I had > change

Re: [PATCH, wwwdocs] readings: Update AIX linker links

2023-01-30 Thread David Edelsohn via Gcc-patches
On Mon, Jan 30, 2023 at 4:52 PM Gerald Pfeifer wrote: > Hi David, > > the noticed the links to the AIX 4.3 and AIX 5L docs were broken and could > not find a good replacement, though I did find one for AIX 7.2. > > How about the patch below? > Hi, Gerald That change is fine with me. Thanks,

Apology to Dr. Elena Zannoni

2022-12-29 Thread David Edelsohn via Gcc
At GNU Cauldron 2022 during the GNU Toolchain Infrastructure BoF session I displayed inappropriate and uncharacteristic behavior towards Dr. Elena Zannoni. Because I realized that my behavior was inappropriate, I proactively apologized to Dr. Zannoni during a conversation immediately after the

Philip Herron and Arthur Cohen appointed Rust front-end maintainers

2022-12-20 Thread David Edelsohn via Gcc
I am pleased to announce that the GCC Steering Committee has appointed Philip Herron and Arthur Cohen as Rust front-end maintainers. Please join me in congratulating Philip and Arthur on their new role. Philip and Arthur, please update your listings in the MAINTAINERS file. Happy holidays!

Gaius Mulley appointed Modula-2 front-end maintainer

2022-12-20 Thread David Edelsohn via Gcc
I am pleased to announce that the GCC Steering Committee has appointed Gaius Mulley as Modula-2 front-end maintainer. Please join me in congratulating Gaius on his new role. Gaius, please update your listings in the MAINTAINERS file. Happy Holidays! Happy hacking! David

Re: GCC 13 bootstrap failure on i686-w64-mingw32

2022-11-21 Thread David Edelsohn via Gcc
Yes, AIX as well. Thanks, David On Sun, Nov 20, 2022 at 2:18 PM Jonathan Wakely via Gcc wrote: > This fails on macOS too (and probably everything non-gnu). > > On Sun, 20 Nov 2022, 12:36 LIU Hao via Gcc, wrote: > > > This is caused by 2efb237ffc68ec9bb17982434f5941bfa14f8b50, which has > >

Re: [PATCH RFC] c++: implement P1492 contracts

2022-11-21 Thread David Edelsohn via Gcc-patches
This patch broke bootstrap on AIX due to its use of strchrnul(). It is an extension available in Linux, but not all targets. /src/src/gcc/cp/contracts.cc:213:21: error: 'strchrnul' was not declared in this scope; did you mean 'strchr'? 213 | size_t role_len = strchrnul (role, ':') - role;

Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

2022-11-18 Thread David Edelsohn via Gcc-patches
On Fri, Nov 18, 2022 at 7:20 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Fri, Nov 18, 2022 at 02:35:30PM +0800, HAO CHEN GUI wrote: > > 在 2022/11/17 21:24, David Edelsohn 写道: > > > Why are you using zero_constant predicate instead of matching >

Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000

2022-11-17 Thread David Edelsohn via Gcc-patches
On Thu, Nov 17, 2022 at 1:39 AM HAO CHEN GUI wrote: > Hi, > The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to > indicate if branch by CC bits is invalid or not. The new expand pattern > "cbranchcc4" is created which intend to match the pattern defined in > "*cbranch",

Re: [rs6000, patch] Enable have_cbranchcc4 on rs6000

2022-11-16 Thread David Edelsohn via Gcc-patches
perand 0 is a comparison operator. Operand 1 and operand 2 are the > first and second operands of the comparison, respectively. Operand 3 > is the code_label to jump to. > > Gui Haochen > Thanks > > 在 2022/11/16 11:04, David Edelsohn 写道: > > It's great to a

Re: [rs6000, patch] Enable have_cbranchcc4 on rs6000

2022-11-15 Thread David Edelsohn via Gcc-patches
On Tue, Nov 15, 2022 at 9:32 PM HAO CHEN GUI wrote: > Hi, > The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to > indicate if branch by CC bits is invalid or not. As rs6000 already has > "*cbranch" insn which does branching according to CC bits, the flag > should be enabled and

Re: [PATCH V2] Enable small loop unrolling for O2

2022-11-09 Thread David Edelsohn via Gcc-patches
> This patch does not change rs6000/s390 since I don't have machines to > test them, but I suppose the default behavior is the same since they > enable flag_unroll_loops at O2. There are Power (rs6000) systems in the Compile Farm. Trial Linux on Z (s390x) VMs are available through the Linux

Re: Interested to contribute!

2022-10-24 Thread David Edelsohn via Gcc
On Mon, Oct 24, 2022 at 4:57 PM StreetCodeC - via Gcc wrote: > Hi! > I am interested in contributing to GCC but I am fairly new to this project > and wish for some heads up and guidance about how to start working! Please > help me understand where are the 'issues' and source code. > Regards, >

GTI project presentation and public discussion

2022-10-20 Thread David Edelsohn via Gcc
The FSF will host a public conversation and Q about the GTI project on: October 24, 10am Eastern Time. You can read the full details here: https://www.fsf.org/events/the-gti-project-a-conversation-and-community-q-a Everyone is welcome to submit questions, attend the event, and engage. Thank

<    1   2   3   4   5   6   7   8   9   10   >