https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
Bug ID: 90367
Summary: Spurious warning array subscript is above array bounds
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90368
Bug ID: 90368
Summary: gdc testsuite uses "ln -s . gdc.test", which doesn't
work on msys2
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #1 from Andrew Pinski ---
I think you reduced it too much. Because with the reduction the warning is
correct. j[i] will be accessed above the array bounds. Though j[0] is always
equal to j[0].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 6 14:58:57 2019
New Revision: 270914
URL: https://gcc.gnu.org/viewcvs?rev=270914&root=gcc&view=rev
Log:
PR target/89221
* config.gcc (i[34567]86-*-*, x86_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #2 from Alexandre Ganea ---
Slighly modified version with zero-init variables still shows the warning:
https://godbolt.org/z/Mht3uF
Andrew: you say "I think you reduced it too much". I simply used "gcc file.cpp
-O3 -Warray-bounds | g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #3 from Viktor Ostashevskyi ---
(In reply to Jonathan Wakely from comment #2)
> I haven't checked a build with that option for ages, so I can easily believe
> I've broken it. I'll take a look tomorrow.
It worked well in GCC 8.2.0 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #3 from Alexandre Ganea ---
Another strange thing, if I change 'SDValue NewBldVec[4];' to 'SDValue
NewBldVec[14];' in the code where the issue occurs, the warning goes away. If I
set it to 13 or less, the warning is still there.
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173
--- Comment #7 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon May 6 15:23:37 2019
New Revision: 270915
URL: https://gcc.gnu.org/viewcvs?rev=270915&root=gcc&view=rev
Log:
/cp
2019-05-06 Paolo Carlini
PR c++/90173
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #6 from Jakub Jelinek ---
We'd probably need to change decl_to_stack_part from hash_map to
hash_map that would just map DECL_UIDs which have
DECL_RTL_IF_SET equal to pc_rtx to the partition numbers, rather than from
decl, or have some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #13 from Iain Sandoe ---
(In reply to Matt Thompson from comment #12)
> (In reply to Iain Sandoe from comment #11)
> > (In reply to Matt Thompson from comment #10)
> > > (In reply to Iain Sandoe from comment #9)
> > > > (In reply to M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #12 from Than McIntosh ---
Created attachment 46304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46304&action=edit
modified test case (file 2 of 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #11 from Than McIntosh ---
Created attachment 46303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46303&action=edit
modified test case (file 1 of 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #13 from Than McIntosh ---
I've made a stab at revising the test case to try to trigger the long compile
time that I'm still seeing the real application code. Still not quite there
yet (revised testcase takes maybe a minute to compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #7 from Michael Matz ---
No, this is not a problem in the stack slot sharing algorithm, but rather in
the input. As presented to expand, and only showing the important parts,
and reordering some BBs to make the flow more obvious:
;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Mon May 6 16:56:39 2019
New Revision: 270917
URL: https://gcc.gnu.org/viewcvs?rev=270917&root=gcc&view=rev
Log:
PR c++/90265 - ICE with generic lambda.
* pt.c (tsubst_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
--- Comment #6 from Jakub Jelinek ---
Related to PR90172.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89424
--- Comment #1 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon May 6 17:00:46 2019
New Revision: 270918
URL: https://gcc.gnu.org/viewcvs?rev=270918&root=gcc&view=rev
Log:
gcc/ChangeLog:
2019-05-06 Kelvin Nilsen
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Mon May 6 17:08:08 2019
New Revision: 270919
URL: https://gcc.gnu.org/viewcvs?rev=270919&root=gcc&view=rev
Log:
PR c++/90265 - ICE with generic lambda.
* pt.c (tsubst_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90347
--- Comment #2 from Marek Polacek ---
Caused by -fsanitize=null.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90347
--- Comment #3 from Marek Polacek ---
ubsan_maybe_instrument_reference_or_call sets
flag_delete_null_pointer_checks = 1;
and then we call tree_single_nonzero_warnv_p -> maybe_nonzero_address ->
symtab_node::nonzero_address
1979 if (!DECL_WEAK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90366
Roman Lebedev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90369
Bug ID: 90369
Summary: error: could not unlink output file
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc |powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #2 from Shawn Landden ---
Created attachment 46305
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46305&action=edit
test case.
These two functions should produce identical code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #4 from Shawn Landden ---
that was compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #3 from Shawn Landden ---
Instead:
.globl without_sel
.type without_sel, @function
without_sel:
.LFB0:
.cfi_startproc
xxlxor 36,34,36
xxland 36,36,35
xxlxor 34,34,36
blr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90349
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #4 from Andrew Pinski ---
Can you attach the original preprocessed source?
the original case does look like it looks like a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #5 from Alexandre Ganea ---
Created attachment 46306
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46306&action=edit
preprocessed source
Please see attachement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #6 from Alexandre Ganea ---
...and the command-line:
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Target/AMDGPU
-I/mnt/f/svn/llvm/lib/Target/AMDGPU -Iinclu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #7 from Alexandre Ganea ---
I used the following GCC version for preprocessing/compiling:
$ /usr/bin/c++ --version
c++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
Bill Schmidt changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
Andrew Pinski changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #10 from Andrew Pinski ---
(In reply to Martin Sebor from comment #8)
> This looks very similar to bug 87072. The C test case below is diagnosed by
> GCC 9, 8, and 7.
More to the point the line number of this reduced testcase is cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #11 from Andrew Pinski ---
Changing DenseMapBase's
ValueT &operator[](const KeyT &t)
To:
{
const KeyT Key = t;
return FindAndConstruct(Key).second;
}
This will cause the warning to go away.
This comes from:
RemapSwizz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #12 from Andrew Pinski ---
I doubt there is anything GCC can do it here in a reasonable fashion.
I will let someone else reduce the testcase in a reasonable way that shows the
problem. Most likely GCC decided that FindAndConstruct sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #13 from Martin Sebor ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Martin Sebor from comment #8)
> > This looks very similar to bug 87072. The C test case below is diagnosed by
> > GCC 9, 8, and 7.
> >
> > $ cat a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #9 from Fredrik Hederstierna
---
I did the test suggested, the results was as follows
A. gcc-8.2.0
B. gcc-9.1.0
C. gcc-9.1.0 -fno-jump-tables
D. gcc-9.1.0 patched "max_ratio_for_size = 2"
Overall CSiBE was
A: 2 413 510 bytes
B: 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
--- Comment #2 from Stafford Horne ---
(In reply to Segher Boessenkool from comment #1)
> Trying 13 -> 14:
>13: r51:QI=[r50:SI+low(`*.LANCHOR0')]
> REG_DEAD r50:SI
>14: r43:SI=zero_extend(r51:QI)
> REG_DEAD r51:QI
> Failed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Segher Boes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #7 from Segher Boessenkool ---
From the combine dump of without_sel:
Trying 8, 9 -> 10:
8: r127:V4SI=r124:V4SI^r131:V4SI
REG_DEAD r131:V4SI
9: r122:V4SI=r127:V4SI&r130:V4SI
REG_DEAD r130:V4SI
REG_DEAD r127:V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Mon May 6 21:50:14 2019
New Revision: 270924
URL: https://gcc.gnu.org/viewcvs?rev=270924&root=gcc&view=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Mon May 6 21:50:14 2019
New Revision: 270924
URL: https://gcc.gnu.org/viewcvs?rev=270924&root=gcc&view=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #10 from Fredrik Hederstierna
---
Tested also gcc-9.1.0 "max_ratio_for_size = 1" just out of curiosity
results was similar compared to gcc-8.2.0:
Overall CSiBE was
2 417 695 bytes (+4185 bytes, +0.17%)
Example file CSiBE "vsprint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 6 23:24:32 2019
New Revision: 270928
URL: https://gcc.gnu.org/viewcvs?rev=270928&root=gcc&view=rev
Log:
2019-05-06 Steven G. Kargl
PR fortran/90290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
Bug ID: 90370
Summary: Does 0 correspond to a POSIX errno value for
std::system_category?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
--- Comment #1 from Jonathan Wakely ---
This is the cause of the issue described in 4.10 of https://wg21.link/p0824r1
(but the presentation there is wrong: the comparison semantics are clearly
defined, the implementation divergence is in whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #17 from Steve Kargl ---
On Mon, May 06, 2019 at 04:40:08PM +, kargl at gcc dot gnu.org wrote:
> > Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
> > I would suggest that we make -fno-optimize-sibling-calls
> > t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89750
--- Comment #2 from Hongtao.liu ---
Created attachment 46307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46307&action=edit
Fix-ix86_expand_sse_comi_round.patch
Fix ix86_expand_sse_comi_round and add runtime tests for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86444
--- Comment #1 from Hongtao.liu ---
Created attachment 46308
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46308&action=edit
Fix-ix86_expand_sse_comi_round.patch
Fix ix86_expand_sse_comi_round and add runtime tests for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371
Bug ID: 90371
Summary: gcc with newlib do not support std::mutex, std::
thread
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #18 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #15)
> Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
> I would suggest that we make -fno-optimize-sibling-calls
> the default on these branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371
--- Comment #2 from jojo ---
Thanks for your reply:)
(In reply to Andrew Pinski from comment #1)
> For your target, needs to fully support pthreads and a few other things.
> You can look at what is needed via libstdc++/configure.ac and related f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #19 from rguenther at suse dot de ---
On Tue, 7 May 2019, jb at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
>
> --- Comment #18 from Janne Blomqvist ---
> (In reply to Thomas Koenig from comment #15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90372
Bug ID: 90372
Summary: [x64][missed optimization] pushes unused r12 onto
stack on unique_ptr use
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #11 from Richard Biener ---
(In reply to Martin Liška from comment #6)
> I'm curious how much can save following patch:
>
> diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h
> index b3bc4b9ddf7..904827fa040 100
101 - 167 of 167 matches
Mail list logo
