https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98343
--- Comment #4 from Pekka S ---
And indeed the patch works on x86_64-w64-mingw32, too.
This patch to the Go testsuite driver changes it to handle +build
lines correctly, which is to say, in the same way that they are
handled by the upstream test driver. Update several tests from the
upstream repo to use "gc" and "!gccgo" as appropriate so that tests
continue to pass. This cleans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98368
Bug ID: 98368
Summary: Seg fault on template method missing required return
statement
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely wrote:
>
> On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> >On Wed, 22 Jul 2020, Patrick Palka wrote:
> >
> >> On Mon, 20 Jul 2020, Patrick Palka wrote:
> >>
> >> > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> >> >
> >> > > On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 49791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49791=edit
new diff with improvements
New diff with a better implementation.
Changes in this version from Version 5:
Commit message change:
Information for Changelogs put in proper format. Thanks go to
Jakub Jelinek for enlightening me how to do that and providing
an excellent example.
c-cppbuiltin.c - Fixed various formatting issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98367
--- Comment #1 from Justin Bassett ---
It also ICEs with a segfault even if the `myobject` doesn't do CTAD itself but
has its type explicitly specified: https://godbolt.org/z/Mjfe6c .
Inlining the non-CTAD version does not ICE, though:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98367
Bug ID: 98367
Summary: ICE with CTAD non-type template parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96840
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:79f57d5cb070bb02ea0a34b5f42658d6659b19a8
commit r11-6245-g79f57d5cb070bb02ea0a34b5f42658d6659b19a8
Author: Patrick Palka
Date:
ted LTO compression algorithms: zlib
gcc version 11.0.0 20201217 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98366
--- Comment #1 from Marek Polacek ---
Seems like since that revision we completely elide the memcmp check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98366
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98366
Bug ID: 98366
Summary: [11 Regression] wrong-code with memcmp and -m32
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348
--- Comment #4 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #3)
> Started with r10-5250-g8b905e9b0c09530c0f660563540257f3d181c2ac
> Perhaps peephole2s or something similar to catch that?
A patch(with peephole2) is posted at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365
Bug ID: 98365
Summary: Miss vectoization
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
--- Comment #10 from Nick Desaulniers ---
(In reply to Jakub Jelinek from comment #9)
> I've said in that thread that I don't really like disabling the inlining, if
> we wanted to make sure everything is stack protected, we'd need to disable
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704
--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you, Marek Polacek for finding that revision.
I checked out the master branch and reverted the commit
f1612b8ae8a60f62cf5456b3357a341550534a7e and now everything compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
Bug ID: 98364
Summary: C++20 module binary bloat
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
From: Thomas Rodgers
Cleans up a few things mentioned on IRC.
Adds
libstdc++/ChangeLog:
* doc/doxygen/user.cfg.in: Add new header.
* include/Makefile.am (std_headers): likewise.
* include/Makefile.in: Regenerate.
* include/precompiled/stdc++.h: Add new header.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80588
Ivan Sučić changed:
What|Removed |Added
CC||sucicf1 at outlook dot com
--- Comment #2
Thanks HJ. Sorry for missing this in my testing.
Kyrill
From: H.J. Lu
Sent: 17 December 2020 19:06
To: Richard Sandiford ; Kyrylo Tkachov via
Gcc-patches ; Kyrylo Tkachov
Subject: [PATCH] Update default_estimated_poly_value prototype in targhooks.h
On Thu, Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98363
Bug ID: 98363
Summary: C++ 20 module ICE for fast_io library
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98362
Bug ID: 98362
Summary: bad file data on Windows for C++ 20 module
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Snapshot gcc-8-20201217 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20201217/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98361
Bug ID: 98361
Summary: L1/L2 cache characteristics not recognized with
-mtune=znver2
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #3 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #2)
> However, my report was specifically for the nvptx target compiler. Just
> compile with 'nvptx-gcc -fopenacc -S' the code I posed, and compare
>
build_aggr_conv did not correctly handle string literal member initializers.
Extended can_convert_array to handle this case. The additional checks of
compatibility of character types, and whether string literal will fit, would be
quite complicated, so are deferred until the actual conversion takes
As yesterday, several issues fixed:
* 98315 Rainer confirmed fixed
* 98300 Reported noted progress, first patch committed
* An m68k 'nop' issue fixed
* 98340 Another clang issue, fixed
* 98324 One PIC issue fixed.
* 98316 solaris libs, Rainer posted patch, which LGTM
* 98324 bootstrap with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On 12/17/20 12:24 PM, Patrick Palka wrote:
On Thu, 17 Dec 2020, Patrick Palka wrote:
On Fri, Dec 11, 2020 at 4:55 PM Patrick Palka wrote:
On Fri, 11 Dec 2020, Jason Merrill wrote:
On 12/11/20 10:31 AM, Patrick Palka wrote:
On Thu, 10 Dec 2020, Patrick Palka wrote:
On Thu, 10 Dec 2020,
> > Subject: [PATCH][GCC] arm: Add support for Cortex-A78C
> >
> > This patch adds support for -mcpu=cortex-a78c command line option.
> > For more information about this processor, see [0]:
> >
> > [0] https://developer.arm.com/ip-products/processors/cortex-a/cortex-
> > a78c
> >
> > OK from
Please find a proposed patch for _Sp_counted_base::_M_release to skip the
two atomic instructions that decrement each of the use count and the weak
count when both are 1. I proposed the general idea in an earlier thread (
https://gcc.gnu.org/pipermail/libstdc++/2020-December/051642.html) and got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #2 from Thomas Schwinge ---
Thanks for having a look.
(In reply to Tom de Vries from comment #1)
> Ok, let's first make a runnable test-case:
> ...
> $ cat src/libgomp/testsuite/libgomp.oacc-c/test.c
> [...]
> Indeed we see the
On 12/17/20 12:12 PM, H.J. Lu wrote:
On Thu, Dec 17, 2020 at 11:07 AM Martin Sebor via Gcc-patches
wrote:
The top of trunk fails to build with the error below. I haven't
spent any time debugging it except to look at git log where
the description for r11-6238 mentions the function also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98347
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
I'd used reg_raw_mode[regno] for general registers, even though
the array is only valid for hard registers. This patch uses
regno_reg_rtx instead.
Tested on i686-linux-gnu, committed as obvious.
Richard
gcc/
PR rtl-optimization/98347
* rtl-ssa/access-utils.h (full_register):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98347
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:00bad763dcb903103d62e1ef77c542dacf31fc0a
commit r11-6241-g00bad763dcb903103d62e1ef77c542dacf31fc0a
Author: Richard Sandiford
On 12/17/20 10:04 AM, Jakub Jelinek wrote:
Hi!
Seems the ggc_remove ppc_nx 3 operand member relies on the hash tables to
contain pointers in the first element, which is not the case for
source_location_table* hash table, which has location_t and unsigned as
first two members and pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
--- Comment #4 from cqwrteur ---
(In reply to Jakub Jelinek from comment #2)
> Maybe fixed by r11-6240-g4a7a3110c70da8bad6978a36d9da3836538a0cc3
Fixed confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
On Thu, Dec 17, 2020 at 11:07 AM Martin Sebor via Gcc-patches
wrote:
>
> The top of trunk fails to build with the error below. I haven't
> spent any time debugging it except to look at git log where
> the description for r11-6238 mentions the function also referenced
> in the error message.
From: Thomas Rodgers
Let's see if this one sticks...
Adds
libstdc++/ChangeLog:
* doc/doxygen/user.cfg.in: Add new header.
* include/Makefile.am (std_headers): likewise.
* include/Makefile.in: Regenerate.
* include/precompiled/stdc++.h: Add new header.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
--- Comment #2 from Jakub Jelinek ---
Maybe fixed by r11-6240-g4a7a3110c70da8bad6978a36d9da3836538a0cc3
The top of trunk fails to build with the error below. I haven't
spent any time debugging it except to look at git log where
the description for r11-6238 mentions the function also referenced
in the error message. Could the patch be responsible for this?
On Thu, Dec 17, 2020 at 6:16 AM Richard Sandiford via Gcc-patches
wrote:
>
> Kyrylo Tkachov via Gcc-patches writes:
> > Hi all,
> >
> > While experimenting with some backend costs for Advanced SIMD and SVE I hit
> > many cases where GCC would pick SVE for VLA auto-vectorisation even when the
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
--- Comment #1 from cqwrteur ---
This patch breaks all platforms it looks like. Even linux has this bug now.
Please fix it asap or it will break everything.
-things like cost calculations or profiling frequencies. The default\n\
+things like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98360
Bug ID: 98360
Summary: sizeof in template difference between g++/icc and
clang++
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98359
Bug ID: 98359
Summary: bootstrapping failure on windows
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98357
--- Comment #1 from Jeff Muizelaar ---
Clang compiles this to:
foo(char*, unsigned long, unsigned long, unsigned long):
# @foo(char*, unsigned long, unsigned long, unsigned long)
xor eax, eax
cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
--- Comment #7 from Andrew Macleod ---
PR 98174 has that patch applied btw.
On Linux/x86_64,
c25b504636fec7bf8f181a84af83a52757ba7e89 is the first bad commit
commit c25b504636fec7bf8f181a84af83a52757ba7e89
Author: Andrew MacLeod
Date: Thu Dec 17 09:24:11 2020 -0500
Fix trap in pointer conversion in op1_range.
caused
FAIL: gcc.dg/pr97750.c (test for excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98358
Nathan Sidwell changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot
gnu.org
---
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO
build.
* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
* configure.ac: Include config/gcc-plugin.m4.
AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO
build.
bfd/
* configure: Regenerated.
binutils/
* configure: Regenerated.
gas/
* configure: Regenerated.
gprof/
* configure: Regenerated.
ld/
* configure: Regenerated.
libctf/
Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating
Add the --enable-pgo-build[=lto] configure option. When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:
1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating
It seems users are confused by the lack of standard library header
units.
gcc/
* doc/invoke.texi (C++ Modules): Document lack of std
library header units.
--
Nathan Sidwell
diff --git i/gcc/doc/invoke.texi w/gcc/doc/invoke.texi
index 054b8371593..8766bcdfc18 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #53 from jiawei ---
Hi Jim,
Levy had asked me to help about the test. I was resigned on EEMBC and
waiting acess for more benchmarks. Now I am testing on csibe and
coremax-pro. I think will lineout the result in this
On 12/17/20 1:05 PM, Ian Lance Taylor wrote:
Thanks for looking into this. I've gotten confused now, though.
Which patch fixes the problem on Solaris? Thanks.
Ian
The patch I submitted upstream is all that is needed to fix the
compilation failures on Solaris:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98358
Bug ID: 98358
Summary: new test case g++.dg/template/pr98297.C in r8-10683
fails
Product: gcc
Version: 8.4.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98347
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Bah, stupid thinko: using regno_raw_mode[regno] instead of
GET_MODE (regno_reg_rtx[regno]) for general registers :-(
Testing a fix.
On Mon, Dec 14, 2020 at 05:26:03PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 03, 2020 at 10:57:56PM -0500, Michael Meissner wrote:
> > --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > @@ -1,5 +1,6 @@
> > -/* { dg-do run {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #52 from Jim Wilson ---
I did some simple testing of my patch alone. I modified the
riscv-gnu-toolchain makefile to use -Os to build all libraries, built a
rv32imac/ilp32 toolchain, and looked at library code size. I see a few
On Fri, Dec 11, 2020 at 01:51:44PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Nov 19, 2020 at 07:05:24PM -0500, Michael Meissner wrote:
> > If the glibc is not 2.32 or later, this code just compiles to using abort.
>
> That is the compile-time target glibc. That is often *not* the glibc
On Thu, Dec 17, 2020 at 8:31 AM Nikhil Benesch via Gcc-patches
wrote:
>
> On 12/17/20 7:28 AM, Rainer Orth wrote:
> > I first tried with the new version included, but that broke badly:
> >
> > cc1 -fpreprocessed sysinfo.i -quiet -O -std=gnu99
> > -fdump-go-spec=tmp-gen-sysinfo.go -o sysinfo.s
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
--- Comment #7 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:2d7a40fa60fb8b9870cfd053a37fc67404353ee2
commit r11-6237-g2d7a40fa60fb8b9870cfd053a37fc67404353ee2
Author: Nathan Sidwell
Date:
Clang didn't like sizeot (uintset::value) in a templated context. Not
sure where the problem lies -- ambiguous std, gcc erroneous accept or
clang erroneous reject. Anyway, this avoids that construct.
PR c++/98340
gcc/cp/
* module.c (uintset::hash::add): Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
--- Comment #6 from Nathan Sidwell ---
Now I look carefully, it appears to be trying to compile libiberty.a (the
library) as a source file. Of course that'll barf.
Configured using "CXX='clang -x c++ -std=c++11' CC=clang" (Of course I
This patch enables MVE vshr instructions for auto-vectorization. New
MVE patterns are introduced that take a vector of constants as second
operand, all constants being equal.
The existing mve_vshrq_n_ is kept, as it takes a single
immediate as second operand, and is used by arm_mve.h.
The
This patch enables MVE vshlq instructions for auto-vectorization.
The existing mve_vshlq_n_ is kept, as it takes a single
immediate as second operand, and is used by arm_mve.h.
We move the vashl3 insn from neon.md to an expander in
vec-common.md, and the mve_vshlq_ insn from mve.md to
This patch adds new movmisalign_mve_load and store patterns for
MVE to help vectorization. They are very similar to their Neon
counterparts, but use different iterators and instructions.
Indeed MVE supports less vectors modes than Neon, so we use
the MVE_VLD_ST iterator where Neon uses VQX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98251
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
--- Comment #5 from David Binderman ---
(In reply to Nathan Sidwell from comment #4)
> Created attachment 49789 [details]
> try this
Thanks. That seemed to build ok.
> I tried building with clang, but it barfed about invalid utf8 in libiberty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98355
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
On Thu, 17 Dec 2020, Patrick Palka wrote:
> On Fri, Dec 11, 2020 at 4:55 PM Patrick Palka wrote:
> >
> > On Fri, 11 Dec 2020, Jason Merrill wrote:
> >
> > > On 12/11/20 10:31 AM, Patrick Palka wrote:
> > > > On Thu, 10 Dec 2020, Patrick Palka wrote:
> > > >
> > > > > On Thu, 10 Dec 2020, Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021
--- Comment #8 from Martin Sebor ---
*** Bug 98281 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98357
Bug ID: 98357
Summary: Bounds check not eliminated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
On 10/29/20 8:11 PM, H.J. Lu via Binutils wrote:
> diff --git a/configure.ac b/configure.ac
> index 7c4bdff0fa..eea9a21099 100644
> --- a/configure.ac
> +++ b/configure.ac
> + if test "$enable_pgo_build" = "lto"; then
> +AC_MSG_CHECKING([whether the compiler supports -flto=jobserver])
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98356
Bug ID: 98356
Summary: [9/10/11 Regression] ICE in
cp_parser_dot_deref_incomplete, at cp/parser.c:7899
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
On Fri, Dec 11, 2020 at 4:55 PM Patrick Palka wrote:
>
> On Fri, 11 Dec 2020, Jason Merrill wrote:
>
> > On 12/11/20 10:31 AM, Patrick Palka wrote:
> > > On Thu, 10 Dec 2020, Patrick Palka wrote:
> > >
> > > > On Thu, 10 Dec 2020, Jason Merrill wrote:
> > > >
> > > > > On 12/10/20 11:21 AM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98355
Bug ID: 98355
Summary: [9/10/11 Regression] ICE in has_attribute, at
c-family/c-attribs.c:5628
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
The attached patch implements delinearization of array accesses in the
Fortran front end, something that has been discussed for a long time.
I've been asked to try to get this patch committed on the OG10 branch
since it is blocking some further optimization work with Graphite for
OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98354
Bug ID: 98354
Summary: OOM: cc1plus: out of memory with operator auto
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98353
Bug ID: 98353
Summary: [9/10/11 Regression] ICE in propagate_necessity, at
tree-ssa-dce.c:1053
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
On 10/15/20 5:05 PM, Tom de Vries wrote:
> On 10/2/20 3:21 PM, Tom de Vries wrote:
>> Hi,
>>
>> Consider the test-case libgomp.c/pr81778.c added in this commit, with
>> this core loop (note: CANARY_SIZE set to 0 for simplicity):
>> ...
>> int s = 1;
>> #pragma omp target simd
>> for (int i =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98352
Bug ID: 98352
Summary: [9/10/11 Regression] ICE in implicitly_declare_fn, at
cp/method.c:2914
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #18 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to Martin Liška from comment #16)
> >
> > EVRP knows the proper range:
> > 2->4 (F) x_6(D) : unsigned int [0, 1][4, 4]
>
> EVRP ATM invokes
On Thu, 17 Dec 2020 at 21:04, Andrea Corallo wrote:
>
> Kyrylo Tkachov writes:
>
> >> -Original Message-
> >> From: Andrea Corallo
> >> Sent: 17 December 2020 14:56
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: Kyrylo Tkachov ; Richard Earnshaw
> >> ; nd ; Prathamesh Kulkarni
> >>
> >>
On 12/17/20 7:28 AM, Rainer Orth wrote:
I first tried with the new version included, but that broke badly:
cc1 -fpreprocessed sysinfo.i -quiet -O -std=gnu99
-fdump-go-spec=tmp-gen-sysinfo.go -o sysinfo.s
now SEGVs with either infinite or very deep recursion:
Thread 2 received signal SIGSEGV,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #1 from Tom de Vries ---
Ok, let's first make a runnable test-case:
...
$ cat src/libgomp/testsuite/libgomp.oacc-c/test.c
#include
#define TYPE float
TYPE a = 1;
TYPE b = 2;
int
main (void)
{
printf ("A: %f\n", a);
#pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
--- Comment #4 from Nathan Sidwell ---
Created attachment 49789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49789=edit
try this
I tried building with clang, but it barfed about invalid utf8 in libiberty.
On 17/12/20 14:05 +, Jonathan Wakely wrote:
On 16/12/20 13:38 +, Jonathan Wakely wrote:
This fixes a bug caused by a mismatch between the macros defined by
when GCC is built and the macros defined by when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500
The refactoring in r11-5500 altered the condition for the gthreads-timed
test from #if to #ifdef. For some reason that macro is always defined,
rather than being defined to 1 or undefined like most of our autoconf
macros. That means the test always passes now, even for targets where
the macro is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98335
--- Comment #1 from Michael Colavita ---
A similar problem appears to occur for the following example:
struct Data {
long a;
union {
long u;
struct {
char b;
char pad[3];
};
};
};
Data
1 - 100 of 242 matches
Mail list logo
