https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112645
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-11-21
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106921
--- Comment #8 from Toni Neubert ---
Hello,
I just wanted to ask what the state of this bug is?
I think that incorrectly compiled code should be much more important than
anything else since any system can be affected without even knowing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112639
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8a8a6d60c670c5153c5109df5fe68deb6fcf466d
commit r14-5638-g8a8a6d60c670c5153c5109df5fe68deb6fcf466d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #16 from Haochen Jiang ---
Well I still could not reproduce that. Need some more investigation if they are
the same case.
/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--prefix=/home/kostadin/gcc-build/../gcc --disable-nls CFLAGS='-O2 -ggdb'
CXXFLAGS='-O2 -ggdb'
Thread model: posix
Supported LTO compression algorithms: zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
--- Comment #4 from Jakub Jelinek ---
https://github.com/llvm/llvm-project/issues/72970
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1fcfd224ff67afd08ea5aa66a8bd687bb21798b2
commit r14-5639-g1fcfd224ff67afd08ea5aa66a8bd687bb21798b2
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #16 from Tamar Christina ---
Ah, saves me the bisect then :)
Morning, new reproducer is:
> cat ratectl.i
double MADPictureC1;
extern int PictureRejected[];
int PictureMAD_0, MADModelEstimator_n_windowSize_i,
MADModelEstimator_n_win
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #17 from Robin Dapp ---
Thanks, I reproduced it on the compile farm with this example. Going to have a
look. riscv doesn't fail in a similar way this time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634
--- Comment #5 from Tobias Burnus ---
@Kostadin: Sebastian posted a patch at
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637451.html
that should be fine as workaround, even if it is not completely correct, cf.
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112646
Bug ID: 112646
Summary: bootstrap broken for clang build on znver3 ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112646
David Binderman changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #10 from Costas Argyris ---
> I suspect there should be an `AC_ARG_ENABLE` in configure.ac?
It doesn't appear to be necessary to me.It also wasn't part of the advice
of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865#c44 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
Andrew Pinski changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112646
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
Jakub Jelinek changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #18 from Robin Dapp ---
Already in ifcvt we have:
_ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25, MADPictureC1_lsm.10_25);
which we should not. This is similar on riscv.
But during value numbering it still is
Value numberi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #19 from Tamar Christina ---
(In reply to Robin Dapp from comment #18)
> Already in ifcvt we have:
>
> _ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25,
> MADPictureC1_lsm.10_25);
>
> which we should not. This is similar on ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
--- Comment #3 from Jakub Jelinek ---
I think the problem is that vec_pack_trunc_optab is a normal OPTAB_D and uses
just the argument mode (V?SFmode in this case) and the result is some floating
point type with half the size. But that is V?HFmo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634
--- Comment #6 from CVS Commits ---
The master branch has been updated by Sebastian Huber :
https://gcc.gnu.org/g:41aacdea55c5d795a7aa195357d966645845d00e
commit r14-5666-g41aacdea55c5d795a7aa195357d966645845d00e
Author: Sebastian Huber
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #20 from Robin Dapp ---
Not really depending on an order but rather expecting that the reduction
variable is in op[1] (as created by ifcvt).
That might already be the problem because here the reduction index is 2. It
just never hap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #21 from Robin Dapp ---
Grml,
../../gcc/tree-vect-loop.cc:12248:1: fatal error: error writing to
/tmp/ccsMqSV2.s: No space left on device
on cfarm185, cannot even build anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
--- Comment #4 from Richard Biener ---
The vectorizer usually checks the operand mode, like with
if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype))
but yeah, ambiguities are bad here. When designing these patterns no
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
--- Comment #6 from Richard Biener ---
But the problem is of course that you then can't have both at the same time,
vec_pack_trunk_v4sf from V8HF and V8BF unless we'd support "VOIDmode" there.
Note there's the "better" {s,z}ext optabs which hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112647
Bug ID: 112647
Summary: Inconsistent Comparison Results of Unsigned Bit Fields
Across Different Compilers and Architectures
Product: gcc
Version: 14.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112647
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110347
--- Comment #2 from Tobias Burnus ---
An explicit 'firstprivate(x)' will be turned in the compiler from a FIELD_DECL
to:
int D.2935 [value-expr: ((struct t *) this)->x];
#pragma omp target firstprivate(D.2934) firstprivate(D.2935)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112611
--- Comment #2 from Xi Ruoyao ---
(In reply to Jiahao Xu from comment #1)
> Due to some issues with the implementation of the [x]vshuf instruction in
> LA464, there is a problem where, when the index value in the register is
> greater than or eq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:e5678468e550e99944fca6bae364696714ffb445
commit r14-5672-ge5678468e550e99944fca6bae364696714ffb445
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:4b6da8e7bdb93d9bca6291157db1c936ac56e7af
commit r14-5671-g4b6da8e7bdb93d9bca6291157db1c936ac56e7af
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:33c2b70dbabc02788caabcbc66b7baeafeb95bcf
commit r14-5673-g33c2b70dbabc02788caabcbc66b7baeafeb95bcf
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370
--- Comment #5 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:c187fe4bceb90643b88a55a54c4040ab9e40e659
commit r14-5674-gc187fe4bceb90643b88a55a54c4040ab9e40e659
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 111370, which changed state.
Bug 111370 Summary: On Aarch64 4% 511.povray_r regression between
g:6cd85273071b5f13 (2023-08-23 00:17) and g:e1f096a3cc96c719 (2023-08-25 22:34)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #3 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:8faae311a60a552ed3d506de28c50c77fa49b229
commit r14-5677-g8faae311a60a552ed3d506de28c50c77fa49b229
Author: Juzhe-Zhong
Date: Tue Nov 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
Jakub Jelinek changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> I think at least x86 doesn't currently have instructions which would support
> both, CCing Hongtao to verify that, but not sure if e.g. RISC-V won't have
> some
27;
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231121 (experimental) (g41aacdea55c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112648
--- Comment #1 from Richard Biener ---
Note that using a --param for a correctness thing isn't recommended, I'd
transition that to -mvect-lmul=N as it also shouldn't only apply to
auto-vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112649
Bug ID: 112649
Summary: [c++23] in presence of inline functions and debug-info
stacktrace reports the deepest callee
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:1d82fc2e6824bf83159389729c31a942f7b91b04
commit r14-5679-g1d82fc2e6824bf83159389729c31a942f7b91b04
Author: Jan Hubicka
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:1d82fc2e6824bf83159389729c31a942f7b91b04
commit r14-5679-g1d82fc2e6824bf83159389729c31a942f7b91b04
Author: Jan Hubicka
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #22 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:1d82fc2e6824bf83159389729c31a942f7b91b04
commit r14-5679-g1d82fc2e6824bf83159389729c31a942f7b91b04
Author: Jan Hubicka
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112650
Bug ID: 112650
Summary: RISC-V parameters are not documented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651
Bug ID: 112651
Summary: RISC-V Vector --param=riscv-autovec-lmul should be
-mvect-lmul
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112648
--- Comment #2 from Jeremy Bennett ---
Thanks Richard. Bug 112651 filed to capture this suggestion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:aef1aaff41190d2f82cf49d8907682b6dff71c3c
commit r14-5681-gaef1aaff41190d2f82cf49d8907682b6dff71c3c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112623
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
Bug ID: 112652
Summary: g++.dg/cpp26/literals2.C FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
Bug ID: 112653
Summary: We should optimize memmove to memcpy using alias
oracle
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Bug 110287 depends on bug 110377, which changed state.
Bug 110377 Summary: Early VRP and IPA-PROP should work out value ranges from
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug 109849 depends on bug 110377, which changed state.
Bug 110377 Summary: Early VRP and IPA-PROP should work out value ranges from
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #10 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639
--- Comment #1 from Tobias Burnus ---
Testing shows that the offsets are correctly handled but that there is an
ordering problem. Example:
int
main ()
{
int a[100] = {};
int *p = &a[0];
uintptr_t iptr;
#pragma omp target map(a, iptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #24 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112648
--- Comment #3 from Jeremy Bennett ---
Following a discussion on the weekly call, it seems that I have misunderstood
the purpose of this parameter. It seems it is a hint to the optimizer that a
particular LMUL value is most efficient, not as a m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651
Jeremy Bennett changed:
What|Removed |Added
Summary|RISC-V Vector |RISC-V Vector new option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654
Bug ID: 112654
Summary: bpf: bpf program load failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654
--- Comment #1 from Brian Witte ---
Created attachment 56658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56658&action=edit
this is a *.tmp.s file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654
--- Comment #2 from Brian Witte ---
$ ./pretty_uname.sh
System Information
--
Kernel Name: Linux
Node Name: debian
Kernel Release:6.5.0-4-amd64
Kernel Version:#1 SMP PREEMPT_DYNAMIC Debian 6.5.10-1 (2023-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639
--- Comment #2 from Tobias Burnus ---
> If 'a' is already present on the device (e.g. 'omp target enter data
> map(a)'), it works.
This applies to both the comment 0 example where only a section of 'a' is
mapped start > 0 and for the comment 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654
--- Comment #3 from Jose E. Marchesi ---
The instruction failing validation seems to be:
e0: bf a4 00 00 00 00 00 00 mov %r4,%r10
Which is a regular MOV instruction with zeroes in imm32 and offset16. It has
SRC=X. So I don't unde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654
--- Comment #4 from Jose E. Marchesi ---
I think the problem here may be that OP's kernel doesn't understand BPF V4
instructions, and the program above has been compiled with them (movs). Try to
use -mcpu=v3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
Andrew Pinski changed:
What|Removed |Added
Summary|[14 regression] failure to |[14 regression] including
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |target
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
Patrick O'Neill changed:
What|Removed |Added
Attachment #56615|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #8 from Jakub Jelinek ---
So, shall we go with
--- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj
2023-11-15 12:45:17.359586776 +0100
+++ libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h 2023-11-21
18:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
Patrick O'Neill changed:
What|Removed |Added
Attachment #56624|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #20 from Andrew Pinski ---
The use of __builtin_ia32_2intersectd128 in avx512vp2intersectvlintrin.h has:
#pragma GCC target("avx512vp2intersect,avx512vl,no-evex512")
While i386-builtin.def does:
BDESC (0, OPTION_MASK_ISA2_AVX512VP2I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
--- Comment #6 from Patrick O'Neill ---
Whoops, got the author/committer mixed up. I meant to refer to Juzhe's fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
Patrick O'Neill changed:
What|Removed |Added
Attachment #56625|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
Patrick O'Neill changed:
What|Removed |Added
Attachment #56626|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #5 from Miro Palmu ---
I have been trying to figure out where exactly the bug is and these are my
findings.
> Or:
>
> #include
>
> consteval void bar() {
> auto _ = [](std::string s) { return s; }({});
> }
>
> int main() {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #11 from Hans-Peter Nilsson ---
(In reply to Rainer Orth from comment #10)
> Since 20230106, this test produces an XPASS, according to gcc-testresults
> postings this happens everywhere:
>
> +XPASS: g++.dg/warn/Wstringop-overflow-4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112619
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
--- Comment #6 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #5)
> The -frounding-math option should solve the issue on this particular
> example. But on my machine, ld gives an "undefined reference to `_up'" error.
That is beca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112619
--- Comment #5 from Jakub Jelinek ---
Created attachment 56663
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56663&action=edit
gcc14-pr112619.patch
If it is ok for TRY_CATCH_EXPR to have second argument be something other than
STATEMENT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #1 from Jakub Jelinek ---
Strange. On cfarm211 which is
SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
the test passes.
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:7:9: warning:
multi-character cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=576
--- Comment #7 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #6)
> That is because the code is GNU C90 and not C++ .
I've used gcc, not g++. But this fails even with -std=gnu90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654
Brian Witte changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112655
Bug ID: 112655
Summary: analyzer/infinite-loop.cc:75: Possible performance
problem ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
--- Comment #7 from Sam James ---
We can add the test case at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112526#c14 too if it's fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
--- Comment #8 from Jakub Jelinek ---
That one seems to be too large IMHO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
--- Comment #9 from Sam James ---
ack, np.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
Bug ID: 112656
Summary: btf: function prototypes generated with name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #1 from Jose E. Marchesi ---
Smaller reproducer:
static void log_event(const char *event_name, void *dev_ptr)
{
}
void lala ()
{
log_event ("foobar", ((void *)0));
}
Note that the FUNC_PROTO for log_event seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #2 from Jose E. Marchesi ---
The btf_collect_datasec function in btf2out.cc traverses the cgraph and, for
each function, transforms its CTF_K_FUNCTION into a pair of BTF_KIND_FUNC_PROTO
and BTF_KIND_FUNC. But if the function is inli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c7c1ee1cfdea228f79ba9d495b407f3689efc608
commit r14-5693-gc7c1ee1cfdea228f79ba9d495b407f3689efc608
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #22 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:2bbc7f4ef6329df62146fd6d0da5f30750cc72b4
commit r14-5697-g2bbc7f4ef6329df62146fd6d0da5f30750cc72b4
Author: Robin Dapp
Date: Tue No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #6 from Jonathan Wakely ---
(In reply to Miro Palmu from comment #5)
> If you use libstdc++ on clang these will not compile but with different
> errors.
The examples in comment 4 do compile using libstdc++ on clang, if you use
libst
1 - 100 of 161 matches
Mail list logo
