Re: Odd Python errors in the G++ testsuite

Hi Ben, This has fallen between the cracks. On Mon, 9 Oct 2023, Ben Boeckel wrote: > On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote: > > I'm seeing these tracebacks for several cases across the G++ testsuite: > > > > Executing on host: pyth

Odd Python errors in the G++ testsuite

Hi, I'm seeing these tracebacks for several cases across the G++ testsuite: Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300) spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6) rules/0/primary-output is ok: p1689-1.o rule

Re: LRA for avr: help with FP and elimination

On Fri, 14 Jul 2023, Vladimir Makarov via Gcc wrote: > > On the avr, the stack pointer (SP) > >is not used to access stack slots > It is very uncommon target then. Same with the VAX target. SP is used for outgoing function arguments, function calls, alloca only. AP is used for incoming

Re: [gcc r14-2248] MIPS: Add bitwise instructions for mips16e2

On Mon, 3 Jul 2023, YunQiang Su via Gcc-cvs wrote: > https://gcc.gnu.org/g:42d6b905c454e8f1b59d9248465d62a489b64972 > > commit r14-2248-g42d6b905c454e8f1b59d9248465d62a489b64972 > Author: Jie Mei > Date: Mon Jun 19 16:29:53 2023 +0800 > > MIPS: Add bitwise instructions for mips16e2 >

Re: End of subscription

On Tue, 9 May 2023, Jakub Jelinek via Gcc wrote: > > Don't want to receive further emails. > > Each mail on the mailing list tells that in the headers: > List-Unsubscribe: , >

Re: Taking Over MIPS Maintenance

On Thu, 18 May 2023, Richard Sandiford via Gcc wrote: > It would be more usual to wait a bit longer until someone becomes > maintainer. But IMO that's only sensible when there's an existing > maintainer to cover the interim. Not questioning YunQiang's overall coding skills I'd be concerned abou

Re: How to regenerate aclocal.m4?

On Sat, 30 Apr 2022, Zopolis0 via Gcc wrote: > I'm trying to regenerate autotools files in liboffloadmic (and other > directories) but when running automake it tells me I need to run aclocal, > which gives me a warning about not finding AM_ENABLE_MULTILIB in library, > which then translates into a

Re: your mail

On Mon, 25 Oct 2021, Joel Sherrill wrote: > I am pleased to announce that the GCC Steering Committee has appointed > Maciej W. Rozycki as maintainer of the Vax backend in GCC. Thank you, that's a great honour. > Maciej, please update your listing in the MAINTAINERS file. Change

VAX/GCC port maintenance

Hi, I have recently started a new position at Embecosm and the company has offered me to sponsor a personal project related to its business. So I had it in my mind already for a while to continue the effort with the VAX backend I have started with the MODE_CC conversion, as a port maintainer.

Re: Making *-netbsd-* to mean ELF not a.out for all CPUs

On Fri, 11 Jun 2021, John Ericson wrote: > I would like to propose that GNU tools consistently interpret configs > with "netbsd" as meaning ELF as opposed to a.out. Currently, newer CPUs > do that, but older ones have "netbsd" mean a.out for historical reasons, > and "netbsdelf" is used instead

Re: Question about PIC code and GOT

On Fri, 11 Jun 2021, vincent Dupaquis wrote: >     I've got the feeling the GOT is not convinient and goes in opposite > direction than the one we try to achieve with having PIC, at least this is the > reason why I'm trying to avoid it. > >     Any clue on the reason why it has been implemented t

Re: Update to GCC copyright assignment policy

On Tue, 1 Jun 2021, Christopher Dimech wrote: > > It is a real problem. As I recall a while ago parts of QEMU had to be > > removed and reimplemented from scratch when the project switched licences, > > because a contributor and therefore a copyright holder (whom I knew in > > person and who I a

Re: Update to GCC copyright assignment policy

On Tue, 1 Jun 2021, DJ Delorie via Gcc wrote: > > GCC is free software; you can redistribute it and/or modify > > it under the terms of the GNU General Public License as published by > > the Free Software Foundation; either version 3, or (at your option) > > any later version. > > > > To me that m

Re: Update to GCC copyright assignment policy

On Tue, 1 Jun 2021, Paul Koning via Gcc wrote: > That seems to create a possible future complication. Prior to this > change, the FSF (as owner of the copyright) could make changes such as > replacing the GPL 2 license by GPL 3. With the policy change, that > would no longer be possible, unle

Re: HELP: MIPS PC Relative Addressing

On Thu, 4 Mar 2021, Jiaxun Yang wrote: > > I'm not sure though why you try to avoid composed relocations given we've > > had them for 20+ years now. Relocations are just calculation operators > > for expressions evaluated at link time rather than assembly or high-level > > language compilation

Re: HELP: MIPS PC Relative Addressing

On Tue, 2 Mar 2021, Jiaxun Yang wrote: > After spending days poking with AUIPC, I suddenly found we indeed have ALUIPC > instruction in MIPS R6, which will clear low 16bit of AUIPC result. > > So the whole thing now looks easier, we can have R_MIPS_PC_PAGE and > R_MIPS_PC_OFST and avoid all mess

Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

On Fri, 19 Feb 2021, Maciej W. Rozycki wrote: > It looks to me however that you actually have control over the relocation > processing code you have referred, so how about improving it to handle the > GNU R_MIPS_HI16 extension as well? FWIW note that the extension has been aroun

Re: HELP: MIPS PC Relative Addressing

On Thu, 25 Feb 2021, Jiaxun Yang wrote: > > You may want to use composed relocations to refer to .LA1 (R_MIPS_32) and > > .LA0 (R_MIPS_SUB). There may or may not be linker updates needed; unlike > > the RISC-V one the MIPS BFD backend already supports composed relocations > > with the usual ELF

Re: HELP: MIPS PC Relative Addressing

On Thu, 25 Feb 2021, Jiaxun Yang wrote: > > > I'll take this approach first, add "lla, dlla" pseudo-instructions to > > > assembler and seeking optimization > > > in future. > > > > The DLA and LA macros are supposed to do that already, no need to invent > > new names. > > Hmm, how could we te

Re: HELP: MIPS PC Relative Addressing

On Thu, 25 Feb 2021, Jiaxun Yang wrote: > > There is a far easier way to do this, which is to just emit an assembler > > macro, and let the assembler generate the labels and relocs.  This is what > > the RISC-V GCC port does by default.  This prevents some optimizations like > > scheduling the two

Re: HELP: MIPS PC Relative Addressing

On Wed, 24 Feb 2021, Jim Wilson wrote: > > I commented on it once, in the course of the FDPIC design project, and I > > find it broken by design. Sadly it has made it into the RISC-V psABI and > > it is hard to revert at this time, too many places have started relying on > > it. > > > > It was

Re: HELP: MIPS PC Relative Addressing

On Wed, 24 Feb 2021, Jiaxun Yang wrote: > For RISC-V, %pcrel_lo shall point to the label of corresponding %pcrel_hi, > like > > .LA0: >     auipc    a0, %pcrel_hi(sym) >     addi  a0, a0, %pcrel_lo(.LA0) I commented on it once, in the course of the FDPIC design project, and I find it broke

Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

On Fri, 19 Feb 2021, Project Revolution via Gcc wrote: > Gentlemen: this was fixed, although it's a bit of an odd solution. We > had to combine both -mno-explicit-relocs and -mno-split-addresses, even > though per the MIPS compiler documentation explicit relocs supersedes > the split addresses

Re: [EXTERNAL]Re: MIPS Maintainer

On Tue, 8 Dec 2020, Chao-ying Fu wrote: > >  Well, it's up to the GCC steering committee really to appoint maintainers > > , however you can post patches and help > > with getting reviews through right away.  There hasn't been much traffic > > with the MIPS po

Re: MIPS Maintainer

Hi Chao-ying, Great to hear from you again! >   We just wonder if you can sponsor me to become a MIPS maintainer, > because Wave Computing would like to continue supporting MIPS > architecture in GCC, although there are very few patches for MIPS > recently. Any feedback is welcome. Well, it

Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?

On Mon, 30 Nov 2020, Jeff Law via Gcc wrote: > > Ping. Anybody got an opinion on the approach we should take? > Could we set warning_threshold to a value to inhibit this behavior > completely.  It seems backwards to me that warnings have this effect. Sounds like rate-limiting of some sort to me

Re: Git commit "Author: [...] via Gcc-patches "

On Thu, 19 Nov 2020, Florian Weimer wrote: > > Should we have a Git commit hook to catch that (and similar variants)? > > It's also possible to move to a mailing list host which does not > rewrite the From: header. The commit hook is better than nothing, > although it's probably a bit tricky—som

Re: `PatchSet' API mismatch causing a total `contrib/mklog.py' failure?

On Mon, 16 Nov 2020, Martin Liška wrote: > I've just pushed fix that supports unidiff 0.5.4. Great, thanks! > > Again, what's the point discussing it? Let's keep to the facts and those > > are that the script does not work with my system which is not unreasonably > > old (released last Sep f

Re: `PatchSet' API mismatch causing a total `contrib/mklog.py' failure?

On Mon, 16 Nov 2020, Jonathan Wakely wrote: > ipython is irrelevant to the mklog.py script, which doesn't use it. > It's what Martin was using on the command-line, but is not actually > relevant to the issue at hand. I am aware of that, what's the point discussing this stuff? It wasn't me who

Re: `PatchSet' API mismatch causing a total `contrib/mklog.py' failure?

On Mon, 16 Nov 2020, Martin Liška wrote: > > Let's retry with `ipython' installed now: > > > > $ git show 2935ff7eb7ac > 1 > > $ ipython > > $ Python 2.7.16 (default, Oct 10 2019, 22:02:15) > > Type "copyright", "credits" or "license" for more information. > > Please no python2, it's dead and

Re: `PatchSet' API mismatch causing a total `contrib/mklog.py' failure?

On Mon, 16 Nov 2020, Martin Liška wrote: > > I have decided to give your `contrib/mklog.py' script a hit and, well, > > ahem, I guess I must be doing something utterly silly, but no matter what > > kind of a diff I hand to the script it does not produce anything unless I > > apply a patch like b

`PatchSet' API mismatch causing a total `contrib/mklog.py' failure?

Hi Martin, I have decided to give your `contrib/mklog.py' script a hit and, well, ahem, I guess I must be doing something utterly silly, but no matter what kind of a diff I hand to the script it does not produce anything unless I apply a patch like below to it, in which case the output produce

Re: Separate commit mailing lists for trunk/branches possible?

On Sun, 19 Jul 2020, Frank Ch. Eigler wrote: > > Not the issue of wasted resources including the list server processing > > and sending the messages intended to my address, bandwidth and all the > > network equipment involved on the way, and finally the local mail server > > receiving and dispa

Re: Separate commit mailing lists for trunk/branches possible?

On Fri, 17 Jul 2020, Christopher Faylor wrote: > > Most of this stuff is vendor branch stuff I find completely uninteresting > >to me and which from my point of view is a waste of resources. I could > >filter it to /dev/null via `procmail', but that would still be a waste. > > Actually, it see

Separate commit mailing lists for trunk/branches possible?

Hi, As you have probably been well-aware the amount of traffic sent to the mailing list has grown dramatically since the switch to GIT. Last month alone I received over 13000 messages, which accounted for ~18.5% of all my incoming traffic. And right now another mailbomb has been in progres

Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

On Tue, 14 Jul 2020, Richard Biener wrote: > > > Arguably this might probably be called a deficiency in libgcc, however > > > the objects are built with `-fexceptions -fnon-call-exceptions' > > > > I consider that broken. It doesn't make any sense to build a lowlevel > > runtime library like lib

RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.)

On Sun, 12 Jul 2020, Maciej W. Rozycki wrote: > I don't think we have a way to redirect the reference to `__GI_memset'. Additionally, I need to mention that where `libgcc.a' has been built at `-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and

Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

[cc-ing Joel as the originator, and ] On Tue, 9 Jun 2020, Jacob Bachmeyer wrote: > >> I ran a quick bisection and the culprit turned out to be: > >> > >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit > >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044 > >> Author: Jacob Bachme

Re: dejagnu version update?

On Tue, 26 May 2020, Rob Savoye wrote: > > I'll run some RISC-V remote GCC/GDB testing and compare results for > > DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes > > many hours to go through these testsuite runs. > > That'd be great. I'd rather push out a stable r

Re: dejagnu version update?

On Tue, 26 May 2020, Rob Savoye wrote: > I processed the patch backlog for DejaGnu, and have gone through the > bug list. It'd be nice if somebody could try master with a more complex > environment, etc... if I'm going to push out a release. For cross > testing all I have is a PI and QEMU. I'l

Re: dejagnu version update?

On Sat, 16 May 2020, Rob Savoye wrote: > > Overall perhaps a patch management system might be good having to make > > chasing patches easier, such as patchwork, and we already use Git, so we > > As an old GNU project, we're required to use what the FSF prefers, > which is on savannah. https:/

Re: dejagnu version update?

On Thu, 14 May 2020, Rob Savoye wrote: > Right now working through patches is probably more important. :-) > There's zero patches on the DejaGnu savannah site, so I'd ask anybody to > submit them so I don't have to dig them out of email archives. I have reposted the single patch I have had out

Re: dejagnu version update?

On Thu, 14 May 2020, Rob Savoye wrote: > Personally, I tried to find funding to refactor DejaGnu in Python, > since Tcl is unmaintained too, but nobody was interested. Thank you for your contribution to DejaGnu over the years and for your input on this occasion. However it does not appear t

Re: dejagnu version update?

Hi Rainer, > > Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this > > very week I have been chasing a phenomenon with Expect's `wait' semantics > > causing a reliable hang in remote testing if `ssh' to the target board > > stops responding for whatever reason. I have come

Re: dejagnu version update?

On Wed, 13 May 2020, Rainer Orth wrote: > > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me. > > If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and > 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang > indefinitely until one manually kill

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Wed, 13 May 2020, Segher Boessenkool wrote: > > > I think that the e200 support was never contributed upstream. > > > > Or rather, it wasn't accepted. Cf. > > , > >

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, 9 May 2020, Eric Botcazou wrote: > > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > > are still lying around. > > I think that the e200 support was never contributed upstream. Or rather, it wasn't accepted. Cf.

Re: Help, Where I can find proper libtool version?

On Wed, 15 Apr 2020, 易会战 via Gcc wrote: > I am trying to add a library into gcc source code tree. The gcc source > have used libtool 2.2.7a 1.1334. but I cannot find the version. It is "libtool (GNU libtool 1.3134 2009-11-30) 2.2.7a" AFAICT, that is 1.3134 rather than 1.1334. I take it there

Re: Not usable email content encoding

On Tue, 14 Apr 2020, Christopher Faylor wrote: > >I think that means that dmarc_moderation_action: "Munge From" can > >simply be switched off then (at least I don't see which other headers > >e.g. gcc@ is rewriting that would cause DMARC to scream; and if there > >are any, then it would be better

Re: OpenACC with AMD Radeon GPU offloading

On Fri, 10 Apr 2020, Thomas Schwinge wrote: > > I run mu code with : > > gfortran -fopenacc -fno-automatic -s Test.f90 -o Test > > I don't know off-hand what '-s' means here, but otherwise that should be > good -- assuming GCC has been built with AMD GPU offloading support, has > been properly in

Re: Not usable email content encoding

On Tue, 7 Apr 2020, Christopher Faylor wrote: > >In a way that's amusing and just reinforces my p.o.v. that DMARC is > >bollocks. > > Not that it means anything but I agree 100%. > > It's like whoever made the "standard" just said "to hell with mailing > lists". Maybe they just didn't know of

Re: Not usable email content encoding

On Tue, 7 Apr 2020, Christopher Faylor wrote: > >Can we please switch it off? It's not like we really had a problem before > >the switch to mailman. > > You can't really make statements like this which imply that you are > aware of "problems" on sourceware when you're not a sourceware > adminis

Re: Not usable email content encoding

Hi Frank, > > I am fairly sure it breaks `git am' too, requiring a `From' override in > > the change description for author attribution in patch application to work > > reliably (I tend to work on my outbox when applying my own patches, so I > > avoid this issue, but I am sure the issue will h

Re: Not usable email content encoding

On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > Out of curiousity, is this rewriting you are talking about the cause for a > > lot of mails showing up as "From: GCC List" rather than their real senders? > > This has become very annoying recently. > > Yes, for emails from domains with dec

Re: Can we please have the old mailing list back

On Thu, 2 Apr 2020, Jonathan Wakely via Gcc wrote: > > Regarding the overseers, they repeatedly spoke up on this list, > > but all the time they use an e-mail that bounces. > > No. ONE of the overseers replies from a personal email address that > bounces, because as the address clearly says, you

Re: Can we please have the old mailing list back

On Fri, 27 Mar 2020, Jeff Law via Gcc wrote: > As an ex IT guy, I've gone both directions depending on the project I was > supporting and certainly see the pros and cons of going highly customized vs > as > generic as possible. In my opinion Chris & Frank are doing the right thing > here > and

Re: Spam, bounces and gcc list removal

Hi Winfried, > [..] > > Spam bouncing is evil and often hits an innocent person > [..] > > others like me might see it different: > Spam discarding is evil and often hits an innocent person. > > Silently discarding a legal mail because of false spam-detection is > the worst case f

Re: Spam, bounces and gcc list removal

On Sun, 22 Mar 2020, Florian Weimer wrote: > > You mean as with a failure response given to the SMTP DATA command? > > This is actually equally evil as the resulting bounce (i.e. a delivery > > failure notification, or a flood of them, once other MTAs have joined in a > > response to a mass m

Re: Spam, bounces and gcc list removal

On Sun, 22 Mar 2020, Florian Weimer wrote: > > Spam bouncing is evil and often hits an innocent person whose address has > > been faked by the sender of spam, making the source of bounces not better > > than the originator. > > I expect this to be an SMTP-level rejection, not a bounce. source

Re: Not usable email content encoding

On Tue, 17 Mar 2020, Segher Boessenkool wrote: > > I'm surprised it's an issue for you: normally your email client > > would transform quoted-printable and copying would do the right thing > > (i.e. select actual patch contents, without whitespace munging). > > > > Are you trying to copy from the

Re: Spam, bounces and gcc list removal

On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > So, a request: Could the overseers either install more effective > > > spam protection for the list as a whole (preferred) > > Heh, if only it were that easy! Spam filtering was and is distinct > from mailing list processing, and as you

Re: Improving GCC's line table information to help GDB

Hi Luis, > Is there a better way to force the compiler to output such a line table > transition without having to resort to a dummy jump? Is there a safer > way to add such transitions without worrying about the optimizer getting > rid of them later on? Should we even worry about preserving suc

Re: ChangeLog's: do we have to?

On Thu, 5 Jul 2018, Tom Tromey wrote: > I use git-merge-changelog from gnulib. If you want to use git am and > avoid manually copying ChangeLog text from the commit message back into > the appropriate files, then it's much better to install the driver and > include the ChangeLog diffs in the patc

[PING][PATCH] gdb/x86: Fix `-Wstrict-overflow' build error in `i387_collect_xsave'

On Tue, 15 May 2018, Maciej W. Rozycki wrote: > gdb/ > * i387-tdep.c (i387_collect_xsave): Make `i' unsigned. Ping for: <https://patchwork.sourceware.org/patch/27269/>. Maciej

[PATCH] gdb/x86: Fix `-Wstrict-overflow' build error in `i387_collect_xsave'

Make `i' defined within `i387_collect_xsave' unsigned, removing a `-Werror=strict-overflow' compilation error: .../gdb/i387-tdep.c: In function 'void i387_collect_xsave(const regcache*, int, void*, int)': .../gdb/i387-tdep.c:1348:1: error: assuming signed overflow does not occur when assuming t

Re: Internal compiler error building libstdc++ for vax

On Sun, 8 Apr 2018, Jeff Law wrote: > I think you need to go back to my earlier reply and read it carefully. > In particular, you need an insn where the label_ref and pc are swapped. Ouch, there are no reversed interlocked branch instructions in the VAX ISA, so these would have to branch around

Re: how to generate - "procedure linkage table" for MIPS

Hi Vidya, On Mon, 5 Mar 2018, V R wrote: > Also on enabling gcc on MIPS with "–with-mips-plt " option the plt stub > wasnt seen. Is there > > anything missing that needs to be done or is there any limitation , please > let me know. What problem are you trying to solve? Can you run `readelf -S

RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

Hi Matthew, On Fri, 11 Nov 2016, Matthew Fortune wrote: > This means that a user consciously creating an object that 'needs' ieee > compliance via use of -fieee=strict or -mieee=strict is thwarted by the > next user who builds the executable. This kind of scenario can occur with > a static librar

Re: Obsolete powerpc*-*-*spe*

On Wed, 15 Mar 2017, Andrew Jenner wrote: > > I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC, > > please correct me if that is incorrect. Also, is "normal" floating > > point supported at all? > > My understanding is that SPE is only present in the e500v1, e500v2 and > e200z[

Re: [PATCH MIPS] Work around Bash 4.2 bug

On Fri, 30 Sep 2016, Hans-Peter Nilsson wrote: > > The patch below works around the Bash 4.2 bug described at > > . > > > * emulparams/elf32bmipn32-defs.sh: Shift quote of > > "x$EMULATION_NAME" to the left to work around > >

RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

Hi Matthew, I'm back to this effort now, thanks for patience. > Thanks for the update. I've read through the whole proposal again and > it looks good. I'd like to discuss legacy objects a bit more though... Thanks for your review. > > 3.4 Relocatable Object Generation > > > > Tools that p

[RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

Dear fellow developers, Here is the second revision of the ABI extension specification previously posted, incorporating feedback received for the first revision. Changes have been made to Section 4 "Implementation Notes", the remaining parts have stayed the same. The master copy of this docum

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

On Mon, 18 Apr 2016, Michael Matz wrote: > E.g. one limitation might very well be that function pointer comparison > for protected functions doesn't work (gives different outcomes if the > pointer is built from inside the exe or from a shared lib). (No matter > how it's built, it will still _w

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

On Mon, 18 Apr 2016, H.J. Lu wrote: > > Any testcase the takes the address of a protected visibility variable > > defined in a shared library now can get the wrong answer, since you > > can argue that any address outside the shared library is wrong > > according to the gABI. > > What value should

RE: [Patch] MIPS FDE deletion

On Wed, 10 Feb 2016, Moore, Catherine wrote: > > I saw your patch handles the `fn_stub' case among others and your test case > > included an `__fn_stub_foo' stub too, which is what PR target/53276 is all > > about, which is why I thought it may have been resolved and the existence > > of the PR a

RE: [Patch] MIPS FDE deletion

On Mon, 11 Jan 2016, Moore, Catherine wrote: > > Does it mean PR target/53276 has been fixed now? What was the commit to > > add .cfi support for the stubs? > > I don't know about the status of PR target/53276. The commit to add > .cfi support for call stubs was this one: > > r184379 | rsand

Re: [Patch] MIPS FDE deletion

Hi Catherine, On Fri, 16 Oct 2015, Moore, Catherine wrote: > MIPS16 call stubs now have .cfi directives. If the linker decides that > one of these call stubs is not required, it will emit incorrect frame > info. This patch suppresses the generation of the frame info by setting > the output s

Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

On Fri, 27 Nov 2015, Joseph Myers wrote: > > I find it highly unlikely though that the writers will (be able to) chase > > individual targets and any obscure hardware-dependent options the targets > > may provide. And we cannot expect people compiling software to be > > What that says to me i

Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

On Fri, 20 Nov 2015, Joseph Myers wrote: > > The target audience for the `-mieee=strict' option is in my idea a > > non-technical user, say a physicist, who does not necessarily know or is > > fluent with the guts of computer hardware and who has the need to build > > and reliably run their so

Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

On Tue, 17 Nov 2015, Joseph Myers wrote: > > Any or all of these options may have effects beyond propagating the IEEE > > Std 754 compliance mode down to the assembler and the linker. In > > particular `-mieee=strict' is expected to guarantee code generated to > > fully comply to IEEE Std 754 ra

Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

On Sat, 14 Nov 2015, Cary Coutant wrote: > > 3.3.2 Static Linking Object Acceptance Rules > > > > The static linker shall follow the user selection as to the linking mode > > used, either of `strict' and `relaxed'. The selection will be made > > according to the usual way assumed for the environ

[RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

Dear fellow developers, On behalf of Imagination Technologies I would like to introduce the following ABI extension to create a compatibility solution for opposing NaN encodings. I will appreciate your feedback and will happily answer any questions and address any concerns you may have. A c

Re: TARGET_PROMOTE_PROTOTYPES question

On Wed, 21 Oct 2015, Jeff Law wrote: > > Now I know that we can't get rid of these truncation/extensions > > entirely, but do we need both? It seems like foo could say that > > if the original registers (198 and 200) are argument registers > > that were extended to SImode due to TARGET_PROMOTE_PR

Re: [PATCH] gcc/testsuite: guality.exp: Fix `test_counts' restoration

On Fri, 14 Nov 2014, Jakub Jelinek wrote: > > gcc/testsuite/ > > * g++.dg/guality/guality.exp (check_guality): Fix `test_counts' > > restoration. > > Ok, thanks. Applied, thanks. Maciej

[PATCH] gcc/testsuite: guality.exp: Fix `test_counts' restoration

tring match "*1 PASS, 0 FAIL, 0 UNRESOLVED*" $execout] > } > remote_file build delete $output > +array set test_counts [array get saved_test_counts] > return $ret > } > OK to apply? 2014-11-14 Maciej W

RE: [RFC, MIPS] Relax NaN rules

On Mon, 24 Mar 2014, Matthew Fortune wrote: > Yes this is a lot simpler than the 3rd mode but disabling the NAN2008 ELF > Flag checks is even more honest as that is what would happen at the > kernel-userland boundary anyway, so why enforce it elsewhere. > > I know I am pushing hard on this topic

Re: [RFC, MIPS] Relax NaN rules

On Sat, 22 Mar 2014, Richard Sandiford wrote: > > Thanks Joseph. I guess I'm not really pushing to have don't-care > > supported as it would take a lot of effort to determine when code does > > and does not care, you rightly point out more cases to deal with > > too. I'm not sure if the benefit wo

RE: [RFC, MIPS] Relax NaN rules

On Fri, 21 Mar 2014, Joseph S. Myers wrote: > > I ask this for another reason as well: since we're adding IFUNC > > capability to MIPS, we may need to harden the dynamic loader to protect > > $f12 and $f14. If signaling NaN was raised on the load, then we have > > more problems to deal with...

Re: i686 elf return values

On Tue, 6 Aug 2013, Gabriel Dos Reis wrote: > On Tue, Aug 6, 2013 at 1:46 PM, Nathan Sidwell wrote: > > Hi, > > i386elf.h defines: > > > > /* The ELF ABI for the i386 says that records and unions are returned > >in memory. */ > > > > #define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \ > >

Re: mips16 and nomips16

On Fri, 25 Jan 2013, Richard Sandiford wrote: > > FWIW, I think the benefit from these attributes being a type property is > > questionable to say the least. My understanding is the only application > > is to prevent the tail-call optimisation from being applied to non-PIC > > standard MIPS f

Re: mips16 and nomips16

On Fri, 18 Jan 2013, Richard Sandiford wrote: > > I would assume that foo would be nomips16 and goo would be mips16. > > > > The definition of plain foo() or goo() says that nothing is specified. > > > > What is not clear then? > > > > This is how all such other attributes in gcc are handled. > >

Re: mips16 and nomips16

On Tue, 15 Jan 2013, David Daney wrote: > > I'm not understanding why mips16 and nomips16 are not simple inheritable > > attributes. > > The mips16ness of a function must be known by the caller so that the > appropriate version of the JAL/JALX instruction can be emitted Not really, the issue of

Re: [RFD+PATCH] ISA bit treatment on the MIPS platform

anges included. And last but not least, I've included an update to cover Linux microMIPS signal trampolines, complementing the change just sent as a followup to the original microMIPS support patch. 2012-05-18 Maciej W. Rozycki gdb/testsuite/ * gdb.base/func-ptrs.c

Re: X32 psABI status

On Sun, 13 Feb 2011, Florian Weimer wrote: > >> Actually, I'm wondering if you can do the translation in user space. > >> There already are 32-on-64 implementations in existence, without > >> kernel changes (recent Hotspot, LuaJIT, and probably some more). > > > > Please check out the x32 kernel s

Re: MIPS atomic memory operations (A.K.A PR 33479).

On Wed, 19 Sep 2007, David Daney wrote: > I just checked myself. 'sync' is not emulated. We will have to make a change > so that it is not emitted on ISAs that do not support it. The problem is if such software is run on a newer processor it may silently break. Tough, I know... We should ha

Re: MIPS atomic memory operations (A.K.A PR 33479).

On Wed, 19 Sep 2007, David Daney wrote: > Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and > 'sync', If sync is not emulated, we would need to adjust the code generation > so that it is not emitted on ISAs that don't support it. While adding "sync" is trivial enough

Re: MIPS atomic memory operations (A.K.A PR 33479).

On Wed, 19 Sep 2007, Ralf Baechle wrote: > Please make this loop closure branch a branch-likely. This is necessary > as a errata workaround for some processors. Do we emulate them for MIPS I? We do emulate "ll" and "sc" and adding "sync" is easy (as a no-op as support for R3000 SMP is unlikel