> On Oct 14, 2022, at 5:15 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/14/22 11:36, Koning, Paul wrote:
>>
>>> On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
>>>
>>> On 10/14/22 10:37, Koning, Paul wrote:
> ...
> But that approach falls down with reload/lra doing
> On Oct 14, 2022, at 4:12 PM, Segher Boessenkool
> wrote:
>
> On Fri, Oct 14, 2022 at 07:58:39PM +, Koning, Paul wrote:
>>> On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
>>> wrote:
>>> On 10/14/22 11:35, Segher Boessenkool wrote:
On Fri, Oct 14, 2022 at 11:07:43AM -0600,
> On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/14/22 11:35, Segher Boessenkool wrote:
>> On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
LRA only ever generates insns that pass recog. The backend allows this
define_insn, requiring it to be
> On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
>
> On 10/14/22 10:37, Koning, Paul wrote:
>>
>>> ...
>>> But that approach falls down with reload/lra doing substitutions without
>>> validating the result. I guess it might be possible to cobble together
>>> something with secondary
> On Oct 14, 2022, at 12:18 PM, Segher Boessenkool
> wrote:
>
> On Fri, Oct 14, 2022 at 12:36:47AM +, Koning, Paul wrote:
>> I guess I'll have to look harder to see if it's possible to make LRA handle
>> CISC addressing modes like memory indirect, autoincrement, autodecrement,
>> and
> On Oct 14, 2022, at 10:38 AM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/14/22 06:37, Koning, Paul wrote:
>>
>>> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
>>> wrote:
>>>
>>>
>>> On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/13/22 17:56, Segher Boessenkool wrote:
>>
>> h8300 fails during GCC build:
>> /home/segher/src/gcc/libgcc/unwind.inc: In function
>> '_Unwind_SjLj_RaiseException':
>> /home/segher/src/gcc/libgcc/unwind.inc:141:1:
> On Oct 13, 2022, at 7:56 PM, Segher Boessenkool
> wrote:
>
> This small patch changes everything that checks targetm.lra_p behave as
> if it returned true.
>
> It has no effect on any primary or secondary target. It also is fine
> for nds32 and for nios2, and it works fine for microblaze
> On Sep 27, 2022, at 8:51 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote:
>> [Changes from V1:
>> - Added a test.]
>>
>> It is common for C BPF programs to use variables that are implicitly
>> set by the BPF loader and run-time. It is
> On Sep 6, 2022, at 8:06 AM, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
>> Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
>> range for the domain is [-MIN, +MAX] for the min and max representable
>>
> On Aug 30, 2022, at 9:22 AM, Jason Merrill via Gcc-patches
> wrote:
>
> On 7/13/22 15:29, Nathan Sidwell wrote:
>> Inspired by a user question. Jason, thoughts?
>> Since C++ is such a moving target, Microsoft have /std:c++latest
>> (AFAICT clang does not), to select the currently
> On Aug 29, 2022, at 1:07 PM, Jeff Law via Gcc-patches
> wrote:
>
> ...
> I guess we could do specialization based on the input range. So rather than
> calling "sin" we could call a special one that didn't have the reduction step
> when we know the input value is in a sensible range.
> On Aug 4, 2022, at 9:17 AM, Chung-Lin Tang wrote:
>
> On 2022/6/28 10:06 PM, Jakub Jelinek wrote:
>> On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
>>> with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
>>>
>>> (1) chunk_size <= -1: wraps into large
On May 25, 2022, at 10:39 AM, Roger Sayle
mailto:ro...@nextmovesoftware.com>> wrote:
On May 25, 2022, at 7:34 AM, Richard Biener via Gcc-patches mailto:patc...@gcc.gnu.org>> wrote:
On Tue, May 24, 2022 at 3:55 PM Roger Sayle
mailto:ro...@nextmovesoftware.com>> wrote:
"For every
> On May 25, 2022, at 7:34 AM, Richard Biener via Gcc-patches
> wrote:
>
> On Tue, May 24, 2022 at 3:55 PM Roger Sayle
> wrote:
>>
>>
>> "For every pessimization, there's an equal and opposite optimization".
>>
>> In the review of my original patch for PR middle-end/98865, Richard
>>
> On Apr 28, 2022, at 8:37 AM, Jonathan Wakely via Gcc-patches
> wrote:
>
> I intend to commit this patch soon. This isn't changing the policy, just
> adjusting the docs to match the current policy.
>
> I'm open to suggestions for better ways to phrase the second sentence,
> clarifying that
I'm not sure if it is valid to assume that a linker script "usually" specifies
a fixed memory location.
paul
> On Apr 4, 2022, at 11:06 AM, Carlos Bilbao via Gcc-patches
> wrote:
>
> Projects that rely on a linker script usually specify a memory location
> where the executable
> On Mar 10, 2022, at 9:27 AM, Jonathan Wakely via Gcc-patches
> wrote:
>
> On Thu, 10 Mar 2022 at 12:16, Jonathan Wakely wrote:
>>
>> On Thu, 10 Mar 2022 at 11:53, Jonathan Wakely via Libstdc++
>> wrote:
>>>
>>> Tested x86_64-linux, and basic soundness check on vax-dec-netbsdelf.
>>
>>
> On Jan 12, 2022, at 1:13 PM, Hans-Peter Nilsson via Gcc-patches
> wrote:
>
>> ...
> I recall comments about code quality regressions. Are there
> actual numbers? (Preferably from around the transition
> time, because I bet targets still supporting "-mlra" have
> regressed on the reload
> On Nov 16, 2021, at 4:19 PM, Marek Polacek via Gcc-patches
> wrote:
>
> On Tue, Nov 16, 2021 at 01:09:15PM -0800, Mike Stump via Gcc-patches wrote:
>> On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches
>> wrote:
>>>
>>> Nitpicking time. It's spelled "ones' complement" rather
> On Nov 16, 2021, at 2:03 AM, Aldy Hernandez via Gcc-patches
> wrote:
>
> On Tue, Nov 16, 2021, 03:20 Marek Polacek via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> On Tue, Nov 16, 2021 at 02:01:47AM +, Koning, Paul via Gcc-patches
>> wrote:
> On Nov 15, 2021, at 8:48 PM, Marek Polacek via Gcc-patches
> wrote:
>
> Nitpicking time. It's spelled "ones' complement" rather than "one's
> complement".
Is that so? I see Wikipedia claims it is, but there are no sources for that
claim. (There is an assertion that it is "discussed
> On Sep 28, 2021, at 2:14 AM, Richard Biener via Gcc-patches
> wrote:
>
> On Tue, Sep 21, 2021 at 4:26 PM Richard Biener via Gcc-patches
> wrote:
>>
>> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
>> is not specified by the target and errors out if DWARF DWARF is
> On Sep 16, 2021, at 11:05 AM, Jeff Law wrote:
>
>
> On 9/16/2021 1:41 AM, Richard Biener wrote:
>> ...
>> That said - yes, I'd consider a.out purely legacy and not fit
>> for the future. But it never came up on the radar of standing
>> in the way of modernizing GCC in any area.
> I'd
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
>
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
As I'm looking at questions about old debug formats, it brings up the question
of old
> On Sep 15, 2021, at 11:55 AM, John David Anglin wrote:
>
> On 2021-09-15 10:06 a.m., Richard Biener wrote:
>>> Is there a simple way to enable -gstabs in build?
>> Currently not. If we're retaining more than pdp11 with a non-DWARF
>> config I'm considering to allow STABS by default for
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
>
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
>
> It also makes us warn when STABS is enabled and removes the corresponding
> diagnostic
> On Sep 1, 2021, at 3:35 PM, Iain Sandoe wrote:
>
>
> [EXTERNAL EMAIL]
>
> Hi Paul,
>
>> ...
>> If so, then I would think that ignoring it for this patch as well is
>> reasonable. If in a given target a pointer that C thinks of as NULL is in
>> fact a valid object pointer, then all
> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches
> wrote:
>
>
>
> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>
>>> On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
>>> wrote:
>>>
>>> Generally OK. There's some C++ front-end bits that Jason ought to take a
>>> quick looksie
> On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
> wrote:
>
> Generally OK. There's some C++ front-end bits that Jason ought to take a
> quick looksie at. Second, how does this interact with targets that allow
> objects at address 0? We have a few targets like that and that
> On Jul 12, 2021, at 12:36 PM, David Malcolm via Gcc-patches
> wrote:
>
> On Mon, 2021-07-12 at 15:25 +0200, Martin Liška wrote:
>> ...
>
> I think the output formats we need to support are:
> - HTML
> - PDF
> - man page (hardly "modern", but still used)
Also info format (for the Emacs
> On Jun 28, 2021, at 11:33 AM, Jan-Benedict Glaw wrote:
>
> Hi Paul!
>
> I'd like to install this patch to let the pdp11-aout configuration
> build again with eg.
>
> ../gcc/configure --target=pdp11-aout --enable-werror-always \
> --enable-languages=all --disable-gcov
> On Jun 11, 2021, at 11:50 AM, Joseph Myers wrote:
>
> ...
>
> "make" at top level should build all the info manuals and man pages, as at
> present (if a suitable Sphinx version is installed), and "make install"
> should install them, in the same directories as at present.
>
> "make
> On Jun 4, 2021, at 3:55 AM, Tobias Burnus wrote:
>
> Hello,
>
> On 13.05.21 13:45, Martin Liška wrote:
>> On 4/1/21 3:30 PM, Martin Liška wrote:
>>> That said, I'm asking the GCC community for a green light before I
>>> invest
>>> more time on it?
>> So far, I've received just a small
> On Jun 2, 2021, at 11:03 AM, Jason Merrill via Gcc-patches
> wrote:
>
> On 6/1/21 3:22 PM, Richard Biener via Gcc wrote:
>> On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc
>> wrote:
...
>>>
>>> The MAINTAINERS file doesn't seem to have such a "DCO list"
>>> yet; does
> On May 21, 2021, at 1:46 PM, Cassio Neri via Gcc-patches
> wrote:
>
> Simple change to std::chrono::year::is_leap. If a year is multiple of 100,
> then it's divisible by 400 if and only if it's divisible by 16. The latter
> allows for better code generation.
I wonder if the optimizer
> On May 9, 2021, at 11:33 AM, abebeos via Gcc-patches
> wrote:
>
> Thank you for your quick response.
>
> ...
> The Issue:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
>
> The Bounty (a bit higher than $7K)
>
>
> On May 5, 2021, at 8:45 AM, Segher Boessenkool
> wrote:
>
> Hi~
>
> On Tue, May 04, 2021 at 04:08:22PM +0100, Richard Earnshaw wrote:
>> On 03/05/2021 23:55, Segher Boessenkool wrote:
>>> CC_STATUS_INIT is suggested in final.c to also be useful for ports that
>>> are not CC0, and at least
> On Apr 21, 2021, at 5:32 PM, Maciej W. Rozycki wrote:
>
> ...
> OTOH switching to LRA regresses code generation seriously, by making the
> indexed and indirect VAX address modes severely underutilised, so while
> with these changes in place the backend can be switched to LRA with just a
> On Apr 19, 2021, at 7:26 PM, Martin Sebor via Gcc-patches
> wrote:
>
> On 4/19/21 3:13 PM, Koning, Paul wrote:
>>> On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches
>>> wrote:
>>>
>>> ...
>>> I was actually thinking of just #including each foo-tests.c file
>>> to bring in the
> On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches
> wrote:
>
> On 4/19/21 2:03 PM, David Malcolm wrote:
>> On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:
>>> The selftests at the end of many source files are only rarely read
>>> or modified, but they
> On Apr 16, 2021, at 6:13 AM, Ville Voutilainen via Gcc-patches
> wrote:
>
> The actual suggestion is at the end; skip straight to it if you wish.
Could you shift this discussion to the gcc list where it fits better?
gcc-patches is for discussion patches to the code.
paul
> On Apr 2, 2021, at 11:40 AM, Martin Sebor via Gcc-patches
> wrote:
>
> ...
> I'm not excited about changing tools. I like that Texinfo is a GNU
> project; AFACT, Sphinx is not.
Why is that important? It's an open source tool, and if it better in
interesting ways I don't see why its
> On Apr 1, 2021, at 9:30 AM, Martin Liška wrote:
>
> Hey.
>
> I've returned to the David's project and I'm willing to finish his transition
> effort.
> I believe using Sphinx documentation can rapidly improve readability, both
> HTML and PDF version,
> of various GCC manuals ([1]). I've
On Apr 1, 2021, at 9:51 AM, Martin Liška
mailto:mli...@suse.cz>> wrote:
[EXTERNAL EMAIL]
On 4/1/21 3:42 PM, Koning, Paul wrote:
Can it provide EPUB or MOBI output?
Yes, [1] lists 'epub' as one of the possible "buildername" options.
Btw. what Python project do you speak about?
Cheers,
Can it provide EPUB or MOBI output? Some of the documentation systems used in
various open source products have that capability, and that is very nice to
have. I have seen this from the one used by the Python project, for example.
Converting other formats to EPUB sometimes works tolerably
> On Mar 24, 2021, at 4:59 AM, Jonathan Wakely via Gcc-patches
> wrote:
>
> On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
>>
>> On target systems that don't support any random_device, not even the
>> default one,
>
> It should be impossible to have no random_device.
Not true; deeply
47 matches
Mail list logo
