at least the next 7 years.
This is no critique on GCC which is for sure a high quality compiler.
Just a suggestion for beginner’s projects as the title indicates.
Regards, Aaron Peter Bachmann
On 3/8/24 5:28 PM, Jonathan Wakely wrote:
> On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc wrote:
>>
>> On 08.03.24 23:00, Peter Bergner wrote:
>>> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
>>>> I CCed Jeff who is on the commitee to forward the mai
erpc port maintainers which you can find
along with their preferred email addresses in the MAINTAINERS file. If you
don't CC them, they may miss seeing the patch.
Peter
to make ia64 use LRA, get write access to the
> git repository and then be promoted maintainer.
One other method for showing activity is posting regular testsuite
results on the gcc-testresults mailing list to show the community
the port is "working".
Peter
On Fri, 19 Jan 2024, LIU Hao wrote:
> ? 2024-01-18 20:54, Jan Beulich ??:
> > I'm sorry, but most of your proposal may even be considered for being
> > acceptable only if you would gain buy-off from the MASM guys. Anything
> > MASM treats as valid ought to be permitted by gas as well (within the
>
On Wed, 10 Jan 2024, Jason Merrill via Gcc wrote:
> On 1/10/24 15:59, Marek Polacek wrote:
> > On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote:
> > > What formatting style do we want for non-trivial lambdas in GCC sources?
> > > I'm thinking the most consistent choice would be
> From: Thomas Schwinge
> Date: Thu, 19 Oct 2023 12:42:26 +0200
> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
Not sure if that counts as "shared", but I regularly drop
in* newlib to build simulator targets (*-elf, *-newabi).
That's git://sou
t declaration too, which I just changed for
consistency-- but it's close enough for me.)
With this, retesting plugin.exp for cris-elf works.
Ok to commit?
-- >8 --
From: Hans-Peter Nilsson
Date: Fri, 1 Sep 2023 04:36:03 +0200
Subject: [PATCH] testsuite: Fix analyzer_cpython_plugin.c decla
On Fri, Jul 07, 2023 at 10:04:06AM -0400, Olivier Dion wrote:
> On Tue, 04 Jul 2023, Peter Zijlstra wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> [...]
> >> On x86-64 (gcc 13.1 -O2) we get:
> >>
> >> t0():
> >>
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> int x = 0;
> int y = 0;
> int r0, r1;
>
> int dummy;
>
> void t0(void)
> {
> __atomic_store_n(&x, 1, __ATOMIC_RELAXED);
>
> __atomic_exchange_n(&dummy, 1, __ATOMIC_SEQ_CST);
> __atomic_thre
a, please feel free to let me
know.
I look forward to working with all of you in the future,
Peter Lafreniere
, that is, reading a pointer
> is not a problem in itself, a long as you don't compare it, but I'm not
> such an expert about this.
One last thought: with the above strict interpretation of the c standard,
it would become nigh on impossible to implement the malloc(3) family of
functi
Hello!
On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories behind,
created by dsymutil:
checking for build system preprocessor... rm: conftest.dSYM: is a
directory
checking for build system executable suffix... rm: conftest.dSYM: is a
directory
checki
> From: Hans-Peter Nilsson
> Date: Thu, 26 May 2022 03:17:01 +0200
Regarding setting the default for the RWX-segment warning
per-target:
> How about the usual method, a line in the ld emulparams
> file for the target?
JFTR: no extra infrastructure bits needed. I found the
right
> From: Jeff Law via Binutils
> Date: Mon, 25 Apr 2022 17:30:59 +0200
> On 4/25/2022 9:26 AM, Nick Clifton wrote:
> > Hi Jeff,
> >
> > Just FYI - I am also looking at adding in another warning. This
> > time for
> > when the linker creates a PT_LOAD segment which has all of the RWX
> > fla
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.
Slight typo. s/VSX/VMX/
Peter
pls
Am 06.05.2022 um 10:48 schrieb Richard Biener via gcc-announce
:
The GCC developers are proud to announce another major GCC release, 12.1.
This year we celebrated the 35th anniversary of the first GCC beta release
and this month we will celebrate 35 years since the GCC 1.0 release!
This r
7;t have anything to do with those specifically.
>
> I'm dumping a bunch of info here largely for posterity / archival, and to find
> out who (from the kernel side) is willing and able to test proposed compiler
> fixes, once those are available.
>
> I'm happy to do so for aarch64; Peter, I assume you'd be happy to look at the
> x86 side?
Sure..
On Mon, 14 Feb 2022, Andras Tantos wrote:
> Hello all!
>
> I'm working on porting GCC to a new processor architecture. I think
> I've finally got to a fairly stable stage, so the next logical step
> would be to test and optimize. For that, I would need some benchmarks,
> and this is where I'm seeki
Not seeing anyone doing the obvious one-up, so JFTR:
On Mon, 10 Jan 2022, David Malcolm via Gcc wrote:
> On Mon, 2022-01-10 at 17:13 +0100, FX wrote:
> > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c
>
> The purpose of these asm tests is to verify that the analyzer doesn't
> get confused by various in
k, could you instead not set LD_LIBRARY_PATH and
instead compile using -L/home/bergner/lib64 -R/home/bergner/lib64 ?
Peter
at happens when you configure with
--with-advance-toolchain=at15.0, it forces the gcc to use AT15's
dynamic linker and AT15's ld.so.cache makes it so that the
dynamic linker finds AT15's libs etc.
Peter
On 12/4/21 9:37 AM, Peter Bergner wrote:
> On 12/4/21 9:25 AM, Michael Meissner wrote:
> ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out
> ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by ./a.out)
> linux-vdso64.so.1
0x7158fb1e)
What I would do is place /opt/at15.0/bin as the 2nd directory in your PATH,
with your new GCC install dir being first. That way, things should be
seemless for you.
Peter
of the
input source operands. You don't mark the source operands that could be
clobbered.
Peter
On Fri, 1 Oct 2021, Nelson Ribeiro via Gcc wrote:
> Hello.
>
> Firstly I want to apologize for this long post, but in a way this post also
> is meant for documenting the work that I have done hunting down this issue.
> Secondly I must say that I do not have much insights on the GCC internals,
> onl
.
This would cover POWER6 and later server CPUs, as well as some other
cpus like in the Power Macs.
Anything without Altivec hardware would need to either not support
IEEE QP at all, or go through the work themselves of coming up with
a -msoft-altivec like ABI.
Peter
On Wed, 30 Jun 2021, Eli Zaretskii via Gcc-patches wrote:
> > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> > From: Martin Li?ka
> > Date: Wed, 30 Jun 2021 12:11:03 +0200
> > > 4. Menus lost the short descriptions of the sub-sections. Example:
> > >
> > >* Designated
fails, or perhaps this script should be made more
> robust.
I admit, that if the same thing happened to me, I would have made the
same mistake...or worse :-), so yeah, a comment about what to do to "fix"
things when gcc_update fails would be greatly appreciated by me too!
Peter
On Tue, 15 Jun 2021, Martin Sebor wrote:
> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> >
> > > On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
>
uthor when
committing that, so we're wondering whether there might be a bug in one
of the commit hooks. Is there someone who an dig into the commit below
and try to find out how the author field was incorrectly set?
Peter
commit a325bdd195ee96f826b208c3afb9bed2ec077e12
Author: Pet
On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> > > My objection is to making our policies and tools more restrictive
> > > than they need to be. We shouldn't expect everyone to study whole
> >
regs[ 0]);
>
>
> +"std r14, %0" : "=m" (regs[ 1]);
>
>
> ...
> to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> to "stw %%r13, %0" etc. under some conditions?
Yes, I think so. The "r13", etc. names are not accepted by gas unless you
use the -mregnames option. It's easier to just remove the 'r'.
Peter
On Mon, Nov 16, 2020 at 12:23:17PM +, Uecker, Martin wrote:
> > > > Another way to drop qualifiers is using a cast. So you
> > > > can use typeof twice:
> > > >
> > > > typeof((typeof(_var))_var) tmp__;
> > > >
> > > > This also works for non-scalars but this is a GCC extension.
>
> (That c
On Mon, Nov 16, 2020 at 12:10:56PM +0100, Peter Zijlstra wrote:
> > > Another way to drop qualifiers is using a cast. So you
> > > can use typeof twice:
> > >
> > > typeof((typeof(_var))_var) tmp__;
> > >
> > > This also works for non-scal
fiers. The syntax as proposed above seems
very error prone to me.
---
Subject: compiler: Improve __unqual_typeof()
Improve our __unqual_scalar_typeof() implementation by relying on C
dropping qualifiers for lvalue convesions. There is one small catch in
that GCC is currently known broken in this re
On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> When I think of qualifiers, I think of const and volatile. I'm not
> sure why the first post I'm cc'ed on talks about "segment" qualifiers.
> Maybe it's in reference to a variable attribute that the kernel
> defines? Looking at
On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> wrote:
> >
> > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > >
> > > + lots of people and linux-toolchains
> >
On Mon, Nov 09, 2020 at 01:38:51PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> >
> > + lots of people and linux-toolchains
> >
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hell
+ lots of people and linux-toolchains
On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> Hello!
>
> I was looking at the recent linux patch series [1] where segment
> qualifiers (named address spaces) were introduced to handle percpu
> variables. In the patch [2], the author mention
On Wed, 23 Sep 2020, Ilya Leoshkevich via Gcc wrote:
> Hi,
>
> "Defining How to Split Instructions" in gccint states the following:
>
> The preparation-statements are similar to those statements that are
> specified for define_expand ... Unlike those in define_expand, however,
> these statements mu
On Thu, 3 Sep 2020, Hans-Peter Nilsson wrote:
> IMHO stepping into the .md really isn't helpful. Even a pattern
> name in a comment in the generated code would be better.
...and JFTR, yes I noticed there is, or rather line indicator
for example /path/to/mmix.md:211 above gen_add
On Thu, 27 Aug 2020, Pip Cet via Gcc wrote:
> I may be missing an obvious workaround, but it seems we currently emit
> a #line directive when including lines from machine description files
> in C files, but never emit a second directive when switching back to
> the generated C file. This makes step
On Wed, 26 Aug 2020, Pip Cet via Gcc wrote:
> Note that whether there is a CC-setting variant depends not just on
> the "cc" attr, but also on the precise operands for some values of the
> "cc" attr, which requires hairy C code to figure out.
>
> Is it possible to avoid this situation by avoiding
On Wed, 26 Aug 2020, Jeff Law wrote:
> On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote:
> > On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> > > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > > > The post-reload splitter in
On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > The post-reload splitter introduces the clobber. The wiki
> > suggests that approach if most insns clobber REG_CC, perhaps because of
> > the missed optimizations you describe
On Thu, 20 Aug 2020, Senthil Kumar Selvaraj wrote:
> What I didn't understand was the (set-attr "cc")
> part - as far I can tell, this results in (set_attr "cc_enabled" ...) in
> all of the three substituted patterns, so I wondered why not just have
> (set_attr "cc_enabled" ...) in the original de
On Wed, 19 Aug 2020, Senthil Kumar Selvaraj wrote:
>
> Hans-Peter Nilsson writes:
>
> > On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> >> As you can deduce from the (set_attr "cc" ..), only constraint
> >> alternatives 0,2,3 and 6 clobber
On Sun, 16 Aug 2020, Pip Cet via Gcc wrote:
> For example, here's what I currently have:
>
> (define_expand "mov"
> [(parallel [(set (match_operand:MOVMODE 0 "nonimmediate_operand" "")
>(match_operand:MOVMODE 1 "general_operand" ""))
> (clobber (reg:CC REG_CC))])]
> ...)
On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> As you can deduce from the (set_attr "cc" ..), only constraint
> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.
Yes, I recognize that.
> My first version of the port adds a post-reload splitter that adds a
> (clobber (
Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on
releases/gcc-10 gave me:
[releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the whole of a
compound object.
Date: Sun Jul 5 20:50:52 2020 +0200
9 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 gcc/test
On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote:
> Its fine to focus on userspace first, but the kernel is far more simple.
>
> Looking at that presentation, the only thing missing for kernel is the
> notrack thunks, in the unlikely case that such code would be tolerated
> (Frankly,
On Sat, 25 Apr 2020, Eric Botcazou wrote:
> > I very much disagree with this. I think my approach was possibly the
> > only viable one, and definitely the most sensible one for this target.
> > Not only is there nothing meaningful to be gained from separating cc
> > setters and users on m68k given
but the last one which points
>> to the SVN revision doesn't. Is that a bug in the actual url that
>> bugzilla added or can we handle these too?
>
> We can/do handle the last one too. httpd mod_rewrite is powerful.
Works now. Thanks for fixing!
Peter
lowing bugzilla entry:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4
The first two git style links work, but the last one which points
to the SVN revision doesn't. Is that a bug in the actual url that
bugzilla added or can we handle these too?
Peter
On Thu, 6 Feb 2020, Segher Boessenkool wrote:
> Instead of "git am" I had "patch -p1 <",
May I suggest "git apply" instead of the good old patch program.
(The "-p1" is of course built-in and you never have to do a
manual roll-back or separate --dry-run pass.)
brgds, H-P
On 1/23/20 12:09 PM, Peter Bergner wrote:
> On 1/23/20 4:29 AM, Jakub Jelinek wrote:
>> so it is not a fast forward merge and we have the requirement that
>> From-SVN: shouldn't appear in commit logs of new commits.
>
> So I just did "git merge releases/gcc-9"
e releases/gcc-9" into our branch and I'm not
seeing any From-SVN: in any of the commit messages. Where/how are
you seeing those?
Peter
te.html a few days ago now also removed svn.html.
The rsync.html page can be removed too, since that was a way to download
the entire svn repo. With git clone, you get the entire repo, so rsync
isn't needed anymore.
Peter
TL;DR: See subject. Verbosity follows.
The git transition is mostly for the better. Thanks to those
investing time and effort. There's always fallout. Here's one
dustcloud:
In the distant past with svn, there messages to gcc-cvs@ were
somewhat like git show --stat, i.e. without the actual cha
essing I'm not the only one who would like this info, so maybe
someone can add this to our wiki?
Peter
Hi
You could have the last payment in your personal account. You need to address
this instantly or it will be deleted.
Go Here To Verify Your Payment Data Is Correct.
Customer email: g...@gnu.org
User ID: TQNLMFJOC9
Enjoy & please let me know how you do.
Thank you!
Cortez
E Market
//gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
Peter
Has there been a change of policy so it's a valid option to use
gcc/ChangeLog for testsuite changes? I was about to move a
semi-randomly spotted misplaced entry, and when checking if
there were others, I noticed that there's like tens of them, so
I thought better ask.
(IMHO it's confusing to have
On 25/04/2019, Richard Biener wrote:
> On Thu, Apr 25, 2019 at 3:03 PM Peter Sewell
> wrote:
>>
>> On 25/04/2019, Richard Biener wrote:
>> > On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell
>> >
>> > wrote:
>> >>
>> >> On 24
On 25/04/2019, Richard Biener wrote:
> On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell
> wrote:
>>
>> On 24/04/2019, Jeff Law wrote:
>> > On 4/24/19 4:19 AM, Richard Biener wrote:
>> >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
>> >&g
On 24/04/2019, Jeff Law wrote:
> On 4/24/19 4:19 AM, Richard Biener wrote:
>> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
>>>
>>> On 4/18/19 6:20 AM, Uecker, Martin wrote:
>>>> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
>>>
On 19/04/2019, Jens Gustedt wrote:
> Hello Peter,
>
> On Fri, 19 Apr 2019 10:11:43 +0100 Peter Sewell
> wrote:
>
>> On 19/04/2019, Jakub Jelinek wrote:
>> > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote:
>> [...]
>
>> > That pen
d objects are
> involved.
A possible compromise position might be to make it implementation-defined
whether round-trip casts of a one-past pointer into integer and back preserve
provenance. I don't know whether that corner case crops up in real code...
best,
Peter
On Thu, 18 Apr 2019 at 14:54, Uecker, Martin
wrote:
>
> Am Donnerstag, den 18.04.2019, 07:42 -0600 schrieb Jeff Law:
> > On 4/18/19 6:20 AM, Uecker, Martin wrote:
> > > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> > > > On Thu, 18
quot; provenance.
> >
> > The additional issue that appears here though
> > is that we cannot even turn (int *)(uintptr_t)p
> > into p anymore since with the conditional
> > substitution we can then still arrive at
> > effectively (&y)[-1] = 1 which is of course
> > undefined behavior.
> >
> > That is, your proposal makes
> >
> > ((int *)(uintptr_t)&y)[-1] = 1
> >
> > well-defined (if &y - 1 == &x) but keeps
> >
> > (&y)[-1] = 1
> >
> > as undefined which strikes me as a little bit
> > inconsistent. If that's true it's IMHO worth
> > a defect report and second consideration.
>
> Similarly that
>
> int x;
> int y;
> uintptr_t pj = (uintptr_t)&y;
>
> if (&x + 1 == &y) {
>
>int* p = (int*)pj; // can be one-after pointer of 'x'
>p[-1] = 1; // well defined?
> }
>
> is undefined but when I add a no-op
>
> (uintptr_t)&x;
>
> it is well-defined is undesirable. Can this no-op
> stmt appear in another function? Or even in
> another translation unit (if x and y are global variables)?
> And does such stmt have to be present (in another
> TU) to make the example valid in this case?
yes to all that - again, in the variant in which
roundtrips of a one-past pointer are supported.
> To me all this makes requiring exposal through a cast
> to a non-pointer (or accessing its representation) not
> in any way more "useful" for an optimizing compiler than
> modeling exposal through address-taking.
interesting, thanks
best,
Peter
> Richard.
>
> > Richard.
> >
> > > Best,
> > > Martin
n would be to not track
> provenance through non-pointers and make
> conversions of non-pointers to pointers have
> "anything" provenance.
>
> The additional issue that appears here though
> is that we cannot even turn (int *)(uintptr_t)p
> into p anymore since with the conditional
> substitution we can then still arrive at
> effectively (&y)[-1] = 1 which is of course
> undefined behavior.
>
> That is, your proposal makes
>
> ((int *)(uintptr_t)&y)[-1] = 1
>
> well-defined (if &y - 1 == &x) but keeps
>
> (&y)[-1] = 1
>
> as undefined
that's true (if x has been exposed).
>which strikes me as a little bit
> inconsistent. If that's true it's IMHO worth
> a defect report and second consideration.
There's a trade-off here. We could permit roundtrips
of pointer-to-integer-to-pointer only recover provenance
if the pointer is properly within the object, giving empty
provenance for a one-past pointer. That would fix the
above, but it's not clear whether this would be a bad
restriction for existing code.
best,
Peter
> Richard.
>
> > Best,
> > Martin
On Wed, 17 Apr 2019 at 15:12, Uecker, Martin
wrote:
>
> Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > > > On Wed, Apr 17, 2019 at 1:53
On 17/04/2019, Richard Biener wrote:
> On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> wrote:
>>
>> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
>> >
>> > On 4/2/19 2:11 AM, Peter Sewell wrote:
>> > > Dear all,
>> > >
>>
On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
>
> On 4/2/19 2:11 AM, Peter Sewell wrote:
> > Dear all,
> >
> > continuing the discussion from the 2018 GNU Tools Cauldron, we
> > (the WG14 C memory object model study group) now
> > have a detailed propo
and let the old ones refer to the description like it is
today.
Best Regards,
Peter
A big fan
d especially like to know whether
it would be feasible to implement - our hope is that it would only require
minor changes. It's presented in three documents:
N2362 Moving to a provenance-aware memory model for C: proposal for C2x
by the memory object model study group. Jens Gustedt, Pete
Zdravím,
Obsah této posty je velmi duverný a legální. Jmenuji se Peter Wong, pracuji s
bankou tady v Hong Kongu. Rozhodl jsem se vás kontaktovat pro moznost
investovat do lukrativního podnikání ve va?í zemi. Jsem ochoten Vám nabídnout
40% investicního zisku jako muj obchodní partner.
Nase
On 2/20/19 9:39 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 08:57:52PM -0600, Peter Bergner wrote:
>> Yes, because they don't have my IRA and LRA patches that exposed this
>> problem. I would say they were buggy for not complaining and silently
>> spilling a hard reg
On 2/20/19 4:04 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 10:08:07AM -0600, Peter Bergner wrote:
>> On 2/19/19 9:09 PM, Alan Modra wrote:
>> That said, talking with Segher and Uli offline, they both think the
>> inline asm usage in the test case should be legal
>
&g
spilling a hard register in the case where we used asm reg("...").
Peter
On 2/19/19 9:09 PM, Alan Modra wrote:
> On Mon, Feb 18, 2019 at 01:13:31PM -0600, Peter Bergner wrote:
>> long input;
>> long
>> bug (void)
>> {
>> register long output asm ("r3");
>> asm ("blah %0, %1, %2" : "=&r" (outp
; input and tries to spill it, but
it's not a pseudo, but an explicit hard register already. I'm not
sure LRA can really safely spill an operand that is an explicit hard
register.
Thoughts?
Peter
ry has this covered, but in the TCB, we
> only have zeroed-out reservations today.
We have non-zero initialized TCB entries on powerpc*-linux which are used
for the GCC __builtin_cpu_is() and __builtin_cpu_supports() builtin
functions. Tulio would know the magic that was used to get them setup.
Peter
ed the rs6000 (ie, ppc*) port over to LRA
from reload, we hit many target problems. It seems LRA is much less
forgiving to bad constraints, predicates, etc. than reload was.
I think that's actually a good thing.
Peter
On 11/1/18 8:40 PM, Segher Boessenkool wrote:
> Hi Peter,
>
> On Thu, Nov 01, 2018 at 07:49:36PM -0500, Peter Bergner wrote:
>> On 11/1/18 7:25 PM, Paul Koning wrote:
>>> I'm running the testsuite on the pdp11 target, and I get a failure when
>>> using
evision? Does it work
before my
revision 264897 commit and broken after? If so, could you try the following to
see
whether that fixes things for you?
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html
My commit above exposed some latent LRA bugs and my patch above tries
to fix issues similar to what you're seeing.
Peter
Hello,
Hope you are doing good. I am not sure whether you got a chance to read my
previous mail (mentioned below).
Please let me know if you are interested in acquiring the complete list of
attendee contacts.
Hope to hear from you soon.
Best Wishes,
Peter
From: Peter Chase
are interested and I shall get back to you with the
pricing and other information.
Best Regards,
Peter Chase
If you don't wish to receive our newsletters, reply back with " Opt Out " in
subject line
cimal floating point)
on powerpc64*-linux, which is only allowed in even-odd register pairs.
It's in *all* cases though, not some of the time.
Peter
On 8/27/18 1:20 PM, sameeran joshi wrote:
> On 8/27/18, Peter Bergner wrote:
>> On 8/27/18 12:13 PM, sameeran joshi wrote:
>>> On 8/27/18, Peter Bergner wrote:
>>>> Well what does:
>>>>
>>>> linux% gcc -I/home/swamimauli/upload/csmith
On 8/27/18 12:13 PM, sameeran joshi wrote:
> On 8/27/18, Peter Bergner wrote:
>> Well what does:
>>
>> linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c
>
> running above command on terminal,gives many warnings and asks for the
> -fgnu-tm op
bug.c
return?
And also, what does:
linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c 2>&1 | grep
'internal compiler error: in expand_expr_addr_expr_1, at expr.c:7862'
linux% echo $?
return?
Peter
then
> exit 0
> else
> exit 1
> fi
When I use creduce, I never write my output to an actual file, but
just pipe it directly into grep. My creduce.sh scripts usually look
like the following which have worked for me in the past.
Peter
#!/bin/bash
CC="/home/bergner/
here without ever using it above, so it's dead code,
which explains why it's removed.
Peter
H.J.: please see last.
> From: Jean Lee
> Date: Sat, 10 Mar 2018 20:22:45 +0800
> > See above regarding looking at patches, but I guess you mean
> > that the patch is trivial, so then I presume it was more or less
> > the same as this, which is basically a copy-paste from looking
> > at rs6000 a
TL;DR: see last sentence.
> From: Jean Lee
> Date: Mon, 5 Mar 2018 19:56:59 +0800
> 2018-03-03 21:14 GMT+08:00 Hans-Peter Nilsson :
>
> > > From: Jean Lee
> > > Date: Fri, 2 Mar 2018 13:29:39 +0800
> > > It is great to go the last mile. I had done the
ative ABI?
Unless someone really wants to work on this, I'll have a look at
adding this once stage1 opens up.
Peter
ml
I wouldn't be surprised if there are more specs/standards that place
restrictions too. Clearly returning from the function that calls
setjmp before calling longjmp must be illegal, since that would result
in clobbering of the stack frame the longjmp would attempt to restore to.
I don't know off hand who/what states that restriction.
Peter
On 3/3/18 5:47 PM, Peter Bergner wrote:
> On 3/3/18 10:29 AM, Jeff Law wrote:
>> Here's the comment from regstat.c:
>>
>> /* We have a problem with any pseudoreg that lives
>> across the setjmp. ANSI says that if a user variable
>
1 - 100 of 820 matches
Mail list logo
