https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97748
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97748
--- Comment #2 from Jakub Jelinek ---
Untested WIP patch, though C++ FE needs some extra work:
--- gcc/c-family/c-common.h.jj 2020-11-03 11:15:07.170681001 +0100
+++ gcc/c-family/c-common.h 2020-11-07 09:37:48.597233063 +0100
@@ -1362,7 +136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97750
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #15 from Jakub Jelinek ---
I plan to work on this early in stage3.
And we really shouldn't use any tables, GCC should figure it all out.
So, for double-word modulo by constant that would be expanded using a libcall,
go for x from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759
--- Comment #5 from Jakub Jelinek ---
Unfortunately we don't TER calls, so the expander doesn't see POPCOUNT (x) == 1
or POPCOUNT (x) <= 1
and the isel pass seems to be (at least so far) extremely vector specific;
another option is do it in match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #4 from Jakub Jelinek ---
I disagree with that resolution, expanding it as a bit test is certainly better
and shorter too.
And it seems even switchconv pass says that it is preferrable to expand it as
bit-test, but during expansion it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764
--- Comment #2 from Jakub Jelinek ---
Created attachment 49525
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49525&action=edit
gcc11-pr97764.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
Bug ID: 97768
Summary: [10/11 Regression] 32-bit f951 ICE on code from
OpenMolcas
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
--- Comment #1 from Jakub Jelinek ---
Seems this is only in the pretty-printing for message that would be printed if
there was an error later on (which there is not).
So I guess it really doesn't matter that much what exactly it prints, but it
sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
--- Comment #2 from Jakub Jelinek ---
If in the testcase I change the penultimate line to:
l = 32 .in. to_upper(str)
so that an error is emitted, the 64-bit little-endian f951 emits:
Error: Operands of user operator ‘in’ at (1) are INTEGER(4)/C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
Jakub Jelinek changed:
What|Removed |Added
CC||markeggleston at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
--- Comment #4 from Jakub Jelinek ---
Or the length could be e.g. local variable:
subroutine baz (lens)
use fortran_strings, only : to_upper, operator(.in.)
integer :: lens
character(len=lens) str
logical l
str = ''
l = 32 .in. to_upp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
--- Comment #6 from Jakub Jelinek ---
I'd have thought doing it inside of
if (ex->ts.u.cl && ex->ts.u.cl->length)
conditional and testing for ex->ts.u.cl->length->expr_type instead.
Plus for the CHARACTER case, it doesn't need to use buffer and c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
--- Comment #7 from Jakub Jelinek ---
Created attachment 49529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49529&action=edit
gcc11-pr97768.patch
More complete (but still untested) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97776
--- Comment #1 from Jakub Jelinek ---
As p is array of pointers, if it was say p[i:2][0:C] it would be
non-contiguous, but in this particular case, while such array sections are
blurry (because
the array section describes the p[i][0], p[i][1] etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97771
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97771
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97793
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97804
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97812
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97812
--- Comment #5 from Jakub Jelinek ---
Can you link with -O2 -flto -save-temps -fdump-tree-optimized
and attach your optimized dumps, such that we can find out if it is a problem
during gimple or some target specific bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
--- Comment #14 from Jakub Jelinek ---
So dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672#c12 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91370
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 91370, which changed state.
Bug 91370 Summary: Implement P1041R4 and P1139R2: Stronger Unicode requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91370
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
--- Comment #6 from Jakub Jelinek ---
Created attachment 49565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49565&action=edit
gcc11-pr88101-wip.patch
Fixed/updated patch that includes first testcase and passes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
Jakub Jelinek changed:
What|Removed |Added
Attachment #49563|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
Jakub Jelinek changed:
What|Removed |Added
Attachment #49567|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #11 from Jakub Jelinek ---
We usually don't backport optimization improvements, even if they fix
regressions, to release branches. There are quite high risks involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
--- Comment #2 from Jakub Jelinek ---
With r11-1967-g5acef69f9d3d9f3c537b5e5157519edf02f86c4d actually.
The version you've mentioned started (properly) rejecting it, this wasn't valid
in OpenMP 4.5, but is valid in 5.0 and for GCC11 the support h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #12 from Jakub Jelinek ---
I agree we should just rename default_is_empty_type to is_empty_type, export
it, declare in tree.h and use it instead that complicated test. TYPE_EMPTY_P
isn't something tree-ssa-uninit.c should care about,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
--- Comment #3 from Jakub Jelinek ---
Created attachment 49576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49576&action=edit
gcc11-pr97862.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
--- Comment #8 from Jakub Jelinek ---
Well, so one enhancement request would be for va_list fields don't warn about
the internal fields, but warn about use of uninitialized va_list itself.
And the second thing is if the
if (tail)
va_start (ap,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
--- Comment #9 from Jakub Jelinek ---
That said, can't reproduce with simplified:
void
foo (char *str, char *tail, ...)
{
__builtin_va_list ap;
if (tail)
__builtin_va_start (ap, tail);
for (int first = 1; str; first = 0)
{
*st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
Summary|wrong code at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
--- Comment #2 from Jakub Jelinek ---
The comments in that commit look incorrect btw,
// if a & b >=0 , then a >= 0.
should have been
// if a % b >=0 , then a >= 0.
(ditto the other one).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
--- Comment #3 from Jakub Jelinek ---
And I think the commit doesn't implement what Bruno wrote.
In particular, it was
b >= 0 && a % b > 0 implies a >= 0
b >= 0 && a % b < 0 implies a <= 0
while the patch implemented
b >= 0 && a % b >= 0 implies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
--- Comment #7 from Jakub Jelinek ---
Actually still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #4 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #3)
> I was going to commit the following but I'll leave it to you.
>
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index d348e39c27a..95cf9e4cb00 100644
> --- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #6 from Jakub Jelinek ---
As I said, [0] is not a VLA bound.
And we don't record anything for constant bounds (even if they are in the
middle).
So perhaps:
/* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97506
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #8 from Jakub Jelinek ---
If you design your own programming language, you can define it whatever way you
want, but for C and C++ it is well defined how the compiler must behave in
these cases, that -2147483648 are two separate tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #9 from Jakub Jelinek ---
Created attachment 49595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49595&action=edit
gcc11-pr91029-2.patch
Untested patch implementing the op1 rules. Dunno what to do for op2, one needs
to create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909
Bug ID: 97909
Summary: expr_not_equal_to (mainly in match.pd) vs. ranger
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97908
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #2 from Jakub Jelinek ---
Please see https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559605.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Jakub Jelinek changed:
What|Removed |Added
Attachment #49595|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #5 from Jakub Jelinek ---
Even that should be fixed by the patch I've posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96849
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918
--- Comment #5 from Jakub Jelinek ---
cvise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #7 from Jakub Jelinek ---
Should be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96929
--- Comment #2 from Jakub Jelinek ---
Created attachment 49603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49603&action=edit
gcc11-pr96929.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918
--- Comment #6 from Jakub Jelinek ---
Reduced testcase (-g -std=c++17 -O1 -flto):
namespace N {
template
bool c;
}
namespace {
class A {};
class B {};
using D = class C {};
class E {};
}
namespace O::P::Q {
struct F {};
}
namespace O::R {
te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-reduction |
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95853
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918
--- Comment #10 from Jakub Jelinek ---
For debug/ tests I guess it isn't really used, just documents that the testcase
is valid C++11 or later, because debug/ tests iterate over various debug
options rather than C++ standard options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918
--- Comment #11 from Jakub Jelinek ---
And the default is -std=gnu++17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
Bug ID: 97933
Summary: [11 Regression] Bootstrap failure on s390x-linux
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
--- Comment #2 from Jakub Jelinek ---
Created attachment 49610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49610&action=edit
ipa-sra.ii.xz
unxz ipa-sra.ii.xz
./cc1plus -quiet -fno-PIE -O2 -fno-checking -fno-exceptions -fno-rtti
-fasynch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
901 - 1000 of 12376 matches
Mail list logo
