On Mon, Jan 22, 2024 at 3:27 PM Hans-Peter Nilsson wrote:
>
> > From: Richard Biener
> > Date: Mon, 22 Jan 2024 08:33:47 +0100
>
> > > - "% function might not be inlinable");
> > > + "% function is not always inlined"
> > > + " unless also
Targets whose binutils support -shared, but that don't have a shared
libc, and that can't add PDC (non-PIC) to shared libraries, may
succeed at the effective target test for -shared, because it brings
nothing from libc, but tests that rely on -shared and that use bits
from libc, such as
newlib-src/libc/include/sys/fenv.h doesn't define the FE_* macros that
libgcc expects to enable decimal float support. Only after newlib is
configured and built does an overriding header that defines those
macros become available in objdir//newlib/targ-include/, but
by then, libgcc has already
Calling arm_neon.h functions that take lanes as arguments may fail to
report malformed values if the intrinsic happens to be optimized away,
e.g. because it is pure or const and the result is unused.
Adding __AARCH64_LANE_CHECK calls to the always_inline functions would
duplicate errors in case
On Mon, 22 Jan 2024, Jeff Law wrote:
>
>
> On 1/15/24 06:34, Richard Biener wrote:
> > When the x86 backend generates code for cpymem with the rep_8byte
> > strathegy for the 8 byte aligned main rep movq it needs to compute
> > an adjusted pointer to the source after doing a prologue aligning
>
When mixing -flto, -ffat-lto-objects and -fdebug-type-section we
fail to reset all type units after early output resulting in an
ICE when attempting to add then duplicate sibling attributes.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR debug/112718
*
There're 2 cases:
1. hwasan-poison-optimisation.c is supposed to scan call to
__hwasan_tag_mismatch4, and x86 have different mnemonic(call) from
aarch64(bl), so adjust testcase to scan either call or bl.
2. alloca-outside-caught.c/vararray-outside-caught.c are supposed to
scan mismatched tags and
Ready push to trunk.
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_option_override_internal):
Enable -mlam=u57 by default when compiled with
-fsanitize=hwaddress.
---
gcc/config/i386/i386-options.cc | 9 +
1 file changed, 9 insertions(+)
diff --git
Pushed to r14-8344.
在 2024/1/17 上午9:24, chenxiaolong 写道:
gcc/ChangeLog:
* doc/sourcebuild.texi: Add attributes for keywords.
---
gcc/doc/sourcebuild.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> Date: Mon, 22 Jan 2024 14:33:59 -0500
> From: Marek Polacek
> The problem seems to be more about conversion so
> g++.dg/conversion/reinterpret5.C
> or g++.dg/cpp0x/constexpr-reinterpret3.C seems more appropriate.
>
> > @@ -0,0 +1,49 @@
>
> Please add
>
> PR c++/113545
> > + unsigned
On 1/21/24 23:12, Monk Chiang wrote:
Since the match.pd transforms (zero_one == 0) ? y : z y,
into ((typeof(y))zero_one * z) y. Add splitters to recongize
this expression to generate SFB instructions.
gcc/ChangeLog:
PR target/113095
* config/riscv/sfb.md: New splitters to
TLS gd ld and ie type symbols will generate corresponding GOT entries,
so non-zero offsets cannot be generated.
The address of TLS le type symbol+addend is not implemented in binutils,
so non-zero offset is not generated here for the time being.
gcc/ChangeLog:
*
LGTM!
Thanks!
在 2024/1/23 上午2:42, Xi Ruoyao 写道:
Binutils 2.42 supports TLS LD/GD relaxation which requires the assembler
macro.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
If la_opt_explicit_relocs is EXPLICIT_RELOCS_AUTO, return false
> Date: Mon, 22 Jan 2024 14:33:59 -0500
> From: Marek Polacek
Oh, there was more... Also, I think I misinterpreted your
reply as meaning that the test-case is ice-on-invalid and I
wrongly replied in agreement to that misinterpretation. :)
(For others at a comparable level of (lack of) C++
This patch to the Go frontend stops passing the iota value to the
lowering pass. It is no longer used. The iota value is now handled
in the determine-types pass. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
896148947b9ff4845c8bc334f8eff30f91ff3c9a
diff
> Date: Mon, 22 Jan 2024 14:33:59 -0500
> From: Marek Polacek
> On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> > I don't really know whether this is the right way to treat
> > CONVERT_EXPR as below, but... Regtested native
> > x86_64-linux-gnu. Ok to commit?
>
> Thanks
In spite of the plea "Please try to keep this file in ASCII collating
order" at the top of the file, the sorting of the entries for the
various -Wfoo options had increased in entropy. This made it hard to
correlate them against e.g. the list of options enabled by -Wall in
the manual (see
gcc/ChangeLog
PR c++/90463
* doc/invoke.texi (Warning Options): Correct lists of options
enabled by -Wall and -Wextra by checking against common.opt
and c-family/c.opt.
---
gcc/doc/invoke.texi | 79 -
1 file changed, 50
This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
This patch caused problems for some users when building gdb, because
it would cause 'guild' to be invoked with the wrong versin of guile.
On the whole it seems simpler to just back this out.
* Makefile.in: Rebuild.
*
Eric> I mean, I've been trying to figure out how to re-run cgen myself, to
Eric> regenerate some cgen-erated files in libopcodes to fix some compiler
Eric> warnings in them, but it's pretty hard to do so; I'd really appreciate
Eric> it if the whole process of regenerating files with cgen could be
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Real-world experience shows that -Wdangling-reference triggers for
user-defined std::span-like classes a lot. We can easily avoid that
by considering classes like
template
struct Span {
T* data_;
std::size
On 22/01/2024 17:09, Richard Sandiford wrote:
> Sorry for the earlier review comment about debug insns. I hadn't
> looked far enough into the queue to see this patch.
>
> Alex Coplan writes:
> > As the PR shows, we were missing code to update debug uses in the
> > load/store pair fusion pass.
On 22/01/2024 15:59, Richard Sandiford wrote:
> Alex Coplan writes:
> > As the PR shows (specifically #c7) we are missing updating uses of mem
> > when inserting an stp in the aarch64 load/store pair fusion pass. This
> > patch fixes that.
> >
> > RTL-SSA has a simple view of memory and by
On 22/01/2024 13:49, Richard Sandiford wrote:
> Alex Coplan writes:
> > In r14-5820-ga49befbd2c783e751dc2110b544fe540eb7e33eb I added support to
> > RTL-SSA for inserting new insns, which included support for users
> > creating new defs.
> >
> > However, I missed that apply_changes_to_insn needed
On 22/01/2024 13:45, Richard Sandiford wrote:
> Alex Coplan writes:
> > This exposes an interface for users to create new uses in RTL-SSA.
> > This is needed for updating uses after inserting a new store pair insn
> > in the aarch64 load/store pair fusion pass.
> >
> > gcc/ChangeLog:
> >
> >
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
This patch extends g++.dg/warn/Wdangling-reference17.C with code
from PR109642. I'm not creating a new test because this one
already #includes the required headers.
PR c++/109642
gcc/testsuite/ChangeLog:
*
Hi
This patch adds support for the indirect clause on the OpenMP 'declare
target' directive in Fortran. As with the C and C++ front-ends, this
applies the 'omp declare target indirect' attribute on affected function
declarations. The C test cases have also been translated to Fortran
where
Hi
There was a bug in the declare-target-indirect-2.c libgomp testcase
(testing indirect calls in offloaded target regions, spread over
multiple teams/threads) that due to an errant fallthrough in a switch
statement resulted in only one indirect function ever getting called:
switch (i % 3)
Testing showed that the libgomp.c/target-52.c failed with:
libgomp: cuCtxGetDevice error: unknown cuda error libgomp: device
finalization failed This testcase uses OMP_DISPLAY_ENV=true and
OMP_TARGET_OFFLOAD=mandatory, and those env vars matter, i.e. it only
fails if dg-set-target-env-var is
On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> I don't really know whether this is the right way to treat
> CONVERT_EXPR as below, but... Regtested native
> x86_64-linux-gnu. Ok to commit?
Thanks for taking a look at this problem.
> brgds, H-P
>
> -- >8 --
> That
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Add -gno-strict-dwarf to dg-options in various btf enum tests
The -gno-strict-dwarf option is needed to ensure enum signedness
is added to type_die.
2024-01-22 John David Anglin
gcc/testsuite/ChangeLog:
PR debug/113382
Alex Coplan writes:
> Hi,
>
> The PR shows two different cases where try_promote_writeback produces an
> RTL pattern which isn't recognized. Currently this leads to an ICE, as
> we assert recog success, but I think it's better just to back out of the
> changes gracefully if recog fails (as we do
Binutils 2.42 supports TLS LD/GD relaxation which requires the assembler
macro.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
If la_opt_explicit_relocs is EXPLICIT_RELOCS_AUTO, return false
for SYMBOL_TLS_LDM and SYMBOL_TLS_GD.
On Mon, Jan 22, 2024 at 8:58 AM Jan Hubicka wrote:
>
> > I compared GCC master branch bootstrap and test times on a slow machine
> > with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13
> > with the backported patch. The performance data isn't precise since the
> >
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13?
-- >8 --
Here we handle the operator expression u < v inconsistently: in a SFINAE
context (such as a requires-expression) we accept the it, and in a
non-SFINAE context we reject it with
error: request for
> Hi,
>
> PR 108007 is another manifestation where we rely on DCE to clean-up
> after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
> can leave behind statements which are fed uninitialized values and
> trap, even though their results are themselves never used.
>
> I have already
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
*
v2 -> v3:
* Updated rtl for cnt, ff1, fl1, bclr, bset, insert and extract[u].
* cv.bitrev requires groups of bits to reverse order. bitreverse does not
support this.
This patch series presents the comprehensive implementation of the BITMANIP
extension for CORE-V.
Tested with
Sorry for the earlier review comment about debug insns. I hadn't
looked far enough into the queue to see this patch.
Alex Coplan writes:
> As the PR shows, we were missing code to update debug uses in the
> load/store pair fusion pass. This patch fixes that.
>
> Note that this patch depends on
> Hi,
>
> When the check for exceeding param_ipa_cp_value_list_size limit was
> modified to be ignored for generating values from self-recursive
> calls, it should have been changed from equal to, to equals toor is
> greater than. This omission manifests itself as PR 113490.
>
> When I examined
I don't really know whether this is the right way to treat
CONVERT_EXPR as below, but... Regtested native
x86_64-linux-gnu. Ok to commit?
brgds, H-P
-- >8 --
That gcc_unreachable at the default-label seems to be over
the top. It seems more correct to just say "that's not
constant" to
> I compared GCC master branch bootstrap and test times on a slow machine
> with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13
> with the backported patch. The performance data isn't precise since the
> measurements were done on different days with different GCC sources under
One update, last Friday, I merged all my patches for counted-by support
(including the Patch to workaround the LTO issue) with the latest trunk,
bootstrapped
and run the testing, everything is good.
Today, when I disabled the Patch that workaround the LTO issue, surprisingly, I
cannot
repeat
On 22/01/2024 12:18, Matthieu Longo wrote:
> rev16 pattern was not recognised anymore as a change in the bswap tree
> pass was introducing a new GIMPLE form, not recognized by the assembly
> final transformation pass.
>
> More details in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
>
>
Alex Coplan writes:
> While working on PR113089, I realised we where missing code to re-parent
> trailing nondebug uses of the base register in the case of cancelling
> writeback in the load/store pair pass. This patch fixes that.
>
> Bootstrapped/regtested as a series on aarch64-linux-gnu
On 1/15/24 06:34, Richard Biener wrote:
The following adjusts find_base_value similar as to what
find_base_term was adjusted for PR113255.
* alias.cc (known_base_value_p): Remove.
(find_base_value): Remove PLUS/MINUS handling
when both operands are not CONST_INT_P.
Alex Coplan writes:
> This patch adds some accessors to set_info and use_info to make it
> easier to get at and iterate through uses in debug insns.
>
> It is used by the aarch64 load/store pair fusion pass in a subsequent
> patch to fix PR113089, i.e. to update debug uses in the pass.
>
>
Alex Coplan writes:
> Hi,
>
> For the testcase in the PR, we try to pair insns where the first has
> writeback and the second uses the updated base register. This causes us
> to record a hazard against the second insn, thus narrowing the move
> range away from the end of the BB.
>
> However, it
On Fri, 19 Jan 2024 at 18:27, Tobias Burnus wrote:
> The problem is as described at
> https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa
>
> "Note that support for Fiji devices has been removed in ROCm 4.0 and
> support in LLVM is deprecated and will be removed in LLVM 18."
>
> Therefore,
Alex Coplan writes:
> As the PR shows (specifically #c7) we are missing updating uses of mem
> when inserting an stp in the aarch64 load/store pair fusion pass. This
> patch fixes that.
>
> RTL-SSA has a simple view of memory and by default doesn't allow stores
> to be re-ordered w.r.t. other
On 1/22/24 00:45, Richard Biener wrote:
On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
Am 18.01.24 um 20:54 schrieb Roger Sayle:
This patch tweaks RTL expansion of multi-word shifts and rotates to use
PLUS rather than IOR for disjunctive operations. During expansion of
these
On Sun, Jan 21, 2024 at 8:03 PM Hongtao Liu wrote:
>
> On Sat, Jan 20, 2024 at 10:30 PM H.J. Lu wrote:
> >
> > When an interrupt handler is implemented by an assembly stub which does:
> >
> > 1. Save all registers.
> > 2. Call a C function.
> > 3. Restore all registers.
> > 4. Return from
On 21/01/2024 07:29, Andrew Pinski wrote:
> So the problem here is the 2 functions check_cpu and check_arch use
> the wrong variable to check if an alias is valid for that cpu/arch.
> check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases
> is an array of index'ed by the cpuname
When an interrupt handler is implemented by an assembly stub which does:
1. Save all registers.
2. Call a C function.
3. Restore all registers.
4. Return from interrupt.
it is completely unnecessary to save and restore any registers in the C
function called by the assembly stub, even if they
There is no need to save callee-saved registers in noreturn functions
if they don't throw nor support exceptions. We can treat them the same
as functions with no_callee_saved_registers attribute.
Adjust stack-check-17.c for noreturn function which no longer saves any
registers.
With this
Changes in v2:
1. Rebase against commit f9df00340e3
2. Don't add redundant clobbered_registers check in ix86_expand_call.
In some cases, there are no need to save callee-saved registers:
1. If a noreturn function doesn't throw nor support exceptions, it can
skip saving callee-saved registers.
On 1/15/24 06:34, Richard Biener wrote:
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
src_ptr +
> On Jan 22, 2024, at 2:40 AM, Richard Biener
> wrote:
>
> On Fri, Jan 19, 2024 at 5:26 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 19, 2024, at 4:30 AM, Richard Biener
>>> wrote:
>>>
>>> On Thu, Jan 18, 2024 at 3:46 PM Qing Zhao wrote:
> On Jan 17, 2024, at 1:43 AM,
> From: Richard Biener
> Date: Mon, 22 Jan 2024 08:33:47 +0100
> > - "% function might not be inlinable");
> > + "% function is not always inlined"
> > + " unless also declared %");
>
> I don't like the "is not always inlined", maybe simply
On Mon, Jan 22, 2024 at 2:24 PM Richard Sandiford
wrote:
>
> Ping for the expr/cfgexpand bits
>
> Richard Sandiford writes:
> > Andrew Pinski writes:
> >> Ccmp is not used if the result of the and/ior is used by both
> >> a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
> >>
Alex Coplan writes:
> In r14-5820-ga49befbd2c783e751dc2110b544fe540eb7e33eb I added support to
> RTL-SSA for inserting new insns, which included support for users
> creating new defs.
>
> However, I missed that apply_changes_to_insn needed updating to ensure
> that the new defs actually got
On Mon, 22 Jan 2024 at 09:51, Jonathan Wakely wrote:
>
> On Sun, 21 Jan 2024 at 22:27, Jonathan Wakely wrote:
> > --- a/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> > +++ b/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> > @@ -17,6 +17,23 @@ test_ostream()
> >VERIFY( ss1.str() ==
Alex Coplan writes:
> This exposes an interface for users to create new uses in RTL-SSA.
> This is needed for updating uses after inserting a new store pair insn
> in the aarch64 load/store pair fusion pass.
>
> gcc/ChangeLog:
>
> PR target/113070
> * rtl-ssa/accesses.cc
LGTM.
Regards
Robin
> No, we didn't undo the optimization.
>
> We just disallow move pattern for (set (reg) (VL_REGNUM)).
Ah, what I referred to was the opposite direction. We allow
(subreg:V8QI (reg:DI ...)) which is not touched by this patch.
Then it is OK.
Regards
Robin
On 09/01/2024 18:43, Jeff Law wrote:
On 1/8/24 06:14, Mary Bennett wrote:
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Alex Coplan writes:
> The next patch in this series exposes an interface for creating new uses
> in RTL-SSA. The intent is that new user-created uses can consume new
> user-created defs in the same change group. This is so that we can
> correctly update uses of memory when inserting a new store
Ping for the expr/cfgexpand bits
Richard Sandiford writes:
> Andrew Pinski writes:
>> Ccmp is not used if the result of the and/ior is used by both
>> a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
>> here by using ccmp in this case.
>> Two changes is required, first we
rev16 pattern was not recognised anymore as a change in the bswap tree
pass was introducing a new GIMPLE form, not recognized by the assembly
final transformation pass.
More details in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
gcc/ChangeLog:
PR target/108933
*
On Mon, 22 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Jan 22, 2024 at 11:56:11AM +0100, Richard Biener wrote:
> > > I guess the || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT
> > > conditions make no sense, all we care is whether it fits in the buffer
> > > or not.
> > > But
Hi!
On Mon, Jan 22, 2024 at 11:56:11AM +0100, Richard Biener wrote:
> > I guess the || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT
> > conditions make no sense, all we care is whether it fits in the buffer
> > or not.
> > But then there is
> > fold_view_convert_expr
> > (and other
No, we didn't undo the optimization.
We just disallow move pattern for (set (reg) (VL_REGNUM)).
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-22 19:25
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Fix regressions due to
Hi Juzhe,
in principle this seems ok to me but I wonder about:
> We shouldn't worry about subreg:...VL_REGNUM since it's impossible
> that we can have such situation,
I think we allow this in legitimize_move for situations like
(subreg:SI (reg:V4QI)). That was not added for correctness but
On Wed, Jan 17, 2024 at 10:51:16AM -0500, Jason Merrill wrote:
> On 1/17/24 01:33, Nathaniel Shead wrote:
> > On Mon, Jan 15, 2024 at 06:10:55PM -0500, Jason Merrill wrote:
> > > Under what circumstances does it make sense for CLASSTYPE_INTERFACE_ONLY
> > > to
> > > be set in the context of
Hi Richard,
The conditions for __ARM_BF16_FORMAT_ALTERNATIVE are redundant, so I wanted to
simplify it.
TARGET_BF16_SIMD implies TARGET_BF16_FP to be true as well.
#define TARGET_BF16_FP (TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP5 \
&& arm_arch8_2 && arm_arch_bf16)
On Mon, 22 Jan 2024, Jakub Jelinek wrote:
> On Mon, Jan 22, 2024 at 11:27:52AM +0100, Richard Biener wrote:
> > We run into
> >
> > static tree
> > native_interpret_int (tree type, const unsigned char *ptr, int len)
> > {
> > ...
> > if (total_bytes > len
> > || total_bytes *
On Mon, Jan 22, 2024 at 11:27:52AM +0100, Richard Biener wrote:
> We run into
>
> static tree
> native_interpret_int (tree type, const unsigned char *ptr, int len)
> {
> ...
> if (total_bytes > len
> || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT)
> return NULL_TREE;
>
>
On Sun, 21 Jan 2024 at 22:27, Jonathan Wakely wrote:
> --- a/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> +++ b/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> @@ -17,6 +17,23 @@ test_ostream()
>VERIFY( ss1.str() == ss2.str() );
> }
>
> +void
> +test_format()
> +{
> + using
This patch fixes the recent regression:
FAIL: gcc.dg/torture/float32-tg-2.c -O1 (internal compiler error: in
reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 (internal compiler error: in
This refactors the handling of PHIs inbetween the main and the
epilogue loop. Instead of trying to handle the multiple exit
and original single exit case together the following separates
these cases resulting in much easier to understand code.
Bootstrap and regtest running on
Hello,
as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79106 is still open from what I
can tell, I wanted to gently bump this patch I provided a while back. It was
earmarked for gcc-11 in
https://gcc.gnu.org/pipermail/gcc-patches/2020-January/539201.html but did not
make it into the release.
gentle ping,
with the increasing use of CI, it seems an idea to tackle this sooner rather
than later.
thanks
Iain
> On 16 Jan 2024, at 11:12, Iain Sandoe wrote:
>
> Tested on x86_64, i686 Darwin, x86_64 Linux,
> OK for trunk? When?
> thanks
> Iain
>
> --- 8< ---
>
> Currently when a test
gentle ping,
this fixes quite a few of the new jit fails on darwin.
thanks
Iain
> On 16 Jan 2024, at 11:10, Iain Sandoe wrote:
>
> Tested on x86_64, i686 Darwin and x86_64 Linux,
> OK for trunk? when ?
> thanks,
> Iain
>
> --- 8< ---
>
> Currently, we have no exports list for libgccjit, which
83 matches
Mail list logo
