> On Jun 1, 2021, at 11:08 AM, Jason Merrill via Gcc wrote:
>
> On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote:
>
>> | From: Mark Wielaard
>>
>> | This seems a pretty bad policy to be honest.
>> | Why was there no public discussion on this?
>>
>> Agreed. I also agree with the
> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc wrote:
>
> The copyright author will be listed as "Free Software Foundation,
> Inc." and/or "The GNU Toolchain Authors", as appropriate.
What does that mean? FSF is a well defined organization. "The GNU Toolchain
Authors" sounds like
> 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
> On Apr 20, 2021, at 9:22 AM, David Starner via Gcc wrote:
>
> Giacomo Tesio wrote:
>> ...
>> Please, do not create a hostile environment for indipendent contributors.
>
> What do you mean by independent? If you're independently wealthy and
> don't need to work, you can avoid this. If
> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc wrote:
>
>> ...
>
> I was under the (likely incorrect, please enlighten me) impression
> that the meteoric rise of LLVM had more to do with the license
> allowing corporate contributors to ship derived works in binary form
> without sharing
> On Apr 15, 2021, at 7:44 PM, Frosku wrote:
>
> On Fri Apr 16, 2021 at 12:36 AM BST, Christopher Dimech wrote:
>>
>> The commercial use of free software is our hope, not our fear. When
>> people
>> at IBM began to come to free software, wanting to recommend it and use
>> it,
>> and maybe
> On Apr 15, 2021, at 11:17 AM, Iain Sandoe wrote:
>
> ...
> responding in general to this part of the thread.
>
> * The GCC environment is not hostile, and has not been for the 15 or so
> years I’ve been part of the community.
Glad to see you feel that way; my view matches yours.
> * We
> On Apr 14, 2021, at 5:38 PM, Ian Lance Taylor wrote:
>
> On Wed, Apr 14, 2021 at 1:49 PM Paul Koning wrote:
>>
>>> ...
>>
>> This is why I asked the question "who decides?" Given a disagreement in
>> which the proposed r
> On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc wrote:
>
> On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc wrote:
>>
>> once or twice when physical violence with threatened, but that's about
>> it (aside from spammers). I don't think we want to get too deep into
>> moderation and
> On Apr 14, 2021, at 2:19 PM, Nathan Sidwell wrote:
>
> On 4/14/21 12:52 PM, Martin Jambor wrote:
>> Hi Nathan,
>> On Wed, Apr 14 2021, Nathan Sidwell wrote:
>>> Do we have a policy about removing list subscribers that send abusive or
>>> other toxic emails? do we have a code of conduct?
> On Apr 9, 2021, at 2:27 AM, Alfred M. Szmidt via Gcc wrote:
>
> These discussions are slightly off topic for gcc@, I'd suggest they
> are moved to gnu-misc-discuss@ or some other more suitable list.
More than "slightly", in my view. I'm close to putting this thread into my
"send straight
I may have lost it in the enormous flood of text, but I want to ask these
general questions.
1. Is there a published code of conduct for GCC community members, possibly
different ones depending on which level of the organization you're in?
2. Is there a formal process for receiving claims of
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
> 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
> 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
> 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
> 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
> 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
> 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 testing
&g
> 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 particularly
> 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
> 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
> 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.
>> *
> 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
> 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
> On Jun 9, 2020, at 10:02 AM, James Dugan
> wrote:
>
> Hello,
> This is a long shot, but is there any archive of the 4.2 source code? I need
> a build for a rhel5.4 server to support a p2v migration. I checked the
> successful builds page and see that this version of rhel was not done for
> On Apr 22, 2020, at 10:11 PM, Senthil Kumar via Gcc wrote:
>
> On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote:
>>
>> On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote:
>>> Hi,
>>>
>>> I'm thinking about attempting to do the CC0 transition for the
>>> AVR port in my spare
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. ;-)
>>
>>
> 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. ;-)
>>
>>
> 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
> 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
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.
> 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
> 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
> On Sep 20, 2019, at 9:18 PM, co...@sdf.org wrote:
>
> On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
>> Introducing the reversed jbb* patterns doesn't seem to help with the
>> original issue. It crashes building libatomic.
>
> My loose understanding of what is going on:
> -
> On Sep 17, 2019, at 8:02 AM, Richard Earnshaw (lists)
> wrote:
>
> ...
> So in summary my proposed timetable would be:
>
> Monday 16th December 2019 - cut off date for picking which git conversion to
> use
>
> Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3.
>
> 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
> On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote:
>
> On Wed, 21 Aug 2019, Paul Koning wrote:
>
>> I agree, but if the new approach generates a warning for code that was
>> written
>> to the old rules, that would be unfortunate.
>
> FWIW I do
> On Aug 21, 2019, at 10:28 AM, Alexander Monakov wrote:
>
> On Tue, 20 Aug 2019, "Markus Fröschle" wrote:
>
>> Thank you (and others) for your answers. Now I'm just as smart as before,
>> however.
>>
>> Is it a supported, documented, 'long term' feature we can rely on or not?
>>
>> If
> On Aug 19, 2019, at 10:08 AM, Alexander Monakov wrote:
>
> On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
>
>> Correct, but note that you can only pack structs and unions, not basic types.
>> there is no way of under-aligning a basic type except by wrapping it in a
>> struct.
>
> I
> On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
>
> All,
>
> this is my first post on these lists, so please bear with me.
>
> My question is about gcc's __attribute__((aligned()). Please consider the
> following code:
>
> #include
>
> typedef uint32_t uuint32_t
> On Aug 9, 2019, at 10:16 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote:
>> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
>>
>> ... However I wonder if this issue is
>> related to the other major outstanding
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
> wrote:
>
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
>>> The old reload (reload[1].c) supports such addressing. As modern
>
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
> wrote:
>
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
>>> The old reload (reload[1].c) supports such addressing. As modern
>
> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
>
>
> On 2019-08-04 3:18 p.m., John Darrington wrote:
>> I'm trying to write a back-end for an architecture (s12z - the ISA you can
>> download from [1]). This arch accepts indirect memory addresses. That is
>> to
>> say, those of
> 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
> On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote:
>
> hi folks,
>
> i was interesting in tackling some problems gcc netbsd/vax has.
> it has some ICEs which are in reload phase. searching around, the answer
> to that is "switch to LRA first". Now, I don't quite know what that is
> yet, but
> 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
>
> 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 23, 2019, at 7:15 PM, Warren D Smith wrote:
>
> x = x^x;
>
> The purpose of the above is to load "x" with zero.
> For very wide types, say 256 bits wide, explicitly loading 0
> is deprecated by Intel since taking too much memory.
> XORing x with itself always yields 0 and is
> 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)
> 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)
> 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
> 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:
>
>
> On Dec 5, 2018, at 11:23 AM, Segher Boessenkool
> wrote:
>
> On Wed, Dec 05, 2018 at 02:19:14AM +0100, Stefan Kanthak wrote:
>> "Paul Koning" wrote:
>>
>>> Yes, that's a rather nasty cut & paste error I made.
>>
&g
> On Dec 4, 2018, at 8:19 PM, Stefan Kanthak wrote:
>
> "Paul Koning" wrote:
>
>> Yes, that's a rather nasty cut & paste error I made.
>
> I suspected that.
> Replacing
>!(den & (1L<<31))
> with
>(signed short) den >
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
Yes, that's a rather nasty cut & paste error I made.
But if the 31 is changed to a 15, is the code correct? I would think so. For
optimization I'd think that an assembly language version would make more sense,
and a few targets do that.
paul
> On Dec 4, 2018, at 5:51 PM, Stefan
> 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
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
in this 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
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
>>>
> 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,
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 current
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 constrain
> 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 (a
> 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
> On Nov 2, 2018, at 9:34 AM, Peter Bergner wrote:
>
> On 11/1/18 10:37 PM, Vladimir Makarov wrote:
>> On 11/01/2018 08:25 PM, Paul Koning wrote:
>>> Is this an LRA bug, or is there something I need to do in the target to
>>> prevent this happening
> On Nov 1, 2018, at 8:49 PM, 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 LRA that works correctly with the old allocator. The issue is that
>> LRA is produc
I'm running the testsuite on the pdp11 target, and I get a failure when using
LRA that works correctly with the old allocator. The issue is that LRA is
producing an insn that is invalid (it violates the constraints stated in the
insn definition).
The insn in the IRA dump looks like this:
> 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 the
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
-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-than-5.c
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
> On Oct 31, 2018, at 5:47 PM, Joseph Myers wrote:
>
> On Wed, 31 Oct 2018, Paul Koning wrote:
>
>> So you mean, add a new keyword (say, "ieee") to dg-effective-target that
>> means "run this test only on ieee targets"?
>
> Note that differ
> On Oct 31, 2018, at 4:11 PM, Rainer Orth
> wrote:
>
> Hi Paul,
>
>> Ok, thanks. So adding a dg-skip-if for my target is indeed correct. Will
>> do so.
>
> please don't: since this is going to be common, please add a
> corresponding effective-target keyword instead, together with
>
> On Oct 31, 2018, at 4:21 PM, Martin Sebor wrote:
>
> On 10/31/2018 12:15 PM, Paul Koning wrote:
>> I noticed a curious inconsistency.
>>
>> Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:
>>
>> void *alloca();
>>
> On Oct 31, 2018, at 3:55 PM, Segher Boessenkool
> wrote:
>
> On Wed, Oct 31, 2018 at 02:20:38PM -0400, Paul Koning wrote:
>> I see some test cases that say dg-add-options ieee. That apparently means:
>> pretend we have IEEE float even when the target does not.
&
I see some test cases that say dg-add-options ieee. That apparently means:
pretend we have IEEE float even when the target does not.
What is the point of doing that? On non-IEEE targets such test cases fail --
at least they do on pdp11. Instead I'd expect a check that skips these tests
if
I noticed a curious inconsistency.
Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:
void *alloca();
void* memcpy ();
Those don't generate warnings in a just built V9.0 gcc for x86. And the
testcase clearly doesn't expect warnings.
But I do get a warning (warning:
> On Oct 30, 2018, at 10:17 AM, Jeff Law wrote:
>
> On 10/30/18 6:55 AM, Paul Koning wrote:
>> Ping. Ok to commit?
>>
>> paul
>>
>>> On Oct 25, 2018, at 2:57 PM, Paul Koning wrote:
>>>
>>> I ran into a failures due to
Ping. Ok to commit?
paul
> On Oct 25, 2018, at 2:57 PM, Paul Koning wrote:
>
> I ran into a failures due to no weak symbol support in my target. This patch
> cures that. Is it right? The test case uses "weakref" so I' not 100% sure
> that checking for
> On Oct 29, 2018, at 4:08 PM, Martin Sebor wrote:
>
> On 10/29/2018 09:19 AM, Paul Koning wrote:
>>
>>
>>> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>>>
>>> On 10/29/2018 07:45 AM, Paul Koning wrote:
>>>> I noticed an i
The description of CONST_WIDE_INT_ELT gave the macro's name as
CONST_WIDE_INT_NUNITS instead.
Committed as obvious.
paul
ChangeLog:
2018-10-29 Paul Koning
* doc/rtl.texi (CONST_WIDE_INT_ELT): Give correct macro name.
Index: doc/rtl.texi
> On Oct 29, 2018, at 11:18 AM, Paul Koning wrote:
>
> ...
>
>> That said, attribute problems aren't handled perfectly consistently
>> in GCC. Some result in errors, others in warnings, and some are
>> silently ignored. I've been tracking the problems
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>>
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>>
I noticed an inconsistency in the handling of the aligned attribute. When
applied to variables, I get an error message if the alignment is too large for
the platform. But when applied to functions, there is no error check. The
same applies to label alignment (from the -falign-labels switch).
I was reviewing some back end code that handles integer values of various
sizes, and got confused reading about CONST_INT and CONST_DOUBLE.
It's pretty clear that CONST_DOUBLE is used for values bigger than
HOST_WIDE_INT. But the description of INTVAL is contradictory. In some
places, it
101 - 200 of 496 matches
Mail list logo
