> On May 6, 2025, at 1:17 PM, Segher Boessenkool
> wrote:
>
> ...
>>> As for MEM(MEM(xyz)) addressing modes I'm less sure - I suppose those
>>> are usually formed at RTL expansion time (rather than, say, by
>>> RTL combine)? If PDP-11 is the only target with those then it might
>>> be easier
> On May 3, 2025, at 6:52 AM, Richard Biener wrote:
>
> On Fri, 2 May 2025, Paul Koning wrote:
>
>>
>>
>>> On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
>>>
>>> ...
>>> NB I understand your position and the need to cut t
> On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
>
> ...
> NB I understand your position and the need to cut the line sometime, and
> I knew what the situation is with the VAX backend and that it would be
> manageable. In principle it might be that it's only that single ICE that
> n
> On Mar 21, 2025, at 11:44 PM, Robert Dubner wrote:
>
> [I am going to try to maintain a grip on my professionalism. A
> professional does not give in to the urge to say, "I told you so".]
>
> This program, compiled with the most recent level of patching, is
> generating the result
>
>
> On Mar 13, 2025, at 2:33 PM, James K. Lowden wrote:
>
> ...
> 3. --enable-languages=cobol, and
> 4. the host and target are "plausible", 64-bit LE.
Why does it need LE? I understand 64 bits. I might try it on my PowerPC based
Mac. :-)
paul
> On Mar 13, 2025, at 11:27 AM, James K. Lowden
> wrote:
>
> On Mon, 10 Mar 2025 19:10:26 +0100
> Richard Biener wrote:
>
>>> What is the right answer? Designated initializers are part of C99,
>>> but weren't added to C++ until C++20
>>> (https://en.cppreference.com/w/cpp/language/initiali
> On Feb 21, 2025, at 2:23 PM, Florian Weimer wrote:
>
> * Paul Koning:
>
>>> On Feb 21, 2025, at 1:59 PM, Florian Weimer wrote:
>>>
>>> * James K. Lowden:
>>>
>>>> As I mentioned in other posts, IMO (IANAL) the copyright i
> On Feb 21, 2025, at 1:59 PM, Florian Weimer wrote:
>
> * James K. Lowden:
>
>> As I mentioned in other posts, IMO (IANAL) the copyright in
>> unimportant and probably unenforceable. The National Computing
>> Centre no longer exists, and the document was also published by NIST
>> which, as
> On Feb 19, 2025, at 8:18 PM, James K. Lowden wrote:
>
> On Wed, 19 Feb 2025 12:55:03 +0100
> Matthias Klose wrote:
>
>> libgcobol/ChangeLog
>> * Makefile.in: New file.
>> * acinclude.m4: New file.
>> * aclocal.m4: New file.
>> * configure.ac: New file.
>> * configure.tgt: New file.
>>
>>
> On Aug 26, 2024, at 10:40 AM, Michael Matz wrote:
>
> Hello,
>
> On Mon, 26 Aug 2024, Paul Koning wrote:
>
>>>>> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
>>>>> 551: [--sp] = 37sp_off = -4 {pushexthisi_const
> On Aug 26, 2024, at 10:14 AM, Michael Matz wrote:
>
> Hello,
>
> On Sun, 25 Aug 2024, Jeff Law wrote:
>
>>> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
>>> 551: [--sp] = 37sp_off = -4 {pushexthisi_const}
>>> 552: [--sp] = r37 sp_off = -8 {movsi_m
> On Jul 30, 2024, at 6:17 AM, Richard Biener wrote:
>
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode instead
> On Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus
> wrote:
>
> On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote:
>>
>>
>>> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
>>> wrote:
>>>
>>>
> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
> wrote:
>
> On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
>>
>>>>> ...
>>>>> could be rewritten into
>>>>>
>>>>> int test (int
> On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus
> wrote:
>
> Ping.
>
> On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
>> Ping.
>>
>> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
>>> This implements hard register constr
Thanks Kewen.
Given that background, the patch is OK.
paul
> On Jun 16, 2024, at 10:01 PM, Kewen.Lin wrote:
>
> Hi Paul,
>
> on 2024/6/14 23:20, Paul Koning wrote:
>> Ok, I understand better now. But if those macros are supposed to be
>> replaced by hoo
Ok, I understand better now. But if those macros are supposed to be replaced
by hook functions, could you make that replacement part of the proposed patch?
paul
> On Jun 13, 2024, at 11:22 PM, Kewen.Lin wrote:
>
> Hi Paul,
>
> on 2024/6/14 04:07, Paul Koning wrote:
What is the effect of this change? The original code intended to have "float"
mean a 32 bit value, and "double" a 64 bit value. There aren't any larger
floats, so I defined the long double size as 64 also. Is the right answer not
to define it?
That part I understand, but why does the patch a
> On May 21, 2024, at 9:57 AM, Jeff Law wrote:
>
>
>
> On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
>> On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
>>>
>>> On Wed, 5 Jul 2023, Joern Rennecke wrote:
I haven't worked with these targets in years and can't really do
se
> On Feb 16, 2024, at 6:34 AM, Maciej W. Rozycki wrote:
>
> On Thu, 15 Feb 2024, Paul Koning wrote:
>
>>> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote:
>>>
>>> ...
>>>
>>> I may choose to implement a non-DWARF unwinder inste
> On Feb 15, 2024, at 5:56 PM, Segher Boessenkool
> wrote:
>
> On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote:
>> I have now started doing this in PR113932.
>
> Thank you!
>
> Segher
Presumably this isn't for version 14 since it's in a late stage, right? I have
my bits about r
> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote:
>
> ...
>
> I may choose to implement a non-DWARF unwinder instead, as the VAX stack
> frame is always fully described by the hardware and there is never ever a
> need for debug information to be able to decode any VAX stack frame (the
> On Nov 22, 2023, at 8:54 AM, Simon Wright wrote:
>
> On 21 Nov 2023, at 23:13, Iain Sandoe wrote:
>
>>> #if defined (__APPLE__)
>>> -#include
>>
>> If removing unistd.h is intentional (i.e. you determined that it’s no longer
>> needed for Darwin), then we should make that a separate patc
> On Aug 16, 2023, at 3:42 PM, Philipp Tomsich wrote:
>
> On Wed, 16 Aug 2023 at 21:10, Alexander Monakov wrote:
>>
>>
>> On Tue, 15 Aug 2023, Jeff Law wrote:
>>
>>> Because if the compiler can optimize it automatically, then the projects
>>> have
>>> to do literally nothing to take advan
> On Aug 16, 2023, at 3:53 AM, Alexander Monakov wrote:
>
>> ...
>> Is "timing-safety" a security property? Not the way I understand that
>> term. It sounds like another way to say that the code meets real time
>> constraints or requirements.
>
> I meant in the sense of not admitting timing
> On Aug 15, 2023, at 8:37 PM, Alexander Monakov wrote:
>
>> ...
>> At some point the system tools need to respect the programmer or operator.
>> There is a difference between writing "Hello, World" and writing
>> performance critical or safety critical code. That is the responsibility
>> of
> On Aug 15, 2023, at 10:07 AM, Alexander Monakov wrote:
>
>
> On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
>
>> Does this as the first paragraph address your concerns:
>
> Thanks, this is nicer (see notes below). My main concern is that we shouldn't
> pretend there's some method of verif
> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code
> On Aug 9, 2023, at 2:32 AM, Alexander Monakov wrote:
>
>
> On Tue, 8 Aug 2023, Jeff Law wrote:
>
>> If the compiler can identify a CRC and collapse it down to a table or clmul,
>> that's a major win and such code does exist in the real world. That was the
>> whole point behind the Fedora e
> On Aug 8, 2023, at 11:55 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-08 11:48, David Malcolm wrote:
>> On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote:
>>>
>>>
>>>> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches
> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches
> wrote:
>> There's probably external tools to do this, not sure if we should replicate
>> things in the driver for this.
>>
>> But sure, I think
> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson wrote:
>
> If the stack frame only contains an alloca area, then
> pdp11_expand_epilogue fails to deallocate it, resulting
> in callee-saved registers and the return address being
> restored from the wrong stack slots. Fixed by adding
> || cfu
> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson wrote:
>
> If the stack frame only contains an alloca area, then
> pdp11_expand_epilogue fails to deallocate it, resulting
> in callee-saved registers and the return address being
> restored from the wrong stack slots. Fixed by adding
> || cfu
> On May 11, 2023, at 11:05 AM, Hans-Peter Nilsson via Gcc-patches
> wrote:
>
> ...
> Yes, very interesting. Thank you for sharing this. I've
> seen regressions with LRA for CRIS too, for
> "double-register-sized" types, which for CRIS, a 32-bit
> target, translates to 64-bit types (DFmode
> On May 2, 2023, at 9:18 AM, Roger Sayle wrote:
>
>
> On 02 May 2023 13:40, Paul Koning wrote:
>>> On May 1, 2023, at 7:37 PM, Roger Sayle
>> wrote:
>>>
>>> ...
>>> The shiftsi.cc regression on xstormy16 is fixed by adding
>>
> On May 1, 2023, at 7:37 PM, Roger Sayle wrote:
>
> ...
> The shiftsi.cc regression on xstormy16 is fixed by adding
> -fno-split-wide-types.
> In fact, if all the regression tests pass, I'd suggest that
> flag_split_wide-types = false
> should be the default on xstormy16 now that we've moved
On the check for verbose==2, should that be verbose >= 2 ?
paul
> On Apr 28, 2023, at 6:38 AM, Tamar Christina via Gcc-patches
> wrote:
>
> Hi All,
>
> genmatch currently outputs commented out line directives that have no effect
> but the compiler still has to parse only to discard.
>
> On Apr 26, 2023, at 8:05 PM, Hans-Peter Nilsson wrote:
>
> Not many targets define this besides msp430, pdp1, xtensa,
> and arm compared to those that appear to unconditionally
> have a hardware division instruction (also, pdp11 and
> msp430 seem confused and should be empty instead of "1"
> On Apr 23, 2023, at 12:47 PM, Segher Boessenkool
> wrote:
>
> This minimal patch enables LRA for all targets. It does not clean up
> the target code, nor does it do anything to generic code: it just
> deletes all target definitions of TARGET_LRA_P.
>
> There are three kinds of changes:
>
I'm not sure about the meaning of part of this. "...resumes at the last
generated insn." Does that mean:
1. If a match is found at some insn, the replacement defined by the matching
define_peephole2 is performed, and then the scan resumes at the first of the
insns produced by the replacement.
> On Mar 21, 2023, at 1:59 PM, Jeff Law via Gcc-patches
> wrote:
>
>
>
> On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote:
>>> On Mar 21, 2023, at 12:56 PM, Paul Koning wrote:
>>>
>>>
>>>
>>>> On
> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches
> wrote:
>
> ...
> Most of the compiler users are not familiar with language standards, or no
> access to language standards. Without clearly documenting such warnings along
> with the option explicitly, the users have not way to kno
> On Jan 13, 2023, at 8:54 PM, Alexandre Oliva via Gcc-patches
> wrote:
>
> Hello, Richard,
>
> Thank you for the feedback.
>
> On Jan 12, 2023, Richard Biener wrote:
>
>> On Tue, Dec 27, 2022 at 5:12 AM Alexandre Oliva via Gcc-patches
>> wrote:
>
>>> This patch extends the memset expan
> On Jan 12, 2023, at 9:40 AM, Segher Boessenkool
> wrote:
>
> On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote:
>>> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool
>>> wrote:
>>> I mean general_operand accepts that sp thing you saw. But
> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool
> wrote:
>
> On Wed, Jan 11, 2023 at 05:07:47PM -0500, Paul Koning wrote:
>>> On Jan 11, 2023, at 2:28 PM, Segher Boessenkool
>>> wrote:
>>> I would say your predicates are way too lenient here (ge
> On Jan 11, 2023, at 2:28 PM, Segher Boessenkool
> wrote:
>
> On Wed, Jan 11, 2023 at 01:42:22PM -0500, Paul Koning wrote:
>> Or, as in my case, because building with LRA as the default triggers an ICE
>> that I don't understand. I posted a note to the GCC l
> On Jan 11, 2023, at 1:32 PM, Segher Boessenkool
> wrote:
>
> On Wed, Jan 11, 2023 at 05:27:36PM +0100, Richard Biener wrote:
>>> Am 11.01.2023 um 16:17 schrieb Segher Boessenkool
>>> :
Note this is more info for port maintainers not for users and
changes.html is for users.
>>>
>
Does this mean that targets that have an option to use LRA or not should now
default to LRA? Some currently default to old reload.
paul
> On Jan 5, 2023, at 2:27 PM, Segher Boessenkool
> wrote:
>
> Hi!
>
> Happy new year everyone.
>
> Is this patch okay to commit?
>
>
> Segher
>
> On Mar 19, 2021, at 5:21 AM, Martin Liska wrote:
>
>
> gcc/ChangeLog:
>
> ...
> * config/pdp11/pdp11.c (pdp11_output_ident): Likewise.
pdp11 is ok. Thanks.
paul
It's probably obvious to most, but... I just got a fairly plausible looking
phishing email pretending that my gcc.gnu.org password was about to expire.
The link it asked me to click on was a giveaway that the mail came from a
criminal, but we know that these red flags can be overlooked.
So jus
> On Jan 7, 2021, at 8:50 PM, Maciej W. Rozycki wrote:
>
> ...
>
> Provide a new iterator to provide copies of FP substitutions across the
> FP modes supported as the substitutions now need to match the mode of
> the operands.
>
> gcc/
> * config/pdp11/pdp11.md (PDPfp): New mod
> On Jan 5, 2021, at 8:54 AM, Senthil Kumar Selvaraj via Gcc-patches
> wrote:
>
>
> Senthil Kumar Selvaraj writes:
>
>> Georg-Johann Lay writes:
>>
>> ...
>>>
>>> 2) We just saw 100reds of insns being dublicated, basically the whole
>>> machine description except for the few insns that le
> On Dec 17, 2020, at 6:21 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via
> Gcc-patches wrote:
>> The work on my github branch was not complete - I'd blindly followed
>> whatever the CC0 Transition wiki mentioned (the first t
> On Dec 16, 2020, at 6:35 AM, Maciej W. Rozycki wrote:
>
> ...
> NB the PDP-11 pieces affected here and tripping this assertion are I
> believe dead code, as these insns are only ever produced by splitters and
> do not appear to be referred by their names.
Right; I gave them names for do
> On Dec 15, 2020, at 9:06 AM, Maciej W. Rozycki wrote:
>
> On Tue, 15 Dec 2020, Martin Liška wrote:
>
>> If I see correctly, starting from this revision I can't compile a cross
>> compiler of x86_64-linux-gnu:
>>
>> ../configure --target=pdp11-aout --disable-bootstrap --enable-languages=c,c
> On Dec 11, 2020, at 9:54 AM, Maciej W. Rozycki wrote:
>
> On Wed, 9 Dec 2020, Paul Koning wrote:
>
>>> This all sounds great. Do you happen to know if it is cycle-accurate
>>> with respect to individual hardware microarchitectures simulated? That
>>
> On Dec 9, 2020, at 9:06 AM, Maciej W. Rozycki wrote:
>
> On Sat, 28 Nov 2020, Paul Koning wrote:
>
>>> Hmm, I gather those systems are able to run some kind of BSD Unix: don't
>>> they support the r-commands which would allow you to run DejaGNU testin
> On Nov 25, 2020, at 12:07 PM, Maciej W. Rozycki wrote:
>
> On Mon, 23 Nov 2020, Paul Koning wrote:
>
>>> ...
>
>> I've hacked together a primitive newlib based "bare metal" execution
>> test setup that uses SIMH, but it's not a par
> On Nov 25, 2020, at 5:05 PM, Hans-Peter Nilsson wrote:
>
> On Tue, 24 Nov 2020, Eric Botcazou wrote:
>
>>> I'm intested in any notes, however vague, on that matter. I was
>>> a bit surprised to see that myself...that is, after fixing
>>> *some* related regressions, like the one in combine.
> On Nov 19, 2020, at 10:38 PM, Maciej W. Rozycki wrote:
>
> Hi,
>
> [Paul, there's a PDP11 piece for you further down here and then 29/31.]
>
> ...
>
> Then there is a fix for the PDP11 backend addressing an issue I found in
> the handling of floating-point comparisons. Unlike all the ot
> On Nov 10, 2020, at 6:09 PM, Jeff Law via Gcc-patches
> wrote:
>
>> ...
>> ChangeLog
>>
>> gcc/
>> PR target/77510
>> * config/mips/gs464.md: Reduce reservation
>> duration to 10 cycles.
>> * config/mips/i6400.md: Likewise.
>> * config/mips/m5100.md: Likewise.
>> * con
> On Nov 10, 2020, at 6:42 AM, Xu Chenghua wrote:
>
>
> Hi:
>
> This patch reduce reservation of model do not more than 10 cycles. The memory
> of genautomata down to 1GB.
Does this make any significant difference in performance of the generated code?
The original cycle counts are from t
> On Jul 18, 2020, at 2:50 PM, Jakub Jelinek via Gcc-patches
> wrote:
>
> Hi!
>
> The following patch adds __builtin_bit_cast builtin, similarly to
> clang or MSVC which implement std::bit_cast using such an builtin too.
> It checks the various std::bit_cast requirements, when not constexpr
Ok, thanks.
paul
> On Mar 11, 2020, at 1:12 PM, Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, the generic code decides to put the a variable into
> lcomm_section, which is a NOSWITCH section and thus the generic code doesn't
> switch into a particular section before using
> On Dec 5, 2019, at 11:17 AM, Joseph Myers wrote:
>
> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
>
>> In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner
>> stated that even he is not using a 80 x 24 terminal anymore, and that
>> should tell us something. ;-)
>>
>> So,
> On Nov 21, 2019, at 7:42 PM, Segher Boessenkool
> wrote:
>
> ...
> Maybe i386 should implement the insn_cost hook as well? For most targets
> that is a lot simpler to get right than rtx_cost, but allowing memory in
> many insns and all the different insn lengths complicates matters. At
>
> On Oct 30, 2019, at 2:24 PM, Jeff Law wrote:
>
> On 10/30/19 2:12 AM, Richard Biener wrote:
>> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
>>
>> I think the wiki has better examples. That said, I wonder how much can
>> be automated here, for example when just considering CCmode (m6
> On Oct 3, 2019, at 9:12 AM, Richard Earnshaw (lists)
> wrote:
>
> On 03/10/2019 10:48, Segher Boessenkool wrote:
>>> ...
>> But ALL_REGS should contain *all* registers. The union of any two register
>> classes has to be contained in some register class, so every register class
>> has to be
On Oct 1, 2019, at 5:14 AM, Segher Boessenkool
wrote:
>
> The regrename pass temporarily changes some operand RTL to CC0 so that
> note_stores and scan_rtx don't see those operands. CC0 is deprecated
> and we want to remove it, so we need to use something else here.
> PC fits the bill fine.
CC
> On Sep 26, 2019, at 12:01 PM, Jeff Law wrote:
>
> On 9/26/19 9:47 AM, Jakub Jelinek wrote:
>> On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
>>> Right. My point is that the multiplication patterns are an exception as
>>> well.
>>
>> Do you have some evidence for that?
> It's in
> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote:
>
> On 9/20/19 11:22 AM, Richard Biener wrote:
>> ...
>> It seems to be that for the goal to keep a target alive a variant #2
>> conversion (according to the wiki) should be closely mirror CC0
>> behavior and thus should be easier to achieve and w
> On Sep 11, 2019, at 11:48 AM, Wilco Dijkstra wrote:
>
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration
> on practically any target. So set it correctly to 1 on Arm.
If the documentation is in
> On Jun 25, 2019, at 4:22 PM, acsaw...@linux.ibm.com wrote:
>
> From: Aaron Sawdey
>
> * config/pdp11/pdp11.md (movmemhi, movmemhi1,
> movmemhi_nocc, UNSPEC_MOVMEM): Change movmem to cpymem.
Ok, thanks.
paul
> On May 15, 2019, at 2:42 PM, Eric Gallager wrote:
>
>> ...
>
> Wasn't Eric S. Raymond working on his own conversion of the GCC repo
> from SVN to Git? Whatever happened to his?
Yes, and from what I recall he found that doing it fully correctly is an
extremely hard task. It might be a goo
> On Mar 25, 2019, at 12:07 PM, Jeff Law wrote:
>
>> ...
>> 1) Does GCC support building with compilers where int is not 32
>>bits wide, or where BITS_PER_UNIT is not 3? (I.e., either is
>>less or more?)
> We've certainly supported 16 bit ints in the past. H8/300 would be an
> example
> On Mar 24, 2019, at 8:21 PM, Martin Sebor wrote:
>
> ...
> PS I have a couple of questions related to the affected code:
> 1) Does GCC support building with compilers where int is not 32
> bits wide, or where BITS_PER_UNIT is not 3? (I.e., either is
> less or more?)
Yes. pdp11 int can
> On Jan 9, 2019, at 3:42 AM, Tom de Vries wrote:
>
> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
>
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) cha
> On Dec 17, 2018, at 2:23 PM, Szabolcs Nagy wrote:
>
> On 17/12/2018 18:22, Uecker, Martin wrote:
>>>
>>> ...
>>
>> So a thread_local static variable for storing the static
>> chain?
>
> something like that, but the more i think about it the
> harder it seems: the call site of the nested f
> On Dec 12, 2018, at 5:12 PM, Uecker, Martin
> wrote:
>> ...
>> I've not seen such an alternative implementation (-fno-trampolines is
>> ignored on all targets I tried),
>
> It was implemented for Ada. But here is a patch to also
> activate it for C:
>
> https://gcc.gnu.org/ml/gcc-patches/2
This fixes a cut & paste oversight in udivmodhi4 (which is currently used only
by the pdp11 target) reported by Stefan Kanthak.
Committed as obvious.
paul
ChangeLog:
2018-12-05 Paul Koning
* udivmodhi4.c (__udivmodhi4): Fix loop end check.
Index: libgcc/udivmodh
> On Nov 26, 2018, at 4:13 AM, Mark Wielaard wrote:
>
> With -Wtrampolines a warning is produced whenever gcc generates executable
> code on the stack at runtime to support taking a nested function address
> that is used to call the nested function indirectly when it needs to access
> any vari
This fixes a number of testsuite failures in pdp11.
Committed.
paul
ChangeLog:
2018-11-25 Paul Koning
* config/pdp11/pdp11.h (TARGET_HAS_NO_HW_DIVIDE): Define.
Index: config/pdp11/pdp11.h
===
--- config/pdp11
test.
Committed.
paul
testsuite/ChangeLog:
2018-11-19 Paul Koning
* gcc.c-torture/execute/align-3.c: Skip if pdp11.
* gcc.c-torture/execute/pr23467.c: Ditto.
* gcc.c-torture/execute/pr36093.c: Ditto.
* gcc.c-torture/execute/pr43783.c: Ditto
> On Nov 19, 2018, at 5:20 PM, Jeff Law wrote:
>
> On 11/19/18 3:18 PM, Paul Koning wrote:
>> This patch changes check_weak_available to report that pdp11 does not
>> support "weak". A number of test case failures are caused by attempts to
>> use weak
gure it's
best to ask for approval.
Ok for trunk?
paul
testsuite/ChangeLog:
2018-11-19 Paul Koning
* lib/target-supports.exp (check_weak_available): Return "no" for
pdp11.
Index: lib/target-supports.exp
=
> On Nov 14, 2018, at 5:19 PM, Jozef Lawrynowicz
> wrote:
>
> On Wed, 14 Nov 2018 11:30:39 -0500
> Paul Koning wrote:
>
>>> On Nov 14, 2018, at 10:44 AM, Jozef Lawrynowicz
>>> wrote:
>>>
>>> Patch 1 tweaks dg directives in tests spe
> On Nov 14, 2018, at 1:00 PM, Jozef Lawrynowicz
> wrote:
>
> On 14/11/2018 16:54, Andreas Schwab wrote:
>> On Nov 14 2018, Jozef Lawrynowicz wrote:
>>
>>> diff --git a/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-10.c
>>> b/gcc/testsuite/c-c++-common/torture/builtin-arith-ove
> On Nov 14, 2018, at 10:44 AM, Jozef Lawrynowicz
> wrote:
>
> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
> these are extensions to existing target selectors in dg directives.
>
> <0001-TESTSUITE-MSP430-Tweak-dg-directives-for-msp430-elf.patch>
For pr41779.c, you
Ping.
I'd like to commit this. The discussion seems to have ended up with the
conclusion that this is a reasonable approach.
paul
> On Nov 1, 2018, at 3:13 PM, Paul Koning wrote:
>
> A number of test cases contain declarations like:
> void *memcpy();
> which cu
This patch corrects a large number of test suite failures. I'm now down to
about 1100 failures out of over 60k total, from at least 4000 before.
Committed.
paul
ChangeLog:
2018-11-08 Paul Koning
* config/pdp11/constraints.md: Add "Z" series cons
> On Nov 4, 2018, at 2:33 PM, Jeff Law wrote:
>
> On 11/1/18 1:30 PM, Paul Koning wrote:
>> A number of test cases fail on pdp11 because they use the "inf" float value
>> which does not exist on that target (nor on VAX). Rainer Orth and Joseph
>> M
> On Nov 5, 2018, at 1:48 PM, Michael Matz wrote:
>
> Hi,
>
> On Mon, 5 Nov 2018, Jeff Law wrote:
>
Don't we have a flag specific to honoring nans? Would that be better
to use than flag_unsafe_math_optimizations? As Uli mentioned,
there's
>>>
>>> That's only relevant for
> On Nov 5, 2018, at 11:45 AM, Jeff Law wrote:
>
>>> ...
>>
>> I can do that, but I'm wondering if some systems have different prototypes
>> than the C standard calls for so I'd end up breaking those.I wouldn't worry
>> about those. I think the bigger question (thanks
> Martin) is whether
> On Nov 3, 2018, at 10:12 PM, Jeff Law wrote:
>
> On 11/1/18 1:13 PM, Paul Koning wrote:
>> A number of test cases contain declarations like:
>> void *memcpy();
>> which currently are silently accepted on most platforms but not on all;
>> pdp11 (and
> On Nov 2, 2018, at 3:19 PM, Rainer Orth wrote:
>
> Hi Paul,
>
>> This patch fixes a number of test case failures on pdp11. Some are too
>> large for the address space, some have dependencies on the float format that
>> don't match the DEC format, some add pdp11 to the targets that expect
> On Nov 1, 2018, at 4:52 PM, Joseph Myers wrote:
>
> On Thu, 1 Nov 2018, Paul Koning wrote:
>
>> +@item inf
>> +Target supports floating point infinite (@code{inf}).
>> @end table
>
> Do you mean supports infinity for type double? (That's what th
ched patch implements this. Ok for trunk?
paul
ChangeLog:
2018-11-01 Paul Koning
* doc/sourcebuild.texi (target attributes): Document new "inf"
effective target keyword.
Index: doc/sourcebuild.texi
===
e the test cases where these
occur are not looking for the message but are testing some other issue, so the
message is not relevant. The attached patch adds dg-prune-output directives to
do so.
Ok for trunk?
paul
ChangeLog:
2018-11-01 Paul Koning
* gcc.dg/Walloca-16
18-11-01 Paul Koning
* gcc.c-torture/execute/20010904-1.c: Align 2 if pdp11.
* gcc.c-torture/execute/20010904-2.c: Ditto.
* c-c++-common/builtin-arith-overflow-2.c: Skip if pdp11.
* gcc.dg/Walloc-size-larger-than-4.c: Ditto.
* gcc.dg/Walloc-size-larger-tha
This fixes some test suite failures due to a missing arithmetic support routine.
Committed.
paul
ChangeLog:
2018-11-01 Paul Koning
* config/pdp11/t-pdp11 (LIB2ADD): Add divmod.c.
(HOST_LIBGCC2_CFLAGS): Change to optimize for size.
Index: config/pdp11/t-pdp11
1 - 100 of 167 matches
Mail list logo
