https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
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, ic
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 in
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: t
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&root=gcc&view=rev
Log:
PR c++/61339 - add warning for mismatch between struct and class
gcc/c-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
Status|UNCONFI
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 c
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&root=gcc&view=rev
Log:
PR c++/79592 - missing explanation of invalid constexpr.
We changed month
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&root=gcc&view=rev
Log:
PR c++/92576 - redeclaration of variable template.
The variable t
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 0
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()
> n
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&root=gcc&view=rev
Log:
PR c++/59655
* pt.c (push_tinst_level_loc): If limit_bad_t
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 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
Andrew Pinski changed:
What|Removed |Added
Depends on||92979
--- Comment #6 from Andrew Pinski
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
Ke
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|
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 t
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&root=gcc&view=rev
Log:
PR target/92841
* config/i386/i386.md (@stack_protect_set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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
> significan
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
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 o
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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92977
Bug ID: 92977
Summary: ICE in gfc_trans_omp_atomic, at
fortran/trans-openmp.c:3526
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
Bug ID: 92976
Summary: [8/9/10 Regression] ICE in trans_associate_var, at
fortran/trans-stmt.c:1963
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92975
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92975
Bug ID: 92975
Summary: ICE in convert_nonlocal_reference_op, in
tree-nested.c:1065
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
--- Comment #6 from G. Steinmetz ---
Compiles these slightly modified cases :
$ cat z2.f90 # no allocatable a
program p
type t
integer :: a
end type
type t2
type(t) :: b
end type
type t3
type(t2) :: c
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #5 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #12 from Tobias Burnus ---
(In reply to Martin Sebor from comment #11)
> Because like all flow-based warnings, -Wstringop-overflow has a non-zero rate
> of false positives
I think false positive is okay fine, but the question is whet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #11 from Martin Sebor ---
Here's some history. When -Wstringop-overflow was introduced it only detected
overflow in calls to C functions like strcpy or memcpy that aren't normally
seen in FORTRAN programs. It provided a means of con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92974
Bug ID: 92974
Summary: diagnostic missing source information
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #30 from Pedro Alves ---
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
to go?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
--- Comment #4 from Alexander Cherepanov ---
(In reply to Richard Biener from comment #3)
> shows we're constant folding this to
>
> __builtin_printf ("%lf\n",
> 3.36210314311209350626267781732175260259807934484647124011e-4932);
Unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92968
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92973
--- Comment #1 from Jakub Jelinek ---
Created attachment 47517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47517&action=edit
gcc10-pr92973.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92973
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92973
Bug ID: 92973
Summary: [10 Regression] Silently accepting defaulted
comparison operators in C++11 .. 17
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92966
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92965
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
Andrew Stubbs changed:
What|Removed |Added
Priority|P3 |P5
Severity|critical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #17 from Martin Jambor ---
If we really decide to fix this in SRA, i can be done (after the previous
patches in the series are in) with something like
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01185.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #15 from Jakub Jelinek ---
As for __builtin_*_eq, we could have some analysis that looks at accesses from
the same base, and e.g. if there is struct S { char name[16]; int whatever; }
and
we see strcmp (p->name, ...) and p->whatever s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92706
--- Comment #4 from Martin Jambor ---
I have proposed the following patches to address this on trunk. The
testcase from comment #3 can be fixed with
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01183.html
The original testcase however needs al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92971
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #10 from Jakub Jelinek ---
Make that:
struct T { char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p; };
struct S { long l; struct T t; };
void
foo (long l, struct S *p)
{
p->l = l;
p->t.a = 2;
p->t.b = 3;
p->t.c = 4;
p->t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #9 from Jakub Jelinek ---
To reproduce, one can use e.g.
./gfortran -B ./ -fopenmp -O3 -flto -flto-partition=1to1 -fno-use-linker-plugin
async_target-2.f90 -fdump-tree-strlen -r -nostdlib -I
../x86_64-pc-linux-gnu/libgomp/ -B ../x86_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92971
--- Comment #2 from Martin Jambor ---
(In reply to fxue from comment #0)
> The variable "values" is defined as static, which makes a questionable side
> effect. History calls will impact result of current call!
>
> for (i = 0; i < count; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92971
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92972
--- Comment #2 from Jakub Jelinek ---
Created attachment 47514
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47514&action=edit
gcc10-pr92972.patch
Untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92972
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92972
Bug ID: 92972
Summary: gcc/lto-wrapper.c:443: identical branches ?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92971
Bug ID: 92971
Summary: Suspicious code in
cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92970
--- Comment #1 from Thomas Schwinge ---
Created attachment 47513
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47513&action=edit
'libgomp.oacc-c-c++-common/pr92970-1.c'
I'm attaching a simple C/C++ test case.
Tobias, will you please prov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92970
Bug ID: 92970
Summary: OpenACC 2.5: 'acc_delete' etc. on non-present data is
a no-op
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949
--- Comment #5 from Andrew Pinski ---
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.
Oh when I was adding bit insert to it, it falls over due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #8 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #7)
> testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing
> 2 bytes into a region of size 1 [-Wstringop-overflow=]
>34 | allocate (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92962
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 17 09:23:59 2019
New Revision: 279455
URL: https://gcc.gnu.org/viewcvs?rev=279455&root=gcc&view=rev
Log:
PR target/92962
* common/config/i386/i386-common.c (proces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #7 from Tobias Burnus ---
Created attachment 47512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47512&action=edit
-fdump-tree-strlen for both host run (async_target-2.f90.180t.strlen1, 1639
lines) and LTO nvptx run (async_targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92969
Bug ID: 92969
Summary: Segmentation fault compiling partial specialization of
auto-deduced member function pointers
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950
--- Comment #3 from Andreas Krebbel ---
Author: krebbel
Date: Tue Dec 17 08:41:54 2019
New Revision: 279454
URL: https://gcc.gnu.org/viewcvs?rev=279454&root=gcc&view=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi
The backend emits 16 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950
--- Comment #2 from Andreas Krebbel ---
Author: krebbel
Date: Tue Dec 17 08:37:26 2019
New Revision: 279453
URL: https://gcc.gnu.org/viewcvs?rev=279453&root=gcc&view=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi
The backend emits 16 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
Thomas Schwinge changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
85 matches
Mail list logo
