https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
--- Comment #3 from Jonathan Wakely ---
The 'operator(int)' case is interesting because it could be a typo for several
other operators, operator+(int) or operator++(int) or operator[](int).
Personally, I know that I forget the double parens for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115439
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:e187ed927ae52df7998376d6ccfdd2181fc8f774
commit r15-7926-ge187ed927ae52df7998376d6ccfdd2181fc8f774
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119135
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.4
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
--- Comment #11 from Konstantinos Eleftheriou ---
We have sent a solution for this
(https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677190.html).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119199
--- Comment #2 from anlauf at gcc dot gnu.org ---
Likely r15-4104.
Null pointer dereference, obviously fixed by:
diff --git a/gcc/fortran/trans-common.cc b/gcc/fortran/trans-common.cc
index 70b45174f84..2db50da20dd 100644
--- a/gcc/fortran/tran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70417
Jonathan Wakely changed:
What|Removed |Added
CC||jkjeon at etri dot re.kr
--- Comment #
rom the flang testsuite at
https://github.com/llvm/llvm-project/tree/main/flang/test
Recent gfortran does this:
test $ ~/gcc/results.20250310.valgrind/bin/gfortran -c -w
./Semantics/blockconstruct02.f90
==19760== Invalid read of size 1
==19760==at 0x8C7902: translate_common(gfc_comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532
--- Comment #9 from Christian Zietz ---
(In reply to Jeffrey A. Law from comment #8)
> Thorsten's testcase doesn't generate memset calls for me using the trunk.
Fwiw, Compiler Explorer's "ARM GCC trunk", which reports itself as...
arm-unknown-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119199
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=119199
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118897
--- Comment #1 from Bi6c ---
I try to minimize the input: https://godbolt.org/z/4G7rq4qGP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119197
Bug ID: 119197
Summary: [feat req] `std::expected` should be nodiscard
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119199
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119188
--- Comment #2 from Luke Shumaker ---
I appreciate the explanation. Does that make it any less of a bug? Should I
change the title to "x86 red-zone not taken into account by
-fcallgraph-info=su"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:40a4f3dead623db86bc8f7255cbe524701f4aeb0
commit r15-7931-g40a4f3dead623db86bc8f7255cbe524701f4aeb0
Author: Gaius Mulley
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Summary|valgri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119124
--- Comment #1 from Bi6c ---
I got ICE (verify_flow_info failed) with asm goto and local function call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119194
Bug ID: 119194
Summary: GCC 14.2.0: Incorrect Handling of const
std::string_view& as a Template Argument
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316
--- Comment #1 from David Binderman ---
As of today, 20250310, still broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119203
Bug ID: 119203
Summary: A type with a constrained operator-> gives error: base
operand of '->' has non-pointer type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119203
--- Comment #1 from Jonathan Wakely ---
For the original example, clang says what's wrong:
arrow.cc:14:7: error: no viable overloaded 'operator->'
14 | iter->i;
| ^
arrow.cc:6:8: note: candidate function not viable: constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119120
--- Comment #4 from Jakub Jelinek ---
I think this regressed with
r0-100845-gbd2e63a1c4d4159f576c31bee9e4090919462aa5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119189
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #7 from Uroš Platiše ---
(In reply to Andrew Pinski from comment #1)
> Do you want an attribute that gets added to a field of a struct which
> contains the function ptr and that you do a->b(...) and that turns into
> a->b(a, ...) au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119174
--- Comment #13 from Richard Sandiford ---
(In reply to Jeffrey A. Law from comment #11)
> Andrew. You're missing the point. This scenario isn't the kind of thing
> that reload and LRA are supposed to fix. They fix constraint problems. ie,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119151
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14/15 Regression] |[13/14 Regression]
|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119186
--- Comment #4 from Jonathan Wakely ---
With GCC 15 you can use __builtin_ctzg which can accept zero.
Or just use std::count_rzero instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119184
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |WONTFIX
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119186
--- Comment #2 from Andrew Pinski ---
__builtin_ctz with a value of 0 is undefined..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #2 from Jonathan Wakely ---
What if the function is not called indirectly, wouldn't the implicit object ref
just be garbage?
My response to this is "just use C++". Then you have functions which are
guaranteed by the language to be "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #5 from Uroš Platiše ---
If it is called directly it could hold NULL, but typically hardware abstraction
device drivers are never called directly. And now you typically have macros
i.e. one of the drivers "work-around" for this:
#de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119188
Bug ID: 119188
Summary: Incorrect -fcallgraph-info=su for leaf functions on
x86-64
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #8 from Andrew Pinski ---
(In reply to Uroš Platiše from comment #5)
> When to bring C++ to tiny micro-controllers is always a debate, as long even
> linux kernel does not want to switch to C++.
There is some movement in doing some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119202
Bug ID: 119202
Summary: Typo in message "%<\\o%> not followed by %<}%>"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119194
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|GCC 14.2.0: Incorr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119202
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Typo in message "%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #12 from Michael Duggan ---
I finally got around to this experiment today, after more than a year. I
changed this line in `coro_build_actor_or_destory_function` from:
DECL_ARTIFICIAL (fn) = true;
to
DECL_ARTIFICIAL (fn) = !act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119194
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119093
--- Comment #2 from Bi6c ---
Thanks for taking a look. To clarify, this code was generated by our fuzzer,
but I believe the ICE is worth addressing.
The error here involves the combination of `__attribute__((target_clones))`
with `__attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119197
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
--- Comment #2 from Andrew Pinski ---
The scalar is handled by match:
(for code1 (eq ne)
(for code2 (eq ne lt gt le ge)
(simplify
(bit_ior:c (code1:c@3 @0 @1) (code2:c@4 (convert?@c0 @0) @2))
(if ((TREE_CODE (@1) == INTEGER_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108
--- Comment #8 from Tamar Christina ---
Ok, so having looked at this I'm not sure the compiler is at fault here.
Similar to the SVN case the snappy code is misaligning the loads intentionally
and loading 64-bits at a time from the 8-bit pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
Bug ID: 119191
Summary: Add fix-it for missing argument list in operator()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115439
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119193
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
--- Comment #2 from Jonathan Wakely ---
EDG is almost there:
"callop.cc", line 2: error: an operator name must be declared as a function
void operator();
^
"callop.cc", line 3: error: expected an operator
void operator(int);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119194
--- Comment #1 from Andrew Pinski ---
*** Bug 119195 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119198
--- Comment #3 from Andrew Pinski ---
In this case oh is not decayed into a pointer from an array type. So yes it is
the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119175
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119195
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #13 from Iain Sandoe ---
I would say that perhaps (noting comment #9) it would be useful to explore
teaching gcov that it should not ignore the actor function (it is identifiable
that a function is a coroutine component)
Part of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119120
--- Comment #3 from Andrew Pinski ---
(In reply to Zoltan Vajda from comment #0)
> This is not an academic problem. The implementation of operator /= of
> std::complex has this behavior until GCC 8.5 (inclusive).
The std::complex's operator /=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118899
--- Comment #1 from Bi6c ---
I try to minimize the input: https://godbolt.org/z/oETd8vnhP
The issue is that the parameters in the macro definition and the usage don't
match:
Defined as `A3(expect, expr, align)`
Used as `A3(0, 32, P64_P_P32_P_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119186
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119182
--- Comment #2 from Andrew Pinski ---
Rather the issue which is testing (and is fixed for GCC 14+) is the decltype(x)
is int rather than int&.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
Bug ID: 119187
Summary: vectorizer should be able to SLP already vectorized
code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > There is another bug report for a similar thing but with SSE and AVX2.
>
> yes PR 95960.
Ah yeah, I guess I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
--- Comment #3 from Richard Biener ---
Oh, so we don't have debug stmts at -O0 because we don't run var-tracking. I
guess the patch is reasonable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> callop.cc:3:16: error: expected type-specifier before ‘(’ token
> 3 | void operator(int, int);
> |^
Oops, I posted the output fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119112
--- Comment #1 from GCC Commits ---
The releases/gcc-14 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:ca0ea3d4192313ad00da4ff734baffcecafe0b1f
commit r14-11399-gca0ea3d4192313ad00da4ff734baffcecafe0b1f
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118871
--- Comment #2 from Jakub Jelinek ---
It is invalid. Non-local goto is a special extension, which needs extra
handling on the assembler level, something that writers of inline asm have no
idea about and what exactly to use there.
So, it is noth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118871
--- Comment #1 from Bi6c ---
Is it considered as invalid code?
I tried with "goto l;", and it is compilable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119201
Bug ID: 119201
Summary: Wrong plural forms in "missing primary template
attribute"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119195
Bug ID: 119195
Summary: GCC 14.2.0: Incorrect Handling of const
std::string_view& as a Template Argument
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
--- Comment #7 from Richard Biener ---
It would ask for a flag on the tree nodes so we don't repeatedly recurse down
the tree. TREE_NO_SIDE_EFFECTS?
But yes, limiting the search depth is the simplest solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119166
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143
--- Comment #4 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:f2339cefd6985e20014f9b0795fb651a96788246
commit r15-7925-gf2339cefd6985e20014f9b0795fb651a96788246
Author: Andre Vehreschild
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143
Andre Vehreschild changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119179
--- Comment #3 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #2)
> By the way: while reducing this example, I've noted that if one uses `VLA()
> {}`, then the byte-filling gets disabled. Is it intended? It's not exactly
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #33 from Jakub Jelinek ---
Created attachment 60692
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60692&action=edit
gcc15-pr117178.patch
Untested fix for the issue mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2025-M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117512
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
101 - 185 of 185 matches
Mail list logo
