https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108816
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224
Alexandre Oliva changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
In the case of the CALL0 ABI, values that must be retained before and
after function calls are placed in the callee-saved registers (A12
through A15) and referenced later. However, it is often the case that
the save and the reference are each only once and a simple register-
register move (with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #8 from Alexandre Oliva ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612198.html has a
simple-minded implementation, that should make it clear what I mean by scratch:
get() pays no regard to the incoming bits in tm, it
On Thu, Feb 16, 2023 at 3:34 PM Andrew MacLeod wrote:
>
>
> On 2/16/23 02:55, Richard Biener wrote:
> > On Wed, Feb 15, 2023 at 6:07 PM Andrew MacLeod via Gcc-patches
> > wrote:
> >> This patch implements the suggestion that we have an alternative
> >> ssa-cache which does not zero memory, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
--- Comment #7 from Henning Baldersheim ---
Thanks, perhaps add 104688 to the see also list.
On Fri, Feb 17, 2023 at 8:09 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> check_dangling_stores has some weirdnesses that causes its behavior to
> change when the target ABI requires C++ ctors to return this: while
> scanning stmts backwards in e.g. the AS ctor on a target that returns
> this
On platforms that fail the ptrtomemfn-cast-to-pfn hack, such as
arm-*-vxworks*, time_get fails with %I and %p because the state is not
preserved across do_get calls.
This patch introduces an alternate hack, that encodes the state in
unused bits of struct tm before calling do_get, extracts them
On vxworks, after destroying the semaphore used to implement a mutex,
__gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls
__throw_concurrence_lock_error. Nothing ensures the mutex_pool
mutexes survive init-once objects containing _Safe_sequence_base. If
such an object completes
Even with vcvt.f32.f64, the FE_UPWARD test rounds down and fails. I'm
not sure whether this opcode disregards the rounding mode (it looks
like it should take it into account) or it is a qemu bug, but it does
not look like GCC is doing anything wrong, and the test fails, so I'm
marking the fail
vxworks ignores O_EXCL in open, so noreplace open succeeds when it is
expected to fail. xfail the tests.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
for libstdc++-v3/ChangeLog
*
The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only
tests for compile-time support. Add a requirement for mve hardware.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
for gcc/testsuite/ChangeLog
PR target/104882
On Thu, 16 Feb 2023, Uros Bizjak wrote:
> simplify_subreg can return VOIDmode const_int operand and will
> cause ICE in simplify_gen_subreg when this operand is passed to it.
>
> The patch prevents VOIDmode temporary from entering simplify_gen_subreg.
> We can't process const_int operand any
Back in September last year, some of the vmsr and vmrs patterns had an
extraneous blank removed, and the case of register names lowered, but
another instance remained, and so did a few testcases.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to
On Thu, 16 Feb 2023, juzhe.zhong wrote:
> Thanks for the great work to fix this issue for rvv.Hi，richard. This is the
> patch to differentiate mask mode of same bytesize. Adjust the precision
> correctly according to rvv isa. Would you mind helping us with this patch ？
> Since it‘s very important
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #13 from rguenther at suse dot de ---
On Thu, 16 Feb 2023, qing.zhao at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
>
> --- Comment #8 from Qing Zhao ---
> > On Feb 16, 2023, at 2:35 AM, rguenther
Commit 3a7ba8fd0cda387809e4902328af2473662b6a4a, a patch for
tree-ssa-sink, enabled the removal of basic blocks in ways that
affected the generated code for both of these tests, deviating from
the expectations of the tests.
The simplest case is that of -2, in which the edge unsplitting ends up
The test uses arm_hard_ok and arm_softfp_ok as if they were mutually
exclusive, but they test whether the corresponding -mfloat-abi= flag
is usable, not whether it is in effect, so it is possible for both to
pass, and then the test comes out with incorrect expectations
whichever the default
Back when quotes were added around "+cdecp" in the "coproc must be
a constant immediate" error in arm-builtins.cc, tests for that message
lagged behind. Fixed thusly.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
for
Thank you all.
Hi Richard,
Could you please help to review the precision adjustment related change when
you free? I am looking forward your option of this issue from the expert’s
perspective, !
Pan
From: juzhe.zhong
Sent: Thursday, February 16, 2023 11:23 PM
To:
check_dangling_stores has some weirdnesses that causes its behavior to
change when the target ABI requires C++ ctors to return this: while
scanning stmts backwards in e.g. the AS ctor on a target that returns
this in ctors, the scan first encounters a copy of this to the SSA
name used to hold
The expected asm output for aes-fuse-[12].c does not correspond to
that which is generated when -mfix-cortex-a57-aes-1742098 is enabled.
It was introduced after the test, and enabled by default for the
selected processor. Disabling the option restores the circumstance
that was tested for.
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t, headers got included in the test that declared functions that
take wint_t parameters,
cp_build_binary_op, that issues -Waddress warnings, issues an extra
warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
when comparing a pointer-to-member-function literal with null.
The reason for the extra warning is that, on arm targets,
TARGET_PTRMEMFUNC_VBIT_LOCATION ==
Though I is supposed to be a constant expression, this is not the case
on vxworks, but this is not what this debug information format test is
testing for, so use real constants to initialize complex variables.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi
When a multi-source module is found to be unsupported, we fail
module_cmi_p and subsequent sources. Override proc unsupported to
mark the result in module_do, and test it to skip module_cmp_p and
subsequent related tests.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and
The test is compatible with clang as well as gcc, but ISTM that
testing for the __clang__ macro is just as potentially error-prone as
macros that used to be GCC-specific are now defined in compilers that
aim for GCC compatibility. Use a __has_include feature test instead.
Regstrapped on
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570617.html
Bernd Edlinger reported that the 95989.cc
test fails without pthread_join at the end of main, but pthread_join
is no good for a test that doesn't require pthreads.
This patch adds a __gthread_join call instead.
Regstrapped
It wasn't long ago that I xfailed these tests on arm-*-eabi, but the
fail is expected on all other arm targets: even when hard float is
available, conversions between 64-bit integers and double are always
emulated on ARM, and the emulation disregards rounding modes. So,
bump the xfail to all of
The '#define func' added in 2021, to test that system headers don't
violate the user namespace, exposes such a bug in the vxworks sysLib.h
header, so add yet another such annotated workaround.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
Quotes were added around the "asm" keyword in the message expected by
the test, so the test needs adjusting.
Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).
Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/arm/asm-flag-4.c: Match quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108810
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2023-02-17
Status|UNCONFIRMED
On Apr 5, 2022, Alexandre Oliva wrote:
> Would something like this be acceptable/desirable? It's overreaching,
> in that not all arm platforms are expected to fail, but the result on
> them will be an unexpected pass, which is not quite as bad as the
> unexpected fail we get on most arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108814
Kewen Lin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
--- Comment #3 from Kewen Lin ---
*** Bug 108814 has been marked as a duplicate of this bug. ***
Ping. Please review the patch.
On 12/01/23 10:21 pm, Surya Kumari Jangala via Gcc-patches wrote:
> Ping
>
> On 04/01/23 1:58 pm, Surya Kumari Jangala via Gcc-patches wrote:
>> swap: Fix incorrect lane extraction by vec_extract() [PR106770]
>>
>> In the routine rs6000_analyze_swaps(), special
On 2023/02/16 7:18, Max Filippov wrote:
> Hi Suwa-san,
Hi!
>
> On Thu, Jan 26, 2023 at 7:17 PM Takayuki 'January June' Suwa
> wrote:
>>
>> In the case of the CALL0 ABI, values that must be retained before and
>> after function calls are placed in the callee-saved registers (A12
>> through A15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
--- Comment #2 from Kewen Lin ---
Created attachment 54478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54478=edit
untested patch
The lvsr and lvsl for generating permutation control vectors only works for LE
as the element ordering is
On 2023-02-16 10:15, David Malcolm via Gcc wrote:
I'm not convinced that it's useful to the end-user to warn about the
"use of q itself" case.
FWIW, -Wuse-after-free=3 already should do this:
At level 3, the warning also diagnoses uses of indeterminate pointers in
equality expressions. All
Committed as obvious:
commit 061b13ed014ba0b6891800a5c7f852bf58e4d856
Author: Jerry DeLisle
Date: Thu Feb 16 18:13:56 2023 -0800
Fortran Tests: Allow passing on mingw.
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to
dg-final.
and
Hi Segher,
Thanks for the comments!
on 2023/2/16 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 16, 2023 at 08:06:02PM +0800, Kewen.Lin wrote:
>> on 2023/2/16 19:14, Segher Boessenkool wrote:
>>> On Thu, Feb 16, 2023 at 05:23:40PM +0800, Kewen.Lin wrote:
This patch is to fix the
OK, I will send another one which remove riscv_scalar_crypto.h and update
testcases with __builtin_riscv_XX
-原始邮件-
发件人: "Kito Cheng"
发送时间: 2023-02-16 21:28:34 (星期四)
收件人: "Liao Shihua"
抄送: gcc-patches@gcc.gnu.org, jia...@iscas.ac.cn, m...@iki.fi,
pal...@dabbelt.com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #13 from Andrew Pinski ---
(In reply to Gabriel Ravier from comment #12)
> It appears this new optimization is non-functional on trunk with x86-64...
> specifically on x86-64, too, on AArch64 it works just fine. So does that
> mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
> On 17 Feb 2023, at 01:05, Alejandro Colomar via Gcc wrote:
>
> On 2/17/23 02:04, Alejandro Colomar wrote:
>> [CC: Added those who contributed to the discussion in linux-man@,
>> and also the authors of N2861 for C2x]
>
> [...]
>
>>
>> There was a discussion in linux-man@ some years
Hi,
在 2023/2/15 下午6:42, WANG Xuerui 写道:
Hi,
On 2023/2/13 18:38, Xi Ruoyao wrote:
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and
Hi,
Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611823.html
This patch does not define new insn for mtvsrws, but use exit one.
As mentioned in PR108338, on p9, we could use mtvsrws to implement
the bitcast from SI#0 to SF (or lowpart DI to SF).
For
On Tue, 14 Feb 2023, NightStrike wrote:
>> Alas http://www.wlandry.net/Projects/FTensor has been down for a while,
>> and there does not appear to be a new location?
> https://wlandry.net/Projects/FTensor/ works
Ah, indeed. Thank you! Somehow that must have been the one combination I
did not
On Tue, 14 Feb 2023, NightStrike wrote:
>> Alas http://www.wlandry.net/Projects/FTensor has been down for a while,
>> and there does not appear to be a new location?
> https://wlandry.net/Projects/FTensor/ works
Ah, indeed. Thank you! Somehow that must have been the one combination I
did not
On 2/17/23 02:04, Alejandro Colomar wrote:
> [CC: Added those who contributed to the discussion in linux-man@,
> and also the authors of N2861 for C2x]
[...]
>
> There was a discussion in linux-man@ some years ago, which now I realize it
> didn't end up being applied (I thought we had
[CC: Added those who contributed to the discussion in linux-man@,
and also the authors of N2861 for C2x]
Hi David,
On 2/16/23 16:15, David Malcolm wrote:
> On Thu, 2023-02-16 at 15:35 +0100, Alejandro Colomar via Gcc wrote:
>> Hi!
>>
>> I was preparing an example program of a
On Mon, 24 Sep 2018, Martin Liška wrote:
> As mentioned in the PR we miss defaults for quite some param option.
> I agreed with Richi that easiest way how to fix that would be to remove
> that from documentation and use rather --help=param. It's done in the
> patch.
And here is a little
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108830
Bug ID: 108830
Summary: Excess warnings from -Wanalyzer-null-dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108806
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
PR analyzer/108806 reports false +ves seen from -fanalyzer on code like this
in qemu-7.2.0's hw/intc/omap_intc.c:
[...snip...]
struct omap_intr_handler_bank_s* bank = NULL;
if ((offset & 0xf80) == 0x80) {
[...set "bank" to non-NULL...]
}
switch (offset) {
[...snip various cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108806
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:4d3b7be281e73ecdaa233598db1a8390422b7770
commit r13-6101-g4d3b7be281e73ecdaa233598db1a8390422b7770
Author: David Malcolm
Date:
Snapshot gcc-10-20230216 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20230216/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #10 from Aaron Ballman ---
One other reason for the Clang behavior that may be worth mentioning is that
this helps users who wish to migrate away from `__attribute__` and towards
`[[]]`. Many (most?) uses of attributes end up behind
Hi!
On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches"
wrote:
>> On 2022-06-09T11:38:22+0200, I wrote:
>> > [...]
>> > *register* your standard 'malloc'ed etc. memory via 'cuMemHostRegister',
>> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108824
Li Shaohua changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to qinzhao from comment #10)
> > the following patch fixed this issue:
>
> This would leak memory.
thank you, I will fix the memory
Hi!
On 2023-02-14T15:11:14+, Andrew Stubbs wrote:
> On 14/02/2023 12:54, Thomas Schwinge wrote:
>> On 2022-01-13T11:13:51+, Andrew Stubbs wrote:
>>> Updated patch: this version fixes some missed cases of malloc in the
>>> realloc implementation.
>>
>> Right, and as it seems I've run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #9 from David Binderman ---
(In reply to David Binderman from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > (In reply to David Binderman from comment #6)
> > > git range now seems to be g:0cbb756fe9c8e13a ..
Hi!
On 2022-01-13T13:53:03+, Andrew Stubbs wrote:
> Pinned memory is allocated via mmap
> --- /dev/null
> +++ b/libgomp/config/linux/allocator.c
> +static void *
> +linux_memspace_calloc (omp_memspace_handle_t memspace, size_t size, int pin)
> +{
> + if (pin)
> +return
Hi!
On 2023-02-10T15:31:47+, Andrew Stubbs wrote:
> On 10/02/2023 14:21, Thomas Schwinge wrote:
>> Is the correct fix the following [...]
>
> Yes, [...]
>>> --- a/libgomp/config/nvptx/allocator.c
>>> +++ b/libgomp/config/nvptx/allocator.c
>>> @@ -125,6 +125,8 @@ nvptx_memspace_alloc
Hi!
On 2023-02-16T18:06:41+, Andrew Stubbs wrote:
> 1. 230216-basic-allocator.patch
>
> Separate the allocator from NVPTX so the code can be shared.
Yay!
> nvptx, libgomp: Move the low-latency allocator code
>
> There shouldn't be a functionality change; this is just so AMD can share
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
Hi!
On 2022-10-24T17:26:44+0100, Andrew Stubbs wrote:
> I've committed this patch to the devel/omp/gcc-12 branch.
> --- a/libgomp/testsuite/libgomp.c/usm-1.c
> +++ b/libgomp/testsuite/libgomp.c/usm-1.c
> --- a/libgomp/testsuite/libgomp.c/usm-2.c
> +++ b/libgomp/testsuite/libgomp.c/usm-2.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #7 from Andrew Pinski ---
(In reply to David Binderman from comment #6)
> git range now seems to be g:0cbb756fe9c8e13a .. g:bd044dae51caea3c,
> which is 6 commits.
Most likely r13-3875-g9e11ceef165bc0 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #6 from David Binderman ---
git range now seems to be g:0cbb756fe9c8e13a .. g:bd044dae51caea3c,
which is 6 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #10 from qinzhao at gcc dot gnu.org ---
the following patch fixed this issue:
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index c555cf5cd50..eca727b010a 100644
--- a/gcc/tree-ssa-uninit.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #9 from qinzhao at gcc dot gnu.org ---
it's a bug in tree-ssa-uninit.cc actually.
when doing the following:
/* Ignore the call to .DEFERRED_INIT that define the original
var itself as the following case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #4)
> git range now seems to be g:59ad8b684dd67e17 .. g:3b54cc9d04c2efb2,
> which is 103 commits.
git range now seems to be g:0cbb756fe9c8e13a ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #9 from Aaron Ballman ---
> GNU attributes are declaration specifiers *in the previous examples given
> here*, not necessarily in all other cases.
Thanks for clarifying!
> (There is then logic in GCC to handle __attribute__ that,
Asking for the lines outside the "#if __CRIS__" part.
Ok to commit?
-- >8 --
tm.texi says for BIGGEST_ALIGNMENT (from which
__BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that
any data type can require on this machine, in bits."
That is, using that value might be too strict for alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108803
--- Comment #6 from Jakub Jelinek ---
Created attachment 54476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54476=edit
gcc13-pr108803.patch
Actually, the above patch isn't correct because for op1 equal to 0 we really
need the
Martin,
> Hello GCC community.
>
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #4 from David Binderman ---
git range now seems to be g:59ad8b684dd67e17 .. g:3b54cc9d04c2efb2,
which is 103 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108819
Andrew Pinski changed:
What|Removed |Added
Target Milestone|13.0|12.3
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #8 from joseph at codesourcery dot com ---
On Thu, 16 Feb 2023, aaron at aaronballman dot com via Gcc-bugs wrote:
> > The logic is that GNU attributes are declaration specifiers (and can mix
> > anywhere with other declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #3 from David Binderman ---
(In reply to David Binderman from comment #2)
> Trying revision 1191a412bb17a734.
Seems bad. Trying 59ad8b684dd67e17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Summary|[13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #2)
> I can see the ICE but the reduced test seems overreduced and invalid; do you
> have the original .ii file?
It was attached in comment #1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
Andrew Pinski changed:
What|Removed |Added
Known to fail||13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108803
--- Comment #5 from Jakub Jelinek ---
The change then would be
--- gcc/optabs.cc.jj2023-01-02 09:32:53.309838465 +0100
+++ gcc/optabs.cc 2023-02-16 19:33:14.583883584 +0100
@@ -507,7 +507,7 @@ expand_subword_shift (scalar_int_mode op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
--- Comment #1 from Slava Barinov ---
Created attachment 54475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54475=edit
Result of -freport-bug
Added full output of -freport-bug call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829
Bug ID: 108829
Summary: internal compiler error: in is_capture_proxy, at
cp/lambda.cc:272
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #2 from David Binderman ---
Trying revision 1191a412bb17a734.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108828
Bug ID: 108828
Summary: ivopts silencing gcc.dg/Wuse-after-free-2.c:115
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|m68k:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
--- Comment #6 from Andrew Pinski ---
(In reply to palmer from comment #5)
> We've run into a handful of things that look like this before, I'm not sure
> if it's a backend issue or something more general. There's two patterns
> here that are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
--- Comment #5 from palmer at gcc dot gnu.org ---
We've run into a handful of things that look like this before, I'm not sure if
it's a backend issue or something more general. There's two patterns here that
are frequently bad on RISC-V:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108803
--- Comment #4 from Jakub Jelinek ---
On the other side, if we knew that the backend would use something like the
shifts with masking, we could then avoid the extra reverse unsigned shift by 1
+ reverse unsigned shift by (63 - op1) & 63 plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370
--- Comment #9 from Joseph S. Myers ---
The glibc build failure has done away and come back at least once since my
previous comment. It came back (I think the most recent time) with
commit 4fa25a7eb322f0a003c1eb15680c71ece345e01e
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last
These patches implement an LDS memory allocator for OpenMP on AMD.
1. 230216-basic-allocator.patch
Separate the allocator from NVPTX so the code can be shared.
2. 230216-amd-low-lat.patch
Allocate the memory, adjust the default address space, and hook up the
allocator.
They will need to be
1 - 100 of 210 matches
Mail list logo
