https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99901
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975
--- Comment #3 from Arseny Solokha ---
gcc-11.0.1-alpha20210404 snapshot (g:c3d3bb0f03dbd02512ab46979088ee8e22520c24)
accepts all three testcases w/o ICE. Is it a duplicate of PR99007?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241
Jason Merrill changed:
What|Removed |Added
Known to work||11.0
Summary|[8/9/10/11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99924
Bug ID: 99924
Summary: ICE in vect_schedule_slp_node, at tree-vect-slp.c:6040
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:55f40d968b0bd3be4478a9481e829a99ee0fa04f
commit r11-7998-g55f40d968b0bd3be4478a9481e829a99ee0fa04f
Author: Jason Merrill
Date:
In this testcase, the parms remembered in LAMBDA_EXPR_EXTRA_SCOPE are no
longer the parms of the FUNCTION_DECL they have as their DECL_CONTEXT, so we
were mangling both lambdas as parm #0. But since the parms are numbered
from right to left we don't need to need to find them in the FUNCTION_DECL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99899
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99899
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:66de517b1c1dd22df7914f8e9a083cd5a73adbe2
commit r11-7997-g66de517b1c1dd22df7914f8e9a083cd5a73adbe2
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99901
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |8.5
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99923
Bug ID: 99923
Summary: Rejects valid if statement with default argument
concept
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-04-06
It’s about improving compiler dumps for the Rust frontend. Full proposal here:
https://docs.google.com/document/d/1gyAOM-f3RyZh3HVpjmIMDSuQ5gBscal71sFY6XUMcHI/edit#
Yizhe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485
Martin Sebor changed:
What|Removed |Added
Known to fail|9.0 |
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85872
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922
Bug ID: 99922
Summary: Bind(C) with assumed length character should work
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99921
Bug ID: 99921
Summary: PowerPC xxeval has the wrong predicates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920
Bug ID: 99920
Summary: [10 regression] ICE building gcc 10 on power 7 BE
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99883
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85777, which changed state.
Bug 85777 Summary: [8/9/10/11 Regression] -fsanitize=undefined makes a
-Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On Mon, Apr 5, 2021 at 2:14 PM Jan Hubicka wrote:
>
> > > /* skylake_cost should produce code tuned for Skylake familly of CPUs.
> > > */
> > > static stringop_algs skylake_memcpy[2] = {
> > > - {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > > - {libcall, {{16,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870
Jason Merrill changed:
What|Removed |Added
Known to work||11.0
Summary|[8/9/10/11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440
Jason Merrill changed:
What|Removed |Added
Summary|[9/10/11 Regression]|[9/10 Regression] Accepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311
Jason Merrill changed:
What|Removed |Added
Known to work||11.0
Summary|[8/9/10/11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:b07dd9b0d0e501a0083da79e2bca17041c007ec8
commit r11-7995-gb07dd9b0d0e501a0083da79e2bca17041c007ec8
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:07f56824fd4da14a48030e698c8eb58de951c741
commit r11-7994-g07f56824fd4da14a48030e698c8eb58de951c741
Author: Jason Merrill
Date:
We never called mark_use for a return value in a function with dependent
return type. In that situation we don't know if the use is as an rvalue or
lvalue, but we can use mark_exp_read instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/96311
*
In r260622 I allowed this under the general principle that [basic.lval]
"Whenever a prvalue appears as an operand of an operator that expects a
glvalue for that operand, the temporary materialization conversion (7.3.4)
is applied to convert the expression to an xvalue." But
> > /* skylake_cost should produce code tuned for Skylake familly of CPUs. */
> > static stringop_algs skylake_memcpy[2] = {
> > - {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > - {libcall, {{16, loop, false}, {512, unrolled_loop, false},
> > - {-1,
On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM
Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
>
> The default debug format (when using only -g) for the AVR target is
> stabs. Is there a reason for it not being DWARF, and would it be
> possible to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754
Stafford Horne changed:
What|Removed |Added
Resolution|FIXED |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754
Stafford Horne changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Martin Sebor changed:
What|Removed |Added
Blocks||99918
--- Comment #1 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12754
Stafford Horne changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
--- Comment #4 from Martin Sebor ---
(In reply to Andrew Pinski from comment #1)
> This comes down to lowering bitfields too soon.
> my bet it will happen even integer bitfields will have a problem.
Yes, unsigned bit-fields suffer the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2018-04-09 00:00:00 |2021-4-5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Bug ID: 99919
Summary: [9/10/11 Regression] bogus -Wmaybe-uninitialized with
a _Bool bit-field
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
--- Comment #3 from Martin Sebor ---
This only seems to affect C _Bool bit-fields and not C++ bool.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
Bug ID: 99918
Summary: suboptimal code for bool bitfield tests
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917
--- Comment #1 from Iain Buclaw ---
(In reply to David Binderman from comment #0)
> trunk.git/gcc/d/dmd/mtype.c:5223:30: error: va_list 'ap' was opened but not
> closed by va_end(). [va_end_missing]
>
> Source code is
>
> va_list ap;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #4 from the_gamester28 at msn dot com ---
(In reply to Jason Merrill from comment #2)
> (In reply to the_gamester28 from comment #0)
> > It seems that the template requirements of invoke_tag(bar_tag, int) are
> > considered while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Hi,
This patch adds TARGET_D_REGISTER_OS_TARGET_INFO as a new D front-end
target hook, implementing `__traits(getTargetInfo, "objectFormat")' for
all targets that have D support files.
This trait was added earlier in the front-end as a stub, however the
target-specific implementation was left
Hi,
This patch adds TARGET_D_REGISTER_CPU_TARGET_INFO as a new D front-end
target hook, implementing `__traits(getTargetInfo, "floatAbi")' for all
targets that have D support files.
This trait was added earlier in the front-end as a stub, however the
target-specific implementation was left out
Hi,
This patch adds TARGET_D_HAS_STDCALL_CONVENTION as a new D front-end
target hook. It replaces the use of the D front-end `is64bit' parameter
in determining whether to insert the "stdcall" function attribute.
It is also used to determine whether `extern(System)' should be the same
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317
Jason Merrill changed:
What|Removed |Added
Known to work||11.0
Summary|[8/9/10/11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9f4c41147a41d08a74990eafe69a1064a3c13435
commit r11-7993-g9f4c41147a41d08a74990eafe69a1064a3c13435
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:62d60246e53778db6ee613377dd013ba4b264968
commit r11-7992-g62d60246e53778db6ee613377dd013ba4b264968
Author: Jason Merrill
Date:
Here we weren't instantiating the enumerators because the arglist still had
the template parameter for the generic lambda, so looking one up failed. We
need to instantiate if the non-lambda enclosing scope is non-dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
Here enclosing_instantiation_of was failing to find a match because otctx is
struct S and current_function_decl is S::S(), so the latter has more
function contexts, and we end up trying to compare S() to NULL_TREE.
After spending a bit of time working on establishing the correspondence in
this
On Sat, Apr 3, 2021 at 6:24 PM Simon Marchi via Gcc wrote:
> The default debug format (when using only -g) for the AVR target is
> stabs. Is there a reason for it not being DWARF, and would it be
> possible to maybe consider possibly thinking about making it default to
> DWARF? I am asking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066
--- Comment #6 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #3)
> r104041, yes. Bizarre that this went unnoticed for over 15 years.
Very surprising, isn't it!
On 4/5/21 12:31 PM, Patrick Palka wrote:
On Mon, 5 Apr 2021, Patrick Palka wrote:
In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and
When the enumeration constants of an enumeration type are defined by explicit
values, the binding generated by -fdump-ada-spec does not use an enumeration
type on the Ada side, because the set of allowed values in C/C++ is larger
than the set of allowed values in Ada, but instead use an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99917
Bug ID: 99917
Summary: gcc/d/dmd/mtype.c:5223: missing call to va_end ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85233, which changed state.
Bug 85233 Summary: Incorrect -Wmaybe-uninitialized with -fpartial-inlining
-finline-small-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85233
Martin Sebor changed:
What|Removed |Added
Known to fail||7.3.0, 8.3.0, 9.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.0, 4.1.0, 4.8.4,
On Mon, 5 Apr 2021, Patrick Palka wrote:
> In this PR, we're crashing because the constraint handling inside
> do_auto_deduction doesn't expect to see an adc_decomp_type context.
> This patch fixes this by treating adc_decomp_type like adc_variable_type
> and adc_return_type during the constraint
Ian,
thank you for taking the time to write this. I appreciate that you have
reached out. I do have a couple of comments though.
On 4/1/21 3:19 PM, Ian Lance Taylor wrote:
On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote:
I think you want the steering committee to issue a statement
In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and adc_return_type during the constraint handling.
Meanwhile, I noticed we weren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99899
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7988-g7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb.
gcc/analyzer/ChangeLog:
PR analyzer/99906
* analyzer.cc (maybe_reconstruct_from_def_stmt): Fix NULL
dereference on calls with zero
The analyzer appeared to enter an infinite loop on malloc-1.c
when -fanalyzer-verbosity=0 was used. In fact, it was slowly
counting from 0 to 0x.
Root cause is looping up to effectively ((unsigned)0) - 1 in
diagnostic_manager::consolidate_conditions when there are no events
in the path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99380
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99380
--- Comment #1 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:dd6f588a7b8878d677af51ff4d1c1e3f9f6f40db
commit r11-7989-gdd6f588a7b8878d677af51ff4d1c1e3f9f6f40db
Author: Nathan Sidwell
Date:
This problem got introduced fixing a module numbering problem. When
preprocessing a header unit, we don't need to send an EXPORT query
unless we're also determining dependencies, or the mapper askedus to.
Sadly the testsuite isn't set up to test this kind of subtlety. I
manually did that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99906
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99886
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99906
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb
commit r11-7988-g7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99886
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:69b66ff02353a87585329bb3cf4ac20d6dee1b16
commit r11-7987-g69b66ff02353a87585329bb3cf4ac20d6dee1b16
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870
--- Comment #7 from Viktor Rosendahl ---
Thanks for your message. I am on vacation. I will be working again on 6th of
April 2021.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
On Mon, Mar 22, 2021 at 6:16 AM H.J. Lu wrote:
>
> Simply memcpy and memset inline strategies to avoid branches for
> Skylake family CPUs:
>
> 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
>load and store for up to 16 * 16 (256) bytes when the data size is
>fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201
Jason Merrill 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=99066
Jason Merrill changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:bd89b8fe9efbdf0a95d827553d1a84fd3cefaa16
commit r11-7986-gbd89b8fe9efbdf0a95d827553d1a84fd3cefaa16
Author: Jason Merrill
Date:
'extern template' should mean that the relevant symbols are never emitted.
But in this case we were assuming that DECL_EXTERNAL was already set on the
variable, so we just needed to clear DECL_NOT_REALLY_EXTERN. Since
DECL_EXTERNAL was not set, we emitted a definition of npos.
Tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066
--- Comment #3 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps caused by PR23691 changes?
r104041, yes. Bizarre that this went unnoticed for over 15 years.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d
commit r11-7985-ga99a7b0afe9a1f6f866e25b8572856ae8c1d3f8d
Author: Jason Merrill
Date:
When building up *_EXTRA_ARGS for a constexpr if or pack expansion, we need
to walk into the body of a lambda to find all the local_specializations that
we need to remember, like we do in find_parameter_packs_r.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99916
Bug ID: 99916
Summary: ICE Segmentation fault when erroneous structured
bindings appears in requires-clause
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
On 4/3/21 10:54 AM, Jason Merrill wrote:
The if allows TEMPLATE_DECL, but then checking DECL_MODULE_IMPORT_P crashes
on TEMPLATE_DECL. Fixed by stripping TEMPLATE_DECL first.
Nathan, does this look right to you?
gcc/cp/ChangeLog:
* ptree.c (cxx_print_decl): Check DECL_MODULE_IMPORT_P
Hi,
This patch changes the default linkage of templates in the D language to
be DECL_WEAK instead of DECL_ONE_ONLY, if supported. This better
matches the expected override semantics of template symbols compiled to
object code. For example:
module rt.config;
template rt_flag()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:76a7e7e706ac4c01cead3c6514322aaad88f9a63
commit r11-7983-g76a7e7e706ac4c01cead3c6514322aaad88f9a63
Author: Iain Buclaw
Date: Sun
e <https://gcc.gnu.org/bugs/> for instructions.
g++ (GCC) 11.0.1 20210405 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
g++ (GCC) 11.0.1 20210405 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
Bug ID: 99914
Summary: d: Template symbols not overridable by normal symbols
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
--- Comment #3 from Brecht Sanders
---
Just to clarify: libwinpthread is built as part of the GCC build against
MinGW-w64.
MinGW-w64 also already has a libwinpthread (including libwinpthread-1.dll which
can be found in the PATH).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
--- Comment #2 from Brecht Sanders
---
By the time I get to that error the build process already generated these
files:
- mingw-w64/mingw/lib/libwinpthread.a
- mingw-w64/mingw/lib/libwinpthread.dll.a
- mingw-w64/mingw/lib/libwinpthread.la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
--- Comment #1 from Andrew Pinski ---
I Noticed:
--enable-threads=posix
and the error message is:
D:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\bin\ld.exe:
R:/winlibs32_stage/gcc-11-20210404/build_mingw/gcc/libgcc_eh.a(unwind-dw2.o):
in
1 - 100 of 104 matches
Mail list logo
