https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92954
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
Eric Gallager changed:
What|Removed |Added
Blocks||87403
Summary|missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92209
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92210
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91839
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91820
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
I think this is good idea since it is consistent with env var
GCC_COLORS -- the color support will be disabled even with
-fdiagnostics-color=always, if GCC_COLORS is set to empty.
And I has experienced more serious problem when I ssh(1) to the remote
machine from a even older terminal, GNOME
Provide a default value of $(toolexeclibdir) for $(ADA_RTL_DSO_DIR), so
that in a `--disable-libada' configuration `make install' places shared
gnatlib libraries, built with `make -C gcc gnatlib-shared', in their
intended version-specific location, fixing a commit r276424 ("libada:
Respect
On Dec 20, 2019, at 8:13 AM, Olivier Hainque wrote:
>
> This change adjusts a few scan-tree-dump expressions
> to allow '$' as well as '.' when matching symbol names,
>
> Ok to commit ?
Ok.
On Dec 20, 2019, at 9:27 AM, Olivier Hainque wrote:
> gcc/testsuite/gcc.dg/cpp/ucs.c #include
> and then crafts a definition of WCHAR_MAX depending
> on __WCHAR_TYPE__.
> Ok to commit ?
Ok.
On Dec 20, 2019, at 10:11 AM, Olivier Hainque wrote:
>
> The attached patch is a proposal for a basic solution
> to an issue which might be an improper thing done by a
> system header on VxWorks, but which is a big pain to fix
> at this level and very simple to address super locally.
> Is this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Dec 9, 2019, at 1:30 PM, Maciej W. Rozycki wrote:
>
> On Fri, 29 Nov 2019, Maciej W. Rozycki wrote:
>
>> Fix a catastrophic libgo testsuite failure in cross-compilation where
>> the shared `libgcc_s' library cannot be found by the loader at run time
>> in build-tree testing and
On Dec 16, 2019, at 4:06 PM, Maciej W. Rozycki wrote:
>
> On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:
>
>> This patch series addresses a problem with the testsuite compiler being
>> set up across libatomic, libffi, libgo, libgomp with no correlation
>> whatsoever to the target compiler
These are new tests. They verify if you are doing a vec_extract of a vector in
memory and the vector's address contains a large offset and the element number
is constant, it generates a prefixed load instruction when -mcpu=future.
Once all of the other V11 patches are checked in, can I check
These tests are new. These tests check that the vector extract from a vector
in memory works correctly for both constant and variable element numbers.
These tests pass with all of the previoius pataches applied. Can I check these
patches into the trunk?
2019-12-20 Michael Meissner
This is patch V8 #6. It makes sure the stack protect insns work when
-mcpu=future and -fstack-protector-strong are used together. We discovered
this failure when we attempted to build GLIBC using -mcpu=future.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00089.html
This test now passes when I
This patch fixes an issue with the output of -fdump-analyzer-supergraph
on BBs with no statements, where the resulting files were unreadable by
dot e.g.:
Error: syntax error in line 1
... ...
in label of node node_10
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to the
This is a reworking of patch V8 #5. It adds a bunch of PC-relative tests for
the -mcpu=future target.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00085.html
This test passes when I run it. Can I check it in?
2019-12-20 Michael Meissner
* gcc.target/powerpc/prefix-pcrel.h: New set
This is a reworking of the tests I submitted previously in V8 #4. It generates
a bunch of loads and stores for various types using large addresses, and
verifies that the number of prefixed loads and stores is correct.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00084.html
This patch works when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93036
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93036
Bug ID: 93036
Summary: [9/10 Regression] g++.dg/cpp2a/nontype-class27.C
testcase accepted in -std=c++17 mode since r276248
Product: gcc
Version: 10.0
Status: UNCONFIRMED
This is V10 patch #12. It adds a test to make sure we don't generate a
prefixed instruction with PRE_INC, PRE_DEC, or PRE_MODIFY.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00846.html
This test passes when I run it. Can I check this into the trunk?
2019-12-20 Michael Meissner
*
On Fri, Dec 20, 2019 at 06:18:04PM -0500, Jason Merrill wrote:
> > BTW, is the testcase valid in C++17 mode? GCC 7/8/9/trunk accept it,
> > but clang++ rejects it.
>
> No, non-template parameters of class types are a C++20 feature.
Trunk accepts it since r276248 aka PR91923 in -std=c++17 mode.
This is V10 patch #11. This adds a new test to validate that for -mcpu=future,
we generate a prefixed load/store if the offset would have been illegal for a
non-prefixed DS or DQ instruction.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00845.html
This test passes when I run the testsuite. Can
This is V10 patch #10. It adds 3 new tests to verify that we generate PADDI/PLI
for large constants when -mcpu=future is used.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00843.html
This test passes when the preceeding patches are applied. Can I check this in?
2019-12-20 Michael Meissner
This is V10 patch #9. It adds new target_supports tests for the new patches:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00842.html
All of the new tests work with these target supports. Can I check it into the
trunk?
2019-12-20 Michael Meissner
* lib/target-supports.exp
This is the same as V10 patch #8. Once the vector extract patches are
committed, this patch flips the default to use PC-relative addressing on 64-bit
Linux systems when the uses -mcpu=future.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00841.html
I have bootstrapped the compiler on a little
On Sun, Dec 15, 2019 at 07:11:25PM +0100, Thomas Koenig wrote:
> Am 10.12.19 um 22:22 schrieb Thomas Koenig:
> > Steve made an excellent suggestion: -finline-arg-packing .
> >
> > So, OK with that change?
>
> In other words, is
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html
>
>
This patch recognizes when we are doing the optimization of vector extract with
a constant element number when the vector is in memory and the vector's address
is PC-relative, to directly re-form the address using a PC-relative load,
instead of loading the address into a temporary register, and
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote:
> >
> > On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've sent another pull request fixing another 20. Here is the list
> > > with those 20 removed (and this still includes the libcpp vs
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #24 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:51:15 2019
New Revision: 279687
URL: https://gcc.gnu.org/viewcvs?rev=279687=gcc=rev
Log:
PR middle-end/91512
PR fortran/92738
* lang.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92738
--- Comment #16 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:51:15 2019
New Revision: 279687
URL: https://gcc.gnu.org/viewcvs?rev=279687=gcc=rev
Log:
PR middle-end/91512
PR fortran/92738
* lang.opt
In doing V11 patch #3, I noticed that the documentation for the 'Q' was
misleading. This patch updates the documentation. Can I check this patch into
the trunk?
2019-12-20 Michael Meissner
* config/rs6000/constraints.md (Q constraint): Update
documentation.
*
As I mentioned in the intro, for the case where we are optimizing the extract
of a variable element from a vector in memory, the current code takes a regular
address, and the temporary that holds the byte offset, and tries to generate a
new address. In particular, it failed when the vector was a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93035
Bug ID: 93035
Summary: Found 91 mangled names which do not demangle using
c++filt
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92966
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92992
--- Comment #3 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92965
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92973
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
This patch incorporates large offsets for -mcpu=future when we optimization a
vector extract from memory and the memory address previously had been a
prefixed address with a large offset.
The current code would generate loading up the constant into a temporary and
then doing an indexed load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028
--- Comment #2 from Colin H Close ---
(In reply to Marek Polacek from comment #1)
> It's not (easily) possible to reproduce the problem with what you've
> provided; the shell script has stuff like
>
Hi!
As mentioned in the PR, the following testcase is miscompiled with avx512vl.
The reason is that the fma *_bcst_1 define_insns have two alternatives:
"=v,v" "0,v" "v,0" "m,m" and use the same
vfmadd213* %3, %2, %0
pattern. If the first alternative is chosen, everything is ok, but if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92745
Marek Polacek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92745
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Fri Dec 20 23:30:04 2019
New Revision: 279686
URL: https://gcc.gnu.org/viewcvs?rev=279686=gcc=rev
Log:
PR c++/92745 - bogus error when initializing array of vectors.
In
Hi!
In C++17/2a mode, cp_parser_constructor_declarator_p because of deduction
guides considers constructor_p in more cases and returns true on
typedef struct S { int x; } T;
T (__attribute__((unused)) qux) (T x);
just because constructor arguments may start with __attribute__ keyword
(as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92974
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92974
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Fri Dec 20 23:25:44 2019
New Revision: 279685
URL: https://gcc.gnu.org/viewcvs?rev=279685=gcc=rev
Log:
PR c++/92974 - bogus location for enum and non-enum in ?: warning.
This patch fixes the bug pointed out in the V10 patch review that the code
modified an input argument to vector extract with a variable element number.
I also added two gcc_asserts to the vector extract address code to signal an
internal error if the temporary base register was used for two
On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > I've sent another pull request fixing another 20. Here is the list
> > with those 20 removed (and this still includes the libcpp vs
> > preprocessor ones that will be handled by the new alias).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92965
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:21:21 2019
New Revision: 279684
URL: https://gcc.gnu.org/viewcvs?rev=279684=gcc=rev
Log:
PR c++/92965
* pt.c (invalid_nontype_parm_type_p): Call
On Fri, Dec 20, 2019 at 05:56:39PM -0500, Jason Merrill wrote:
> On 12/20/19 3:27 PM, Marek Polacek wrote:
> > In r268428 I changed reshape_init_r in such a way that when it sees
> > a nested { } in a CONSTRUCTOR with missing braces, it just returns
> > the initializer:
> > + else if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92966
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:19:23 2019
New Revision: 279683
URL: https://gcc.gnu.org/viewcvs?rev=279683=gcc=rev
Log:
PR c++/92966
* method.c (early_check_defaulted_comparison): Don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92973
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:18:09 2019
New Revision: 279682
URL: https://gcc.gnu.org/viewcvs?rev=279682=gcc=rev
Log:
PR c++/92973
* method.c (early_check_defaulted_comparison): For
On 12/17/19 3:51 PM, Jakub Jelinek wrote:
Hi!
On the following testcase, complain & tf_error is 0 during sfinae, so we
don't emit error, but we called structural_type_p with explain=true anyway,
which emitted the inform messages.
Fixed by doing it only when we emit the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:16:58 2019
New Revision: 279681
URL: https://gcc.gnu.org/viewcvs?rev=279681=gcc=rev
Log:
PR c++/92666
* call.c (convert_arg_to_ellipsis): For floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92992
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 23:15:52 2019
New Revision: 279680
URL: https://gcc.gnu.org/viewcvs?rev=279680=gcc=rev
Log:
PR c++/92992
* call.c (convert_arg_to_ellipsis): For
On 12/17/19 3:57 PM, Jakub Jelinek wrote:
Hi!
When the prototype of defaulted comparison operator is incorrect, we set
DECL_MAYBE_DELETED, but don't set DECL_DEFAULTED_FN and other flags, so we
ICE during synthetize_method.
Seems only marking DECL_MAYBE_DELETED those operators that we are also
This set of patches reworks the vector extract issues in the V10 patches.
If you recall, in V10, you pointed out that for vector extract, the existing
code overwrote an input argument, and that is fixed in these patches.
In V10, I added two new constraints (ep and em) to categorize whether a
On 12/17/19 3:59 PM, Jakub Jelinek wrote:
Hi!
As discussed on IRC, defaulted comparison operators were added only in
C++2a, so we shouldn't accept it in older standard modes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2019-12-17 Jakub Jelinek
PR
On 12/18/19 6:44 PM, Jakub Jelinek wrote:
Hi!
convert_arg_to_ellipsis used to call decay_conversion for all types
(which calls mark_rvalue_use), but it doesn't anymore in GCC 10,
and while for INTEGRAL_OR_ENUMERATION_TYPE_P args it calls
cp_perform_integral_promotions which does that too and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78622
--- Comment #7 from Jonathan Wakely ---
(In reply to Jerry DeLisle from comment #6)
> (In reply to Jerry DeLisle from comment #5)
> > Author: jvdelisle
> > Date: Fri Dec 16 20:27:51 2016
> > New Revision: 243765
> >
> Wrong PR number, my
On 12/19/19 11:33 AM, Richard Sandiford wrote:
This test:
typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si = x;
ICEs with:
a.c:4:11: internal compiler error: in convert_like_real, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237
--- Comment #14 from Jonathan Wakely ---
(In reply to Thomas Koenig from comment #12)
> Author: tkoenig
> Date: Sun Feb 10 15:52:38 2019
> New Revision: 268748
>
> URL: https://gcc.gnu.org/viewcvs?rev=268748=gcc=rev
> Log:
> 2019-02-10 Thomas
Yes, much more. When you traverse a CFG, the analysis develops into a tree
(for example a tree of uses). That is, every basic block could be
*recursively* a root of an individual linear iteration for up to all basic
blocks. Sum them up, and you will get a polynomial expression. I don't
insist that
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> I've sent another pull request fixing another 20. Here is the list
> with those 20 removed (and this still includes the libcpp vs
> preprocessor ones that will be handled by the new alias).
Thanks, merged.
--
Joseph S. Myers
jos...@codesourcery.com
On 12/18/19 6:40 PM, Jakub Jelinek wrote:
Hi!
While looking at PR92666, I've spotted a wrong-code issue where we ignore
any side-effects on arguments passed to ellipsis if they have
decltype(nullptr) type.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and
On 12/20/19 3:27 PM, Marek Polacek wrote:
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert
On 12/19/19 6:05 PM, Marek Polacek wrote:
build_min_non_dep wasn't setting any location so when we were emitting the
warning in the following test while instantiating a template, it's location
was UNKNOWN_LOCATION. Rather than adding a location_t parameter, let's use
the location from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51083
Jonathan Wakely changed:
What|Removed |Added
URL|http://www.freefilehosting. |http://www.freefilehosting.
On 12/20/19 3:27 PM, Marek Polacek wrote:
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert
On Fri, Dec 20, 2019 at 02:57:57AM +0100, Dmitry Mikushin wrote:
> Trying to plan memory consumption ahead-of-work contradicts with the nature
> of the graph traversal. Estimation may work very well for something simple
> like linear or log-linear behavior.
Almost everything we do is (almost)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044
--- Comment #7 from Jonathan Wakely ---
Fixed by r218018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64004
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> Author: rguenth
> Date: Mon Nov 24 14:02:36 2014
> New Revision: 218018
>
> URL: https://gcc.gnu.org/viewcvs?rev=218018=gcc=rev
> Log:
> 2014-11-24 Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|NEW
Snapshot gcc-8-20191220 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20191220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On Fri, 20 Dec 2019 at 21:41, Joseph Myers wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
> > >
> > > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> > >
> > > > I've attached an updated list to this mail, which removes the items
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29027
--- Comment #6 from Jonathan Wakely ---
(In reply to Janis Johnson from comment #3)
> Subject: Bug 29027
>
> Author: janis
> Date: Wed Apr 1 17:31:26 2009
> New Revision: 145422
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=145422
> Log:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36460
--- Comment #9 from Jonathan Wakely ---
(In reply to Andy Hutchinson from comment #2)
> Subject: Bug 36460
>
> Author: hutchinsonandy
> Date: Wed Jun 18 21:48:50 2008
> New Revision: 136919
>
> URL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947
--- Comment #2 from Marek Polacek ---
The problem here is the cp_unevaluated_operand check:
10147 if (DECL_CONSTRUCTOR_P (fn)
10148 && !(flags & LOOKUP_ONLYCONVERTING)
10149 && !cp_unevaluated_operand
10150
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've attached an updated list to this mail, which removes the items
> > > we've analysed. There are 531 remaining.
> >
> > With the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8895
--- Comment #5 from Jonathan Wakely ---
Comment 4 belongs to PR 8995.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990
--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch cleaned up and with adjusted error message at
https://gcc.gnu.org/ml/fortran/2019-12/msg00182.html
The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
misleading error message. The patch below rectifies that.
OK for trunk?
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
Index: gcc/fortran/match.c
===
---
On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > I've attached an updated list to this mail, which removes the items
> > we've analysed. There are 531 remaining.
>
> With the current version of the script (including the various whitelisted
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93034
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
--- Comment #4 from Marek Polacek ---
template struct S {
S(T *);
~S();
};
struct X {
struct C {
S d;
float e;
};
X();
};
S f(S);
X::X() { C a[]{f("")}; }
$ ./cc1plus -quiet 93033.C
93033.C: In constructor ‘X::X()’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93009
--- Comment #7 from Jakub Jelinek ---
Created attachment 47537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47537=edit
gcc10-pr93009.patch
Untested fix.
The bug is obvious, these *_bcst_1 patterns used =v,v 0,v v,0 m,m constraints
but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832
--- Comment #11 from qinzhao at gcc dot gnu.org ---
Hi, (In reply to Martin Liška from comment #10)
> Fixed on trunk.
I am trying to back port the fix for 89832 into our company's gcc8.2.1 release.
by looking at the patch, it's huge, and it's
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> I've attached an updated list to this mail, which removes the items
> we've analysed. There are 531 remaining.
With the current version of the script (including the various whitelisted
component pairs discussed) and with data freshly downloaded from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93009
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+
On Fri, Dec 20, 2019 at 12:03 PM J Decker wrote:
>
>
> On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote:
>
>>
>>
>> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer
>> wrote:
>>
>>> * J. Decker:
>>>
>>> > Here's the gist of what I would propose...
>>> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote:
>
>
> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote:
>
>> * J. Decker:
>>
>> > Here's the gist of what I would propose...
>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>> >
>> > In C, there are two operators . and ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93034
Bug ID: 93034
Summary: variant not constexpr in c++17 mode
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote:
> * J. Decker:
>
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be
template class b {
public:
b(a *);
~b();
};
class c {
struct C {
b d;
float e;
};
c();
};
b f(b);
c::c() { C a[]{f("")}; }
1 - 100 of 243 matches
Mail list logo
