Richard,
My wolf fence failed to detect an issue at the end of my pass
so I'm now hunting for a problem I caused in a following pass.
Your thoughts?
Gary
- Wolf Fence Follows -
int
wf_func ( tree *slot, tree *dummy)
{
tree t_val = *slot;
gcc_assert( t_val->ssa_name.var);
return
Another missed attribute-visibility-requirement, causing a failure for
e.g. mmix-knuth-mmixware. Committed as obvious.
gcc/testsuite:
* c-c++-common/builtin-has-attribute-4.c: Require visibility.
--- gcc/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c.orig Mon Jan
13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96194
Hans-Peter Nilsson changed:
What|Removed |Added
CC||michael at michaelmarley dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96292
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
Bug ID: 96293
Summary: Extraneously noisy "taking address of packed member
may result in an unaligned pointer value"
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84079
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor
-Warray-bounds fails to trigger when taking the address of an element
of a multi-dimensional array at an index that's equal to the bound of
one of the higher dimensions of the array. The attached simple patch
corrects this shortcoming. I will commit it tomorrow unless there are
suggestions for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96292
Bug ID: 96292
Summary: Internal compiler error when compiling Mesa 20.1.x
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #18 from vvinayag at arm dot com ---
(In reply to Ilya Leoshkevich from comment #17)
> Created attachment 48917 [details]
> aarch64 native build fix
>
> Could you please try the attached patch? It fixed the issue for me, and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291
Bug ID: 96291
Summary: -flto fails as "internal compiler error: Segmentation
fault" during IPA pass: cp
incall_for_symbol_thunks_and_aliases()
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #17 from Ilya Leoshkevich ---
Created attachment 48917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48917=edit
aarch64 native build fix
Could you please try the attached patch? It fixed the issue for me, and
survived
Richard,
I was really hopeful about your suggestions but I went over my code and
anything that modified anything had a cfun_push and cfun_pop associated with it.
Also, enabling the extra annotations didn't make a difference.
I'm thinking a wolf fence test that scans for malformed default_def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58156
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Zhongyunde writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Wednesday, July 22, 2020 12:12 AM
>> To: Zhongyunde
>> Cc: gcc-patches@gcc.gnu.org; Yangfei (A)
>> Subject: Re: 答复: [PATCH PR95696] regrename creates overlapping
>> register
Richard Sandiford writes:
> luoxhu writes:
>> Hi,
>>
>> On 2020/7/22 19:05, Richard Sandiford wrote:
>>> This wasn't really what I meant. Using subregs is fine, but I was
>>> thinking of:
>>>
>>>/* Also try a wider mode if the necessary punning is either not
>>> desirable or not
Hello Joseph, Martin,
Asher Gordon writes:
> Joseph Myers writes:
>
>> I don't see you in the FSF copyright assignment list; could you
>> complete
>> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
>> (unless you're already covered by an employer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
Bug ID: 96290
Summary: nonsensical bounds in VLA types in -Warray-bounds
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi Richard,
Many thanks for the peer review and feedback. I completely agree that POPCOUNT
and PARITY iterators simplifies things and handle the IFN_ variants. Likewise,
using
integer_type_node as the type of shift constants also matches the idioms used
elsewhere in match.pd and fold. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96241
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92091
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> Am I correct to understand that #include is handled by the preprocessor?
Yes.
Other compilers always show the path to the included file in
On 7/22/20 1:00 PM, Segher Boessenkool wrote:
>> gcc/
>> PR target/96236
>> * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Handle
>> little-endian memory ordering.
>>
>> gcc/testsuite/
>> PR target/96236
>> * gcc.target/powerpc/mma-double-test.c:
Segher Boessenkool writes:
> Hi!
>
> On Wed, Jul 22, 2020 at 03:53:34PM +0200, Andrea Corallo wrote:
>> Andrew Pinski writes:
>> > Can you give a simple example of what this patch does?
>>
>> Sure, this pass simply moves a sliding window over the insns trying to
>> make sure that we never have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |10.3
LWG recently decided it should be ill-formed to instantiate std::future
and std::shared_future for types that can't be returned from a function.
This adds static assertions to enforce it (std::future already failed,
but this makes the error more understandable).
LWG 3466 extends that to
The as-base type never got a name. For modules I needed to give it a
name to serialize properly, and it's useful when debugging the compiler,
so we may as well have it on trunk. There's also a bug where its fields
can have NSDMIs from the main class. This happens to be silent on
trunk, but
David,
Note, for the first explanation, this is the hash table for the default defs
and not
some private pass specific table so I'm not directly touching it in way.
However, that
doesn't mean some other common or not so common function I'm invoking has
the side effect of doing this in some
New insn types should be documented in rtl.texi (I think in the "Insns"
section).
--
Joseph S. Myers
jos...@codesourcery.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236
--- Comment #3 from Peter Bergner ---
Fixed on trunk. I will backport to the GCC 10 release branch once it reopens.
I would have set the target milestone to 10.3, but that version isn't an option
right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236
--- Comment #2 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:ae575662833d70cb7d74b9538096c7becc79af14
commit r11-2278-gae575662833d70cb7d74b9538096c7becc79af14
Author: Peter Bergner
Date:
A new pragma needs to be documented in extend.texi. Such documentation
should be comprehensible to users who don't know anything about the
internals of GCC or other compilers, so that they can understand when it
would be appropriate to use the pragma in their source code.
--
Joseph S. Myers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
--- Comment #8 from kargl at gcc dot gnu.org ---
New patch. This adds a bool component to gfc_forall_iterator so
that an iterator with an index-name that shadows a variable from
outer scope can be marked. Shadowing only occurs when a type-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88604
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
On Wed, Jul 22, 2020 at 05:52:00PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * gfortran.h (enum gfc_omp_if_kind): Add OMP_IF_CANCEL and OMP_IF_SIMD.
> * openmp.c (OMP_SIMD_CLAUSES): Add OMP_CLAUSE_IF.
> (gfc_match_omp_clauses, resolve_omp_clauses): Handle 'if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
Andreas Urban changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
--- Comment #4 from Andreas Urban ---
Looking closer at how Perl exec works, along with join on empty strings and
variable, there would seem to be no problem:
exec 'gcc', join(' ', @cppflags, @cflags, '-o', '$@', '$<')
There may be one or two
Hi Peter,
On Wed, Jul 22, 2020 at 12:01:21PM -0500, Peter Bergner wrote:
> PR96236 shows a problem where we don't correctly store our 512-bit
> accumulators
> correctly in little-endian mode. The patch below detects when we're doing a
> little-endian memory access and stores to the correct
Hi!
On Wed, Jul 22, 2020 at 09:26:39AM +0800, Kewen.Lin wrote:
> +/* For some target specific vectorization cost which can't be handled per
> stmt,
> + we check the requisite conditions and adjust the vectorization cost
> + accordingly if satisfied. One typical example is to model shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #4 from Martin Sebor ---
(In reply to Martin Sebor from comment #3)
> I support including more diagnostics in -Wall and -Werror
I meant "-Wall and -Wextra."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See
luoxhu writes:
> Hi,
>
> On 2020/7/22 19:05, Richard Sandiford wrote:
>> This wasn't really what I meant. Using subregs is fine, but I was
>> thinking of:
>>
>>/* Also try a wider mode if the necessary punning is either not
>> desirable or not possible. */
>>if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
Martin Sebor changed:
What|Removed |Added
Depends on||82922
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
--- Comment #3 from Andreas Urban ---
(In reply to Jonathan Wakely from comment #1)
> Ignoring it could lead to equally undesirable behaviour though.
>
> for file in *.cc ; do gcc "$fil" ; done
>
> Don't those languages support something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
--- Comment #2 from Andreas Schwab ---
If you pass a non-file-name where a file name is expected you are doing
something wrong, and you need to fix *that*. Hiding errors is doing a
disservice.
PR96236 shows a problem where we don't correctly store our 512-bit accumulators
correctly in little-endian mode. The patch below detects when we're doing a
little-endian memory access and stores to the correct memory locations.
This passed bootstrap and regtesting with no regressions. Raji
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
Joseph C. Sible changed:
What|Removed |Added
CC||josephcsible at gmail dot com
---
[AMD Public Use]
> That's deliberate, so that we can use the same x86-* names for 32-bit library
> selection (once we define matching micro-architecture levels there).
Understood.
> If numbers are out, what should we use instead?
> x86-sse4, x86-avx2, x86-avx512? Would that work?
Yes
Hi!
On Wed, Jul 22, 2020 at 03:53:34PM +0200, Andrea Corallo wrote:
> Andrew Pinski writes:
> > Can you give a simple example of what this patch does?
>
> Sure, this pass simply moves a sliding window over the insns trying to
> make sure that we never have more then 'max_branch' branches for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96289
Bug ID: 96289
Summary: Unnecessary saving and re-testing of the carry flag
with __builtin_usub_overflow
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
--- Comment #1 from Jonathan Wakely ---
Ignoring it could lead to equally undesirable behaviour though.
for file in *.cc ; do gcc "$fil" ; done
Don't those languages support something like the Bourne shell's "$@" which does
the right thing?
Hi,
Sorry, please ignore the previously attached file, which isn't the latest one
although almost are the same. The latest tested is attached here.
Sorry for the inconvenience.
BR,
Kewen
on 2020/7/22 下午11:48, Kewen.Lin via Gcc-patches wrote:
>
> It's a great idea, by following your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96288
Bug ID: 96288
Summary: [DR 1734] __is_trivial and __is_tirivil_copyable fails
for deleted members
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
On Mon, 20 Jul 2020, Patrick Palka wrote:
> On Mon, 20 Jul 2020, Jonathan Wakely wrote:
>
> > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++ wrote:
> > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > >
> > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++ wrote:
> > > > > On Fri,
Hi Segher,
on 2020/7/22 下午4:26, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 22, 2020 at 09:44:52AM +0800, Kewen.Lin wrote:
>> This trivial patch is to rename adjust_vectorization_cost to
>> adjust_vect_cost_per_stmt. Hope it's more meaningful, as well
>> as to avoid the confusion between
Adds support for the simd and cancel modifier of
'if (: logical_expr)', which is already
supported in C/C++.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675
--- Comment #4 from Patrick Palka ---
Here's a non-template testcase that ICEs from the same assert in
build_over_call (with -std=c++17, --enable-checking=yes):
struct b {};
b operator|(b, b) { return {}; }
b e, f, g;
using h = decltype(e | f |
Hi Richard,
Thanks for the review!
on 2020/7/22 下午5:11, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> - else if (LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
>> -{
>> - peel_iters_prologue = 0;
>> - peel_iters_epilogue = 0;
>> + if (LOOP_VINFO_FULLY_MASKED_P
We don't need to add CONST_DECLs to a template decl's decl list. Also
made the code flow a bit clearer.
gcc/cp/
* class.c (maybe_add_class_template_decl_list): Don't add
CONST_DECLs.
nathan
--
Nathan Sidwell
diff --git i/gcc/cp/class.c w/gcc/cp/class.c
index
I discovered the dump machinery would get confused by filenames
containing '-'. Fixed thusly as obvious.
gcc/
* dumpfile.c (parse_dump_option): Deal with filenames
containing '-'
nathan
--
Nathan Sidwell
diff --git i/gcc/dumpfile.c w/gcc/dumpfile.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411
--- Comment #4 from Will Wray ---
I mis-read this so was too hasty in suggesting "can be closed".
The standard states that a expression evaluation fails to be a constant
expression if it evaluates "reinterpret_cast" (i.e., by named token,
not by
I had to debug structural_comptypes, and its complex if conditions and
tail calling of same_type_p made that hard. I'd hope we can turn the
eqivalent of return boolean_fn () ? true : false; into a tail call of
the boolean. We also were not dealing with TYPEOF_TYPE.
gcc/cp/
Hi,
On 2020/7/22 19:05, Richard Sandiford wrote:
> This wasn't really what I meant. Using subregs is fine, but I was
> thinking of:
>
>/* Also try a wider mode if the necessary punning is either not
>desirable or not possible. */
>if (!CONSTANT_P (store_info->rhs)
>
The testcase gfortran.dg/goacc/routine-module-mod-1.f90 fails due to an extra
'warning: region is worker partitioned but does not contain worker partitioned
code' message in subroutine g_1. subroutine g_1 is marked with '!$acc routine
gang', but the loop inside is only assigned gang vector loop
Here are some more places where we can declare variables at the
assignment point, rather than use C89. Also, let's name our variables
by what they contain -- the register allocator is perfectly able to
track liveness for us.
gcc/cp/
* decl.c (decls_match): Move
I noticed the default capture mode and the discriminator both used ints.
That seems excessive. This shrinks them to 8 bits and 16 bits
respectively. I suppose the discriminator could use the remaining 24
bits of an int allocation unit, if we're worried about more that 64K
lambdas per
This is a follow up to commit 5c9669a0e6c respectively discussion
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html
In case that an alignment constraint is less than the size of a
corresponding scalar type, ensure that we advance at least by one
iteration. For example, on s390x we
On 21/07/20 20:08 +, Joseph Myers wrote:
On Tue, 21 Jul 2020, Jonathan Wakely via Gcc-patches wrote:
I also noticed some strings give an underflow error with glibc's
strtod, but are valid for the Microsoft implementation. For example,
this one:
This test fails because the "'seq' overrides other OpenACC loop specifiers"
error is not appearing in the compiler output. The C-equivalent version of the
test (c-c++-common/goacc/loop-2-kernels.c) has these tests XFAILed in the commit
'Make new OpenACC kernels conversion the default; adjust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
Bug ID: 96287
Summary: Empty string argument to gcc should be ignored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68929
--- Comment #4 from Jonathan Wakely ---
Probably related to PR c++/96286, because if we stopped trying to compile a
class after a failed static_assert then we wouldn't keep recursing in Eric's
example here.
I noticed add_path was calling strlen more than once on the same string.
Let's not do that.
gcc/
* incpath.c (add_path): Avoid multiple strlen calls.
--
Nathan Sidwell
diff --git i/gcc/incpath.c w/gcc/incpath.c
index 8a2bda00f80..8437939bf1e 100644
--- i/gcc/incpath.c
I noticed the mangler's handling of templates could be simplified. We
know template_info is non-null, which is sufficiently boolean -- no need
for an explicit bool return. also some of the internals of
template_args_equal had crept into find_substitution. Let's not do that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286
Bug ID: 96286
Summary: Unhelpful errors after a failed static_assert
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, July 22, 2020 12:12 AM
> To: Zhongyunde
> Cc: gcc-patches@gcc.gnu.org; Yangfei (A)
> Subject: Re: 答复: [PATCH PR95696] regrename creates overlapping
> register allocations for vliw
>
>
Richard Biener writes:
> I wonder if such effect of instructions on the pipeline can be modeled
> in the DFA and thus whether the scheduler could issue (always ready)
> NOPs?
I might be wrong but the DFA model should be reasoning in terms of
executed instructions given an execution path, on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #2 from Jonathan Wakely ---
But they're not enabled by default, meaning that the unsafe, ill-formed code is
still accepted by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
--- Comment #24 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:748ada0acb6fd746207aaff23a468717eee06555
commit r11-2270-g748ada0acb6fd746207aaff23a468717eee06555
Author: H.J. Lu
Date: Wed Jul 22
The test c-c++-common/goacc/routine-nohost-1.c currently fails because it fails
to find some tree dump output. The problem is that the relevant tree pass is now
oaccloops rather than oaccdevlow.
This patch corrects the requested tree dump. I will be committing this one in
OG10 as 'obvious'.
On Wed, Jul 22, 2020 at 7:25 AM Dimitar Dimitrov wrote:
>
> On сряда, 22 юли 2020 г. 2:04:35 EEST Sunil Pandey via Gcc-patches wrote:
> > On Tue, Jul 21, 2020 at 12:50 AM Richard Biener
> >
> > wrote:
> > > On Tue, Jul 21, 2020 at 7:16 AM Sunil Pandey wrote:
> > > > On Mon, Jul 20, 2020 at 5:06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96281
Richard Biener changed:
What|Removed |Added
Component|other |middle-end
On сряда, 22 юли 2020 г. 2:04:35 EEST Sunil Pandey via Gcc-patches wrote:
> On Tue, Jul 21, 2020 at 12:50 AM Richard Biener
>
> wrote:
> > On Tue, Jul 21, 2020 at 7:16 AM Sunil Pandey wrote:
> > > On Mon, Jul 20, 2020 at 5:06 AM Richard Biener
> > >
> > > wrote:
> > > > On Sat, Jul 18, 2020
On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha
wrote:
>
> On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote:
> >
> > * Richard Biener:
> >
> > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> > > wrote:
> > >>
> > >> * Dongsheng Song:
> > >>
> > >> > I fully agree
gcc.dg/goacc/loop-processing-1.c fails mainly because the dg-final directive at
the end has been incorrectly split into two lines, which breaks it completely.
The pass that emits the tested tree output is now oaccloops, not oaccdevlow.
'.UNIQUE (OACC_HEAD_MARK, 0, 1, 36)' is also changed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-07-22
Known to work|
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (reverse_iterator): Constrain
converting constructor and converting assignment operator.
Access source iterator's data member directly instead of
calling base().
(move_iterator): Likewise.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #1 from Richard Biener ---
There's -pedantic and -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86498
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
Jonathan Wakely changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
--- Comment #5 from Jonathan Wakely ---
Another one that G++ rejects:
void f(char*);
int (...);
int = f("foo");
> On Jul 18, 2020, at 2:50 PM, Jakub Jelinek via Gcc-patches
> wrote:
>
> Hi!
>
> The following patch adds __builtin_bit_cast builtin, similarly to
> clang or MSVC which implement std::bit_cast using such an builtin too.
> It checks the various std::bit_cast requirements, when not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Jonathan Wakely changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The linker error alone doesn't make the root cause obvious, but it's a
> fairly well known and well documented problem:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #12 from Jonathan Wakely ---
(In reply to Zhihao Yuan from comment #11)
> 1. Adjust the error message to say, "The first non-inline, non-pure function
> may not have a definition in ."
That error comes from the linker. The linker is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
Hi Andrew,
thanks for reviewing I'll work on your comments. Just replying to the
high level questions.
Andrew Pinski writes:
> On Wed, Jul 22, 2020 at 3:10 AM Andrea Corallo wrote:
>>
>> Hi all,
>>
>> this second patch implements the AArch64 specific back-end pass
>> 'branch-dilution'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
--- Comment #4 from Jonathan Wakely ---
(In reply to Eyal Rozenberg from comment #0)
> While this is true, it is a bit confusing. But even supposing I looked up
> what this error means and realized what was going on, I would still need to
> go
On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> > wrote:
> >>
> >> * Dongsheng Song:
> >>
> >> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> >> > recommend using isa tags by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
--- Comment #3 from Jonathan Wakely ---
(In reply to Eyal Rozenberg from comment #2)
> Ok, still - the linker knows which virtual methods it needs, and it knows
> which are provided by each compiled translation unit. Isn't that enough?
The
1 - 100 of 190 matches
Mail list logo
