https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93328
--- Comment #3 from Paco Arjonilla ---
But this gets optimized indeed!
#include
using type = std::uint32_t;
type foo(type v){
type r = ((v << 24) & 0xFF00)
| ((v << 8) & 0x00FF)
| ((v >> 8) & 0xFF00)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94266
Bug ID: 94266
Summary: aarch64：ICE during GIMPLE pass: forwprop
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
--- Comment #6 from Mark Paris ---
(In reply to Steve Kargl from comment #5)
> On Thu, Mar 19, 2020 at 10:24:10PM +, markwayne1969 at gmail dot com
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
> >
> > --- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #8 from Segher Boessenkool ---
SFmode values are stored as DP IEEE float normally. There may be other
cases as well, but this is the obvious one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #9 from dave.anglin at bell dot net ---
This is with Debian ld 2.34 on hppa-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94265
Bug ID: 94265
Summary: wrong warning "duplicated 'if' condition"
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264
Bug ID: 94264
Summary: Array-to-pointer conversion not performed on array
prvalues
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Snapshot gcc-10-20200322 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20200322/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94263
Bug ID: 94263
Summary: build wxpython raspian
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Fine, thanks. Just FYI, I built binutils master to check if the issue
> also exists with the v2
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #7 from rsandifo at gcc dot gnu.org
---
Created attachment 48080
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48080=edit
Proof-of-concept hack to back up the point in comment 4
This hack shows what I mean in comment 4. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #6 from Zdenek Sojka ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> (In reply to Zdenek Sojka from comment #1)
> > I observe the same issue, and it breaks libgcc build for me:
>
> What configure arguments do you use?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
>> > --- Comment #23 from Iain Sandoe ---
>> > unpatched GCC master, gcc-9.x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Martin Liška ---
>> Can you provide some pointers where to look? I'm totally unfamiliar
>> with this code. Maybe it's easier for you to try the Solaris/SPARC
>>
> 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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Zdenek Sojka from comment #1)
> I observe the same issue, and it breaks libgcc build for me:
What configure arguments do you use?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #4 from rsandifo at gcc dot gnu.org
---
The cycling comes from reloading:
(insn 7 6 8 2 (set (reg:SD 122 [ a32 ])
(mem/c:SD (reg/f:DI 120) [1 a32+0 S4 A32]))
"gcc/testsuite/gcc.target/powerpc/pr39902-2.c":15:13 516
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239
Jakub Jelinek changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94262
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136
Iain Buclaw changed:
What|Removed |Added
Target Milestone|9.4 |10.0
--- Comment #4 from Iain Buclaw ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #25 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from Iain Sandoe ---
> > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK
> > >=
> > Xcode
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #5 from Martin Liška ---
Yes, I can confirm it still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94262
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-03-22
Ever confirmed|0
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94262
Bug ID: 94262
Summary: valgrind error in get_pure_location
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Iain Sandoe ---
> unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK >=
> Xcode commandline tools 11.3b.
I've recently tried both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
Hi Winfried,
> [..]
> > Spam bouncing is evil and often hits an innocent person
> [..]
>
> others like me might see it different:
> Spam discarding is evil and often hits an innocent person.
>
> Silently discarding a legal mail because of false spam-detection is
> the worst case
On Sun, 22 Mar 2020, Florian Weimer wrote:
> > You mean as with a failure response given to the SMTP DATA command?
> > This is actually equally evil as the resulting bounce (i.e. a delivery
> > failure notification, or a flood of them, once other MTAs have joined in a
> > response to a mass
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jakub Jelinek ---
> Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542459.html
> Sorry for that.
I've just applied your patch (the primary one
* Maciej W. Rozycki:
> On Sun, 22 Mar 2020, Florian Weimer wrote:
>
>> > Spam bouncing is evil and often hits an innocent person whose address has
>> > been faked by the sender of spam, making the source of bounces not better
>> > than the originator.
>>
>> I expect this to be an SMTP-level
On Sun, 22 Mar 2020, Florian Weimer wrote:
> > Spam bouncing is evil and often hits an innocent person whose address has
> > been faked by the sender of spam, making the source of bounces not better
> > than the originator.
>
> I expect this to be an SMTP-level rejection, not a bounce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
--- Comment #1 from Andrew Pinski ---
Short types are promoted to int when passed to variable arguments functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94256
--- Comment #2 from Sultan Alsawaf ---
(In reply to Andrew Pinski from comment #1)
> That is why it is limited in the first place:
> /* Update number of blocks and the estimate for number of insns
>in the region. Return true if the region
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038
--- Comment #5 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:fbe60463bb80d859d4842f0113a6b24fe9cc9bd4
commit r10-7323-gfbe60463bb80d859d4842f0113a6b24fe9cc9bd4
Author: Iain Buclaw
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #1 from rguenther at suse dot de ---
On March 22, 2020 12:46:45 PM GMT+01:00, "rsandifo at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
>
>Bug ID: 94261
> Summary: [10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #4 from Arseny Solokha ---
(In reply to Jan Hubicka from comment #3)
> The testcase builds for me now
It still ICEs for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
Bug ID: 94261
Summary: [10 Regression] ICE in vect_get_vec_def_for_operand_1
for 3-element condition reduction
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259
--- Comment #1 from Sergei Trofimovich ---
I also noticed a minor infelicity: if you pass just --with-zstd build system
will do a few unexpected things:
- it will not fail of zstd is not present in system but will silently skip zstd
support
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260
Bug ID: 94260
Summary: Specific friend function inside c++20
concept-constrained class template triggers 'not
usable in a constant expression' error
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259
Bug ID: 94259
Summary: --without-zstd seems to have no effect and links
libzstd if available
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
General notes:
* GCC on Darwin depends on the installed “binutils”, typically provided by a
version of “Xcode" or “Xcode command line tools”. Unless noted otherwise, the
bootstrap sequences here make use of the last available xcode command line
tools and SDK for the platform version.
* Apple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
--- Comment #6 from Jakub Jelinek ---
It is not going to be fixed in GCC 9, only in 10, where it should be fixed
already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
Bug ID: 94258
Summary: Warning Correction while using format specifiers %hx
and %ho
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Am 21.03.20 um 21:29 schrieb Frank Ch. Eigler via Gcc:
Hi -
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
--- Comment #5 from Emil Fihlman ---
If a free is behind a flag gcc and the allocation is also behind a flag, gcc
should not complain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873
--- Comment #4 from Emil Fihlman ---
Problem persists with gcc 9.3, though it's no longer dependent on the bitfield.
https://godbolt.org/z/RGu6hu
If a free is behind a flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #2 from Zdenek Sojka ---
(In reply to Zdenek Sojka from comment #1)
> I observe the same issue, and it breaks libgcc build for me:
...
>
> (for reasons unknown to me, git gcc-descr returns "r10-7320" for me for the
> same git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Martin Liška ---
> Ah, ok. Can you please do some basic debugging what's hapenning?
Can you provide some pointers where to look? I'm totally unfamiliar
with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #1
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
* Maciej W. Rozycki:
> On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote:
>
>> > > So, a request: Could the overseers either install more effective
>> > > spam protection for the list as a whole (preferred)
>>
>> Heh, if only it were that easy! Spam filtering was and is distinct
>> from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #4 from Martin Liška ---
Ah, ok. Can you please do some basic debugging what's hapenning?
Btw. is the Solaris using ELF?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
--- Comment #8 from Kewen Lin ---
> It's most likely either SCEV or expand_simple_operations looking throuhg
> the single-arg PHI (which we should avoid for LC PHI nodes)
Thanks Richi, I found the loop-closed PHI form was broken after we
Hello Maciej,
On Sat, Mar 21, 2020 at 09:22:31PM +, Maciej W. Rozycki wrote:
[..]
> Spam bouncing is evil and often hits an innocent person
[..]
others like me might see it different:
Spam discarding is evil and often hits an innocent person.
Silently discarding a legal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94257
Bug ID: 94257
Summary: ICE in inline nested namespace
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
78 matches
Mail list logo
