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
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 and obvious as well, so
> >> please just
> > * 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
The code that collect2 generates, compiles and links into applications
and shared libraries to initialize constructors and register DWARF tables
is built with the compiler options used to invoke the linker. If the
compiler options change the visibility from default, the library
initialization
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
The Power Vector ABI is available at
https://github.com/power8-abi-doc/vector-function-abi
It apparently did not attach correctly to the sourceware wiki or the
filename is different.
Thanks, David
On Mon, Aug 17, 2020 at 1:44 PM GT wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday,
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
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
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
atomic_float/value_init.cc requires libatomic on some targets, i.e.,
when it tries to perform an atomic operation with a 64 bit floating
point double type on a 32 bit target. This patch adds AIX to the list
of targets that require the libatomic option and adds the option to
the
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
>
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:
> > > >
> > > > output_constant_def_contents() can
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))
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
> > asserts in GCC machinery to
output_constant_def_contents() can call get_constant_section() with an
EXP that is a CONSTRUCTOR, which is not a declaration. This can hit
asserts in GCC machinery to choose a named section for the initialization
data that expects the parameters to be DECLs.
get_constant_section() is a wrapper
Mark,
A full bootstrap is successful with the translation markers restored
and declaring hint as "const char *".
const char *hint = _(" [see %<-fno-allow-invalid-boz%>]");
I assume that the translation system works correctly for that style.
Do you want to apply the patch or do you want me to?
Mark,
A quick test with
const char hint [] = _(" [see %<-fno-allow-invalid-boz%>]");
reproduces the failure.
const char *hint = _(" [see %<-fno-allow-invalid-boz%>]");
seems to work. I will do a full bootstrap test with that change later today.
Do you want me to commit it if it works or do
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 02/07/2020 08:18, Mark Eggleston 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 02/07/2020 08:18, Mark Eggleston wrote:
> > On 01/07/2020 20:07, David Edelsohn wrote:
> >> This patch breaks bootstrap.
> >
> > Apologies. I didn't see this
I already had removed your change. I hope that you did not re-break bootstrap.
You should be re-producing the breakage and then confirming the fix,
not randomly applying patches and asking others if you didn't break it
again. That is not appropriate for GCC development.
Thanks David
On Thu,
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
operator() (0B, D.2440) >>>>>;
> return;
>
> Martin
>
> >
> > Thanks, David
> >
> > On Tue, Jun 30, 2020 at 12:23 PM David Malcolm wrote:
> >>
> >> On Tue, 2020-06-30 at 10:12 -0600, Martin Sebor wrote:
> >>>
: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: warning: use o
The unexpected warning is
gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warning: use of
possibly-NULL '' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]
This is the same location as one of the existing "leak" warnings.
How would you like pr94028.C to be adjusted in the
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
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.
> >
> >
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.]
> >
> > When AIX added 64 bit support, it implemented what
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
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
>
[I'll start by repeating what I wrote about a similar libgcc change to
provide background and context.]
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
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
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:
>
> *
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
> >> vextddvhx, along with built-in access
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
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
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
On Fri, May 8, 2020 at 9:13 PM Bill Schmidt wrote:
>
> From: Kelvin Nilsen
>
> Add the xxeval insn and access it via the vec_ternarylogic built-in
> function. As part of this, add support to the built-in function
> infrastructure for functions that take four arguments.
>
> Bootstrapped and
On Wed, Apr 29, 2020 at 7:48 AM Jakub Jelinek wrote:
>
> Hi!
>
> This is the rs6000 version of the earlier committed x86, aarch64 and arm
> fixes, as create_tmp_var_raw is used because the C FE can call this outside
> of function context, we need to make sure the first references to those
>
On Tue, Apr 28, 2020 at 4:02 PM Jakub Jelinek wrote:
>
> On Tue, Apr 28, 2020 at 05:42:00PM +0200, Jakub Jelinek wrote:
> > Ok, below in the updated patch:
>
> This is what I've successfully bootstrapped/regtested on powerpc64le-linux
> (last posted patch with the lto-common.c addition included).
While looking up C++14 information, I noticed that some links in
current navigation pages refer to cxx1y.html instead of
cxx-status.html. This patch changes the NEWS item to refer to
cxx-status.html#cxx14 and the Projects index to refer to C++ language
features instead of C++14 language features.
On Sat, Apr 25, 2020 at 6:03 AM Jakub Jelinek wrote:
>
> Hi!
>
> As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14
> vs. C++17 ABI incompatibilities which are not fixed by mere adding of
> cxx17_empty_base_field_p calls. Unlike the issues that were seen on other
> targets
On Thu, Apr 23, 2020 at 12:13 PM Bill Schmidt wrote:
>
> A user reported that we are still referring to a public review
> draft of the ELFv2 ABI specification. Replace that by a permalink.
>
> Tested with "make pdf" and verified the link is hot. Is this okay
> for master?
>
> Thanks,
> Bill
>
>
On Thu, Apr 2, 2020 at 5:30 AM CHIGOT, CLEMENT wrote:
>
> Description:
> * AIX applications using 128-bit long double must be linked with
>libc128.a, in order to have 128-bit compatible routines.
>
> Tests:
> * AIX 7.2, 7.1: Build/Tests: OK
>
> Changelog:
> * config/rs6000/aix61.h
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 the only robust solution is in
> > common code: calls.c:precompute_register_parameters().
> >
> > AIX, like other platf
This patch is for an AIX problem, but the only robust solution is in
common code: calls.c:precompute_register_parameters().
AIX, like other platforms, needs to call a function to obtain the
pointer to thread-local storage. If the thread local variable is
referenced as a parameter to a function
301 - 355 of 355 matches
Mail list logo
