I'm having a little difficulty with my workflow, and I'm hoping someone
can spot the problem.
I have a user branch set up with the contrib/git-add-user-branch.sh
script. Here are the relevant portions of my .git/config:
[remote "users/wschmidt"]
url = git+ssh://wschm...@gcc.gnu.org/g
On 2/4/20 4:31 PM, Andreas Schwab wrote:
On Feb 04 2020, Bill Schmidt wrote:
wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run
users/wschmidt +wschmidt/builtins
To git+ssh://gcc.gnu.org/git/gcc.git
* [new branch] wschmidt/builtins -> wschmidt/builtins
Well, tha
On 2/4/20 5:09 PM, Andreas Schwab wrote:
On Feb 04 2020, Bill Schmidt wrote:
Hm. If I'm understanding you correctly, this still attempts to create a
new branch:
wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run
users/wschmidt +wschmidt/builtins:users/wschmidt/builtins
At Cauldron this year, several people complained to me that our latest
ABI document was behind a registration wall. I'm happy to say that
we've finally gotten past the issues that were holding it there, and it
is now openly available at:
https://members.openpowerfoundation.org/document/dl/576
Hi,
I ran into a couple of aliasing issues with a project I'm working on,
and have some questions.
The first is an issue with TOC-relative addresses on PowerPC. These are
symbolic addresses that are to be loaded from a fixed slot in the table
of contents, as addressed by the TOC pointer (r2). I
On Fri, 2016-04-08 at 13:41 -0700, Richard Henderson wrote:
> On 04/08/2016 11:10 AM, Bill Schmidt wrote:
> > The first is an issue with TOC-relative addresses on PowerPC. These are
> > symbolic addresses that are to be loaded from a fixed slot in the table
> > of contents
On Tue, 2016-04-12 at 10:00 +0930, Alan Modra wrote:
> On Fri, Apr 08, 2016 at 01:41:05PM -0700, Richard Henderson wrote:
> > On 04/08/2016 11:10 AM, Bill Schmidt wrote:
> > > The first is an issue with TOC-relative addresses on PowerPC. These are
> > > symbolic addr
> On Jul 25, 2016, at 4:04 AM, Richard Biener wrote:
>
> On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote:
>
>> Hi,
>> I am trying to write a WIP patch to warn for dead function calls,
>> and incidentally it caught the following dead call to gimple_bb() from
>> slsr_process_phi () in gimple-ssa-s
gned load/store performance on earlier processors
was less efficient, so the tradeoffs differ.
I hope this is helpful!
Bill Schmidt, Ph.D.
IBM Linux Technology Center
You wrote:
> I have a issue/question using VMX/VSX on Power8 processor on a little endian
> system.
> Using intrinsics function, i
larger must use vec_vsx_ld to avoid errors.
Again, sorry for my previous omission!
Thanks,
Bill Schmidt, Ph.D.
IBM Linux Technology Center
On Fri, 2015-03-13 at 15:42 +, Ewart Timothée wrote:
> thank you very much for this answer.
> I know my memory is aligned so I will use vec_ld/s
e swap the element)
> 6) memory: BE
>
> I understand ld/st_vsx_vec load/store from LE/BE, but as the VXU can compute
> in both mode what should I swap (I precise I am working with 32/64 bits float)
>
> Best,
>
> Tim
>
> Timothée Ewart, Ph. D.
> http://www.link
On 12/3/18 8:34 AM, Florian Weimer wrote:
> * Aaron Sawdey:
>
>> If you are aware of any real world code that is faster when built
>> with -fno-builtin-strcmp and/or -fno-builtin-strncmp, please let me know
>> so I can look at avoiding those situations.
> Sorry, I have not tried to benchmark this.
On 5/21/19 11:47 AM, Martin Sebor wrote:
> The GCC coding style says to use "floating-point" as an adjective
> rather than "floating point." After enhancing the -Wformat-diag
> checker to detect this I found a bunch of uses of the latter, such
> as in:
>
> gcc/c/c-decl.c:10944
> gcc/c/c-parser
On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
> On 21/05/2019 21:18, Bill Schmidt wrote:
>> On 5/21/19 11:47 AM, Martin Sebor wrote:
>>> The GCC coding style says to use "floating-point" as an adjective
>>> rather than "floating point." A
On 5/22/19 9:58 AM, Martin Sebor wrote:
> On 5/22/19 6:27 AM, Richard Earnshaw (lists) wrote:
>> On 22/05/2019 13:17, Bill Schmidt wrote:
>>> On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
>>>> On 21/05/2019 21:18, Bill Schmidt wrote:
>>>>> On 5/2
On 10/4/19 10:13 AM, Steve Ellcey wrote:
I am curious if anyone has tried running 'peak' SPEC 2017 numbers using
profiling. Now that the cactus lto bug has been fixed I can run all
the SPEC intrate and fprate benchmarks with '-Ofast -flto -march=native'
on my aarch64 box and get accurate results
That second set of failures occurs already on 7.4.1...
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been
Er, sorry, I guess that is saying the same thing as it is broken in
7.5. Oops.
On 11/7/19 9:24 AM, Bill Schmidt wrote:
That second set of failures occurs already on 7.4.1...
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision
277823.
I have so far bo
On 11/11/19 7:26 AM, Richard Biener wrote:
On Fri, 8 Nov 2019, Bill Schmidt wrote:
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and
late in the
release? I can run a quick test with TSan turned on to see where we're at.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Jan 23, 2017, at 6:53 AM, Maxim Ostapenko wrote:
>
> H
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
>> TSan support was contributed to LLVM by a student working at one of the US
>> National Labs a while back. I helped him with some of the PPC assembly
&
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
>> TSan support was contributed to LLVM by a student working at one of the US
>> National Labs a while back. I helped him with some of the PPC assembly
&
> On Jan 23, 2017, at 8:47 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:45:16AM -0600, Bill Schmidt wrote:
>>> 2017-01-23 Jakub Jelinek
>>>
>>> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>>>
>>>
Hi Igor,
(Apologies for not threading this, I haven't received my digest for this
list yet)
You wrote:
>I recently checked this old discussion about when/why to use lxvd2x instead of
>lvsl/lvx/vperm/lvx to load elements from memory to vector:
>https://gcc.gnu.org/ml/gcc/2015-03/msg00135.ht
On Fri, 2013-04-12 at 15:51 +0100, Sofiane Naci wrote:
> Hi,
>
> Consider the following sequence, which computes 2 addresses to access an
> array:
>
> _2 = (long unsigned int) i_1(D);
> _3 = _2 * 200;
> _4 = _3 + 1000;
> _6 = A2_5(D) + _4;
> *_6[0] = 1;
> _9 = _3 + 2000;
> _10 = A2_
On Fri, 2013-04-12 at 11:18 -0500, Bill Schmidt wrote:
> On Fri, 2013-04-12 at 15:51 +0100, Sofiane Naci wrote:
> > Hi,
> >
> > Consider the following sequence, which computes 2 addresses to access an
> > array:
> >
> > _2 = (long unsigned int) i_1(D);
&g
Six years ago, Michael Matz proposed a patch for generating profile
instrumentation in a thread-safe manner:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html
Reading through the thread, I saw a few minor objections, but nothing to
indicate the patch should be withdrawn. However, apparentl
Mon, Apr 22, 2013 at 12:59 PM, Bill Schmidt
> wrote:
> > Six years ago, Michael Matz proposed a patch for generating profile
> > instrumentation in a thread-safe manner:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html
> >
> > Reading th
On Mon, 2013-08-05 at 11:47 +0100, Tejas Belagod wrote:
> Hi,
>
> I'm looking for some help understanding how BIT_FIELD_REFs work with
> big-endian.
>
> Vector subscripts in this example:
>
> #define vector __attribute__((vector_size(sizeof(int)*4) ))
>
> typedef int vec vector;
>
> int foo(v
On Mon, 2013-08-12 at 11:54 +0100, Tejas Belagod wrote:
> >> What's interesting to me here is the bitpos - does this not need
> >> BYTES_BIG_ENDIAN correction? This seems to be inconsistenct with what
> >> happens
> >> with reduction operations in the autovectorizer where the scalar result in
>
Hi,
It was recently pointed out to me that our new powerpc64le-linux-gnu
target does not yet have a corresponding directory in libstdc
++-v3/config/abi/post/ to hold a baseline_symbols.txt for the platform.
I've been looking around and haven't found any documentation for how the
minimum baseline s
On 7/9/20 12:13 PM, Richard Biener via Gcc wrote:
On July 9, 2020 3:43:19 PM GMT+02:00, David Edelsohn via Gcc
wrote:
On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose wrote:
On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose
wrote:
https://gcc.gnu
On 7/13/20 7:08 AM, Florian Weimer wrote:
* Bill Schmidt via Gcc:
Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure
that would be accepted (though I do not have the power to pre-approve
it). Or I can put it on my list for later in the summer when my life
settles down.
On 8/10/20 3:30 AM, Jonathan Wakely via Gcc wrote:
Hi Matt,
The best thing to do here is file a bug report with the code to reproduce it:
https://gcc.gnu.org/bugzill
Thanks
Also, be sure to follow the instructions at https://gcc.gnu.org/bugs/.
Bill
On Sat, 8 Aug 2020 at 23:01, Soul Stu
Hi! I'm working on a project where it's desirable to generate a
target-specific header
file while building GCC, and install it with the rest of the target-specific
headers
(i.e., in lib/gcc//11.0.0/include). Today it appears that only those
headers
listed in "extra_headers" in config.gcc will
Thanks for the pointer! I'll have a look at this.
Much obliged,
Bill
On 11/12/20 9:54 AM, Jonathan Wakely wrote:
On Thu, 12 Nov 2020 at 15:39, Bill Schmidt via Gcc wrote:
Hi! I'm working on a project where it's desirable to generate a
target-specific header
file while bu
On 11/12/20 10:06 AM, Marc Glisse wrote:
On Thu, 12 Nov 2020, Bill Schmidt via Gcc wrote:
Hi! I'm working on a project where it's desirable to generate a
target-specific header file while building GCC, and install it with
the rest of the target-specific headers (i.e., in
lib/g
On 11/12/20 10:15 AM, Bill Schmidt via Gcc wrote:
On 11/12/20 10:06 AM, Marc Glisse wrote:
Does the i386 mm_malloc.h file match your scenario?
Ah, that looks promising indeed, and perhaps very simple! Marc,
thanks for the pointer!
And indeed, with this example it was a two-line change
Hi! I'm attempting to do something that may not have been done before,
so I'm looking for advice, or a pointer to where, in fact, it has been
done before. :)
I'm automatically generating a back-end header file that declares some
structures that include trees, and a bunch of global variables t
Actually, the "./filename" syntax works fine. I was missing a
dependency in my t-rs6000 to make the header file appear available.
Sorry for the noise!
Bill
On 1/4/21 11:40 AM, Bill Schmidt wrote:
Hi! I'm attempting to do something that may not have been done before,
so
On 1/4/21 1:36 PM, Jeff Law wrote:
On 1/4/21 10:40 AM, Bill Schmidt via Gcc wrote:
Hi! I'm attempting to do something that may not have been done
before, so I'm looking for advice, or a pointer to where, in fact, it
has been done before. :)
I'm automatically generating a
On 4/20/21 7:42 AM, Richard Kenner via Gcc wrote:
Troubling indeed, but this might just be an overzealous manager.
IBM, like other corporations, has made significant technical
contributions to GCC over the years, for example the scheduler and
the vectorizer, and thus has assigned the copyright of
On 8/30/21 8:04 AM, Florian Weimer wrote:
There has been a discussion, both off-list and on the gcc-help mailing
list (“Why vectorization didn't turn on by -O2”, spread across several
months), about enabling the auto-vectorizer at -O2, similar to what
Clang does.
I think the review concluded tha
On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> Hi Joseph,
>
> On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote:
>> On Mon, 4 Oct 2021, Segher Boessenkool wrote:
>>> Some current Power GCC targets support neither. Some support only
>>> double-double. Making IEEE QP float work on th
Thanks, Jakub, for starting this discussion, and to everyone who weighed in.
The conversation
went in a number of different directions, so I'd like to summarize my
understanding of points
where I think there was agreement. I'd also like to separate out short-term
considerations
for powerpc64le
Would starting from Advance Toolchain 15 with the most recent glibc make things
easier for Thomas to test?
Thanks,
Bill
On 10/29/21 4:06 PM, Michael Meissner via Gcc wrote:
> On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
>> Hi Michael,
>>
>> I tried this out on the one POWER mac
Hi!
On 12/3/21 5:56 AM, Thomas Koenig wrote:
>
> Hi Jakub,
>
>> Note, we want to test both building gcc on ppc64le with older glibc
>> and newer glibc (and that libgfortran will have the same ABI between both
>> and one can move gcc including libgfortran and libquadmath from the older
>> glibc set
48 matches
Mail list logo
