On Wed, Apr 21, 2021 at 3:42 PM Martin Liška wrote:
>
> On 4/21/21 6:03 PM, David Edelsohn via Gcc-patches wrote:
> > I am requesting a freeze on non-bug fix patches to trunk.
> >
> > In the GCC 12 announcement, Jakub stated:
> >
> > "The trunk has branch
On Wed, Apr 21, 2021 at 3:16 PM Jakub Jelinek wrote:
>
> On Wed, Apr 21, 2021 at 08:28:55PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > There's a patch attempt for the problem with
> > > std::thread::hardware_concurrency where
> > > it's used only if _GLIBCXX_HAS_GTHREADS is set.
> > >
> >
I am requesting a freeze on non-bug fix patches to trunk.
In the GCC 12 announcement, Jakub stated:
"The trunk has branched for the GCC 11 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during the RC phase of GCC 11 so it
is possible
This patch broke bootstrap on AIX.
std::thread is not provided in all instances. GCC is not compiled
multi-threaded by default.
error: `std::thread' has not been declared.
Thanks, David
Hi, Jonathan
Thanks for the further investigation. I definitely encountered the
missing _M_try_acquire in __platform_semaphore.
Thanks, David
On Wed, Apr 21, 2021 at 8:12 AM Jonathan Wakely wrote:
>
> On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
> >On 20/04/21 22:12 -0700, Thomas Rodgers
On 4/16/21 8:56 AM, Bill Schmidt via Gcc-patches wrote:
> The standard for many Power vector interfaces is now the recently
> published Power Vector Intrinsics Programming Reference. Reference
> that document for the relevant interfaces, and remove redundant
> information from the GCC user's
AIX uses a compiler-managed TOC for global data, including TLS symbols.
The GCC TOC implementation manages the TOC entries through the
constant pool.
TLS symbols sometimes require a function call to obtain the TLS base
pointer. The arguments to the TLS call can conflict with
On Thu, Apr 1, 2021 at 12:45 AM Martin Liška wrote:
>
> On 3/31/21 8:45 PM, David Edelsohn via Gcc-patches wrote:
> > This patch is causing new crashes in the testsuite.
> >
> > ICE in release_body, at graph.c:1863
> > ranges offset out of range
This patch is causing new crashes in the testsuite.
ICE in release_body, at graph.c:1863
ranges offset out of range
Thanks, David
GCC currently emits TLS relocation decorations on symbols in DWARF sections.
Recent changes to the AIX linker cause it to reject such symbols.
This patch removes the decorations (@ie, @le, @m) and emit only the
qualified symbol name.
Bootstrapped on powerpc-ibm-aix7.3.2.0.
On Fri, Mar 26, 2021 at 11:27 PM Xionghu Luo wrote:
>
> From: "luo...@cn.ibm.com"
>
> 32bit and P7 VSX could also benefit a lot from the variable vec_insert
> implementation with shift/insert/shift back method.
>
> Tested pass on P7BE/P8BE/P8LE{-m32,m64} and P9LE{m64}.
I successfully
On Wed, Mar 24, 2021 at 11:30 AM Iain Sandoe wrote:
>
> David Edelsohn via Gcc-patches wrote:
>
> > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
> > wrote:
> >> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
> >>> On Mon, Mar 22, 2
On Wed, Mar 24, 2021 at 11:32 PM Xionghu Luo wrote:
>
> On 2021/3/24 23:56, David Edelsohn wrote:
> > On Wed, Mar 24, 2021 at 1:44 AM Xionghu Luo wrote:
> >> l2 cache size for Power8 is 512kB, correct the copy paste error from
> >> Power7.
> >> Tested no performance change for SPEC2017.
> >>
>
On Wed, Mar 24, 2021 at 3:46 PM David Edelsohn wrote:
>
> On Wed, Mar 24, 2021 at 11:30 AM Iain Sandoe wrote:
> >
> > David Edelsohn via Gcc-patches wrote:
> >
> > > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
> > > wrote:
> > >>
On Wed, Mar 24, 2021 at 11:30 AM Iain Sandoe wrote:
>
> David Edelsohn via Gcc-patches wrote:
>
> > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
> > wrote:
> >> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
> >>> On Mon, Mar 22, 2
On Wed, Mar 24, 2021 at 1:44 AM Xionghu Luo wrote:
>
> l2 cache size for Power8 is 512kB, correct the copy paste error from Power7.
> Tested no performance change for SPEC2017.
>
> gcc/ChangeLog:
>
> 2021-03-24 Xionghu Luo
>
> * config/rs6000/rs6000.c (struct processor_costs): Change
On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
wrote:
>
> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
> >
> > On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
> > wrote:
> >
> > > Oh, and for a type like
> > >
> > > struct { struct { struct { ... { double x; } } } } } };
> > >
> > >
On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
wrote:
> Oh, and for a type like
>
> struct { struct { struct { ... { double x; } } } } } };
>
> the layout now looks quadratic in work (each field layout will look at
> the nest rooted at it
> up to the bottom). It looks to me as we require(?)
The AIX power alignment rules apply the natural alignment of the
"first member" if it is of a floating-point data type (or is an aggregate
whose recursively "first" member or element is such a type). The alignment
associated with these types for subsequent members use an alignment value
where the
Hao,
Segher and I do not doubt that the patch can improve the examples and
testcases. The question is if those examples are representative of
common situations and if the patch truly improves performance overall
-- for real workloads. Can you test the performance impact of your
patch, not only
On Wed, Mar 17, 2021 at 8:26 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Mar 17, 2021 at 03:35:30PM -0400, David Edelsohn wrote:
> > I disagree with your new definitions and I disagree with the manner in
> > which you are trying to change the values.
>
> Yes.
>
> > Your patch is NOT okay
Hao,
What are you trying to change? What are you trying to enable?
Section Anchors already are enabled in the rs6000 port.
MIN_ANCHOR_OFFSET and MAX_ANCHOR_OFFSET already are defined with other
values and for good reason. From rs6000.c:
/* Use a 32-bit anchor range. This leads to sequences
On Tue, Mar 16, 2021 at 10:23 PM HAO CHEN GUI wrote:
>
> Segher,
>
> The const_anchor should work on both 64 and 32 bit. I think the
> constant loading is cheap on 32 bit platform, so I only enabled it on
> 64 bit. I will add a test case and verify the patch on Darwin and AIX.
I will say
I suspect that this is incorrect. Did you look at the discussion of
the choice of anchor limits when first implemented? We specifically
chose 32 bit range.
Thanks, David
On Tue, Mar 16, 2021 at 10:21 AM will schmidt wrote:
>
> On Mon, 2021-03-15 at 11:11 +0800, HAO CHEN GUI via Gcc-patches
GCC on AIX generates thread local uninitialized data in the common section,
which could conflict with another module.
This patch changes the code generation to place static uninitialized
thread local data into the local common section specified with .lcomm.
This change also
AIX word-aligns floating point doubles. This behavior also extends to
double _Complex, which had been overlooked when compiler support for
double _Complex was added.
This patch adds DCmode to the modes whose alignment is adjusted and
adds a testcase to confirm the correct
The new pr99305.C testcase is failing on Power.
FAIL: g++.dg/opt/pr99305.C -std=gnu++14 scan-tree-dump-times
optimized " = (unsigned char) c_[0-9]*(D);" 3
FAIL: g++.dg/opt/pr99305.C -std=gnu++17 scan-tree-dump-times
optimized " = (unsigned char) c_[0-9]*(D);" 3
This patch adds missing periods to the symbol name for TLS helper functions.
Bootstrapped on powerpc-ibm-aix7.2.2.0.
Thanks, David
* config/rs6000/rs6000.md (tls_get_tpointer_internal): Prepend
period to symbol name.
(tls_get_addr_internal): Same.
diff
On Tue, Mar 2, 2021 at 8:48 AM Richard Sandiford
wrote:
>
> Alexandre Oliva writes:
> > On Feb 26, 2021, Segher Boessenkool wrote:
> >
> >> On Fri, Feb 26, 2021 at 12:31:16PM -0500, David Edelsohn wrote:
> >>> On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva
> >>> wrote:
> >>> >
> >>> > This
Alex,
dejagnu should not report that sqrt_insn is available on PowerPC in
confirmations when it is not. The correct fix and the one suggested
by Richard and Segher is to test for the availability of sqrt, not to
assume that it exists in PowerPC.
The test should not explicitly add
On Fri, Feb 26, 2021 at 11:14 AM Alexandre Oliva wrote:
>
> These tests use -mvsx in their dg-options list, so they are only
> applicable if the -mvsx option is supported by the compiler.
>
> Tested with target ppc64-vx7r2, configured to force altivec disabled,
> and thus to reject vsx. Ok to
On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva wrote:
>
> This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
> tests. Tested on x86_64-linux-gnu, and on the affected platform. Ok to
> install?
I'm sort of surprised that sqrt instruction would be available for the
target but
On Thu, Feb 25, 2021 at 8:05 PM Peter Bergner wrote:
>
> The initialization of compat builtins assumes the builtin we are creating
> a compatible builtin for exists and ICEs if it doesn't. However, there are
> valid reasons why some builtins are disabled for a particular compile.
> In this case,
On Thu, Feb 4, 2021 at 4:26 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Thu, Feb 04, 2021 at 09:26:47PM +0100, Jakub Jelinek wrote:
> > On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches
> > wrote:
> > > Jenkins does function on AIX. I w
Okay.
Thanks, David
On Mon, Feb 1, 2021 at 2:17 PM wrote:
>
> From: Aaron Sawdey
>
> In a previous fusion-combine patch for rs6000, Segher had asked me to
> comment out the automatic regeneration of fusion.md. And more recently
> Edelsohn pointed out that gcc_update needed to fix the timestamp
AIX only permits use of Altivec VSRs 20-31 in a Vector Extended ABI mode.
This patch explicitly enables use of the VSRs using the new -mabi=vec-extabi
command line option also implemented in LLVM for AIX.
Bootstrapped on powerpc-ibm-aix7.2.3.0 and powerpc64le-linux-gnu.
This patch is okay with the removal of
{ target powerpc*-*-* }
from the pr79251-run.c testcase directives.
As I explained in the earlier email, I still believe that the testcase
is not testing what you intend, but this patch is a definite
improvement and removes the failures. We can correct
On Tue, Jan 26, 2021 at 10:56 PM Xionghu Luo wrote:
>
> Hi,
>
> On 2021/1/27 03:00, David Edelsohn wrote:
> > On Tue, Jan 26, 2021 at 2:46 AM Xionghu Luo wrote:
> >>
> >> From: "luo...@cn.ibm.com"
> >>
> >> UNSPEC_SI_FROM_SF is not supported when TARGET_DIRECT_MOVE_64BIT
> >> is false for -m32,
On Tue, Jan 26, 2021 at 2:46 AM Xionghu Luo wrote:
>
> From: "luo...@cn.ibm.com"
>
> UNSPEC_SI_FROM_SF is not supported when TARGET_DIRECT_MOVE_64BIT
> is false for -m32, don't generate VIEW_CONVERT_EXPR(ARRAY_REF) for
> variable vector insert. Remove rs6000_expand_vector_set_var helper
>
On Tue, Jan 26, 2021 at 1:11 PM will schmidt wrote:
>
> On Tue, 2021-01-26 at 01:46 -0600, Xionghu Luo via Gcc-patches wrote:
> > From: "luo...@cn.ibm.com"
> >
> > (rs6000_expand_vector_set_var): Delete.
>
> The diff conflates the deleted function with the changes to an existing
>
Those are the fold-vec-extract-* changes. And they fix a regression
on AIX. Another difference to detangle.
I'm referring to the new fold-vec-insert-* failures. I fixed the p9
failures, but some of the tests now ICE when targeting P8.
Thanks, David
On Fri, Jan 22, 2021 at 8:03 PM Segher
On Thu, Jan 21, 2021 at 6:51 PM Segher Boessenkool
wrote:
>
> Hi!
>
> You never committed 2/4? That makes it harder to review this one :-)
>
> On Sat, Oct 10, 2020 at 03:08:24AM -0500, Xionghu Luo wrote:
> > gcc/ChangeLog:
> >
> > 2020-10-10 Xionghu Luo
> >
> > *
All of these testcases no fail on AIX. This was not tested properly.
Please fix.
Thanks, David
On Thu, Jan 21, 2021 at 7:19 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Sat, Oct 10, 2020 at 03:08:25AM -0500, Xionghu Luo wrote:
> > 2020-10-10 Xionghu Luo
> >
> > *
aix: make ctype_inline.h thread-safe and avoid _OBJ_DATA char subscript.
g++.dg/warn/Wstringop-overflow-6.C tests for a bogus overflow warning in
system headers. This testcase was generating a -Wchar-subscript warning
on AIX because ctype_inline.h was subscripting AIX _OBJ_DATA
Thanks for fixing this, Jeff.
I didn't realize that the testcase was testing the explicit source
code line number hard coded the expected DWARF output.
It would have been nice if the testcase included a comment about the
purpose and to alert people that the expected output needs to change
if
On Mon, Jan 18, 2021 at 11:49 AM Jakub Jelinek wrote:
>
> On Mon, Jan 18, 2021 at 11:31:37AM -0500, David Edelsohn via Gcc-patches
> wrote:
> > On Mon, Jan 18, 2021 at 6:01 AM Mark Wielaard wrote:
> > >
> > > Hi David,
> > >
> > > On Sun, Jan
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 version to 4 unless explicitly
> >
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.
*
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
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 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
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
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
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:
> > On Thu, Jan
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". The patch
> > specifically chooses
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
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
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
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:
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
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 have crept
> >>in on AIX. All the same:
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-ice-1.c
> > explicitly prunes that output, but
On Mon, Nov 23, 2020 at 1:31 PM Jonathan Wakely wrote:
>
> On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:
> >On Sun, 22 Nov 2020, 12:29 Iain Sandoe, wrote:
> >
> >> thanks for looking at this over the weekend.
> >>
> >> Jonathan Wakely via Gcc-patches wrote:
> >>
> >> > On Sat,
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:
Hi, Thomas
I see
"during GIMPLE pass: omplower"
message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c
explicitly prunes that output, but kernels-decompose-ice-2.c does not.
Is there a reason that the second testcase does not prune that output
or can we add it?
Thanks, David
On
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
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
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?
>
>
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
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. This removes the "no such
variable" error messages for C and C++ test cases, but they still
occur for Fortran.
I guess that
Hi, Thomas
The standard version of Tcl installed on AIX currently is Tcl 8.4.
I'll see if I can have a newer version on the side.
The patch resolves the "no such variable" error message. (Great!
Thanks!) I now see:
during GIMPLE pass: omplower
as an Excess error. Any idea where that comes
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:
> I worry a bit about the less common native targets -- aix,
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++-common/goacc/kernels-decompose-1.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
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 to contemplate these days. I'm
> >> sure those
> 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
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
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
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
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
> +++
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. Segher and I both agree that
> > it's cleaner and
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
+++
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 amongst maintainers. And
> > Segher
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
> > >
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
> > already are in the gcc.target/powerpc
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
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
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
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
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
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
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
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]'
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
201 - 300 of 355 matches
Mail list logo
