On Sun, 22 Mar 2020, Patrick Palka wrote:
> This patch relaxes an assertion in tsubst_default_argument that exposes a
> latent
> bug in how we substitute an array type into a cv-qualified wildcard function
> parameter type. Concretely, the latent bug is that given the function
> template
>
>
On Wed, Mar 18, 2020 at 04:53:59PM -0500, Segher Boessenkool wrote:
> Could you please send a new patch (could be the same patch even) that
> is easier to review for me?
The PLT is volatile. On PowerPC it is a bss style section which the
dynamic loader initialises to point at resolver stubs
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
Thanks,
- Eddy B.
On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote:
> This is the libiberty (mainly for binutils/gdb) counterpart of
> https://github.com/alexcrichton/rustc-demangle/pull/23.
>
> Relevant links
This patch relaxes an assertion in tsubst_default_argument that exposes a latent
bug in how we substitute an array type into a cv-qualified wildcard function
parameter type. Concretely, the latent bug is that given the function template
template void foo(const T t);
one would expect the type
On 3/22/20 2:55 PM, Segher Boessenkool wrote:
> Maybe this stuff would be simpler (and more obviously correct) if it
> was more explicit CC_REGNUM is a fixed register, and the code would use
> it directly everywhere?
Indeed the biggest issue I have in this patch is what CC_MODE to expose from
the
Hi!
On Fri, Mar 20, 2020 at 07:42:29PM -0700, Richard Henderson via Gcc-patches
wrote:
> @@ -2382,7 +2382,7 @@ aarch64_gen_compare_reg_maybe_ze (RTX_CODE code, rtx x,
> rtx y,
> cc_mode = CC_SWPmode;
> cc_reg = gen_rtx_REG (cc_mode, CC_REGNUM);
> emit_set_insn (cc_reg,
In this PR we're emitting -Wnoexcept warnings about potentially-throwing NSDMIs
when computing the noexcept specification of a class's defaulted default
constructor. Alhough these warnings are in some sense valid, this patch takes
the route of suppressing them, because:
1. the warning message
On 3/22/20 12:30 PM, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Mar 20, 2020 at 07:42:25PM -0700, Richard Henderson via Gcc-patches
> wrote:
>> Duplicate all usub_*_carryinC, but use xzr for the output when we
>> only require the flags output. The signed versions use sign_extend
>> instead of
Hi!
On Fri, Mar 20, 2020 at 07:42:25PM -0700, Richard Henderson via Gcc-patches
wrote:
> Duplicate all usub_*_carryinC, but use xzr for the output when we
> only require the flags output. The signed versions use sign_extend
> instead of zero_extend for combine's benefit.
You actually use
> Hi.
>
> Similarly to other ipa_ref field, we must preserve the values
> before create_reference is called. It's due to fact that ipa_ref
> is a pointer to a vector that can be relocated to a different location.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
>
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file,
On Fri, Mar 20, 2020 at 8:41 AM Nathan Sidwell wrote:
> If it could be tested on arm &| riscv, that'd be additional verification.
I did riscv testing, both cross and native, and didn't see any new
problems with the patch.
Jim
Hi Wilco,
On Mon, Mar 09, 2020 at 05:53:41PM +, Wilco Dijkstra wrote:
> Hi,
>
> There is no single PC offset that is correct given CPUs may use different
> offsets.
Isn't it always an offset of 8 in ARM mode and 4 bytes in Thumb mode ?
At least in ARMv7 and in AArch32 state in ARMv8 ?
>
On Sun, 2020-03-22 at 11:31 -0600, Sandra Loosemore wrote:
> The new-ish analyzer test cases sigsetjmp-5.c and sigsetjmp-6.c were
> failing on nios2-elf and probably other newlib targets due to lack
> of
> support for sigsetjmp.
Sorry about the breakage.
> I didn't see a suitable existing
>
Hi.
Similarly to other ipa_ref field, we must preserve the values
before create_reference is called. It's due to fact that ipa_ref
is a pointer to a vector that can be relocated to a different location.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be
Hi Mark,
Please find attached a fix for PR93600.
This builds on the patch originally submitted to the PR by Steve Kargl,
the dreaded "Unclassifiable statement error" is replaced by the correct
error message. It would have been posted earlier had not one of the test
cases failed as a result
Hi Mark,
Please find attached Steve Kargl's fix for PR93814.
The attached patch does not match the ChangeLog; it seems to
be for PR93484.
Regards
Thomas
The new-ish analyzer test cases sigsetjmp-5.c and sigsetjmp-6.c were
failing on nios2-elf and probably other newlib targets due to lack of
support for sigsetjmp. I didn't see a suitable existing
effective-target test for this, so I added one.
OK to commit?
-Sandra
commit
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/gcc/es.po
(This file,
Hi,
This patch is an addition to the last change, which started including
content imported files in the make dependency list. Now phony targets
are also written out if -MP is given.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk.
Regards
Iain.
---
gcc/d/ChangeLog:
Hi
The lambda-vis.C test fails everywhere for targets that use a ‘_’ as
USER_LABEL_PREFIX.
This prepends an optional match for the additional USER_LABEL_PREFIX
to the scan assembler checks.
Tested on x86_64-darwin, and linux,
applied to master as obvious,
thanks
Iain
2020-03-22 Iain
21 matches
Mail list logo
