https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878
--- Comment #1 from Sebastian Huber ---
It may have something to do with TARGET_RISCV_DEFAULT_ABI == ilp32d. The
gcc/tm.h in the build tree contains this:
gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ARCH
gcc/tm.h:# define TARGET_RISCV_DEFAULT_ARCH
On Thu, Jan 28, 2021 at 11:31 AM Bin.Cheng wrote:
>
> On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches
> > wrote:
> > >
> > > Hi,
> > > As described in commit message, we need to avoid computing niters info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
--- Comment #1 from Richard Biener ---
With perf you'll have to use -gdwarf-4 anyway since otherwise it cannot parse
debug in my experience. Quite some tools need to be brought up-to-date with
DWARF5 yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Richard Biener changed:
What|Removed |Added
Target Milestone|11.0|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878
Bug ID: 98878
Summary: Incorrect multilib list for riscv*-rtems
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98868
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Andrew Pinski changed:
What|Removed |Added
Depends on||91753
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
--- Comment #1 from Andrew Pinski ---
I am 90% sure this is just a register allocation issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
--- Comment #10 from rguenther at suse dot de ---
On Thu, 28 Jan 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
--- Comment #5 from rguenther at suse dot de ---
On Thu, 28 Jan 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
>
> --- Comment #4 from Jakub Jelinek ---
> Alternatively, couldn't we support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Bug ID: 98877
Summary: [AArch64] Inefficient code generated for tbl NEON
intrinsics
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98876
Bug ID: 98876
Summary: demangler-warning: unable to demangle
Product: gcc
Version: 7.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98355
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96137
--- Comment #6 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f8f5388c9e94d4324c31d82b335fa138518e3171
commit r11-6967-gf8f5388c9e94d4324c31d82b335fa138518e3171
Author: Marek Polacek
Date:
On 1/28/21 10:57 PM, Marek Polacek wrote:
My r11-86 adjusted cp_parser_class_name to do
- scope = parser->scope;
+ scope = parser->scope ? parser->scope : parser->context->object_type;
if (scope == error_mark_node)
return error_mark_node;
but that caused endless looping in
My r11-86 adjusted cp_parser_class_name to do
- scope = parser->scope;
+ scope = parser->scope ? parser->scope : parser->context->object_type;
if (scope == error_mark_node)
return error_mark_node;
but that caused endless looping in cp_parser_type_specifier_seq (the
while (true) loop)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Liu Hao changed:
What|Removed |Added
CC|lh_mouse at 126 dot com|
--- Comment #20 from Liu Hao ---
0.
Hi,
This patch tries to optimize PowerPC 64 bit constant generation when
the constant can be transformed from a 32 bit or 16 bit constant by
rotating, shifting and mask AND.
The attachments are the patch diff file and change log file.
Bootstrapped and tested on powerpc64le with no
I rebusmitted the patch after verifying it still builds and works with the
current branch as:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564486.html
| Subject: [PATCH] Add conversions between _Float128 and Decimal.
| Message-ID: <20210129024208.ga25...@ibm-toto.the-meissners.org>
--
[PATCH] Add conversions between _Float128 and Decimal.
This patch implements conversions between _Float128 and the 3 Decimal
floating types. It does by extendending the dfp-bit conversions to add a
new binary floating point type (KF), and doing the conversions in the same
mannor as the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Bug ID: 98875
Summary: DWARF5 as default causes perf probe to hang
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a
failure in the test suite for the IBM Advance Toolchain. The test in
question uses "perf probe" to set a tracepoint at "main" in a newly built
(with GCC 11) binary of "/bin/ld". With the patch applied, the command
enters an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065
Bug 98065 depends on bug 98799, which changed state.
Bug 98799 Summary: [11 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Martin Sebor changed:
What|Removed |Added
Component|c |middle-end
Last reconfirmed|
On 1/28/21 2:27 PM, David Malcolm via Gcc wrote:
On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote:
On 28/01/2021 21:23, David Malcolm via Gcc wrote:
I wrote a blog post covering what I've been working on in the
analyzer
in this release:
The go1 compiler always turns on debugging, to support Go stack traces
and functions like runtime.Callers. With the recent switch to turn on
DWARF 5 by default, this caused failures with some versions of gas,
such as 2.35.1, because the assembly code would assume DWARF 5 but the
driver would not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930
Bug 81930 depends on bug 98841, which changed state.
Bug 98841 Summary: wrong ‘operator=’ should return a reference to ‘*this’
[-Weffc++]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98841
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:850a8ec54c4310d779004299bf9a0dec52324e9e
commit r11-6964-g850a8ec54c4310d779004299bf9a0dec52324e9e
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98874
Bug ID: 98874
Summary: PowerPC test
gcc.target/powerpc/ppc-fortran/pr80108-1.f90 uses
wrong dg-options
Product: gcc
Version: 11.0
Status: UNCONFIRMED
The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causing some confusion. When the warning is issued for
an access to an in-bounds member via a pointer to a struct that's
larger than the pointed-to object,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
--- Comment #2 from Peter Bergner ---
*** Bug 98873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Peter Bergner changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Michael Meissner changed:
What|Removed |Added
Target||powerpc64le-gnu-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Bug ID: 98873
Summary: PowerPC test
gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now
fails
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Bug ID: 98872
Summary: ICE leads to SEGV on MMA test case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On Thu, Jan 28, 2021 at 11:38:34PM +0100, Eric Botcazou wrote:
> > Aware. I don't have access to, e.g., a sparc box. But the test I've added
> > uses -mstrict-align where possible to check that the issue is resolved.
>
> There are relatively fast SPARC64/Linux (gcc202) and SPARC/Solaris
> Aware. I don't have access to, e.g., a sparc box. But the test I've added
> uses -mstrict-align where possible to check that the issue is resolved.
There are relatively fast SPARC64/Linux (gcc202) and SPARC/Solaris machines
(gcc210 and gcc211) in the Compile Farm:
Snapshot gcc-8-20210128 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20210128/
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=96137
--- Comment #5 from Marek Polacek ---
A more realistic test:
void
fn ()
{
X.operator T();
}
On Thu, Jan 28, 2021 at 11:02:36PM +0100, Eric Botcazou wrote:
> > Bootstrapped/regtested on
> > * x86_64-pc-linux-gnu
> > * powerpc64le-unknown-linux-gnu
> > * aarch64-linux-gnu
> > ok for trunk?
>
> None of them is strict alignment though, isn't it?
Aware. I don't have access to, e.g., a
> Bootstrapped/regtested on
> * x86_64-pc-linux-gnu
> * powerpc64le-unknown-linux-gnu
> * aarch64-linux-gnu
> ok for trunk?
None of them is strict alignment though, isn't it?
--
Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
1zeeky at gmail dot com changed:
What|Removed |Added
Attachment #50077|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871
Bug ID: 98871
Summary: Cannot silence -Wmaybe-uninitialized at declaration
site
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
--- Comment #1 from Andrew Macleod ---
Very large function (16000+ basic blocks) with a lot of exception regions, and
a pattern whereby about 300 pointers are live to all the regions. We spend a
lot of time propagating an unchanging non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #12 from Jan Hubicka ---
> > Honza, any ideas on this?
> The comment on assert says
> /* In LTO mode we may have speculative edges set. */
> gcc_assert (in_lto_p || size_info->size == size_info->self_size);
>
> Which
On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote:
> On 28/01/2021 21:23, David Malcolm via Gcc wrote:
> > I wrote a blog post covering what I've been working on in the
> > analyzer
> > in this release:
> >
> > https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
>
On Thu, Jan 28, 2021 at 01:58:26PM -0600, Peter Bergner wrote:
> On 1/28/21 1:47 PM, Segher Boessenkool wrote:
> > On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
> >> The second patch I want you to review is:
> >
> > "This patch replaces the following three patches:"
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #11 from Jan Hubicka ---
> Honza, any ideas on this?
The comment on assert says
/* In LTO mode we may have speculative edges set. */
gcc_assert (in_lto_p || size_info->size == size_info->self_size);
Which seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Marek Polacek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #18 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:513ee7d2cd9a60339a50dc9c4cba39a8f1c707f0
commit r11-6963-g513ee7d2cd9a60339a50dc9c4cba39a8f1c707f0
Author: Marek Polacek
Date:
On 28/01/2021 21:23, David Malcolm via Gcc wrote:
> I wrote a blog post covering what I've been working on in the analyzer
> in this release:
>
> https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
>
As a gcc user, I am always glad to hear of more static analysis
On 1/28/21 3:36 PM, Marek Polacek wrote:
On Thu, Jan 28, 2021 at 03:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
On 1/28/21 10:34 AM, Marek Polacek wrote:
A year ago I submitted this patch:
~~
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with
On 1/28/21 2:22 AM, Jakub Jelinek wrote:
On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:
+ if (TREE_CODE (bound) == PLUS_EXPR
+ && integer_all_onesp (TREE_OPERAND (bound, 1)))
+{
+ bound = TREE_OPERAND (bound, 0);
+ if (TREE_CODE (bound) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58354
--- Comment #2 from 1zeeky at gmail dot com ---
This has been fixed as of gcc 10.2.
On 1/28/21 1:31 AM, Richard Biener wrote:
On Thu, Jan 28, 2021 at 12:08 AM Martin Sebor via Gcc-patches
wrote:
Attached is another attempt to fix the problem caused by allowing
front-end trees representing nontrivial VLA bound expressions to
stay in attribute access attached to functions.
Hi,
I committed a test case for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539
with
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=80198c701a7fc09e736ccffe470ee5033ca59a69
but that commit did not make it into the PR, I put it
in by hand.
I had this problem previously, then it was thought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #12 from CVS Commits ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:dd1537924e18e87a44abbd4063de89f7b48c60d5
commit r8-10744-gdd1537924e18e87a44abbd4063de89f7b48c60d5
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:2d9597f400e3456240e4499c9a9bc7023380247f
commit r9-9209-g2d9597f400e3456240e4499c9a9bc7023380247f
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-01-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0f42bb8722204fb83dcd001cc4254ad25b969402
commit r10-9308-g0f42bb8722204fb83dcd001cc4254ad25b969402
Author: Harald Anlauf
On Thu, Jan 28, 2021 at 03:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/28/21 10:34 AM, Marek Polacek wrote:
> > A year ago I submitted this patch:
> >
> > ~~
> > Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
> > gets "const d[0]" with TYPE_USER_ALIGN=0 but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #30 from cqwrteur ---
> Great. So build with --disable-libstdcxx-verbose as well and stop
> complaining about a feature that other people find useful.
But even GCC bootstraps itself with EH, RTTI disabled (of course you are not
I wrote a blog post covering what I've been working on in the analyzer
in this release:
https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
Hope this is of interest
Dave
On 1/28/21 10:34 AM, Marek Polacek wrote:
A year ago I submitted this patch:
~~
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by
build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1.
When we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
david.welch at netronome dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
Bug ID: 98870
Summary: [11 regression] assembler output count off for
gcc.target/powerpc/ppc-fortran/ieee128-math.f90 after
r11-6959
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #29 from cqwrteur ---
(In reply to Jakub Jelinek from comment #23)
> And memcpy must be provided as documented in the GCC documentation:
> Most of the compiler support routines used by GCC are present in
> @file{libgcc}, but there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927
--- Comment #5 from Dominique d'Humieres ---
> Seems fixed... I'll try to commit the test case this evening.
I still get
31 | M = v_array_par(1)%MyFunc()
| 1
Error: Cannot convert TYPE(mytype) to REAL(4) at (1)
with
module
On 1/28/21 1:47 PM, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
>> The second patch I want you to review is:
>
> "This patch replaces the following three patches:"
>
> Please send a patch that modifies *current* code, and that is *tested*
> with
On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
> On Thu, Jan 28, 2021 at 12:59:18PM -0600, Segher Boessenkool wrote:
> > On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > > > The whole thread is at
> > > >
On Thu, Jan 28, 2021 at 12:59:18PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > > The whole thread is at
> > > https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
> > > .
> > >
> > > I
On 1/28/21 10:24 AM, Jakub Jelinek wrote:
On Thu, Jan 28, 2021 at 10:04:12AM -0500, Jason Merrill wrote:
We emit a bogus warning on the following testcase, suggesting that the
operator should return *this even when it does that already.
The problem is that normally cp_build_indirect_ref_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #24 from Jakub Jelinek ---
Actually asm (".global pthread_cond_init"); (etc.) is probably better, doesn't
need relocations, just adds the symbol to the symtab as non-weak.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #23 from Jakub Jelinek ---
Unaware of extern directive in gas.
I'd think (but it would need to be surrounded by configury checks) that
something like:
.section .gnu.need.pthread_cond, "e"
.8byte pthread_cond_init
...
.previous
where
On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > The whole thread is at
> > https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
> > .
> >
> > I approved *that* version of the patch.
>
> Yes you approved the built-in renaming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #22 from Jonathan Wakely ---
In that case it finds the no-op symbol in libc.so.6 and doesn't crash.
$ g++ cv.C -g -Wl,--trace-symbol=pthread_cond_destroy
/usr/bin/ld: /lib64/libc.so.6: definition of pthread_cond_destroy
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #28 from cqwrteur ---
(In reply to cqwrteur from comment #27)
> > But portable code can't rely on deterministict exceptions either, yet you
> > insist that it's essential and you can't live without it. It seems you're
> > quite happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #21 from Jakub Jelinek ---
So how does that work for dynamic linking when -lpthread is not linked in?
Does it crash too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #27 from cqwrteur ---
> But portable code can't rely on deterministict exceptions either, yet you
> insist that it's essential and you can't live without it. It seems you're
> quite happy to rely on non-standard things when it suits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98862
--- Comment #3 from Ye Luo ---
Cool. -foffload=-latomic resolved my problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #20 from Jonathan Wakely ---
I don't think so. The linker just doesn't resolve the undefined weak symbol for
pthread_cond_destroy is left equal to zero, and so there's a segfault when it
gets called.
$ g++ cv.C -static -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #26 from Jonathan Wakely ---
(In reply to cqwrteur from comment #24)
> (In reply to Jonathan Wakely from comment #22)
> > (In reply to cqwrteur from comment #20)
> > > 1. Freestanding C++ in the current situation is very problematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #25 from cqwrteur ---
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have std::move. You do not have std::forward.
> > You do not have std::addressof(). you do not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #24 from cqwrteur ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to cqwrteur from comment #20)
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
--- Comment #7 from Vladimir Makarov ---
I've reproduced it on gcc-10 branch.
For some reason, LRA does not change register class for reload pseudo.
This bug will take some time for a fix as the fix will probably affect very
sensitive part of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #23 from Jakub Jelinek ---
And memcpy must be provided as documented in the GCC documentation:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions. GCC requires the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861
--- Comment #22 from Jonathan Wakely ---
(In reply to cqwrteur from comment #20)
> 1. Freestanding C++ in the current situation is very problematic. (You do
> not have memcpy, you do not have std::move. You do not have std::forward.
> You do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98869
--- Comment #2 from Jakub Jelinek ---
It is required by OpenMP 4.5, and the OpenMP 5.0 support that allows this is
not finished yet.
1 - 100 of 250 matches
Mail list logo
