I've received a report of a mingw build failure:
../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of
function 'fork' [-Wimplicit-function-declaration]
185 | pid = fork ();
| ^~~~
> Cc: Jonathan Yong <10wa...@gmail.com>, Jan Hubicka , Nathan
> Sidwell
> Date: Fri, 01 Dec 2023 09:02:55 +0100
> X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
> DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
> RCVD_IN_MSPIKE_H3,
On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc
> > wrote:
> >>
> >> I've received a report of a mingw build failure:
> >>
> >> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
> >>
On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc wrote:
>
> I've received a report of a mingw build failure:
>
> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of
> function 'fork'
On Fri, 1 Dec 2023, LIU Hao via Gcc wrote:
> >> What's the best way to fix this? I expect it's going to impact other
> >> targets (perhaps for different functions) because all of
> >> libgcov-interface.c is built unconditionally. I don't think we run
> >> configure for the target, so we can't
On Fri, 1 Dec 2023, Richard Biener via Gcc wrote:
> On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer wrote:
> >
> > * Richard Biener:
> >
> > > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc
> > > wrote:
> > >>
> > >> I've received a report of a mingw build failure:
> > >>
> > >>
On Dez 01 2023, Richard Biener via Gcc wrote:
> Hmm, so why's it then referenced and not "GCed"?
This has nothing to do with garbage collection. It's just the way
libgcc avoids having too many source files. It would be exactly the
same if every function were in its own file.
--
Andreas
在 2023/12/1 16:19, Eli Zaretskii via Gcc 写道:
As far as I understand it, mingw doesn't have fork and doesn't declare
it in , so it's not clear to me how this has ever worked. I
would expect a linker failure. Maybe that doesn't happen because the
object containing a reference to fork is only
Florian Weimer via Gcc writes:
> [...]
> Numbers do not tally up because one package can have multiple issues.
> The autoconf column counts packages where file-name based heuristics
> suggest the critical errors are in autoconf-style feature probes, where
> they are ignored and could silently
* Richard Biener:
> On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc wrote:
>>
>> I've received a report of a mingw build failure:
>>
>> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
>> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration
>> of
> On Dez 01 2023, Richard Biener via Gcc wrote:
>
> > Hmm, so why's it then referenced and not "GCed"?
>
> This has nothing to do with garbage collection. It's just the way
> libgcc avoids having too many source files. It would be exactly the
> same if every function were in its own file.
THe
在 2023/12/1 17:09, Richard Biener via Gcc 写道:
Hmm, so why's it then referenced and not "GCed"?
The classical "solution" is to make the reference weak via sth like
extern typeof(fork) fork () __attribute__((weak));
There are issues about weak symbols on mingw targets. Calls to weak functions
On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > On Dez 01 2023, Richard Biener via Gcc wrote:
> >
> > > Hmm, so why's it then referenced and not "GCed"?
> >
> > This has nothing to do with garbage collection. It's just the way
> > libgcc avoids having too many source
Snapshot gcc-12-20231201 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231201/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
When I moved two_value to match.pd, I removed the check for the {0,+-1}
as I had placed it after the {0,+-1} case for cond in match.pd.
In the case of {0,+-1} and non boolean, before we would optmize those
case to just `(convert)a` but after we would get `(convert)(a != 0)`
which was not handled
This patch set fixes PR 111972 and the fallout from it.
The first patch is a fix to zero_one_valued_p's convert pattern
which I hit while running the testsuite with the last patch.
The second patch is a fix for -fanalyzer which I had implemented with
a different version of the 3rd patch while I
While working on PR 111972, I was getting a regression
due to zero_one_valued_p matching a signed 1 bit integer
when it came to convert. This patch fixes that by checking
the outer type too.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd
From: Andrew Pinski
The check for the type seems unnecessary and gets in the way sometimes.
Also with a patch I am working on for match.pd, it causes a failure to happen.
Before my patch the IR was:
_1 = BIT_FIELD_REF ;
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #15 from Andrew Pinski ---
Patch set finally posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639019.html
Iain Sandoe writes:
> HI Sam,
Hi Iain,
>
> I think this qualifies as obvious (it’s on my list, but I did not get to it
> yet,
> so go ahead).
Thanks. I can't push it myself - could you do that for me?
thanks again,
sam
>
> Iain
>
>> On 2 Dec 2023, at 05:30, Sam James wrote:
>>
>> From:
From: Iain Sandoe
r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
Fixed thus.
Signed-off-by: Iain Sandoe
Signed-off-by: Sam James
libiberty/ChangeLog:
PR other/112823
* simple-object-mach-o.c (simple_object_mach_o_write_segment):
Cast the first argument
HI Sam,
I think this qualifies as obvious (it’s on my list, but I did not get to it yet,
so go ahead).
Iain
> On 2 Dec 2023, at 05:30, Sam James wrote:
>
> From: Iain Sandoe
>
> r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
> Fixed thus.
>
> Signed-off-by: Iain Sandoe
>
Jeff Law writes:
> On 12/1/23 18:13, Sam James wrote:
>> 钟居哲 writes:
>>
>>> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>>>
>>>
+ opt_machine_mode opt_mode = riscv_vector::get_vector_mode (smode,
nunits);
Remove.
+ if (opt_mode.exists ()) -> if (riscv_vector::get_vector_mode
(smode, nunits).exists ())
+ emit_insn (
+ gen_movdi (int_reg, gen_lowpart (GET_MODE (int_reg), dest)));
Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804
--- Comment #1 from Andrew Pinski ---
Looks like -finline-stringops is not correc5 for the case where ptrmode !=
Pmode. I might take a look next week or the week afterwards.
I also suspect you might hit it on x32 also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
Leverage previous approach.
Before this patch:
.L5:
add a3,s0,s2
add a4,s6,s2
add a5,s7,s2
vsetvli zero,s0,e64,m8,ta,ma
vle8.v v4,0(s2)
vle8.v v3,0(a3)
mv s2,s1
vle8.v v2,0(a4)
vle8.v v1,0(a5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Hi!
The middle kind _BitInt lowering is mostly done by casting the BITINT_TYPE
operands (if any) to a signed/unsigned integer type which has larger/equal
precision, using such integer type also for the lhs (if BITINT_TYPE) and
and adding a cast after the statement from that new lhs to the old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804
Bug ID: 112804
Summary: ICE in aarch64 crosscompiler in plus_constant, at
explow.cc:102
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
Hi!
handle_operand_addr for INTEGER_CSTs uses wi::min_precision (UNSIGNED
for non-negative constants, SIGNED for negative ones) and from that
computes mp as minimum number of limbs which can represent that value,
and in some cases creates a test BITINT_TYPE with that precision to
categorize it
On Fri, 1 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> When debugging PR112750, I've noticed some issues in the computation
> of precisions and the following patch attempts to fix those.
>
> The pass uses range_to_prec function, which possibly using ranger returns
> minimum precision of some
libgcc/ChangeLog:
PR target/112777
* libgcov.h (GCOV_SUPPORTS_ATOMIC): Honor that __LIBGCC_HAVE_LIBATOMIC
is
always defined as either 0 or 1.
---
libgcc/libgcov.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
Sam James changed:
What|Removed |Added
Depends on||108476, 85678
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112801
--- Comment #3 from JuzheZhong ---
(In reply to Richard Biener from comment #2)
> I think wrong-code should be high-priority ;)
Oh. I see. Sorry. I thought it was the previous RVV shift ISA issue.
since I saw c(g[1] >> 32);
Confirm it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112805
Bug ID: 112805
Summary: Failed to compile C++20 code with usage of modules
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hello Kewen:
On 24/11/23 3:01 pm, Kewen.Lin wrote:
> Hi Ajit,
>
> Don't forget to CC David (CC-ed) :), some comments are inlined below.
>
> on 2023/10/8 03:04, Ajit Agarwal wrote:
>> Hello All:
>>
>> This patch add new pass to replace contiguous addresses vector load lxv with
>> mma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588
Andrew Pinski changed:
What|Removed |Added
CC||ma.anshukov at gmail dot com
---
This simple patch allows me to build a cross-compiler to riscv using
older versions of RedHat's system compiler. The issue is PR c++/60994
where g++ doesn't like the same name (demand_flags) to be used by both
a variable and a (enumeration) type, which is also undesirable from a
(GNU) coding
Yes, OK, thanks for that. CC'ing Juzhe as this is his pass.
Regards
Robin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93575
Matthias Klose changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79792
Matthias Klose changed:
What|Removed |Added
Resolution|--- |WORKSFORME
libphobos/ChangeLog:
* m4/druntime/cpu.m4: Support loongarch* targets.
* libdruntime/Makefile.am: Same.
* libdruntime/Makefile.in: Regenerate.
* configure: Regenerate.
---
libphobos/configure | 21 ++-
libphobos/libdruntime/Makefile.am | 3 +
libphobos/ChangeLog:
* libdruntime/config/loongarch/switchcontext.S: New file.
---
.../config/loongarch/switchcontext.S | 133 ++
1 file changed, 133 insertions(+)
create mode 100644 libphobos/libdruntime/config/loongarch/switchcontext.S
diff --git
gcc/ChangeLog:
* config/loongarch/loongarch-d.cc: Undefine LoongArch32.
Define LoongArch_SF, LoongArch_F32, LoongArch_F64
gcc/d/ChangeLog:
* dmd/cond.d: Same.
* implement-d.texi: Same.
---
gcc/config/loongarch/loongarch-d.cc | 27 ++-
This patchset is based on Zixing Liu's initial support patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631260.html
Update v1 -> v3:
Rebased onto the dmd/druntime upstream state.
Regtested on loongarch64-linux-gnu with the following result:
=== libphobos Summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112806
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
When querying a single set of vector defs with the overloaded
vect_get_vec_defs API then when you try to use the overload with
the vector type specified the call will be ambiguous with the
variant without the vector type. The following fixes this by
re-ordering the vector type argument to come
Hi!
On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c.
The following patch fixes the former ones (they need recent binutils to
be enabled), for pr83126.c because I didn't have graphite configured I've
just verified that the test compiles (didn't without the patch) and that
* Thomas Schwinge:
> I'm not proposing a patch as I don't know whether you'd like to just
> silence the diagnostic, fix (?) the test case, and/or add another
> 'dg-error'-checking test case? (I've not yet looked at the history of
> the test case.)
Jakub just posted a patch:
[PATCH]
* Jakub Jelinek:
> Hi!
>
> On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c.
>
> The following patch fixes the former ones (they need recent binutils to
> be enabled), for pr83126.c because I didn't have graphite configured I've
> just verified that the test compiles
On 30/11/2023 23:56, Joseph Myers wrote:
> On Thu, 30 Nov 2023, Jonny Grant wrote:
>
>> ChangeLog:
>>
>> htdocs/git.html: change example to use git:// and correct
>> spelling repostiory -> repository .
>
> git:// (unencrypted / unauthenticated) is pretty widely
Background:
RVV ISA vx instructions for example vadd.vx,
When EEW = 64 and RV32. We can't directly use vadd.vx.
Instead, we need to use:
sw
sw
vlse
vadd.vv
However, we have some special situation that we still can directly use
vadd.vx directly for EEW=64 && RV32.
that is, when scalar is a known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112760
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On Fri, 2023-12-01 at 15:46 +0800, Yang Yujie wrote:
> diff --git a/libphobos/src/std/math/hardware.d
> b/libphobos/src/std/math/hardware.d
> index cb6cb87845c..8d11459a8ac 100644
> --- a/libphobos/src/std/math/hardware.d
> +++ b/libphobos/src/std/math/hardware.d
> @@ -177,6 +177,20 @@ private:
>
On Fri, Dec 1, 2023 at 9:19 AM Sebastian Huber
wrote:
>
> libgcc/ChangeLog:
OK.
> PR target/112777
>
> * libgcov.h (GCOV_SUPPORTS_ATOMIC): Honor that
> __LIBGCC_HAVE_LIBATOMIC is
> always defined as either 0 or 1.
> ---
> libgcc/libgcov.h | 2 +-
> 1 file changed, 1
Hello Richard,
Thank you for the review. Fixed the problems and committed to master.
Thanks,
Di
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, November 30, 2023 8:21 PM
> To: Di Zhao OS ; gcc-patches@gcc.gnu.org
> Cc: Philipp Tomsich
> Subject: Re: [PATCH] aarch64:
ary-trunk-r14-6048-20231201170246-g6563d6767ed-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231201 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112771
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9bfebcb1b7ae4e7160644f2104424d6bab4a23f7
commit r14-6050-g9bfebcb1b7ae4e7160644f2104424d6bab4a23f7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91209
Matthias Klose changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112770
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b1fe98dee21773b9d908469effe2580567b903fb
commit r14-6051-gb1fe98dee21773b9d908469effe2580567b903fb
Author: Jakub Jelinek
Date:
This is mainly for the convenience of testing, and we will consider the
issues you mentioned.
在 2023/12/1 下午6:01, Xi Ruoyao 写道:
On Fri, 2023-12-01 at 17:55 +0800, mengqinggang wrote:
Generate la.tls.desc macro instruction for TLS descriptors model.
la.tls.desc expand to
pcalau12i $a0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #9 from Robin Dapp ---
Ok, it's not the fold_extract_last expander. It just appeared that way here
because I disabled some other things.
What we want to do is extract the last element from a vector. This works as
long as we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112753
Jakub Jelinek changed:
What|Removed |Added
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #11 from Robin Dapp ---
When I define a vec_extract...bi pattern we don't enter the if (vec_extract) in
expmed because e.g.
bitsize = {1, 0}
bitnum = {3, 4}
and GET_MODE_BITSIZE (innermode) = {1, 0} with innermode = BImode.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112750
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Fri, Dec 1, 2023 at 8:34 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, December 1, 2023 3:04 PM
> > To: Jiang, Haochen
> > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> > ubiz...@gmail.com
> > Subject: Re: [PATCH] i386: Mark Xeon Phi
On Fri, 1 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> The middle kind _BitInt lowering is mostly done by casting the BITINT_TYPE
> operands (if any) to a signed/unsigned integer type which has larger/equal
> precision, using such integer type also for the lhs (if BITINT_TYPE) and
> and adding a
On Fri, 1 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> handle_operand_addr for INTEGER_CSTs uses wi::min_precision (UNSIGNED
> for non-negative constants, SIGNED for negative ones) and from that
> computes mp as minimum number of limbs which can represent that value,
> and in some cases creates a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112805
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 112805, which changed state.
Bug 112805 Summary: Failed to compile C++20 code with usage of modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112805
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112806
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> [[likely]]/__builtin_expect is kinda of documented:
>
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Other-Builtins.html#index-
> fprofile-arcs-1
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112806
--- Comment #1 from Andrew Pinski ---
[[likely]]/__builtin_expect is kinda of documented:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Other-Builtins.html#index-fprofile-arcs-1
Everything else is just a hint.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
Matthias Klose changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2023-12-01
CC|
On Fri, 2023-12-01 at 18:01 +0800, Xi Ruoyao wrote:
> On Fri, 2023-12-01 at 17:55 +0800, mengqinggang wrote:
> > Generate la.tls.desc macro instruction for TLS descriptors model.
> >
> > la.tls.desc expand to
> > pcalau12i $a0, %desc_pc_hi20(a)
> > ld.d $a1, $a0, %desc_ld_pc_lo12(a)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289
--- Comment #3 from Florian Weimer ---
Jan, do you actually experience a build failure? The part you quoted only shows
warnings.
Thomas, the safe thing to do would be to use __builtin_calloc and
__builtin_realloc in those spots because it
On Nov 30, 2023, Jan Hubicka wrote:
>> + if (VAR_P (replaced))
>> +varpool_node::create_alias (sym_node->decl, replacement);
>> + else
>> +cgraph_node::create_alias (sym_node->decl, replacement);
Unfortunately, this change didn't work. Several of the C++ tests
regressed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
Sam James changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #16 from David Brown ---
Thank you for making these changes. There's always a trade-off between
supporting code that "has always compiled fine and works in testing", and
making it harder for people to write new poor quality code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224
Sam James changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
Bug 44209 depends on bug 106537, which changed state.
Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
Sam James changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82919
Sam James changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 28/11/23 3:14 pm, Kewen.Lin wrote:
> on 2023/11/28 15:05, Michael Meissner wrote:
>> I tried using this patch to compare with the vector size attribute patch I
>> posted. I could not build it as a cross compiler on my x86_64 because the
>> assembler gives the following error:
>>
>> Error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
In BPF section names are used to encode the kind of BPF program and
other metadata, involving all sort of non alphanumeric characters.
For example:
/* use auto-attach format for section definition. */
SEC("uretprobe//proc/self/exe:trigger_func2")
int handle_uretprobe_byname(struct pt_regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102260
Matthias Klose changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112771
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112770
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi Indu.
This is OK. Thanks.
> PR debug/112656 - btf: function prototypes generated with name
>
> With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
> generated BTF section.
>
> As noted in the discussion in the bugzilla, the number of
> BTF_KIND_FUNC_PROTO types output
From: Pan Li
If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.
This patch would like to reuse the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808
Bug ID: 112808
Summary: Consider enabling _GLIBCXX_ASSERTIONS checks by
default for debug builds
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
On Fri, 1 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c.
>
> The following patch fixes the former ones (they need recent binutils to
> be enabled), for pr83126.c because I didn't have graphite configured I've
> just verified
Hey,
I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in this
commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an error which I
unfortunately missed. This patch fixes that test.
Did regression testing on arm-none-eabi and found no regressions. Output of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740
--- Comment #11 from Richard Biener ---
The only thing that's maybe suspicious is that
machine_mode mode = GET_MODE (target);
but we test
/* Use sign-extension for uniform boolean vectors with
integer modes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112777
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
1 - 100 of 294 matches
Mail list logo
