https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113155
--- Comment #6 from Sergey Kirdyankin ---
bin>arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=C:/work/distributiv/arm-gnu-toolchain-13.2/bin/../libexec/gcc/arm-none-eabi/13.2.1/lto-wrapper.exe
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113155
--- Comment #5 from Andrew Pinski ---
Again how did you configure gcc because that changes which libgcc is being used
and with what options?
Also I suspect you should just be using -march=armv7e-m+fp instead.
Provide the output of:
`arm-none-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160
--- Comment #2 from Yihua Liu ---
It seems that llvm member considers it a bug, see llvm-project Issue #76450.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #16 from Tamar Christina ---
>
> I wonder whether ARM SVE can also use this approach VEC_EXTRACT with index =
> 0.
Perhaps, I'll look into it thanks. though this is ofcourse only applicable when
the mask comes from whilelo.
In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113155
--- Comment #4 from Sergey Kirdyankin ---
Compiler command line (platform configure):
arm-none-eabi-gcc -march=armv7e-m -mcpu=cortex-m4 -mfloat-abi=hard
-mfpu=fpv4-sp-d16 -mthumb ...
Disassembler:
080016c0 <__aeabi_f2ulz>:
80016c0: b5d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160
--- Comment #1 from Andrew Pinski ---
This is also fails with clang and libc++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #15 from Tamar Christina ---
(In reply to JuzheZhong from comment #14)
> > > > sure, but you can't use BIT_FIELD_REF on VLA vectors.
> > >
> > > So, for length partial vector. We can use VEC_EXTRACT with index = 0 since
> > > VEC_EX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #14 from JuzheZhong ---
(In reply to Tamar Christina from comment #13)
> (In reply to JuzheZhong from comment #12)
> > (In reply to Tamar Christina from comment #11)
> > > (In reply to JuzheZhong from comment #10)
> > > > (In reply t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #13 from Tamar Christina ---
(In reply to JuzheZhong from comment #12)
> (In reply to Tamar Christina from comment #11)
> > (In reply to JuzheZhong from comment #10)
> > > (In reply to Tamar Christina from comment #9)
> > > > (In rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #12 from JuzheZhong ---
(In reply to Tamar Christina from comment #11)
> (In reply to JuzheZhong from comment #10)
> > (In reply to Tamar Christina from comment #9)
> > > (In reply to JuzheZhong from comment #8)
> > > > Suppose the l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #11 from Tamar Christina ---
(In reply to JuzheZhong from comment #10)
> (In reply to Tamar Christina from comment #9)
> > (In reply to JuzheZhong from comment #8)
> > > Suppose the loop mask is generated by whilelo instruction of AR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #10 from JuzheZhong ---
(In reply to Tamar Christina from comment #9)
> (In reply to JuzheZhong from comment #8)
> > Suppose the loop mask is generated by whilelo instruction of ARM SVE.
> >
> > Suppose we have 8 elements in a singl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #9 from Tamar Christina ---
(In reply to JuzheZhong from comment #8)
> Suppose the loop mask is generated by whilelo instruction of ARM SVE.
>
> Suppose we have 8 elements in a single whole vector.
>
> mask = whilo (0, res) if res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #8 from JuzheZhong ---
(In reply to Tamar Christina from comment #7)
> You may be able to use the same approach as
>
> else if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
>
> that is, reverse both the mask and the vector and using e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160
Bug ID: 113160
Summary: Const valarray (g)slice and indirect_array fail to
match valarray in template functions
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #7 from Tamar Christina ---
You may be able to use the same approach as
else if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
that is, reverse both the mask and the vector and using extract last.
It's not going to be performance criti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #6 from Tamar Christina ---
(In reply to JuzheZhong from comment #5)
> (In reply to Tamar Christina from comment #4)
> > (In reply to JuzheZhong from comment #3)
> > > I guess this code is just disabling partial vector for length for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #5 from JuzheZhong ---
(In reply to Tamar Christina from comment #4)
> (In reply to JuzheZhong from comment #3)
> > I guess this code is just disabling partial vector for length for now.
> >
> > And need me to test and port this par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #4 from Tamar Christina ---
(In reply to JuzheZhong from comment #3)
> I guess this code is just disabling partial vector for length for now.
>
> And need me to test and port this part for length in the followup patches.
>
> Am I r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #12 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #3 from JuzheZhong ---
Thanks Tamar. And I agree with you. This is not supposed to let early break to
handle that. It should be optimization on scalar IR instead of loop
vectorizer.
I believe it is GCC-15 topic.
Btw, I am trying t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113154
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #8 from kargl at gcc dot gnu.org ---
Created attachment 56956
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56956&action=edit
git diff cannot find trigpi.c (updated file)
The new file tries to deal with a system with REAL(4),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #7 from kargl at gcc dot gnu.org ---
Created attachment 56955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56955&action=edit
test program for inverse functions
The attach program tests the inverse functions, e.g., acospi, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #10 from Ian Lance Taylor ---
The makecontext/getcontext/setcontext functions are called by libgo on
GNU/Linux for all targets other than x86_64. It is not the case that they are
used only on *BSD systems.
The default gc implementa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Bug ID: 113159
Summary: More robust std::sort for silly comparator functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #6 from Mikael Pettersson ---
Affects gcc-11 and newer, gcc-10 and older are ok. Started with:
d10f3e900b0377b4760a090b0f90371bcef01686 is the first new commit
commit d10f3e900b0377b4760a090b0f90371bcef01686
Author: qing zhao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99980
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158
Andrew Pinski changed:
What|Removed |Added
Summary|Erroneous "looser exception |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:019abe7aa98feae1514c0e51c51fe424e28e2c21
commit r13-8181-g019abe7aa98feae1514c0e51c51fe424e28e2c21
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #6 from kargl at gcc dot gnu.org ---
In reflecting on the possibility of an OS lacking support for
REAL(10) but having a REAL(16), the mapping of types into
C are likely REAL(4) <--> float, REAL(8) <--> double, and
REAL(16) <--> long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158
Bug ID: 113158
Summary: Erroneous "looser exception specification" error for
class template
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #5 from Alexey Dobriyan ---
My standardspeak is very bad.
I think std::is_trivial_v types should have relaxed initialisation ordering,
because all C structs and unions are std::is_trivial_v.
If I understand this stuff correctly, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113157
Bug ID: 113157
Summary: compilation error in PGO
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
Tamar Christina changed:
What|Removed |Added
Last reconfirmed|2023-12-25 00:00:00 |2023-12-27
Summary|Middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113136
--- Comment #8 from Tamar Christina ---
Thanks, was able to reproduce with `--enable-checking=yes,rtl,extra`.
The issue seems to be that the value is unused, and we were relying on DSE
removing such statement. but with --enable-checking=yes,rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #23 from YunQiang Su ---
I guess, we should drop TRULY_NOOP_TRUNCATION_MODES_P and
TARGET_MODE_REP_EXTENDED for MIPS. In fact, it will only effect MIPS64 SI->DI.
Then it may reduce the maintain workload for MIPS64.
Let's have a try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113136
--- Comment #7 from Tamar Christina ---
(In reply to Sam James from comment #6)
> Can you try with --enable-checking=yes,rtl,extra? I can reproduce this on
> godbolt too: https://godbolt.org/z/56r9ejMn5.
trying with that.. from the dump on godb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113136
--- Comment #6 from Sam James ---
Can you try with --enable-checking=yes,rtl,extra? I can reproduce this on
godbolt too: https://godbolt.org/z/56r9ejMn5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #4 from Andrew Stubbs ---
It's going to be difficult to make this test work when only one page of locked
memory is available. :-(
I will look at making it "unsupported".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Pilar Latiesa changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #7 from Tamar Christina ---
Have update the memory analysis part to support inverted loops. now working on
wiring through virtual phis during peeling.
Aside form this missing part CFG looks correct. will have a final patch in a
bit
install --enable-checking=release
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231227 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144
--- Comment #6 from Tamar Christina ---
Created attachment 56954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56954&action=edit
candidate-patch1.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144
--- Comment #5 from Tamar Christina ---
Loop seems to have been peeled and versioned, and has very convoluted sequence
of merge blocks for the exits.
I initially thought it would be enough to update the immediate reachable blocks
from the new e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033
--- Comment #12 from Xi Ruoyao ---
Missed-optimization fixed at r14-6851.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113148
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113148
--- Comment #5 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:f19ceb2d49afdfa527d2109476a3f1d383c47e1b
commit r14-6852-gf19ceb2d49afdfa527d2109476a3f1d383c47e1b
Author: Xi Ruoyao
Date: Wed Dec 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113112
--- Comment #3 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:c4ac073d4fc7474e29d085bbd10971138ee7478e
commit r14-6850-gc4ac073d4fc7474e29d085bbd10971138ee7478e
Author: Juzhe-Zhong
Date: Wed Dec 27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
--- Comment #1 from Andrew Pinski ---
Most like __optimize__ ("-fno-tree-loop-distribute-patterns") was not working
for avr before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
Bug ID: 113156
Summary: AVR build broken due to ICE while compiling libgcc,
started with r14-6201-gf0a90c7d7333fc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
58 matches
Mail list logo
