: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since commit gcc-15-3735-g664e0ce580a8, we have noticed failures in
gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116260
--- Comment #3 from Christophe Lyon ---
Thanks for the additional information, indeed in our CI we do not run
validations for several "variations", so it's not surprising this case is not
handled very well.
So you suggest having one manifest pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
||clyon at gcc dot gnu.org
Status|ASSIGNED|RESOLVED
--- Comment #23 from Christophe Lyon ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Bug 115635 depends on bug 115661, which changed state.
Bug 115661 Summary: [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu
since r15-1599-g63512c72df09b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #16 from Christophe Lyon ---
(In reply to Richard Biener from comment #15)
> OK, looking the fix was only half complete. Can you try
It works with this, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #14 from Christophe Lyon ---
Created attachment 58522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58522&action=edit
Wrong code after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #13 from Christophe Lyon ---
Yes it breaks at the same point, again we are returning an uninitialized value.
Adding annotate asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #11 from Christophe Lyon ---
Created attachment 58520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58520&action=edit
vect dump broken after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #5 from Christophe Lyon ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*). (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #2 from Christophe Lyon ---
Created attachment 58431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58431&action=edit
vect dump OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #3 from Christophe Lyon ---
Created attachment 58432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58432&action=edit
vect dump broken
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Created attachment 58428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58428&action=edit
Code generated bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #1 from Christophe Lyon ---
Created attachment 58429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58429&action=edit
Wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since gcc-15-276-gbed6ec161be (g:bed6ec161be8c5ca2f24195900ce3c9b81c3e141) we
have noticed a regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Christophe Lyon changed:
What|Removed |Added
Target|arm |arm aarch64
--- Comment #2 from Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #32 from Christophe Lyon ---
Created attachment 58110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110&action=edit
patch v2
Here is another patch proposal along the lines of what you suggest in #c24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #30 from Christophe Lyon ---
> ./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
> pr114801.c -mthumb -O2 -da
Thanks, for some reason -O2 had disappeared from my flags, it does ICE with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #27 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #25)
>
> Indeed, it ICEs e.g. during CSE.
> Though, that also means it is just about luck, if something isn't a
> CONST_INT at expansion time but simplified into C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #26 from Christophe Lyon ---
Thanks for testing, my build is still in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #22 from Christophe Lyon ---
Sure, that's what I'm worried about.
So we can:
- leave this as-is for gcc-14 (known bug)
- commit what we discussed in #c15 #c16, (with an improved testcase as you
mentioned on the list,) thus at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #19 from Christophe Lyon ---
So basically values such as 0x are not UB and we want to accept them.
I tested:
diff --git a/gcc/rtx-vector-builder.cc b/gcc/rtx-vector-builder.cc
index 9509d9fc453..f89aa717903 100644
--- a/gcc/rtx-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #16 from Christophe Lyon ---
Thanks for the suggestion, this works.
I've posted the patch + testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #14 from Christophe Lyon ---
Created attachment 58050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050&action=edit
patch proposal
Here is the patch I propose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #12 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #11)
> So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> same size, 2 bytes, so I'd go with
> else if (VALID_MVE_PRED_MODE (mode))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #8 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #5)
> Guess the primary question is why there is the gen_lowpart call at all.
> Is it that normally the mode of x is already right due to the prototypes of
> the bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #7 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > lowpart_subreg does not work either.
> >
> > If we put the predicates in a variable in the testcase, then in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #3 from Christophe Lyon ---
lowpart_subreg does not work either.
If we put the predicates in a variable in the testcase, then in
function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
116 [ _3 ]) 0) so taking g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #7 from Christophe Lyon ---
So yes indeed at r14-5423-gfbe4e64365ec7f, autoreconf will generate the same
contents, but starting at r14-5424-gdb50aea6259545 we get this discrepancy.
We can probably commit the "fixed" version, but sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #6 from Christophe Lyon ---
(In reply to Andrew Pinski from comment #1)
> The last time aclocal.m4 had an include for override.m4 was
> r9-3776-g22e052725189a4 .
IIUC that commit actually removed the include for override.m4 ?
> Ar
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Running either 'autoreconf' or 'aclocal -I ../config' in libcpp/ generates
aclocal.m4 and configure scripts with slightl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
--- Comment #4 from Christophe Lyon ---
I'm wondering whether you missed check_effective_target_arm_arch_FUNC_link and
friends?
Maybe check_effective_target_arm_arch_v7a_neon_link would work here, but it
does not use the exact same flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
--- Comment #2 from Christophe Lyon ---
I think the last -march option overrides the previous one(s).
I'd say the test should use an effective-target which checks that linking is
actually OK rather than just a compile OK test. Not sure if an ad
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
After g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #5 from Christophe Lyon ---
Exactly. I have a (one-line) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2024-03-14
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
--- Comment #3 from Christophe Lyon ---
What I meant by arm-* is that we see the same issue on several of the
configurations we test, as can be seen on
https://linaro.atlassian.net/browse/GNU-1100
We have recently improved the extraction of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Also seen on arm targets.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
We have detected the following regression since gcc-14-7124-g6686e16fda4:
FAIL: gcc.dg
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: tamar.christina at arm dot com
Target Milestone: ---
Since g:7cbe41d35e6 (gcc-14-7115-g7cbe41d35e6), we have noticed the following
regression on
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
A few analyzer tests relying on fileno() fail on arm-eabi:
c-c++-common/analyzer/fileno-1.c
c-c++-common/analyzer/flex-with-call
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637422.html
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit g:ed52bc2e30c (arm: testsuite: avoid hard-float ABI
incompatibility with -march) a few testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #4 from Christophe Lyon ---
@mkretz, this commit may also be of interest for some more context:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d12d2aa4fccc76a9a08c8120c5e37d9cab8683e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #1 from Christophe Lyon ---
For gcc.target/arm/bfloat16_vector_typecheck* tests, the log says:
FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors)
Excess errors:
bfloat16_vector_typecheck_1.c:122:17: error: in
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
Commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #3 from Christophe Lyon ---
The original problem is fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628998.html, and it seems
better not to call GLIBCXX_CHECK_LINKER_FEATURES and silently hide a potential
problem.
May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #2 from Christophe Lyon ---
Oops sorry I pushed an unwanted patch, which I reverted with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #12 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #11)
> Please file a separate bug for these failures.
Thanks for the pointers, I digged a bit more, and filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1112
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
Target Milestone: ---
As a follow-up to bug #104167, I've looked in more detail after Jonathan&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Christophe Lyon from comment #8)
> > On arm-eabi targets (thus, using newlib), we've noticed new errors:
>
> New since when? These files haven
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit r14-3110-g7fb65f10285 (MATCH: [PR110937/PR100798] (a ? ~b : b)
should be optimized to b ^ -(a)), I have noticed regressions on aarch64:
Running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #8 from Christophe Lyon ---
Created attachment 55707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55707&action=edit
pr110378-1.C.083i.sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #20 from Christophe Lyon ---
Sorry for the typo in the date in the commit message :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #17 from Christophe Lyon ---
Thanks Andrew, I wasn't aware of vect_float_strict.
I confirm it makes the test UNSUPPORTED.
Can you commit the fix or do you want me to do it on your behalf?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #15 from Christophe Lyon ---
(In reply to Richard Biener from comment #14)
> (In reply to Christophe Lyon from comment #12)
> > The new testcase (gcc.dg/vect/pr110381.c) fails:
> > FAIL: gcc.dg/vect/pr110381.c -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Christophe Lyon changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Christop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
--- Comment #2 from Christophe Lyon ---
This regression appeared after the patch that re-implements vdupq, but the
issue is likely more generic.
velo r
I tried to update arm_init_mve_builtins() with:
+ if (in_lto_p)
+ {
+ arm_mve::handle
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since I rewrote (a lot of) MVE intrinsics, use of LTO is broken:
$ cat ~/t.c
#include
int main(void)
{
return vaddvq(vdupq_n_s8 (1));
}
# no LTO, OK:
$ arm-none-eabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #3 from Christophe Lyon ---
So we have a different behavior in
libstdc++-v3/include/experimental/bits/simd_detail.h:
#if defined __ARM_NEON && (__ARM_ARCH >= 8 || defined __aarch64__)
#define _GLIBCXX_SIMD_HAVE_NEON_A32 1
#else
#defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #2 from Christophe Lyon ---
Just noticed that the test passes if GCC is configured --with-arch=armv7-a, but
fails when forcing -march=armv8-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit g:668d43502f465d48adbc1fe2956b979f36657e5f, I've noticed that
experim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #11 from Christophe Lyon ---
Thanks, trunk is now OK on both arm and aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #8 from Christophe Lyon ---
I guess gcc185 is an aarch64 machine? (as opposed to arm)
I confirm your patch fixes the problem on aarch64 (the testcase now passes),
but it still fails on arm, with:
/arm-linux-gnueabihf/libstdc++-v3/in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #6 from Christophe Lyon ---
> trunk or the backport? I tested trunk on gcc185. Will check.
That's on trunk (didn't check on the branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #5 from Christophe Lyon ---
Not sure how to update/fix the testcases though?
Since they get the declaration of fclose from stdio.h, we'd need to make
dg-error conditional to the glibc version in use, which seems unpractical.
Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Christophe Lyon from comment #0)
> > Maybe there's something wrong with the detection of HAVE_GETENTROPY in
> > configure?
>
> We only do a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Christophe Lyon changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
--- Comment #5 from Christophe Lyon ---
Fixed on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #10 from Christophe Lyon ---
Can you try to revert my patches:
f0d3b6e384a68f8b58bc750f240a15cad92600cd
ccb9c7b129206209cfc315ab1a0432b5f517bdd9
and remove your patch at comment #5 ?
You should still see the problem you reported in b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #6 from Christophe Lyon ---
(In reply to James McKelvey from comment #5)
> This works:
>
> $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64
> 2c2
> < MULTILIB_DIRNAMES = 64
> ---
> > MULTILIB_DIRNAMES = 64 32
I gue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #4 from Christophe Lyon ---
Indeed my patch aimed at catching such inconsistencies.
I guess before that the build had a 'strange' behavior? (with a missing
dirname, some parts of the shell genmultilib shell script would expand into
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #3 from Christophe Lyon ---
and patching test_dfp_17.c like so:
- ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */
+ ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */
makes it pass on aa
1 - 100 of 1134 matches
Mail list logo
