On Mon, Jan 18, 2021 at 6:01 AM Mark Wielaard wrote:
>
> Hi David,
>
> On Sun, Jan 17, 2021 at 06:12:06PM -0500, David Edelsohn wrote:
> > GCC now defaults to DWARF 5. AIX only supports DWARF 4 (3.5).
> >
> > This patch overrides the default DWARF
GCC now defaults to DWARF 5. AIX only supports DWARF 4 (3.5).
This patch overrides the default DWARF version to 4 unless explicitly
stated.
gcc/ChangeLog:
* config/rs6000/aix71.h (SUBTARGET_OVERRIDE_OPTIONS): Override
dwarf_version to 4.
* con
On Tue, Jan 12, 2021 at 12:41 PM Rainer Orth
wrote:
>
> Hi Jonathan,
>
> >> On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
> >>>Hi everyone,Â
> >>>
> >>>I've reworked the patch to merged dragonfly and AIX
> >>>models into the new one named "ieee_1003.1-2008".Â
> >>>It seems okay on the AIX part b
On Tue, Jan 12, 2021 at 10:25 AM Jonathan Wakely wrote:
>
> On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
> >Hi everyone,
> >
> >I've reworked the patch to merged dragonfly and AIX
> >models into the new one named "ieee_1003.1-2008".
> >It seems okay on the AIX part but if someone can test
> >on
On Mon, Jan 11, 2021 at 10:56 AM CHIGOT, CLEMENT
wrote:
>
> >> Hi David, Clement,
> >>
> >>> The patch is local to libstdc++ AIX support, so I believe that I can
> >>> approve it.
> >>
> >>have you considered merging the dragonfly and aix trees? I'm asking
> >>because it seems prudent to try and
Hi, Clement
The patch is local to libstdc++ AIX support, so I believe that I can approve it.
libstdc++ loads the gcc testsuite target-supports.exp extensions. The
patch needs to update the libstdc++ testcases to require wchar32 or
utf-8 as appropriate to avoid the failures.
Thanks, David
On Mon
On Fri, Jan 8, 2021 at 1:52 PM Jakub Jelinek wrote:
>
> On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote:
> > This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
> > think that should be equivalent in all practical cases (I can imagine
> > some strange target wher
Hi, Bernd
Thanks for investigating this and creating a revised version of the
patch. With the second patch, the gcc.misc-test/outputs.exp results
are clean on AIX.
Thanks, David
On Fri, Jan 8, 2021 at 1:59 PM Bernd Edlinger wrote:
>
> On 1/8/21 3:23 PM, David Edelsohn wrote:
> > O
On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger wrote:
>
> Hi,
>
> On 1/7/21 5:12 PM, Rainer Orth wrote:
> > The unsetenv needs to be wrapped in
> >
> > if [info exists env(MAKEFLAGS)] {
> >
>
> Done.
>
> > @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
> > if { $ogl !=
Thanks for clarifying the issue.
As you implicitly point out, GCC knows the type of INT64 and defines
the macro __INT64_TYPE__ . The revised code can use that directly,
such as:
#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
|| defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
typedef __INT64_TYPE__
On Wed, Jan 6, 2021 at 4:42 PM Jakub Jelinek wrote:
>
> On Wed, Jan 06, 2021 at 04:20:22PM -0500, David Edelsohn wrote:
> > Your response doesn't correspond to the patch nor to what I described.
> >
> > Nowhere did I say that int64_t must correspond to "long&quo
On Wed, Jan 6, 2021 at 2:37 PM Jakub Jelinek wrote:
>
> On Wed, Jan 06, 2021 at 01:38:25PM -0500, David Edelsohn via Gcc-patches
> wrote:
> > Is this an acceptable solution to determine the value at compile-time?
>
> This looks wrong to me. The fact that long is 64-b
On Wed, Jan 6, 2021 at 1:55 PM Marc Glisse wrote:
>
> On Wed, 6 Jan 2021, David Edelsohn via Gcc-patches wrote:
>
> > Currently the type of streamoff is determined at libstdc++ configure
> > time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_LONG and
> > _GLI
Use __SIZEOF_LONG__ and __SIZEOF_LONG_LONG__ to determine the type of
streamoff at compile time instead of _GLIBCXX_HAVE_INT64_T_LONG and
_GLIBCXX_HAVE_INT64_T_LONG_LONG.
Currently the type of streamoff is determined at libstdc++ configure
time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_L
On Mon, Dec 14, 2020 at 9:44 AM Rainer Orth
wrote:
>
> Hi David,
>
> > On Fri, Dec 4, 2020 at 5:35 AM Rainer Orth
> > wrote:
> >
> >> On AIX 7.2, there are changes like
> >>
> >> -PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
> >> symbol ^_?ir$ (found ir) has section ^\\.tb
On Sat, Dec 5, 2020 at 6:12 AM Alan Modra wrote:
>
> On Thu, Oct 29, 2020 at 10:10:58PM +1030, Alan Modra wrote:
> > Fixes
> > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x
> > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3
> > FAIL: gcc.target/powerpc/signbit
On Fri, Dec 4, 2020 at 5:35 AM Rainer Orth
wrote:
> On AIX 7.2, there are changes like
>
> -PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section symbol
> ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found _tls5.tls_[TL],4)
> +PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assem
On Thu, Nov 26, 2020 at 6:02 PM Jonathan Wakely wrote:
>
> On 26/11/20 22:33 +, Jonathan Wakely wrote:
> >On 26/11/20 15:33 -0500, David Edelsohn via Libstdc++ wrote:
> >>Hi, Jonathan
> >>
> >>Thanks for the recent fixes. I still see a few errors that
Hi, Thomas
Actually, yes, AIX does allow dereference of a NULL pointer.
Thanks, David
On Fri, Nov 27, 2020 at 9:15 AM Thomas Schwinge wrote:
>
> Hi David!
>
> On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches
> wrote:
> > On Tue, Nov 24, 2020 at 5:19 AM Thomas
On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2020-11-21T10:50:10-0500, David Edelsohn wrote:
> > I see
> >
> > "during GIMPLE pass: omplower"
> >
> > message for kernels-decompose-ice-2.c. kernels-decompose-ic
ly via Gcc-patches wrote:
> >>
> >> > On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
> >> > wrote:
> >> >> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
> >> >> fixes. And a few c++ failures with
I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes. And a few c++ failures with similar symptoms. I'm not certain
that it is due to this patch, but it's the likely suspect.
FAIL: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++
id
On Tue, Nov 17, 2020 at 8:18 PM David Edelsohn wrote:
>
> Hi, Thomas
>
> The patch resolves the "no such variable" error message, but I see
>
> "during GIMPLE pass: omplower"
>
> excess error message.
>
> I installed Tcl 8.6 with Expect 5.45.
On Sat, Nov 21, 2020 at 12:37 AM Michael Meissner
wrote:
>
> PowerPC: require IBM long double for pr70117.
>
> Since the test is explicitly checking for IBM extended double, do not try to
> run it when long double is IEEE 128-bit.
>
> I have tested this patch and the first patch in the series on a
On Fri, Nov 20, 2020 at 2:48 AM Richard Biener
wrote:
>
> On Fri, Nov 20, 2020 at 12:58 AM Segher Boessenkool
> wrote:
> >
> > On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > > > No, the vast majority of people will *not* (consciously) use them,
> > > > because the target defaults w
On Thu, Nov 19, 2020 at 1:54 AM Kewen.Lin wrote:
>
> Hi,
>
> The insn type of p8_mtvsrd_df looks missed to be updated
> with mtvsr. Here I supposed mtvsrd's all usages should
> be with the same insn type.
>
> This patch is to fix its current insn type mfvsr by mtvsr.
>
> Is it ok for trunk?
>
> B
On Wed, Nov 4, 2020 at 11:44 AM Carl Love wrote:
>
> David:
>
> I have reworked the patch moving the new vector instruction patterns to
> vsx.md. Also, cleaned up the vector division instructions. The
> div3 pattern definitions are the only ones that should be
> defined.
>
> I have retested the
cur for Fortran.
I guess that the patch is necessary because there seems to be
something else still behaving differently on AIX.
Any insights?
Thanks, David
On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn wrote:
>
> Hi, Thomas
>
> The standard version of Tcl installed on AIX curren
here that comes from and why it doesn't
appear on other targets? Does that need to be captured and ignored?
Thanks, David
On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge
wrote:
>
> Hi David!
>
> While you were writing your email, I've also been busy:
>
> On 2020
On Mon, Nov 16, 2020 at 3:41 PM Jeff Law wrote:
>
> On 11/14/20 7:08 PM, David Edelsohn wrote:
> > On Sat, Nov 14, 2020 at 8:58 PM Jeff Law wrote:
> >>
> >> On 11/14/20 6:35 PM, David Edelsohn wrote:
> >>>>>>>> Jeffrey Law wrote:
> &g
On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge wrote:
>
> Hi David!
>
> Thanks for reporting.
>
> On 2020-11-15T15:47:15-0500, David Edelsohn wrote:
> > I am seeing a number of new failures on AIX related to the OpenACC
> > kernels patches.
> >
> > c-c+
Thomas,
I am seeing a number of new failures on AIX related to the OpenACC
kernels patches.
c-c++-common/goacc/kernels-decompose-1.c
c-c++-common/goacc/kernels-decompose-2.c
gfortran.dg/goacc/kernels-decompose-1.f95
gfortran.dg/goacc/kernels-decompose-2.f95
libgomp.oacc-c++/../libgomp.oacc-c-c++-
On Sat, Nov 14, 2020 at 8:58 PM Jeff Law wrote:
>
>
> On 11/14/20 6:35 PM, David Edelsohn wrote:
> >>>>>> Jeffrey Law wrote:
> >> I worry a bit about the less common native targets -- aix, hpux and the
> >> like. But testing them is too painful
> Jeffrey Law wrote:
> I worry a bit about the less common native targets -- aix, hpux and the
> like. But testing them is too painful to contemplate these days. I'm
> sure those with access to suitable hardware will chime in if something
> is amiss.
All of these testcases now fail on AIX w
rs6000: Fix bootstrap after r11-4793.
The patch omitted a change for rs6000.c, fixed thus.
gcc/ChangeLog:
* config/rs6000/rs6000.c
(rs6000_mangle_decl_assembler_name): ChangeDECL_IS_BUILTIN
-> DECL_IS_UNDECLARED_BUILTIN.
diff --git a/gcc/config/rs6000/rs6000.
On Tue, Nov 3, 2020 at 4:18 PM Nathan Sidwell wrote:
>
> AIX needed a fixinclude. It contained
>
> typedef struct {...} *ptr;
>
> that's an ODR landmine. Fixed by giving the struct a name
Okay.
Thanks, David
On Mon, Nov 2, 2020 at 4:11 AM Kewen.Lin wrote:
> >> Hi,
> >>
> >> As Segher's suggestion in the PR, for 128bit_direct_move, this new
> >> version leverages vector pack insns instead of vector perms with
> >> one control vector. The performance evaluation shows that it's on
> >> par with the pre
On Fri, Oct 30, 2020 at 4:07 PM Carl Love wrote:
>
> GCC maintainers:
>
> The following patch adds new builtins for the vector integer multiply,
> divide and modulo operations. The builtins are:
> vec_mulh(), vec_div(), vec_dive(), vec_mod() for signed and unsigned
> integers and long long intege
On Fri, Oct 30, 2020 at 4:07 PM Carl Love wrote:
> diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
> b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
> new file mode 100644
> index 000..549bc742d12
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/power
On Fri, Oct 30, 2020 at 12:36 PM Carl Love wrote:
>
> David:
>
> On Wed, 2020-10-28 at 20:43 -0400, David Edelsohn wrote:
> > Better, but please use
> >
> > /* { dg-require-effective-target int128 } */
> >
> > not "target int128" in the selector
The 20_util/unique_ptr/creation/for_overwrite.cc test relies on
operator new, which requires special features on AIX. This patch
disables the testcase.
Thanks, David
--- a/libstdc++-v3/testsuite/20_util/unique_ptr/creation/for_overwrite.cc
+++ b/libstdc++-v3/testsuite/20_util/unique_ptr/creation
On Thu, Oct 29, 2020 at 12:53 AM Alan Modra wrote:
>
> On Wed, Oct 28, 2020 at 11:35:07PM -0400, David Edelsohn wrote:
> > Alan,
> >
> > It is disrespectful for you to ignore the review of a maintainer and
> > your colleague. You may not pick and choose amongs
On Wed, Oct 28, 2020 at 7:28 PM Alan Modra wrote:
>
> On Wed, Oct 28, 2020 at 01:44:54PM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 28, 2020 at 09:18:35PM +1030, Alan Modra wrote:
> > > >From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
> > > From: Alan Modra
> > > Date
On Wed, Oct 28, 2020 at 7:21 PM Carl Love wrote:
>
> David:
>
> On Sat, 2020-10-24 at 11:29 -0400, David Edelsohn wrote:
> > Hi, Carl
> >
> > Not commenting on the implementation.
> >
> > Please stop using powerpc*-*-* in the test cases. The test cases
On Wed, Oct 28, 2020 at 6:46 AM Alan Modra wrote:
>
> commit 25ffd3d34e means we no longer define an overloaded
> __builtin_byte_in_set for -m32, so the more informative
> "__builtin_byte_in_set is not supported in this compiler
> configuration" is not reported.
>
> Regression tested powerpc64-lin
On Wed, Oct 28, 2020 at 6:48 AM Alan Modra wrote:
>
> From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
> From: Alan Modra
> Date: Wed, 28 Oct 2020 15:57:57 +1030
> Subject:
>
> I noticed this test is unsupported on power10 when looking through
> test logs. There seems no re
On Wed, Oct 28, 2020 at 6:26 AM Alan Modra wrote:
>
> git commit badeac77f552 changed expected number of addi instructions,
> causing these fails on powerpc-linux.
>
> gcc.target/powerpc/fold-vec-insert-int-p9.c: \\maddi\\M found 12 times
> FAIL: gcc.target/powerpc/fold-vec-insert-int-p9.c scan-as
The current COARRAYS branch correctly bootstraps on AIX. Thanks for
correcting the contents and ordering of the header files.
Thanks, David
On Tue, Oct 27, 2020 at 1:31 PM Thomas Koenig wrote:
>
> I just committed
>
> https://gcc.gnu.org/g:0c261d5b5c931d9e9214d06531bdc7e9e16aeaab
>
> to hopeful
On Mon, Oct 26, 2020 at 7:35 PM Alan Modra wrote:
> $ grep mcmodel gcc/config/rs6000/*.opt
> gcc/config/rs6000/aix64.opt:mcmodel=
> gcc/config/rs6000/aix64.opt:Known code models (for use with the -mcmodel=
> option):
> gcc/config/rs6000/linux64.opt:mcmodel=
> gcc/config/rs6000/linux64.opt:Known
FAIL: gcc.target/powerpc/swaps-p8-22.c (test for excess errors)
Excess errors:
cc1: error: '-mcmodel' not supported in this configuration
* gcc.target/powerpc/swaps-p8-22.c: Disable for -m32.
diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-22.c
b/gcc/testsuite/gcc.target/powerpc/swaps-p8-2
On Sun, Oct 25, 2020 at 7:20 AM Alan Modra wrote:
>
> All these tests fail with -m32 due to lack of int128 support, in some
> cases with what I thought was not the best error message. For example
> vsx_mask-move-runnable.c:34:3: error: unknown type name 'vector'
> is misleading. The problem isn'
Hi, Carl
Not commenting on the implementation.
Please stop using powerpc*-*-* in the test cases. The test cases
already are in the gcc.target/powerpc directory.
Do the test cases really need lp64, or should this require something
like int128?
Thanks, David
On Fri, Oct 23, 2020 at 9:56 PM Carl
This patch broke bootstrap on AIX.
/nasfarm/edelsohn/src/src/libgomp/target.c: In function
'gomp_target_init.part.':
/nasfarm/edelsohn/src/src/libgomp/target.c:3367:45: error: array
subscript [-19877956975980120, 19877956975980120] is outside array
bounds of 'struct gomp_device_descr[0]' [-Werror=
xvcvhpsp instruction converts a vector of bfloat16 half precision to single
precision. The intrinsics vextract_fp_from_shorth and
vextract_fp_from_shortl select the high or low four elements of a
half precision vector to convert. The intrinsics use vperm to select
the appropri
It also is confusing for the patch to perform
$(ARX) -X32_64
when immediately before the fragment created ARX by explicitly
stripping -X32_64. If it's going to perform
ar -X32_64
it should use the normal $(AR) variable.
Thanks, David
On Thu, Oct 8, 2020 at 5:06 AM CHIGOT, CLEMENT wrote:
>
>
This solution doesn't really appeal to me, but there aren't any good options.
AIX caches shared objects in memory for faster startup. If the
archive file permissions do not include read-other (world readable),
the shared object is not cached. But using this option might cause
permission problem
On Thu, Oct 1, 2020 at 8:02 PM Andrew MacLeod wrote:
>
> On 10/1/20 5:30 PM, David Edelsohn wrote:
> >>> * config/rs6000/rs6000-call.c: Include value-range.h.
> >>> * config/rs6000/rs6000.c: Likewise.
> >> This is okay for trunk, thanks! (It is trivial a
> > * config/rs6000/rs6000-call.c: Include value-range.h.
> > * config/rs6000/rs6000.c: Likewise.
>
> This is okay for trunk, thanks! (It is trivial and obvious as well, so
> please just commit things like this without prior approval.)
This patch is not the correct long-term solution, as I explai
-ibm-aix7.2.0.0
Thanks, David
gcc/ChangeLog:
2020-09-26 David Edelsohn
Clement Chigot
* collect2.c (visibility_flag): New.
(main): Detect -fvisibility.
(write_c_file_stat): Push and pop default visibility.
0001-aix-collect2
On Thu, Aug 27, 2020 at 9:21 AM Bill Schmidt wrote:
>
> Prior to P10, ELFv2 hasn't implemented nonlocal sibcalls. Now that we do,
> we need to be sure that r12 is set up prior to such a call.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions. Is this okay for tru
y, more than enough of each.
> >
> > It is very very VERY hard to review this without being told the proper
> > setting here.
> >
>
> What this is about:
>
> David Edelsohn wanted to have new library functions, one for each of these 6
> single-precision functi
On Mon, Jul 13, 2020 at 8:06 AM Florian Weimer wrote:
>
> The intent was that this was implied by powerpc64-unknown-linux-gnu,
> but this not very obvious because of the ELFv1 vs ELFv2 ABI
> differences.
It's okay to _add_ PPC64LE without removing PPC64. This is okay.
I'm not certain why it's u
On Thu, Jul 30, 2020 at 11:55:19AM +0200, Richard Biener wrote:
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> OK for trunk and backports?
I'd go with it for trunk and 10.2.1 now and consider further backports
later. Maybe even defer the 10.2.1 backport for two weeks.
I believ
On Thu, Jul 30, 2020 at 1:22 AM HAO CHEN GUI wrote:
>
> David,
>
> Seems there is something wrong with my email box. I lost your email. I
> reconfigured the box and it should be OK now.
>
> Could you inform me how to exclude AIX from the condition testing? By
> the ABI? Thanks a lot.
The purpose
/value_init.cc testcase.
Bootstrapped on powerpc-ibm-aix7.2.0.0
Okay?
Thanks, David
2020-07-28 David Edelsohn
Jonathan Wakely
* testsuite/lib/dg-options.exp (add_options_for_libatomic): Add
target powerpc-ibm-aix*.
* testsuite
On 2020/7/28 下午1:25, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>
> This patch adds non-relative jump table support for 64bit rs6000. It
> implements ASM_OUTPUT_ADDR_VEC_ELT and corresponding expansion of jump table
> instruction for 64bit rs6000. We want to put non-relative jump table in
> data.
On Fri, Jul 24, 2020 at 5:01 AM CHIGOT, CLEMENT wrote:
>
> Description:
> This patch adds the support to build 64bit GCC applications on AIX 7.1
The patch was not correct because defaultaix64.h substitutes POWER7
target default in 64 bit mode, which AIX 7.1 defaults to POWER4.
PPC64 Linux
On Tue, Jul 21, 2020 at 5:54 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Tue, Jul 21, 2020 at 05:54:27AM -0500, Xiong Hu Luo wrote:
> > --- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c
> > @@ -3,7 +3,7 @@
> >
On Tue, Jul 21, 2020 at 4:04 AM Richard Biener
wrote:
>
> On Fri, Jul 10, 2020 at 4:54 PM David Edelsohn wrote:
> >
> > On Fri, Jul 10, 2020 at 2:55 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Jul 9, 2020 at 8:29 PM David Edelsohn wrote:
> >
H-P,
After your patch to the testsuite, the cpp/pragma-eof.c testcase is
failing on all targets. Would you please investigate and fix?
Thanks, David
Unfortunately this patch is eliciting a number of new testsuite
failures, all like
error: unrecognizable insn:
(insn 44 43 45 5 (parallel [
(set (reg:SI 199)
(unspec:SI [
(reg:SF 202)
] UNSPEC_SI_FROM_SF))
(clobber
On Fri, Jul 10, 2020 at 2:55 AM Richard Biener
wrote:
>
> On Thu, Jul 9, 2020 at 8:29 PM David Edelsohn wrote:
> >
> > output_constant_def_contents() can call get_constant_section() with an
> > EXP that is a CONSTRUCTOR, which is not a declaration. This can hit
> &g
it with direct calls to targetm.asm_out.select_section() (for which it
now is a complete pass-through), and update the Target Hook
documentation.
What's the preferred path forward?
Thanks, David
gcc/ChangeLog
2020-07-09 David Edelsohn
* varasm.c (get_constant_section): Change
patch or do you want me to?
Thanks, David
On Thu, Jul 2, 2020 at 11:47 AM David Edelsohn wrote:
>
> Mark,
>
> A quick test with
>
> const char hint [] = _(" [see %<-fno-allow-invalid-boz%>]");
>
> reproduces the failure.
>
> const char *hint = _(&q
e to commit it if it works or do you want me to report it to you?
Thanks, David
On Thu, Jul 2, 2020 at 9:38 AM David Edelsohn wrote:
>
> On Thu, Jul 2, 2020 at 8:56 AM Mark Eggleston
> wrote:
> >
> > On 02/07/2020 13:25, David Edelsohn wrote:
> > > On Thu, J
On Thu, Jul 2, 2020 at 8:56 AM Mark Eggleston
wrote:
>
> On 02/07/2020 13:25, David Edelsohn wrote:
> > On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
> > wrote:
> >> I've committed the change from array to pointer. Does this fix your builds?
> >>
>
On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
>
> I've committed the change from array to pointer. Does this fix your builds?
>
> On 02/07/2020 08:18, Mark Eggleston wrote:
> > On 01/07/2020 20:07, David Edelsohn wrote:
> >> This patch breaks bootstrap.
>
n Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
>
> I've committed the change from array to pointer. Does this fix your builds?
>
> On 02/07/2020 08:18, Mark Eggleston wrote:
> > On 01/07/2020 20:07, David Edelsohn wrote:
> >> This patch breaks bootstrap.
> &
This patch breaks bootstrap.
It is not portable to use _( ... ) to initialize an array.
In file included from /nasfarm/edelsohn/src/src/gcc/fortran/gfortran.h:52,
from /nasfarm/edelsohn/src/src/gcc/fortran/check.c:32:
/nasfarm/edelsohn/src/src/gcc/fortran/check.c: In function 'bo
Why did you mark PR96008 as a duplicate? The ICE is a duplicate, but
the wrong IL is a C++ FE bug.
Thanks, David
On Tue, Jun 30, 2020 at 1:45 PM Martin Sebor wrote:
>
> On 6/30/20 10:47 AM, David Edelsohn wrote:
> > Also, cpp1y/lambda-generic-69078-1.C elicits a similar,
2020 at 12:23 PM David Malcolm wrote:
>
> On Tue, 2020-06-30 at 10:12 -0600, Martin Sebor wrote:
> > On 6/30/20 8:47 AM, David Edelsohn via Gcc-patches wrote:
> > > The unexpected warning is
> > >
> > > gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warn
o be adjusted in the testsuite to
account for this?
Thanks, David
On Tue, Jun 30, 2020 at 10:18 AM David Malcolm wrote:
>
> On Tue, 2020-06-30 at 09:51 -0400, David Edelsohn wrote:
> > The changes to the non-null warning now produce an additional warning
> > for analyzer/pr940
The changes to the non-null warning now produce an additional warning
for analyzer/pr94028.C on one of the "leak" lines. This causes new
failures on trunk.
Because non-null is not the purpose of the analyzer test, I propose
pruning the output to resolve the new failures. Alternatively, I
could e
On Wed, Jun 24, 2020 at 3:33 AM Richard Biener
wrote:
>
> On Tue, Jun 23, 2020 at 10:37 PM Ilya Leoshkevich via Gcc-patches
> wrote:
> >
> > Hello,
> >
> > I needed to test [1] on AIX and OpenBSD and noticed
> > download_prerequisites doesn't work there. The attached patch fixes
> > it.
> >
> > O
This patch removes ifneq from Makefile fragments in gcc/Makefile.in
and empty.mk in libgcc/Makefile.in.
GNU Make supports the "-include" keyword to prevent warnings and errors due to
inclusion of non-existent files. This patch changes gcc/ and libgcc/ to use
"-include" in place of the historical
On Sun, Mar 29, 2020 at 6:44 AM Richard Sandiford
wrote:
>
> David Edelsohn writes:
> > On Sat, Mar 28, 2020 at 6:42 AM Richard Sandiford
> > wrote:
> >>
> >> David Edelsohn via Gcc-patches writes:
> >> > This patch is for an AIX problem, but t
Hi, Will
On Fri, Jun 12, 2020 at 12:22 AM will schmidt wrote:
>
>
> Hi,
> Fix codegen implementation for the builtin vec_pack_to_short_fp32.
>
> Regtests are underway against powerpc64 (power7be,power8le,power9le).
> (this is a power9 builtin, so should be a noop for most of those).
> OK
On Wed, Jun 3, 2020 at 3:14 PM Iain Sandoe wrote:
>
> Hi David,
>
> thanks for working on this!
>
> David Edelsohn wrote:
>
> > [I'll start by repeating what I wrote about a similar libgcc change to
> > provide background and context.]
> >
> >
On Wed, Jun 3, 2020 at 2:38 PM Richard Biener
wrote:
>
> On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool
> wrote:
> >On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote:
> >> >> mask = vec_cmp of the comparison
> >> >> true_masked = true_op & mask;
> >> >> false_masked
On Wed, Jun 3, 2020 at 9:41 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jun 2, 2020 at 5:00 PM Martin Liška wrote:
> >>
> >> On 6/2/20 1:09 PM, Richard Biener wrote:
> >> > So please be constructive. Like, provide a testcase that ICEs
> >> > with the FAILs replaced by gcc
On Tue, Jun 2, 2020 at 4:32 PM Segher Boessenkool
wrote:
>
> Hi Xiong Hu,
>
> On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> > Double array in structure as function arguments or return value is accessed
> > by BLKmode, they are stored to stack and load from stack with redundant
> >
st: Add system configury stanza. Define tmake_file.
* config/t-aix: New file.
* empty.mk: New file.
From cf96afed42fcda9debb1351e86b511316ee4d781 Mon Sep 17 00:00:00 2001
From: David Edelsohn
Date: Fri, 15 May 2020 17:46:08 -0400
Subject: [PATCH] FAT target library support
libgomp/
When AIX added 64 bit support, it implemented what Apple MacOS Darwin
calls "FAT" libraries for its equivalent functionality -- both 32 bit
and 64 bit objects (or shared objects) are co-located in the same
archive. GCC on AIX historically has followed the GCC multilib
directory hierarchy approach
On Mon, May 25, 2020 at 1:58 PM Richard Biener
wrote:
>
> On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool
> wrote:
> >On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote:
> >> On Mon, May 25, 2020 at 1:10 PM guojiufu
> >wrote:
> >> Since a new flag is not needed to fix the r
TL;DR: This patch updates configure.ac and Makefile.in in libcpp and
libdecnumber to substitute AR archiver.
AIX supports "FAT" libraries containing 32 bit and 64 bit objects
(similar to Darwin), but commands for manipulating libraries do not
default to accept both 32 bit and 64 bit object files.
On Mon, May 18, 2020 at 9:38 AM Iain Buclaw wrote:
>
> Hi,
>
> Looking at the results of building all targets (with D the front-end),
> I noticed this configuration failed due to support being removed in
> SVN r263506.
>
> OK?
>
> Regards,
> Iain.
>
> ---
> contrib/ChangeLog:
>
> * config-
On Mon, May 11, 2020 at 10:56 PM Bill Schmidt wrote:
>
> On 5/11/20 9:48 AM, David Edelsohn wrote:
> > On Sun, May 10, 2020 at 9:14 AM Bill Schmidt wrote:
> >> From: Kelvin Nilsen
> >>
> >> Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
>
On Sun, May 10, 2020 at 9:14 AM Bill Schmidt wrote:
>
> From: Kelvin Nilsen
>
> Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
> vextddvhx, along with built-in access and overloaded built-in
> access to these insns.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with n
On Sat, May 9, 2020 at 9:16 AM Bill Schmidt wrote:
>
> From: Kelvin Nilsen
>
> Adds new instructions vstribr, vstrihr, vstribl, and vstrihl, with
> overloaded built-in support.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions, using a compiler configured for Powe
On Sat, May 9, 2020 at 9:08 PM Bill Schmidt wrote:
>
> From: Kelvin Nilsen
>
> Changes to the built-in specification occurred after early patches
> added support for these. The name of vec_clzm became vec_cntlzm,
> and vec_ctzm became vec_cnttzm. Four of the overloaded forms of
> vec_gnb were r
301 - 400 of 2119 matches
Mail list logo
