https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96625
--- Comment #1 from Hongtao.liu ---
movabs rax,0x1ff8 --- it also clear high 3 bits.
andrax,rdi
differs from
andrax,0xfff8
using g++ -O2 test.c -S got
---
movq%rdi, %rax
andq$-8, %rax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81043
Mike Detwiler changed:
What|Removed |Added
CC||shazamancan at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81043
--- Comment #3 from Mike Detwiler ---
I would like to share a temporary workaround that I have developed for this.
Consider the usual pattern for writing a partial specialization:
original decl:
template
class my_class;
specialization:
templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Bug ID: 96645
Summary: std::variant default constructor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96633
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-08-17
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #35 from Iain Sandoe ---
(In reply to niek from comment #34)
> Any progress on this issue?
>
> (The issue is still present in gcc-trunk...)
I have a couple of ideas, but very short of time to try them out, sorry about
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646
Bug ID: 96646
Summary: [11 Regression] ICE: Segmentation fault (in
tree_class_check)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96647
Bug ID: 96647
Summary: Can't resolve pointer to overloaded member with auto
return type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88242
fiesh at zefix dot tv changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022
fiesh at zefix dot tv changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583
fiesh at zefix dot tv changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
fiesh at zefix dot tv changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
James Hilliard changed:
What|Removed |Added
CC||james.hilliard1 at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96648
Bug ID: 96648
Summary: [11 Regression] ICE in get_field_at_bit_offset, at
analyzer/region.cc:229
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
--- Comment #11 from Volker Reichelt ---
Hi Marek, any news on this one? It's three months now...
Or should I file a new bug for the regression on trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #11 from Jonathan Wakely ---
> Standard says that if:
> std::is_constructible_v
> then
> std::is_constructible_v, Foo&&>
Where does it say that?
The fact a constructor participates in overload resolution doesn't mean it has
to be w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96649
Bug ID: 96649
Summary: parisc: very slow compilation when multiplying by a
large constatnt
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96650
Bug ID: 96650
Summary: [11 Regression] ICE in on_fact, at
analyzer/constraint-manager.cc:1785
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96651
Bug ID: 96651
Summary: -fanalyzer switch
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96652
Bug ID: 96652
Summary: Segmentation fault with instantiate_class_template_1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> It would be better to fix the lock policy at configure-time, so it is a
> constant for a given build of libstdc++.
That was done for PR 67843 with r266533, p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96653
Bug ID: 96653
Summary: Compile time and memory hog w/ -O1 -fanalyzer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: compile-time-hog, memory-hog
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #4 from Jonathan Wakely ---
(In reply to James Hilliard from comment #2)
> We've been hitting a bug in buildroot with an application(apcupsd) that
> links against libsupc++.a directly.
Maybe I missed it, but I don't see the linker co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96647
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654
Bug ID: 96654
Summary: Failure to optimize vectorized conversion to `int`
with AVX
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #5 from James Hilliard ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to James Hilliard from comment #2)
> > We've been hitting a bug in buildroot with an application(apcupsd) that
> > links against libsupc++.a directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #12 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #11)
> > Standard says that if:
> > std::is_constructible_v
> > then
> > std::is_constructible_v, Foo&&>
>
> Where does it say that?
>
> The fact a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96633
--- Comment #2 from Alexander Monakov ---
Martin added me to CC so I assume he wants me to chime in.
First of all, I find Nathan's behavior in that gcc@ thread distasteful at best
(but if you ask me, such responses are simply more harm than good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96655
Bug ID: 96655
Summary: [OOP] CLASS dummy arguments: Bogus "Duplicate OPTIONAL
attribute specified"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: reje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96656
Bug ID: 96656
Summary: Segmentation fault with make_friend_class
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #6 from Jonathan Wakely ---
(In reply to James Hilliard from comment #5)
> That might be somewhere here:
> http://autobuild.buildroot.org/results/3be/
> 3bedf404de0ea42ee3ba624cded65d310a847af9/apcupsd-3.14.14/config.log
No, I meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
Bug ID: 96657
Summary: libsupc++.a missing required functions from
src/c++98/atomicity.cc when atomic builtins are not
supported
Product: gcc
Version: 9.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #7 from James Hilliard ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to James Hilliard from comment #5)
> > That might be somewhere here:
> > http://autobuild.buildroot.org/results/3be/
> > 3bedf404de0ea42ee3ba624cded6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616
David Malcolm changed:
What|Removed |Added
Summary|Many new analyzer failures |pr93032-mztools.c
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #13 from Jonathan Wakely ---
(In reply to m.cencora from comment #12)
> So unless I am missing something, I see no escape hatch for making such
> constructor ill-formed for some types.
Consider:
#include
struct X
{
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96641
--- Comment #1 from Arseny Solokha ---
A C++ testcase, for that matter.
struct uh {
virtual void
sx ();
};
struct iz : uh {
virtual void
sx ()
{
sx ();
}
};
void
a2 ()
{
iz ().sx ();
}
% gcc-11.0.0 -fanalyzer -c dmkwon0d.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658
Bug ID: 96658
Summary: Unhelpful -Wstrict-overflow warning from
std::push_heap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
--- Comment #2 from James Hilliard ---
(In reply to Jonathan Wakely from comment #1)
> I think r244051 caused libsupc++.a to depend on libstdc++.so for targets
> that don't support lock-free atomics for int.
Yeah, the current workaround we came
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #14 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to m.cencora from comment #12)
> > So unless I am missing something, I see no escape hatch for making such
> > constructor ill-formed fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
--- Comment #3 from Jonathan Wakely ---
Yes, I think that's what we need to do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #15 from Jonathan Wakely ---
(In reply to m.cencora from comment #14)
> Whether Bar is empty class or not is irrelevant for this bug.
No it isn't. Your examples already work for tuples of non-empty classes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96630
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387
cents2823 at yahoo dot co.jp changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|std::variant defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #2 from Sergey ---
(In reply to Jonathan Wakely from comment #1)
> This is not a bug in std::variant:
>
>
> template
> struct bool_constant
> {
> static constexpr bool value = B;
> using type = bool_constant;
> };
>
> using tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9
commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9
commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9
commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9
commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #3 from Jonathan Wakely ---
It doesn't compile the code in comment 1. That code doesn't use any standard
library components, so it doesn't make any difference whether you use libc++ or
not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96639
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2020-08-17
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536
--- Comment #6 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #1)
> I'm testing patch like
>
>emit_insn ((word_mode == SImode)
> ? gen_incsspsi (reg_255)
> : gen_incsspdi (reg_255));
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #4 from Jonathan Wakely ---
And libc++'s std::variant is still affected by the same issue, but instead of
the default constructor being deleted it just has the wrong exception
specification:
#include
void testVarStruct()
{
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #17 from m.cencora at gmail dot com ---
Ah, I see. I was under the impression, that tuple elements were always stored
as base classes, but now I see that it is only the case if element type is
empty non-final class.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96659
Bug ID: 96659
Summary: error: cast from 'const ana::region*' to 'long int'
loses precision in store.h
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
David Malcolm changed:
What|Removed |Added
CC||trass3r at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96659
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #4 from Andrew Pinski ---
Do we ever transverse the hashtable that use symbolic_binding? If so using the
pointer value should almost never use really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #5 from David Malcolm ---
(In reply to Andrew Pinski from comment #4)
> Do we ever transverse the hashtable that use symbolic_binding? If so using
> the pointer value should almost never use really.
Andrew: sorry, I'm having difficu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #6 from Andrew Pinski ---
(In reply to David Malcolm from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > Do we ever transverse the hashtable that use symbolic_binding? If so using
> > the pointer value should almost ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #7 from David Malcolm ---
(In reply to Andrew Pinski from comment #6)
> What I mean is if you ever traversing a hashtable, the hash should not use
> the value of a pointer because it could change between runs.
Thanks.
Unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96634
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #8 from Andrew Pinski ---
(In reply to David Malcolm from comment #7)
> There are a few places I'm hashing based on trees, for constants and types.
> Is there a good way to hash those? (avoiding pointer values)
Maybe iterative_hash_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96660
Bug ID: 96660
Summary: [11 regression] ICE and many failures in
gcc.dg/analyzer/data-model-1.c after r11-2708
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256
Andrew Pinski changed:
What|Removed |Added
CC||mikulas at artax dot
karlin.mff.cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96649
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606
--- Comment #3 from Andrew Pinski ---
(In reply to RyuaNerin from comment #2)
> Unsigned long int is 64bit integer in x64.
Or rather unsigned long on x86 Linux is 64 bits while on x86 Windows, it is
32bits.
There is no bug with GCC here still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661
Bug ID: 96661
Summary: configure:16984: error: unsupported system, cannot
find Fortran int kind=16
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96662
Bug ID: 96662
Summary: s390x uses clc taking variable execution time in
crypto code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
--- Comment #12 from Marek Polacek ---
(In reply to Volker Reichelt from comment #11)
> Hi Marek, any news on this one? It's three months now...
> Or should I file a new bug for the regression on trunk?
No news yet. I've been largely away from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> I thought that this might be a good candidate for frontend fix.
> Similar to thomas's frontend optimizations except except the
> transformation is always do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445
Alexander Karzhenkov changed:
What|Removed |Added
CC||karzh at mail dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661
--- Comment #1 from Tobias Burnus ---
(In reply to John David Anglin from comment #0)
> Guess this is because target doesn't support int128.
For "omp depend", the OpenMP spec requires that an integer type is used – and
the libgomp implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661
--- Comment #2 from dave.anglin at bell dot net ---
On 2020-08-17 2:10 p.m., burnus at gcc dot gnu.org wrote:
> I do not see an easy way out; we had the same issue before with GCN and there
> the solution was to add support for int128, cf. PR 9630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:35c5f8fb432c8e68af68ab48c8d3107e7839775e
commit r11-2723-g35c5f8fb432c8e68af68ab48c8d3107e7839775e
Author: David Malcolm
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96639
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:42c5ae5d7f0ad89b75d93c497fe44b6c66da7e76
commit r11-2724-g42c5ae5d7f0ad89b75d93c497fe44b6c66da7e76
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96644
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:b00a83047574eb6f8d1e670ad439609125873506
commit r11-2725-gb00a83047574eb6f8d1e670ad439609125873506
Author: David Malcolm
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #6 from Steve Kargl ---
On Mon, Aug 17, 2020 at 06:03:31PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
>
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96644
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96639
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642
David Malcolm changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #6)
> To fix, the above, you'll need to look at iresolve.c
>
> static void
> gfc_resolve_minmax (const char *name, gfc_expr *f, gfc_actual_arglist *args)
> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96660
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96663
Bug ID: 96663
Summary: Composite type default 'Read attribute does not
perform validity checking for defaulted components
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96651
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #8 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-August/054884.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #9 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-08-17
Keywords|
1 - 100 of 128 matches
Mail list logo
