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=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=89750
--- Comment #2 from Hongtao.liu ---
Created attachment 46307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46307=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=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
> >
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=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=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=gcc=rev
Log:
2019-05-06 Steven G. Kargl
PR fortran/90290
* match.c
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
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=gcc=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=gcc=rev
Log:
PR tree-optimization/88709
PR tree-optimization/90271
*
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:V4SI
REG_DEAD r130:V4SI
REG_DEAD r127:V4SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Segher
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=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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
--- Comment #11 from Andrew Pinski ---
Changing DenseMapBase's
ValueT [](const KeyT )
To:
{
const KeyT Key = t;
return FindAndConstruct(Key).second;
}
This will cause the warning to go away.
This comes from:
RemapSwizzle[i] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
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
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=90323
Bill Schmidt changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90367
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
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
--- 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
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=edit
preprocessed source
Please see attachement.
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=90349
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See
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=78010
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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=90323
--- Comment #2 from Shawn Landden ---
Created attachment 46305
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46305=edit
test case.
These two functions should produce identical code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc |powerpc*-*-*
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=90366
Roman Lebedev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
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=90347
--- Comment #2 from Marek Polacek ---
Caused by -fsanitize=null.
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=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=gcc=rev
Log:
PR c++/90265 - ICE with generic lambda.
* pt.c
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=gcc=rev
Log:
gcc/ChangeLog:
2019-05-06 Kelvin Nilsen
PR target/89424
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=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=gcc=rev
Log:
PR c++/90265 - ICE with generic lambda.
* pt.c
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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
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=edit
modified test case (file 1 of 2)
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=edit
modified test case (file 2 of 2)
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
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
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=90173
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=gcc=rev
Log:
/cp
2019-05-06 Paolo Carlini
PR c++/90173
* decl.c
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.
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 #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 |
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=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=gcc=rev
Log:
PR target/89221
* config.gcc (i[34567]86-*-*, x86_64-*-*):
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=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
Bug ID: 90367
Summary: Spurious warning array subscript is above array bounds
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477
--- Comment #5 from Martin Sebor ---
(In reply to Alexandre Ganea from comment #4)
The test case has been reduced a little too far -- it reads an uninitialized
variable:
for (unsigned i;; i++)
for (; i;)
if (j[i] == j[0])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #12 from Matt Thompson ---
(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 Matt Thompson from comment #8)
>
>
> > I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #10 from Than McIntosh ---
Update: it looks like we are not out of the woods quite yet -- I am seeing some
similar behavior farther into the build. I will try to produce another reduced
test case (this one is proving more difficult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
Roman Lebedev changed:
What|Removed |Added
See Also||https://bugs.llvm.org/show_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312
--- Comment #7 from Martin Liška ---
Author: marxin
Date: Mon May 6 14:01:45 2019
New Revision: 270912
URL: https://gcc.gnu.org/viewcvs?rev=270912=gcc=rev
Log:
Backport r270899
2019-05-06 Martin Liska
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90366
Bug ID: 90366
Summary: OpenMP default(none) - std::cerr is diagnosed as "not
specified in enclosing 'parallel'", unlike clang
Product: gcc
Version: 9.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
--- Comment #1 from Roman Lebedev ---
Forgot to add https://godbolt.org/z/CeVhEu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
Bug ID: 90365
Summary: OpenMP default(none) + schedule(dynamic, variable) -
difference with clang
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90358, which changed state.
Bug 90358 Summary: [10 Regression] 526.blender_r train run does not finish
after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Mon May 6 13:40:00 2019
New Revision: 270911
URL: https://gcc.gnu.org/viewcvs?rev=270911=gcc=rev
Log:
2019-05-06 Richard Biener
PR tree-optimization/90358
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig ---
Hi Tomas,
> I understand the compiler may not know and typically does not whether the
> called function accepts "character(len=1)" or "character(len=*)", so it may
> have to pass the 1. But the situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477
Alexandre Ganea changed:
What|Removed |Added
CC||alexandre.ganea at ubisoft dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
--- Comment #1 from Richard Biener ---
I can link correctly with -D_GLIBCXX_USE_CXX11_ABI=0 have yet to check a build
with the gcc4 ABI as default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90277
--- Comment #4 from Jonathan Wakely ---
(In reply to François Dumont from comment #3)
> As stated in my message this patch can be consider as a fix for this PR as
> it reserve buckets for 11 buckets so iterators are not invalidated during
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364
Bug ID: 90364
Summary: 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at
-Ofast and native march/mtune
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88828
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Mon May 6 12:43:30 2019
New Revision: 270908
URL: https://gcc.gnu.org/viewcvs?rev=270908=gcc=rev
Log:
2019-05-06 Richard Biener
PR tree-optimization/88828
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89656
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Mon May 6 12:40:18 2019
New Revision: 270907
URL: https://gcc.gnu.org/viewcvs?rev=270907=gcc=rev
Log:
2019-05-06 Richard Biener
PR bootstrap/90359
Backport from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362
--- Comment #2 from Stafford Horne ---
Originally reported by Richard Selvaggi.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #14 from rguenther at suse dot de ---
On Mon, 6 May 2019, tomas.kalibera at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
>
> --- Comment #13 from Tomas Kalibera ---
> I understand the compiler may not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Stafford Horne changed:
What|Removed |Added
Target||or1k
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Bug ID: 90363
Summary: or1k: Extra mask insn after load from memory
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Mon May 6 12:40:18 2019
New Revision: 270907
URL: https://gcc.gnu.org/viewcvs?rev=270907=gcc=rev
Log:
2019-05-06 Richard Biener
PR bootstrap/90359
Backport from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89655
--- Comment #9 from Richard Biener ---
Author: rguenth
Date: Mon May 6 12:40:18 2019
New Revision: 270907
URL: https://gcc.gnu.org/viewcvs?rev=270907=gcc=rev
Log:
2019-05-06 Richard Biener
PR bootstrap/90359
Backport from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Mon May 6 12:38:35 2019
New Revision: 270906
URL: https://gcc.gnu.org/viewcvs?rev=270906=gcc=rev
Log:
2019-05-06 Richard Biener
PR tree-optimization/90328
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
Richard Biener changed:
What|Removed |Added
Known to work||10.0
Summary|[7/8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362
Stafford Horne changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362
Stafford Horne changed:
What|Removed |Added
Target||or1k
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362
Bug ID: 90362
Summary: or1k: Soft divide does not work correctly
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #11 from Iain Sandoe ---
(In reply to Matt Thompson from comment #10)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to Matt Thompson from comment #8)
> I don't usually remove it from my path because it had never caused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
Bug ID: 90361
Summary: Undefined symbols in libstdc++ when building with
--with-default-libstdcxx-abi=gcc4-compatible
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #10 from Matt Thompson ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Matt Thompson from comment #8)
> >
> > I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at
> > the same point in make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #13 from Tomas Kalibera ---
I understand the compiler may not know and typically does not whether the
called function accepts "character(len=1)" or "character(len=*)", so it may
have to pass the 1. But the situation where I suggest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90346
Martin Liška changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #9 from Iain Sandoe ---
(In reply to Matt Thompson from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Matt Thompson from comment #6)
> > > (In reply to Iain Sandoe from comment #5)
> > > > (In reply to Matt
1 - 100 of 162 matches
Mail list logo
