https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
Richard Biener changed:
What|Removed |Added
Known to fail||9.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95172
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95154
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #11 from rguenther at suse dot de ---
On Mon, 18 May 2020, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
>
> --- Comment #10 from bin cheng ---
> Hi，should I backport this and PR95110 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163
Martin Liška changed:
What|Removed |Added
Known to fail||11.0, 7.5.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95159
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95152
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
nterminated" "unterminated macro" } */
| ^
0xd9b92f crash_signal
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/toplev.c:328
0x18578d3 _cpp_lex_direct
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182
--- Comment #2 from Andrew Pinski ---
Also explictly this part of the documentation makes it clear that Pmode should
be DImode for AARCH64 ILP32:
define this to be the integer mode corresponding to the width of a hardware
pointer
The hardware
Hello, this is the mail server on mailmarketingworldbee.live.
I am sending you this message to inform you on the delivery status of a
message you previously sent. Immediately below you will find a list of
the affected recipients; also attached is a Delivery Status Notification
(DSN) report in
On Sun, May 17, 2020 at 8:23 PM duanbo (C) wrote:
>
> Hi,
>
> This changes the definition of Pmode for aarch64 port.
> Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even
> under ILP32.
> Because of that definition, machine mode of symbol_ref which is supposed to
> be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
This changes the definition of Pmode for aarch64 port.
Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even
under ILP32.
Because of that definition, machine mode of symbol_ref which is supposed to be
SImode becomes DImode under target ILP32.
Definition of Pmode should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182
Bug ID: 95182
Summary: Change the definition of Pmode
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #10 from bin cheng ---
Hi，should I backport this and PR95110 to branches? Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
--- Comment #3 from Marek Polacek ---
struct H {
int a;
};
struct I {
int c;
H b;
};
struct E { I d; };
void foo(E);
template
void fn ()
{
int a = 42;
int = a;
foo({1, {H{k}}});
}
Hello, this is the mail server on mailmarketingworldbee.live.
I am sending you this message to inform you on the delivery status of a
message you previously sent. Immediately below you will find a list of
the affected recipients; also attached is a Delivery Status Notification
(DSN) report in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95179
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
> Hi,
>
> While trying out -fanalyzer on the bzip2 source code I noticed that
> it
> did warn about some unsafe calls in the signal handler, but din't
> warn
> about the exit call:
>
On Sun, 2020-05-17 at 18:39 -0400, David Malcolm via Gcc-patches wrote:
> On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
[...snip...]
> How about something like this (though I even haven't checked if it
> compiles, and am not 100% sure what the wording should be):
>
> bool emit
On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
> Hi,
>
> While trying out -fanalyzer on the bzip2 source code I noticed that
> it
> did warn about some unsafe calls in the signal handler,
Great.
> but din't warn
> about the exit call:
>
Snapshot gcc-11-20200517 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20200517/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Am 15.05.20 um 22:33 schrieb Harald Anlauf:
Here's a new attempt to finally fix this PR and any known fallout.
In order to handle division by zero in declarations, but still accept the
code snippet adapted from 521.wrf_r (from spec2017), I removed the hunk
that was added to fix PR94399, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181
--- Comment #3 from ahmet özhan ---
Comment on attachment 48554
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48554
gcc 10 don't compile but clang compile
>#include
>
>namespace math {
>
> template
> requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181
--- Comment #2 from ahmet özhan ---
Comment on attachment 48554
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48554
gcc 10 don't compile but clang compile
>#include
>
>namespace math {
>
> template
> requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181
--- Comment #1 from ahmet özhan ---
gcc 9.3 compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181
Bug ID: 95181
Summary: internal compiler error: in push_access_scope, at
cp/pt.c:241
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Hi,
While trying out -fanalyzer on the bzip2 source code I noticed that it
did warn about some unsafe calls in the signal handler, but din't warn
about the exit call:
https://sourceware.org/pipermail/bzip2-devel/2020q2/000107.html
It was easy to add exit to the async_signal_unsafe_fns, but since
Ne plus rien recevoir de notre part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95180
Bug ID: 95180
Summary: Failure to reject invalid code with attempted
redefinition of symbol with different linkage
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95179
Bug ID: 95179
Summary: explicit constructor not used for static inline member
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
--- Comment #2 from Marek Polacek ---
It actually started with r5-7-g1c982d13138ee4518db10b6fbe02fa32d09ab51e -- it
was latent for a while.
On 5/17/20 1:43 PM, Maciej W. Rozycki wrote:
> patch service before. It doesn't appear linked to our mailing list either
> and instead you need to go through the hoops of a web interface (and open
> an account first) to submit a change.
From what I remember, it was decided the GNU toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95178
Bug ID: 95178
Summary: error: array subscript has type char
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
On Sat, 16 May 2020, Rob Savoye wrote:
> > Overall perhaps a patch management system might be good having to make
> > chasing patches easier, such as patchwork, and we already use Git, so we
>
> As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
Bug ID: 95177
Summary: error: array subscript has type char
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Hi,
This avoids a (bogus) warning that occurs with some bootstrap
compilers.
tested on x86-64-darwin, x86-64-linux-gnu,
applied to master as obvious,
thanks
Iain
gcc/cp/ChangeLog:
2020-05-17 Iain Sandoe
* coroutines.cc (morph_fn_to_coro): Initialize the
gro variable.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #13 from Tobias Burnus ---
(In reply to Andreas Schwab from comment #12)
> This breaks gfortran.dg/gomp/target1.f90 on riscv.
See comment 10 – or PR95109, which points to comment 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #12 from Andreas Schwab ---
This breaks gfortran.dg/gomp/target1.f90 on riscv.
/daten/src/gcc/gcc/gcc/testsuite/gfortran.dg/gomp/target1.f90:318:0: internal
compiler error: in lookup_decl_in_outer_ctx, at omp-low.c:3967
0xbb9b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95176
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
This patch collapses a couple existing patterns (branch_true, branch_false) into
a single pattern and updates all the combiner/peephole branches to use the same
basic structure. This makes the cc0->CC_REG transition easier in a variety of
ways, particularly with optimizing compare/branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95168
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95166
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95167
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Hi,
This patch backports r11-445 to the gcc-10 release branch.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed.
Regards,
Iain.
---
libphobos/ChangeLog:
PR d/95166
* libdruntime/core/cpuid.d (cpuidX86): Do not use i7 detection on AMD
processors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95168
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:999c80acfdd890b789678c989c3d740969c14d20
commit r10-8150-g999c80acfdd890b789678c989c3d740969c14d20
Author: Iain Buclaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95167
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:999c80acfdd890b789678c989c3d740969c14d20
commit r10-8150-g999c80acfdd890b789678c989c3d740969c14d20
Author: Iain Buclaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95166
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:999c80acfdd890b789678c989c3d740969c14d20
commit r10-8150-g999c80acfdd890b789678c989c3d740969c14d20
Author: Iain Buclaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
--- Comment #10 from H.J. Lu ---
Fixed for GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95176
Bug ID: 95176
Summary: Failure to optimize division followed by
multiplication to modulo followed by subtraction
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
--- Comment #9 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:266f44a91c0c9705d3d18e82d7c5bab32927a18f
commit r11-446-g266f44a91c0c9705d3d18e82d7c5bab32927a18f
Author: H.J. Lu
Date: Sun May 17
Duplicate the cmpstrn pattern for cmpmem. The only difference is that
the length argument of cmpmem is guaranteed to be less than or equal to
lengths of 2 memory areas. Since "repz cmpsb" can be much slower than
memcmp function implemented with vector instruction, see
Hi,
This patch merges the D runtime library with upstream druntime 5cc061a8,
and the D standard library with upstream phobos 64ed4684f.
Fixes included within are:
- core.cpuid has been fixed to not use i7 detection on AMD processors
(fixes PR95166).
- std.net.curl has been fixed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95166
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:e977a5df5bae2bce6e3e95456f5da0dbfdd02934
commit r11-445-ge977a5df5bae2bce6e3e95456f5da0dbfdd02934
Author: Iain Buclaw
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95168
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:e977a5df5bae2bce6e3e95456f5da0dbfdd02934
commit r11-445-ge977a5df5bae2bce6e3e95456f5da0dbfdd02934
Author: Iain Buclaw
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95167
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:e977a5df5bae2bce6e3e95456f5da0dbfdd02934
commit r11-445-ge977a5df5bae2bce6e3e95456f5da0dbfdd02934
Author: Iain Buclaw
Date: Sun
On Sun, May 17, 2020 at 9:07 AM Uros Bizjak wrote:
>
> On Sat, May 16, 2020 at 8:13 PM H.J. Lu wrote:
> >
> > On Fri, May 15, 2020 at 11:21:30AM +0200, Uros Bizjak wrote:
> > > On Wed, May 13, 2020 at 5:58 PM H.J. Lu wrote:
> > >
> > > > > > > The question is, why STV pass creates its funny
On Sun, May 17, 2020 at 6:14 PM Gerald Pfeifer wrote:
>
> On Fri, 8 May 2020, Uros Bizjak wrote:
> >> A user reported that gcc -m32 on x86-64 does not define __ILP32__
> >> and I found the same on i686 (with gcc -x c -dM -E /dev/null).
> :
> >> This patch does the same for all "regular" 32-bit
On Fri, 8 May 2020, Uros Bizjak wrote:
>> A user reported that gcc -m32 on x86-64 does not define __ILP32__
>> and I found the same on i686 (with gcc -x c -dM -E /dev/null).
:
>> This patch does the same for all "regular" 32-bit x86 targets.
>> Tested on i386-unknown-freebsd11.3 so far.
> OK.
On Sat, May 16, 2020 at 8:13 PM H.J. Lu wrote:
>
> On Fri, May 15, 2020 at 11:21:30AM +0200, Uros Bizjak wrote:
> > On Wed, May 13, 2020 at 5:58 PM H.J. Lu wrote:
> >
> > > > > > The question is, why STV pass creates its funny sequence? The
> > > > > > original
> > > > > > sequence should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95175
Bug ID: 95175
Summary: constexpr and alias template
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95075
--- Comment #1 from Iain Buclaw ---
Also present in upstream implementation, I'll ask the author of the change
about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
This patch is the gcc-9 backport of mainline r11-154 / gcc-10 r10-8149.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
the gcc-9 branch.
Regards
Iain
---
gcc/d/ChangeLog:
PR d/94970
* d-codegen.cc (force_target_expr): Move create_temporary_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:80cefde6212c3de603dda46d05123a750b378ff2
commit r9-8601-g80cefde6212c3de603dda46d05123a750b378ff2
Author: Iain Buclaw
Date:
Hi,
This patch has been backported from mainline r11-154.
The ICE is also present on the gcc-9 branch, and this applies cleanly
there as well, so will send out another email for that backport.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
the gcc-10 branch.
Regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:79f2ae6ecffbef5c1f78459f6980e0f91121022d
commit r10-8149-g79f2ae6ecffbef5c1f78459f6980e0f91121022d
Author: Iain Buclaw
On Thu, Nov 3, 2016 at 12:51 AM Uros Bizjak wrote:
>
> Hello!
>
> > This patch adds a test to the cmpstrnsi pattern in i386.md so that it
> > will bail out (FAIL) if neither of the strings is a constant string. It
> > can only work as a proper strncmp if the length is not longer than both
> > of
Having noticed this in some other case I went through all of our
pages and found this this instance in the GCC 10 release notes where
.
commit f1d2be6c9fcc52d676266e7ede123953d150aaf3
Author: Jonathan Wakely
Date: Thu May 7 11:24:04 2020 +0100
Document C++17 ABI changes in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95174
Bug ID: 95174
Summary: [D] Incorrect compiled functions involving const fixed
size arrays
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
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, 'gcc-10.1.0.sv.po', has
Whoops, I seem to have a discrepancy in my local tree and upstream.
I've reverted this patch.
Aldy
On 5/17/20 1:50 PM, Aldy Hernandez wrote:
There's no reason to export operand_less_p from tree-vrp when its only
use is in vr-values.c. Function moved.
Committed as obvious.
Aldy
There's no reason to export operand_less_p from tree-vrp when its only
use is in vr-values.c. Function moved.
Committed as obvious.
Aldy
commit 8bfc81876f9325891a52d036a9c454d0c81b3033
Author: Aldy Hernandez
Date: Fri May 8 13:36:32 2020 +0200
Move operand_less_p to vr-values.c.
diff
Missed this on the previous patch. The method live_on_edge() no
longer needs to be inside the vrp_insert class. I've removed the
prototype.
Committed to mainline.
On Sun, May 17, 2020 at 1:35 PM Aldy Hernandez wrote:
>
> Funny, I had queued up more or less the same changes on my tree, but
>
Funny, I had queued up more or less the same changes on my tree, but
Giuliano beat me to it.
I am committing the attached patch that has been approved by Jeff.
I moved a couple more functions into the vrp_insert class, as well as
abstract out the liveness bitmap into its own class. I also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173
Bug ID: 95173
Summary: [D] ICE on some architecture targets when trying to
use unknown attribute
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Howdy.
There's really no reason why the array bounds code should live in
tree-vrp, when all it really needs is a get_value_range() call back.
Particularly painful is that it partially lives inside the vrp_prop class.
This patch moves the array bounds code into its own class, while taking
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #13 from Bernd Edlinger ---
Hi Andrew,
You are right about the instruction re-ordering, that is done in
a compiler pass, which simply re-orders RTL instruction lists.
But I think when the code motion happens, we just
have no easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #12 from Andrew Burgess ---
> But what I learned from writing the patch is that gcc cannot
> easily tell if a range will be empty or not. That is because
> the assembler does emit the line info and the views,
> and the assembler
84 matches
Mail list logo
