> 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 uns
> 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 a
> 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.
>>
>> B
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 sho
> 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 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 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:
/home/s
> 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 ot
> 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 reloads,
> 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 s
> 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, J
> 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 substitutions
> 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.
The
> 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 implement
> 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
>> numbers
> 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
> 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 makes
> 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 a
> 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 sor
> 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 fr
> 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 thos
> 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 object
> 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 defin
> 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 n
> 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 at
> 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 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 tha
> 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 could
> 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 the
> 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 feedba
> 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 html"
> 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 info
> 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 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)
>
> https://www.bountysource.com/issues/84630749-avr-convert-the-backen
> 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
>> Bie
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 pessimizati
> 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 embe
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 we
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,
Marti
> 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 spe
> 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 aff
> 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 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 contribu
> 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 cod
> 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 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 --disable-shared
> 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 si
47 matches
Mail list logo
