https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #18 from Jakub Jelinek ---
Created attachment 59147
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59147&action=edit
gcc15-pr116738.patch
I think I've managed to make it working. Here it is.
Rest in incremental changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
--- Comment #10 from Jakub Jelinek ---
(In reply to Raffaello Bertini from comment #9)
> More than to fix something,
> it was a suggestion to evolve or add a warning to tell the user that those
> kind of statements are basically like not written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91464
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #3 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #10 from Jakub Jelinek ---
"__builtin_shufflevector instead of __builtin_shuffle for better code
generation"
is certainly not true. Both of the builtins are different and they have their
pros and cons. For the swgl code if it has b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #15 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > Though, unsure about why ieee is used in the name of some of the patterns,
> > my copy of IEEE says that minNum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #13 from Jakub Jelinek ---
Though, unsure about why ieee is used in the name of some of the patterns, my
copy of IEEE says that minNum and maxNum should return the non-NaN operand if
one is NaN and other is not, and unspecified which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #12 from Jakub Jelinek ---
I think the problem is the mixing of four different substitutions in a single
pattern,
in particular round_saeonly and round_saeonly_scalar and mask and mask_scalar.
is from the second,
and
from the firs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #8 from Jakub Jelinek ---
Not needed (in main) in C99 or later, GCC defaults to -std=gnu17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #6 from Jakub Jelinek ---
C testcase with unnecessary clutter removed:
#include
static inline float
clamp (float f)
{
__m128 v = _mm_set_ss (f);
__m128 zero = _mm_setzero_ps ();
__m128 greatest = _mm_set_ss (__FLT_MAX__);
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116636
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression]
|D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116678
--- Comment #3 from Jakub Jelinek ---
Fixed (hopefully) on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] wrong|[12 Regression] wrong code
gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #20 from Jakub Jelinek ---
Fixed for 14.3 too. Not going to backport further I think.
||2024-09-12
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Created attachment 59103
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59103&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104690
--- Comment #6 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #4)
> Couldn't the C front end insert a trap at the end of the function for -O0
> compilations? That would at least diagnose this for unoptimized builds.
> That's wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104690
--- Comment #5 from Jakub Jelinek ---
It would be difficult in all cases. Essentially, the sanitizer would need to
change the ABI of the function to return a pair of normal return type, boolean
flag whether it fell off from the function end wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116636
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=116627
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #
|does not compile|does not compile since
||r15-2331
CC||jakub at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116627
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116159
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at redhat dot com|
--- Comment #5 from Jakub Jelin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116159
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #7 from Jakub Jelinek ---
(In reply to Zdenek Sojka from comment #6)
> Is the -DDEBUG in dg-options correct? I think the testcase won't fail at
> runtime when -DDEBUG is used.
It is not. main body should be just
if (foo (0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116614
--- Comment #7 from Jakub Jelinek ---
Created attachment 59059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59059&action=edit
gcc15-pr116614.patch
Lightly tested updated patch which fixes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116614
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=116614
--- Comment #5 from Jakub Jelinek ---
I've been testing
2024-09-05 Jakub Jelinek
PR lto/116614
* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
comments.
(SHN_HIRESERVE): Use uppercase hex d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116606
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
-bisection |
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Started with r9-3194-gbdfbaa72c5b25f273a7e4
: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
cat abc.C
#define A(n) struct T##n {} t##n;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116501
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #8 from Jakub Jelinek ---
For the :DI !TARGET_64BIT, perhaps *insvdi_lowpart_1, *adddi3_doubleword_zext,
*adddi3_doubleword_concat, *adddi3_doubleword_concat_zext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #7 from Jakub Jelinek ---
For the m vs. o, there are quite a few (grepped just for the :TI cases because
:DI doesn't necessarily mean double-word):
grep 'match_operand:TI . ([^)]*).*m' tmp-mddump.md
(set (match_operand:TI 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #4 from Jakub Jelinek ---
But in that case, why doesn't LRA consider simply forcing the complex memory
address into a single register and with that needing one less register?
&r,ro,r or &r,r,ro is something that happens in various pl
,
||amacleod at redhat dot com,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Can't be bisected due to the --param=vrp-block-limit=0 dependency, and that has
been only introduced in r15-1622,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418
--- Comment #8 from Jakub Jelinek ---
void foo ();
template
void bar ()
{
decltype(auto) v = ({ foo (); 3; });
}
doesn't need -O1 nor -g to trigger the error, and can be reproduced with
-std=c++14 and higher. Still started with that commit,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418
Jakub Jelinek changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116572
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
long v;
template struct A;
template , typename = C>
class B;
template <>
struct A
{
static int foo(char *s, const char *t, long n) { return __builtin_memcmp(s,
t, n); }
};
template
stru
Priority|P3 |P1
Keywords|needs-bisection |
CC| |jakub at gcc dot gnu.org,
||law at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
S
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Created attachment 59041
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59041&action=edit
gcc15-pr116501.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116224
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Created attachment 59039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59039&action=edit
gcc15-pr116449.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
Jakub Jelinek changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116486
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116486
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=116486
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116130
--- Comment #15 from Jakub Jelinek ---
The FE part is now implemented (and handling it in the middle end if there are
no pointer/reference arguments too), but improving handling of functions with
those attributes with pointer/reference arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116387
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|--- |15.0
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2024-08-15
Status|UNCONFIRMED |ASSIGNED
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
../../gcc/fortran/resolve.cc: In function ‘bool resolve_operator(gfc_expr*)’:
../../gcc/fortran/resolve.cc:4649:22: error: too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106658
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116376
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
Jakub Jelinek changed:
What|Removed |Added
Attachment #58923|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
Jakub Jelinek changed:
What|Removed |Added
Attachment #58914|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
Jakub Jelinek changed:
What|Removed |Added
Attachment #58912|0 |1
is obsolete|
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Consider
struct B { B (); ~B (); };
struct A { A (); ~A (); };
A foo (const B &, const B &);
const A &x = foo (B {}, B {});
I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
Jakub Jelinek changed:
What|Removed |Added
Attachment #58908|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116331
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
--- Comment #4 from Jakub Jelinek ---
The above patch is on top of the PR107637 patch (just to avoid patch
conflicts).
Anyway, on #c2 previously the IL had a CLEANUP_POINT_EXPR around the e
reference initializer as well as the A temporary create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
--- Comment #3 from Jakub Jelinek ---
Created attachment 58908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58908&action=edit
gcc15-pr115769-wip.patch
Untested patch which fixes #c0 testcase without -DCURRENT, but breaks in a
different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
--- Comment #2 from Jakub Jelinek ---
Better testcase:
// CWG2867 - Order of initialization for structured bindings.
// { dg-do run { target c++17 } }
#define assert(X) do { if (!(X)) __builtin_abort(); } while (0)
namespace std {
template s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115769
--- Comment #1 from Jakub Jelinek ---
*** Bug 116345 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116345
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
https://wg21.link/cwg2867
We already do implement the right ordering, e initializer is evaluated first,
then the get calls in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116287
Jakub Jelinek changed:
What|Removed |Added
Known to fail|14.2.1, 15.0|14.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
--- Comment #3 from Jakub Jelinek ---
Created attachment 58878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58878&action=edit
gcc15-pr107637-wip.patch
Completely untested WIP patch, with which the above testcase now passes also in
-std=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
--- Comment #2 from Jakub Jelinek ---
Adjusted testcase so that it also verifies what is destructed first, S vs. T in
the various cases and standards:
// P2718R0 - Wording for P2644R1 Fix for Range-based for Loop
// { dg-do run { target c++11 }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116290
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116290
--- Comment #3 from Jakub Jelinek ---
Looks like ivopts.
In message_info_load, ivopts dumps are the first ones to contain differences
like
[local count: 955630198]:
- # _172 = PHI <_32(59), 0(56)>
# _173 = PHI <_33(59), label_117(56)>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115239
Jakub Jelinek changed:
What|Removed |Added
CC||hans.buchmann.wantuch@gmail
||jakub at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #3 from Jakub Jelinek ---
The second argument is ptrdiff_t, so on some targets where ptrdiff_t is int it
can be valid (most 32-bit arches), but where it is long int or long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116287
--- Comment #1 from Jakub Jelinek ---
Created attachment 58870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58870&action=edit
gcc15-pr116287.patch
Untested fix.
at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2024-08-08
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 115744, which changed state.
Bug 115744 Summary: [C++26] P2747R2 - constexpr placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115754
Bug 115754 depends on bug 115744, which changed state.
Bug 115744 Summary: [C++26] P2747R2 - constexpr placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116276
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91940
--- Comment #11 from Jakub Jelinek ---
Only 16-bit byteswap has the r>> 8 canonical form, larger byteswaps don't.
Larger byteswaps certainly aren't rotates, but just permutes. So, if the
vectorizer doesn't try that already, it should try to vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 109126, which changed state.
Bug 109126 Summary: [DR2387] Linkage of const-qualified variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
--- Comment #5 from Jakub Jelinek ---
Oh, and I think there is another problem with that paper.
module : private ;
is valid, but the addition of https://eel.is/c++draft/cpp.module#2 stands in a
way,
the pp-tokens in that case don't match pp-modu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
--- Comment #4 from Jakub Jelinek ---
Perhaps given http://eel.is/c++draft/cpp.pre#7 makes the default for
preprocessing directives not macro expanded unless otherwise specified, change
http://eel.is/c++draft/cpp.module#3
"Any preprocessing toke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
--- Comment #3 from Jakub Jelinek ---
Oh, and
#define SEMICOLON ;
module SEMICOLON
or
#define EMTPY
module EMPTY ;
etc.
>From what I understand, ; coming from macro was meant to be certainly ok since
wg21.link/p1857r3 and the optional attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126
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=116152
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116252
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116245
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 13696 matches
Mail list logo
