This patch fixes an issue whereby compile-time checks on return
aggregates with anonymous access discriminants were not performed when
multiple of such discriminants were present, the aggregate was within an
extended return statement, or the aggregate was within a qualified
expression.
Tested on
Fix three-letter typos like "alllowed" or "corrresponding". They can be
detected with this command:
$ grep "[[:alpha:]]\([[:lower:]]\+\)\1\1" ...
but need to be manually filtered for things like "ieee", "dd-mm-" or
hexadecimal literals.
Tested on x86_64-pc-linux-gnu, committed on trunk
In certain cases of conversions to interface types, the compiler
generates a special function to handle the conversion. In cases where
such a function has an extra accessibility-level formal and the target
type of the conversion has a designated type that comes from a limited
view (via
This adds references to Ada 2020 in the section documenting the two size
attributes used by GNAT, namely Object_Size and Value_Size, as well as
in the head comment of Subtypes_Statically_Match.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-18 Eric Botcazou
gcc/ada/
*
The compiler gave a wrong error about "must override" in the following
case. A private type is completed with a derived type that inherits a
must-override function. Outside that package, a type extension of the
private type is declared. The function on that type extension is not
visible, and is
Ada202X allows some aspects related to shared variable control to appear
on formal type declarations. These aspects represent new enforceable
parts of the contract between generic units and instantiations.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-18 Ed Schonberg
gcc/ada/
This gets rid of an old bypass used in the compiler, which would copy
the value set in an Object_Size clause for record types onto Size.
This means that a confirming Object_Size clause can prevent packing,
which is counter-intuitive given that Object_Size is not supposed to
pertain to packing at
This patch fixes a bug in which if a parent package has a use clause in
its private part, and a child of that parent has a use clause for the
same thing in its context clause, the compiler incorrectly warns that
the one in the child is redundant.
Tested on x86_64-pc-linux-gnu, committed on trunk
This patch documents that switch -gnatd_K is reserved to enable
machinery that detects known problem issues of previous releases.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-12-18 Javier Miranda
gcc/ada/
* debug.adb: Document -gnatd_K as a reserved switch for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Well, this one has been around for a while.
this->X::~X() is handled by finish_class_member_access_expr and its
lookup_destructor subroutine; let's use it in cp_parser_lookup_name for the
case where this-> is implicit.
Tested x86_64-pc-linux-gnu, applying to trunk.
* parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996
Bug 16996 depends on bug 3187, which changed state.
Bug 3187 Summary: gcc lays down two copies of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090
Bug 41090 depends on bug 3187, which changed state.
Bug 3187 Summary: gcc lays down two copies of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
What|Removed |Added
This patch builds on the Fortran front-end support posted earlier in
this series to enable polymorphic class pointers to be used in OpenACC
directives as well. It was last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00541.html
This version is largely the same as the previous
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part adds Fortran execution tests to libgomp.
Tested alongside other patches in this series with offloading to
NVPTX. OK?
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the Fortran front-end support for parsing the new
attach and detach clauses, as well as derived-type members on
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part adds C and C++ execution tests to libgomp.
Tested alongside other patches in this series with offloading to
NVPTX. OK?
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the C and C++ changes to parse attach and detach
clauses and struct member accesses via "." or "->" on other
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the middle-end support for OpenACC 2.6 attach and
detach operations, either as standalone clauses or as
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
It contains just the minimal libgomp bits necessary to support the OpenACC
runtime API routines (acc_attach, acc_detach and
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part contains the libgomp runtime support for the GOMP_MAP_ATTACH and
GOMP_MAP_DETACH mapping kinds (etc.), as introduced by the
This is a rebased version of the reference count consistency checking
patch last posted upstream here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00239.html
This is not necessary for proper operation of the rest of the patches
in this series, but has proved useful in development.
Tested
This patch was previously posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00321.html
This version is the same as the last-posted version. The middle-end patch
later in the series depends on this. Tested alongside other patches in
this series with offloading to NVPTX. OK?
Thanks,
This patch was previously approved here, but I have not committed it yet
(without the other patches in this series):
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01156.html
Included for completeness. I will commit this alongside other patches
if they are approved (or it could probably go in
This patch has been broken out of the "OpenACC 2.6 manual deep copy
support" patch, last posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html
This part is included for completeness. It is the same as the patch
posted by Thomas here:
This is a rebased version of the reference-count overhaul patch last
posted here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02235.html
This version omits parts of the above patch already committed upstream and
merges some recent REFCOUNT_INFINITY changes. This patch causes the newish
Hi,
This patch series provides support for OpenACC 2.6's manual deep copy
(attach/detach) feature. Many of these patches have been submitted
previously, but this series has been rebased and the large deep-copy
part proper has been split into several pieces for ease of review.
Tested with
The size_info of ipa_size_summary are created by r277424. It should be
duplicated for cloned nodes, otherwise self_size and estimated_self_stack_size
would be 0, causing param large-function-insns and large-function-growth working
inaccurate when ipa-inline.
gcc/ChangeLog:
2019-12-18
On Wed, 18 Dec 2019, Joseph Myers wrote:
> On Wed, 18 Dec 2019, Bernd Schmidt wrote:
>
> > On 12/17/19 10:32 PM, Joseph Myers wrote:
> > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
> >
> > It seems that permission bits are not reproduced entirely correctly. For
> > example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
On Wed, Dec 18, 2019 at 10:50 AM Andrew Pinski wrote:
>
> On Tue, Dec 17, 2019 at 6:33 PM Hongtao Liu wrote:
> >
> > Hi:
> > This patch is to simplify A * C + (-D) -> (A - D/C) * C when C is a
> > power of 2 and D mod C == 0.
> > bootstrap and make check is ok.
>
> I don't see why D has to
On Tue, Dec 17, 2019 at 6:33 PM Hongtao Liu wrote:
>
> Hi:
> This patch is to simplify A * C + (-D) -> (A - D/C) * C when C is a
> power of 2 and D mod C == 0.
> bootstrap and make check is ok.
I don't see why D has to be negative here.
>TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
+ &&
Hi:
This patch is to simplify A * C + (-D) -> (A - D/C) * C when C is a
power of 2 and D mod C == 0.
bootstrap and make check is ok.
changelog
gcc/
* gcc/match.pd (A * C + (-D) = (A - D/C) * C. when C is a
power of 2 and D mod C == 0): Add new simplification.
gcc/testsuite
Ping :)
Patch is here:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00099.html
On 2019/12/3 10:31, luoxhu wrote:
Hi Martin and Honza,
On 2019/11/18 21:02, Martin Liška wrote:
On 11/16/19 10:59 AM, luoxhu wrote:
Sorry that I don't quite understand your meanning here. I didn't grep the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92981
Bug ID: 92981
Summary: [10 Regression] ICE in get_partitioning_class, at
symtab.c:1966
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-checking,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #1 from Hongtao.liu ---
test.c.033.fre1
foo (unsigned int * restrict src1, int i, int k, int n)
{
int sum;
int j;
long unsigned int _1;
long unsigned int _2;
unsigned int * _3;
unsigned int _4;
sizetype _7;
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
Bug ID: 92980
Summary: [miss optimization]redundant load missed by fre.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
PR92923 shows a problem where builtin function usage is causing performance
problems due to unneeded subreg usage. These are being caused by the front-
end emitting unneeded VIEW_CONVERT_EXPR's on the builtin functions operands.
These in tern where caused by a lack of overloaded builtin entries
On Wed, 18 Dec 2019, Bernd Schmidt wrote:
> On 12/17/19 10:32 PM, Joseph Myers wrote:
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
>
> It seems that permission bits are not reproduced entirely correctly. For
> example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn
Bernd Schmidt :
> I vote for including .cvsignore files. Their absence makes diff comparisons
> of "git ls-tree" on specific revisions needlessly noisy.
A few minutes ago I implmemted and pushed a --cvsignores read option
for Subversion dumps. That should do what you eant.
--
On Tue, Dec 17, 2019 at 05:35:24PM -0600, Segher Boessenkool wrote:
> On Tue, Dec 17, 2019 at 05:29:44PM -0500, Michael Meissner wrote:
> > On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> > > > +;; Return true if the operand is a valid memory address that does not
> > > >
On 12/16/19 6:20 PM, Jason Merrill wrote:
On 11/29/19 6:23 PM, Strager Neds wrote:
How can we solve this problem? Some ideas (none of which I like):
* Disallow this code, possibly with an improved diagnostic.
* Silently make the section SECTION_LINKONCE if there is a conflict.
* Silently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
--- Comment #16 from Martin Sebor ---
Author: msebor
Date: Tue Dec 17 23:53:07 2019
New Revision: 279480
URL: https://gcc.gnu.org/viewcvs?rev=279480=gcc=rev
Log:
PR c++/61339 - add warning for mismatch between struct and class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Tue, Dec 17, 2019 at 05:29:44PM -0500, Michael Meissner wrote:
> On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> > > +;; Return true if the operand is a valid memory address that does not
> > > use a
> > > +;; prefixed address.
> > > +(define_predicate
On 12/17/19 10:32 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
It seems that permission bits are not reproduced entirely correctly. For
example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and
the git-svn repository) to -rw-r--r-- in this
I attempted to use the analyzer to detect CVE-2005-1689, a double-free in
krb5-1.4.1's src/lib/krb5/krb/recvauth.c
With v1-v4 of the analyzer, it emits 11 double-free warnings:
https://dmalcolm.fedorapeople.org/gcc/2019-11-13/CVE-2005-1689.html
of which most were either false positives or
Whilst analyzing the reproducer for detecting CVE-2005-1689
(krb5-1.4.1's src/lib/krb5/krb/recvauth.c), the analyzer reports
a false double-free of the form:
krb5_xfree(inbuf.data);
krb5_read_message(..., );
krb5_xfree(inbuf.data); /* false diagnostic here. */
where the call to
gcc/analyzer/ChangeLog:
* ChangeLog: New file.
---
gcc/analyzer/ChangeLog | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 gcc/analyzer/ChangeLog
diff --git a/gcc/analyzer/ChangeLog b/gcc/analyzer/ChangeLog
new file mode 100644
index ..7144b69596e2
---
Whilst analyzing the reproducer for detecting CVE-2005-1689
(krb5-1.4.1's src/lib/krb5/krb/recvauth.c), the analyzer reported
11 double-free diagnostics on lines of the form:
krb5_xfree(inbuf.data);
with no deduplication occcurring.
The root cause is that the diagnostics each have a
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (dedupe_winners::add): Add logging
of deduplication decisions made.
---
gcc/analyzer/diagnostic-manager.cc | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git
On Mon, Dec 16, 2019 at 04:00:14PM -0500, Jason Merrill wrote:
> On 12/16/19 3:55 PM, Jason Merrill wrote:
> > On 12/14/19 4:25 PM, Marek Polacek wrote:
> > > On Fri, Dec 13, 2019 at 05:56:57PM -0500, Jason Merrill wrote:
> > > > On 12/13/19 3:20 PM, Marek Polacek wrote:
> > > > > + /* Given
On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 11, 2019 at 07:29:05PM -0500, Michael Meissner wrote:
> > +(define_memory_constraint "em"
> > + "A memory operand that does not contain a prefixed address."
> > + (and (match_code "mem")
> > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92977
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||openmp
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #16 from Martin Sebor ---
The warning doesn't affect code generation. It's issued independent of it.
We'll have to agree to disagree about the validity of the test case in comment
#0, but I do agree that at least some of your test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Tue Dec 17 21:46:40 2019
New Revision: 279473
URL: https://gcc.gnu.org/viewcvs?rev=279473=gcc=rev
Log:
PR c++/79592 - missing explanation of invalid constexpr.
We changed months back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Tue Dec 17 21:46:11 2019
New Revision: 279472
URL: https://gcc.gnu.org/viewcvs?rev=279472=gcc=rev
Log:
PR c++/92576 - redeclaration of variable template.
The variable templates
We changed months back to use the pre-generic form for constexpr evaluation,
but explain_invalid_constexpr_fn was still using DECL_SAVED_TREE. This
mostly works, but misses some issues due to folding. So with this patch we
save the pre-generic form of constexpr functions even when we know they
The variable templates patch way back when forgot to add handling here. The
simplest answer seems to be recursing to the underlying declaration.
Tested x86_64-pc-linux-gnu, applying to trunk.
* decl.c (redeclaration_error_message): Recurse for variable
templates.
---
I noticed we didn't have a hint for std::byte yet.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/name-lookup.c| 2 ++
gcc/testsuite/g++.dg/lookup/missing-std-include-9.C | 3 +++
2 files changed, 5 insertions(+)
create mode 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #35 from Manuel López-Ibáñez ---
In any case, looking at the uninit dump with -fdump-tree-all-all-lineno it
appears that GCC knows the block where the warning is triggered is never
executed:
;; basic block 13, loop depth 0, count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Note bswap pass is very fragile. In fact if we increase the limit by 1,
> things dont work any more. There needs to be a better way of handling this.
PR 92979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #34 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #15)
> I think the following smaller test case independent of libstdc++ captures
> the same issue as the bigger test case in comment #4. Again, declaring f()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59655
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 17 21:40:14 2019
New Revision: 279470
URL: https://gcc.gnu.org/viewcvs?rev=279470=gcc=rev
Log:
PR c++/59655
* pt.c (push_tinst_level_loc): If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #14 from Martin Sebor ---
(In reply to Tobias Burnus from comment #12)
The warnings have been enabled by default since _FORTIFY_SOURCE (and Builtin
Size Checking) was introduced. Given their severity I don't think we want
consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
Andrew Pinski changed:
What|Removed |Added
Depends on||92979
--- Comment #6 from Andrew Pinski
I've made test conversions of the GCC repository with reposurgeon
available (gcc.gnu.org / sourceware.org account required to access
these git+ssh repositories, it doesn't need to be one in the gcc group
or to have shell access). More information about the repositories,
conversion choices made
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979
Bug ID: 92979
Summary: bswap not finding a bswap with a memory load at the
beginging of the instruction stream
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 92236, which changed state.
Bug 92236 Summary: [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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?
2019-12-17 Jakub Jelinek
PR c++/92973
* method.c
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 going
to mark DECL_DEFAULTED_FN results in
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #13 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #9)
Thanks for the nice test case! The assumptions the warning makes aren't
accidental: it tries to detect bugs that would otherwise go undetected, and it
relies on
Hi!
big ? "-fno-pie" : "-fno-pie" doesn't make much sense, either we want to
use big ? "-fno-PIE" : "-fno-pie", but as both mean the same thing, I think
just using "-fno-pie" is good enough. + a few formatting nits and one
comment typo.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68012
Jason Merrill changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 17 20:40:01 2019
New Revision: 279468
URL: https://gcc.gnu.org/viewcvs?rev=279468=gcc=rev
Log:
PR target/92841
* config/i386/i386.md (@stack_protect_set_1_,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84255
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92560
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082
Jason Merrill changed:
What|Removed |Added
Known to work||10.0, 9.2.1
Known to fail|10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #33 from Jason Merrill ---
(In reply to Pedro Alves from comment #32)
> Usually maybe-uninit warnings point to false positives involving scalars,
> and initializing them is practically free. But here the size of T may be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040
Roman Zhuykov changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978
Bug ID: 92978
Summary: std::gcd mishandles mixed-signedness
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591
--- Comment #9 from Roman Zhuykov ---
Started discussion in mailing list:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01223.html
Hello.
As pointed out in the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591#c1, the test can be
fixed by DFA-checking more adjacent row sequences in the partial
schedule.
I've found that on powerpc64 gcc.c-torture/execute/pr61682.c test
catches same issue with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #32 from Pedro Alves ---
Right, the potentially-sensitive aspect is what I mean to stress here. Usually
maybe-uninit warnings point to false positives involving scalars, and
initializing them is practically free. But here the size
Hi,
I'm interested in printing VAR_DECL trees that are of type
RECORD_TYPE. I am using the function print_generic_decl
for debugging and found this interesting behaviour.
When I do initialization of structs using the following
syntax:
```
struct aStruct { _Bool e; int a; char b; float c; double
On 12/16/19 6:31 PM, Martin Sebor wrote:
+ class_decl_loc_t *rdl = class2loc.get (type_decl);
+ if (!rdl)
+{
+ rdl = _or_insert (type_decl);
I was thinking
class_decl_loc_t *rdl = _or_insert (type_decl);
OK with that change.
Jason
On 12/10/19 4:02 PM, Jakub Jelinek wrote:
Hi!
On the following testcase, we emit 2 errors and 1 warning, when the user
really should see one error. The desirable error is static_assert failure,
the bogus error is during error recovery, complaining that a no_linkage
template isn't defined when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92774
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #31 from Jason Merrill ---
(In reply to Pedro Alves from comment #30)
> I assume so, but do we really want to zero-initialize the buffer? T might
> be large, and I'd think that pessimization to quiet a warning isn't the
> right way
Hi Thomas,
I am reasonably comfortable with the current patch (regarding your
TODOs) – see attachment. It is the previous patch plus your changes plus
one additional condition (see below) in target.c's first
GOMP_MAP_IF_PRESENT handling.
I intent to re-test it tomorrow and then commit it,
1 - 100 of 201 matches
Mail list logo
