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=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=60972
Eric Gallager changed:
What|Removed |Added
CC||jason at redhat dot com,
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=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=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=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=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=89663
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
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=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=89664
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=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=89667
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=89665
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=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=89669
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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
--- 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
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=89668
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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 #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=89661
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
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=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=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=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=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=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=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=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 #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=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 #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=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 #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
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also|
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=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=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=89651
Jakub Jelinek changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #9 from Jakub Jelinek ---
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=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=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=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
--- 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=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=89644
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Blocks|
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=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=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=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 #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
--- 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=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=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=87644
Fritz Reese changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
101 - 172 of 172 matches
Mail list logo
