https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644
Fritz Reese changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89672
Bug ID: 89672
Summary: NULL pointer check optimized out for the return value
of memchr(NULL, c, 0)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43673
--- Comment #5 from Xiong Hu XS Luo ---
Ben's reply regarding to testing dfp on other targets:
"
> I suggest to test it on a platform where dfp is not supported as well,
At this stage, the patches on the trunk don't identify any targets as
supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43673
--- Comment #4 from Xiong Hu XS Luo ---
Hi, Joseph, recently, I summited a quick fix in
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01949.html for this issue.
Actually this was introduced by the initial patch
https://gcc.gnu.org/ml/gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
--- Comment #6 from Jason Merrill ---
(In reply to Jason Merrill from comment #4)
> The cast is ambiguous
>
> To construct a 'base', we consider the two constructors
>
> 1) base(const base&);
> 2) base(base&&);
>
> for each of them we could co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43673
Xiong Hu XS Luo changed:
What|Removed |Added
CC||joseph at codesourcery dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Tue Mar 12 03:19:22 2019
New Revision: 269602
URL: https://gcc.gnu.org/viewcvs?rev=269602&root=gcc&view=rev
Log:
PR c++/86521 - wrong overload resolution with ref-qualifiers.
Her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
--- Comment #4 from Jason Merrill ---
The cast is ambiguous
To construct a 'base', we consider the two constructors
1) base(const base&);
2) base(base&&);
for each of them we could convert the argument by either
3) operator U () &&
4) operato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89244
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89644
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89650
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2019-03-10 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89671
--- Comment #1 from Hasan ---
The Arch package:
https://www.archlinux.org/packages/community/x86_64/telegram-desktop/
The source of the package: https://github.com/telegramdesktop/tdesktop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
--- Comment #9 from Jürgen Reuter ---
Sorry if that maybe a stupid question but is it wise that close before the new
release to start such a bigger coding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89671
Bug ID: 89671
Summary: Demangling segfault
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #13 from Jörn Engel ---
None of those examples convince me. If you or I know that a zero-argument is
impossible, but the compiler doesn't know, wouldn't that still be UB? And if
the compiler knows, it can remove the branch either wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89655
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89656
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651
Jakub Jelinek changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #9 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Mon Mar 11 22:27:39 2019
New Revision: 269598
URL: https://gcc.gnu.org/viewcvs?rev=269598&root=gcc&view=rev
Log:
PR fortran/89651
* trans-openmp.c (gfc_omp_clause_default_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #12 from Jakub Jelinek ---
(In reply to Jörn Engel from comment #11)
> Out of curiosity, if the only non-broken way to call __builtin_ctz(foo) is
> via "foo ? __builtin_ctz(foo) : 32", why isn't the conditional moved into
> __builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #11 from Jörn Engel ---
I stand corrected. Thank you very much!
Out of curiosity, if the only non-broken way to call __builtin_ctz(foo) is via
"foo ? __builtin_ctz(foo) : 32", why isn't the conditional moved into
__builtin_ctz()? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
--- Comment #8 from Thomas Koenig ---
Created attachment 45946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45946&action=edit
First step towards a patch
Expect quite a few regressions, but this seems to do the
trick for this PR and PR 77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #10 from Andrew Pinski ---
I forgot to list what L15 was:
.L15:
tzcntl %eax, %eax
vzeroupper
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #9 from Andrew Pinski ---
(In reply to Jörn Engel from comment #6)
> True for one, but not the other.
>
> return mask ? __builtin_ctz(mask) : 32;
> 1099: 83 f6 ffxor$0x,%esi
> 109c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #8 from Jörn Engel ---
Updated testcase below fails to remove the branch with my gcc-8.
/*
* usage:
* gcc -std=gnu11 -Wall -Wextra -g -march=core-avx2 -mbmi -fPIC -O3 % &&
./a.out < /dev/zero
*/
#include
#include
#include
#incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61261
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #7 from Jakub Jelinek ---
int
foo (int x)
{
return x ? __builtin_ctz (x) : 32;
}
works without conditionals just fine for me, both in 8.x and trunk, both C and
C++, both -O2 and -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89655
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Mon Mar 11 21:58:43 2019
New Revision: 269597
URL: https://gcc.gnu.org/viewcvs?rev=269597&root=gcc&view=rev
Log:
PR middle-end/89655
PR bootstrap/89656
* vr-values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89656
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Mar 11 21:58:43 2019
New Revision: 269597
URL: https://gcc.gnu.org/viewcvs?rev=269597&root=gcc&view=rev
Log:
PR middle-end/89655
PR bootstrap/89656
* vr-values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #6 from Jörn Engel ---
True for one, but not the other.
return mask ? __builtin_ctz(mask) : 32;
1099: 83 f6 ffxor$0x,%esi
109c: 74 47 je 10e5
109e:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71312
--- Comment #1 from Jonathan Wakely ---
A slightly simpler fix:
--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -34,7 +34,9 @@ namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
__gnu_cxx::__mutex&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89668
--- Comment #4 from Pei JIA ---
I just strictly follow
http://linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html,
and I'm using the following command line:
su nobody -s /bin/bash -c "PATH=$PATH make -k check"
Should I do:
su nobody -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #5 from Jakub Jelinek ---
(In reply to Jörn Engel from comment #4)
> Fair enough. That means the only way to get tzcnt without a conditional is
> by using inline asm.
Of course not.
Either you can use _tzcnt_u32, or you can use x ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89668
--- Comment #3 from Andrew Pinski ---
You can also look at the progress by tail -f gcc.log or gcc.sum if you want.
But yes there are many testcases which causes this to be slow especially if you
are not using -j.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #4 from Jörn Engel ---
Fair enough. That means the only way to get tzcnt without a conditional is by
using inline asm. Annoying, but something I can work with.
Annoying because for CPUs with BMI1, tzcnt is well-defined and I explic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71312
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89668
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89668
--- Comment #1 from Jonathan Wakely ---
(In reply to Pei JIA from comment #0)
> So, my questions are:
>
> Is make[2]: autogen: Command not found an ERROR? Is autogen required?
This seems pretty clearly documented at
https://gcc.gnu.org/inst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #2 from Jörn Engel ---
The input is 32. Does the "undefined-if-zero" thing give gcc license to remove
code depending on the output? If it does, why is the code only removed when
comparing against 31/32, not when comparing against 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
--- Comment #1 from Andrew Pinski ---
__builtin_ctz is undefined if the input is 0 as documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670
Bug ID: 89670
Summary: __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be
<31 ?
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89669
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89669
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Mon Mar 11 20:40:34 2019
New Revision: 269594
URL: https://gcc.gnu.org/viewcvs?rev=269594&root=gcc&view=rev
Log:
PR libbacktrace/89669
* Makefile.am (BUILDTESTS): O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89615
--- Comment #4 from dave.anglin at bell dot net ---
On 2019-03-06 7:26 p.m., redi at gcc dot gnu.org wrote:
> OK, so then maybe something like this:
>
> --- a/libstdc++-v3/include/ext/codecvt_specializations.h
> +++ b/libstdc++-v3/include/ext/code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Summary|[9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89665
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89669
Bug ID: 89669
Summary: /usr/ccs/bin/ld: Unsatisfied symbols:
backtrace_uncompress_zdebug
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89667
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89663
--- Comment #3 from Jakub Jelinek ---
Created attachment 45944
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45944&action=edit
gcc9-pr89663.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89668
Bug ID: 89668
Summary: make[2]: autogen: Command not found
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89667
Bug ID: 89667
Summary: initializers for character string arrays (char *[])
appear to reside in protected storage
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660
--- Comment #2 from Marek Polacek ---
Untested patch:
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -9433,10 +9433,12 @@ maybe_warn_pessimizing_move (tree retval, tree
functype)
}
/* Warn if the move is redundant. It is redundant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89663
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89665
--- Comment #2 from Giacinto Cifelli ---
It mentions the following:
"A parameter in the replacement list, unless preceded by a # or ##
preprocessing token or followed by a ## preprocessing token (see below), is
replaced by the corresponding argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89663
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #3 from Richard Biener ---
(In reply to jos...@codesourcery.com from comment #2)
> On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote:
>
> > where the first result is off. The IL looks like
> >
> > int r = (int) ((long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82608
--- Comment #1 from Martin Sebor ---
A few more test cases:
$ cat z.c && gcc -O2 -S -Wall z.c
int idx_negative (void)
{
int n = 4;
char a[n];
return a[-99]; // -Warray-bounds (since GCC 8)
}
int idx_cst_too_big (void)
{
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651
--- Comment #7 from Jim Feng ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Jim Feng from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > On the other side, the testcase is invalid, because you are summing
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651
--- Comment #6 from Jakub Jelinek ---
(In reply to Jim Feng from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > On the other side, the testcase is invalid, because you are summing
> > uninitialized data. It is like if you did:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68160
Eric Gallager changed:
What|Removed |Added
CC||jason at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60972
Eric Gallager changed:
What|Removed |Added
CC||jason at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651
--- Comment #5 from Jim Feng ---
(In reply to Jakub Jelinek from comment #4)
> On the other side, the testcase is invalid, because you are summing
> uninitialized data. It is like if you did:
> program pr89651
> integer :: n
> real, allocata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82179
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660
--- Comment #1 from Marek Polacek ---
Slightly reduced:
namespace std {
template T &&move(T &&);
}
template struct D {
template D (D x) : k(&x.foo ()) {}
S &foo ();
int *k;
};
D bar ();
struct F {
D baz () {
D f = bar ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89666
--- Comment #2 from John David Anglin ---
Looks like test needs:
/* { dg-require-alias "" } */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89666
--- Comment #1 from John David Anglin ---
Created attachment 45942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45942&action=edit
ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89666
Bug ID: 89666
Summary: FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf
"Unified;" 2
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
--- Comment #4 from Mathias Stearn ---
@Jakub, This code doesn't have either mutable or noexcept, so the "wrong place
in the grammer" issue doesn't apply. That part of the fix seems correct and
useful.
While it seems correct to fix what the c++1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89665
--- Comment #1 from Andrew Pinski ---
The question here is does it match what the C standard says it should be
instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89663
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #2 from joseph at codesourcery dot com ---
On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote:
> where the first result is off. The IL looks like
>
> int r = (int) ((long double) log (p) * (long double) inv_log_of_base);
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89665
Bug ID: 89665
Summary: inconsistent macro expansion
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89654
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89644
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89644
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664
Bug ID: 89664
Summary: [8/9 Regression] ICE in free_bb, at
tree-ssa-math-opts.c:522
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89663
Bug ID: 89663
Summary: ICE in expand_builtin_int_roundingfn_2, at
builtins.c:2831
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662
Bug ID: 89662
Summary: [9 Regression] ICE in contains_struct_check, at
tree.h:3545
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #30 from Jonathan Wakely ---
Created attachment 45940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45940&action=edit
Patch to fix resource_adaptor failures due to max_align_t bugs
Could you please try this patch on Soalris an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651
--- Comment #4 from Jakub Jelinek ---
On the other side, the testcase is invalid, because you are summing
uninitialized data. It is like if you did:
program pr89651
integer :: n
real, allocatable :: t(:)
n = 10
allocate (t(n))
print *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Bug ID: 89661
Summary: FAIL: gfortran.dg/class_61.f90 -O (internal
compiler error)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89460
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89460
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Mon Mar 11 16:28:11 2019
New Revision: 269588
URL: https://gcc.gnu.org/viewcvs?rev=269588&root=gcc&view=rev
Log:
PR libstdc++/89460 Fix Networking TS test failures on HP-UX
Check for av
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
1 - 100 of 172 matches
Mail list logo
