> 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
> 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
> 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
> 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
> 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
> 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
> 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
> ||
> 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
> ||
> 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
>>> -fno-split-wide-types.
>>> In fact, if all the regression
> 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
> 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 Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches
wrote:
...
> 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
> 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
> 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 your
>>> constraints do not? (I don't
> 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 (general_operand),
>>> but this needs more
> 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 list about what I saw,
>> but
> 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
> 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
>>> would be required for performance
> 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
>>> with a realistic environment
> 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 clean setup.
>> And it hasn't been posted, I
> 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
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
41 matches
Mail list logo
