The following makes sure to clear loops number of iterations when
outlining them as part of a SESE region as can happen with
auto-parallelization. The referenced SSA names become stale otherwise.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/107865
在 2022/11/25 15:37, Hi-Angel 写道:
Why? A default is merely a default. I don't really see why changing
that should help you specifically. A decision "which assembly syntax
to use" is one that makes a project like ones you're contributing to,
not GCC. If they decided to use AT syntax, they won't
Hi Haochen,
Sorry for the late review.
on 2022/10/11 15:38, HAO CHEN GUI wrote:
> Hi,
> This patch modifies the help function which generates permute index for
> vector byte reversion and generates permute index directly for little endian
> targets. It saves one "xxlnor" instructions on P8
On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc wrote:
>> One annoying thing about GCC is that, for x86 if I need to write I piece of
>> inline assembly then I
>> have to do it twice: one in AT syntax and one in Intel syntax.
> Why? A default is merely a default. I don't really see why changing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106923
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc wrote:
> One annoying thing about GCC is that, for x86 if I need to write I piece of
> inline assembly then I
> have to do it twice: one in AT syntax and one in Intel syntax.
Why? A default is merely a default. I don't really see why changing
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107865
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. One
annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I have
to do it twice: one in AT syntax and one in Intel syntax.
The AT syntax is an awkward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #8 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #7)
> > - if (width < HOST_BITS_PER_WIDE_INT)
> > + if (width < HOST_BITS_PER_WIDE_INT
> > + && (mode != QImode || !flag_signed_char))
> typo should be
> +
Update in V3:
Remove !flag_signaling_nans since there's already HONOR_NANS (BFmode).
Here's the patch:
After supporting real __bf16, the implementation of _mm_cvtsbh_ss went
wrong.
The patch add a builtin to generate pslld for the intrinsic, also
extendbfsf2 is supported with pslld when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #7 from Hongtao.liu ---
> - if (width < HOST_BITS_PER_WIDE_INT)
> + if (width < HOST_BITS_PER_WIDE_INT
> + && (mode != QImode || !flag_signed_char))
typo should be
+ && (mode != QImode || flag_signed_char))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #6 from Hongtao.liu ---
For pattern
(set (reg:QI 607)
(const_int 255 [0xff]))
general_operand return false for op const_int 255 QImode since
trunc_int_for_mode (INTVAL (op), mode) return -1, INVAL (op) is 255.
---cut from
Based on the discussions in previous mails:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607139.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607197.html
I will update the patch accordingly, and then submit a new version.
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
Hi Richard,
Thanks a lot for your comments!
Richard Biener writes:
> On Wed, 23 Nov 2022, Jiufu Guo wrote:
>
>> Hi Jeff,
>>
>> Thanks a lot for your comments!
>
> Sorry for the late response ...
>
>> Jeff Law writes:
>>
>> > On 11/20/22 20:07, Jiufu Guo wrote:
>> >> Jiufu Guo writes:
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107865
Bug ID: 107865
Summary: [12/13 Regression] ICE in verify_loop_structure, at
cfgloop.cc:1748 (Error: loop 3's number of iterations
'_61 > 0 ? (uint128_t) (_61 + -1) : 0' references
Hi Richard,
on 2022/11/23 00:08, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Many thanks for your review comments!
>>
> on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As discussed in PR98125, -fpatchable-function-entry with
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:f120196382ac5ac49ec4a60f8abad42f22d45a91
commit r13-4294-gf120196382ac5ac49ec4a60f8abad42f22d45a91
Author: Kewen.Lin
Date: Thu Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #5 from Hongtao.liu ---
Also I get below from build_common_tree_nodes
/* Define `char', which is like either `signed char' or `unsigned char'
but not the same as either. */
char_type_node
= (signed_char
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Hongtao.liu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
This patch is a followup to my not-yet-reviewed patch
[PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606218.html
In comments on a previous iteration of that patch, I was asked to do
something to delete unused
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/bugs.html: Regenerate.
* doc/xml/manual/intro.xml: Document LWG 3656 change.
* include/std/bit (__bit_width, bit_width): Return int.
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This copies the better tests from gcc-12 to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/106201
* testsuite/27_io/filesystem/iterators/106201.cc: Improve test.
* testsuite/experimental/filesystem/iterators/106201.cc: New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3892251498c16c9507cf8471f4f10676212e9ead
commit r13-4292-g3892251498c16c9507cf8471f4f10676212e9ead
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #8 from Brjd ---
__get_cpuid(0): eax=0xa, ebx=0x756e6547, ecx=0x6c65746e, edx=0x49656e69
__get_cpuid(1): eax=0x106ca, ebx=0x20800, ecx=0x40e39d, edx=0xbfe9fbff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #14 from Michael_S ---
I tested a smaller test bench from Comment 3 with gcc trunk on godbolt.
Issue appears to be only partially fixed.
-Ofast result is no longer a horror that it was before, but it is still not as
good as -O3 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #18 from Sergei Trofimovich ---
The fix also fixed all initial llvm-12's test suite failures for me. Thank you!
Snapshot gcc-10-20221124 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20221124/
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=107819
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #7)
>
> In the meantime, do you have an idea where to force the generation of a
> temporary? I've been scrolling through gfc_conv_procedure_call to see
> if that might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Andrew Pinski changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.1.0, 11.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> int_max+1 is not a core constant (C++20 7.7 [expr.const] paragraph 5, bullet
oops, s/core constant/core constant expression/
> 5.7), so is not usable as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Hmm, I don't know if I reduced it too much but this might be __bfloat16_t
> related ...
It is not, I changed 0.0bf16 to just 0.0f and it fails. still reducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #8 from Mikael Morin ---
(In reply to anlauf from comment #3)
> Could need help by some expert on this...
I guess I qualify as expert.
Reading the code again after years, it is not exactly crystal clear...
Here is a dump of what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #2 from Andrew Pinski ---
Hmm, I don't know if I reduced it too much but this might be __bfloat16_t
related ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #6)
> (In reply to anlauf from comment #5)
> > Second, I stumbled over:
> >
> > ! 15.5.2.3 Argument association
> > ! (4) A present dummy argument with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158
--- Comment #9 from urs at akk dot org ---
After commit ce917b0422c145779b83e005afd8433c0c86fb06 this doesn't show up
anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #7 from Jonathan Wakely ---
(In reply to Markus F.X.J. Oberhumer from comment #6)
> Please note that I'm explicitly using "int_max" and not "INT_MAX",
It's a constexpr variable with the same value, so that makes no difference
If a char * global was initialized with a rvalue from
`gcc_jit_context_new_string_literal` containing a format string,
dumping the context causes libgccjit to SIGSEGV due to an improperly
constructed call to vasprintf. The following code snippet can reproduce
the crash:
int main(int argc, char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #6 from Markus F.X.J. Oberhumer ---
Please note that I'm explicitly using "int_max" and not "INT_MAX", and I'd
appreciate if you could give me a link where the standard says this is
"ill-formed". Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #1 from Andrew Pinski ---
/path/to/mycodedistr/include/mycode/grfx/_cpu/../color/../../_stdafx/_math.hpp:111:23:
internal compiler error: Segmentation fault
0x120e72f crash_signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Andrew Pinski changed:
What|Removed |Added
Keywords||FIXME
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #5 from Jonathan Wakely ---
To expand on that, the standard allows compilers to do anything for undefined
behaviour, including making it valid with well-defined semantics. So wrapping
for undefined overflow is a conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #8 from Jakub Jelinek ---
Alloca itself doesn't touch the stack on many architectures, and the code
doesn't have to have a function call in between.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #4 from Jonathan Wakely ---
Andrew is right. The C++ standard says this is ill-formed, the -fwrapv option
isn't allowed to change that.
The option means that runtime overflow is well-defined instead of undefined,
but that doesn't
des:
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-src/configure --enable-languages=c,c++
--enable-multiarch --program-suffix=-trunk
gcc version 13.0.0 20221124 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #7 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #4)
> Say for
> void bar (char *);
> void
> foo (int x, int y)
> {
> __attribute__((assume (x < 64)));
> for (int i = 0; i < y; ++i)
> bar (__builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #6 from Mikael Morin ---
(In reply to anlauf from comment #5)
> (In reply to Mikael Morin from comment #4)
> > But is it required to generate a temporary?
> > As I understand it, the code is invalid, and (correctly) diagnosed, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Bug ID: 107863
Summary: ICE with unrecognizable insn when using
-funsigned-char with some AVX builtins
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Hi Harald,
please find attached an obvious patch by Steve for a technical
regression that resulted from improvements in error recovery
of bad uses of associate.
Regtested on x86_64-pc-linux-gnu.
Will commit soon unless there are comments.
Obvious enough, I think. Thanks!
As a sidenote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107862
--- Comment #1 from Andrew Pinski ---
I don't think this is valid code.
In the function dynamic_data_to_array you have:
std::array data;
But test.size() is not a constexpr unless test is a constexpr. making test a
constexpr does not work
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Wednesday, November 23, 2022 4:18 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH]AArch64 sve2: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107862
Bug ID: 107862
Summary: Returning an std::vector from a lambda fails to be
constexpr, while a custom class with allocated storage
works
Product: gcc
Version:
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, November 23, 2022 4:18 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH]AArch64 sve2: Fix expansion of division [PR107830]
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #3 from Markus F.X.J. Oberhumer ---
Indeed.
And just for reference I had also reported this as clang bug in
https://github.com/llvm/llvm-project/issues/59195
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #2 from Andrew Pinski ---
Note clang rejects even just:
#include
#define wrap_inc(x) ((x) + 1 < (x))
constexpr int int_max = INT_MAX;
bool b0 = wrap_inc(int_max);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #1 from Andrew Pinski ---
Right, this is by design and I don't think it is a bug. The reasoning is the
C++ constant expressions have a way of requiring you to having to figure out if
it was going to overflow and cause different
The nvptx reverse-offload code mishandled the case that there was a reverse
offload function that isn't called inside a target region. In that case,
the linker did not include GOMP_target_ext and the global variable it uses.
But the plugin-nvptx.c code expected that the latter is present.
Found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Host|x86_64-apple-darwin21 |aarch64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #3 from simon at pushface dot org ---
Created attachment 53961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53961=edit
gcc/config.log
As requested (this time, sorry about previous attempt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107577
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #2 from simon at pushface dot org ---
Created attachment 53960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53960=edit
gcc/config.log
As requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |libgcc
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
--- Comment #5 from Arnout Vandecappelle ---
Based on
> glibc builds needs to be fixed such that it does not reference the function
> in the unwinder at -O0
I've traced through the map file why this symbol is pulled in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
Bug ID: 107861
Summary: C++ static_assert() does not honor -fwrapv, leading to
compilation error
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
--- Comment #3 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #2)
> it's loop invariant motion that hoists the v + v compute out of the loop
> and thus outside of its controlling condition. You can see it's careful
> to not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> But is it required to generate a temporary?
> As I understand it, the code is invalid, and (correctly) diagnosed, so there
> is nothing else to do.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #1 from Andrew Pinski ---
Can you attach config.log from the gcc directory?
It should have done detected filds :
gcc_GAS_CHECK_FEATURE([filds and fists mnemonics],
gcc_cv_as_ix86_filds,,
[filds (%ebp); fists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
--- Comment #15 from Sébastien Michelland ---
Thanks, turns out my bisected commit was related after all...
I can confirm that test cases from OP and #4 (with protocol from OP) are no
longer broken for me on yesterday's master.
> Am 24.11.2022 um 17:28 schrieb Stefan Schulze Frielinghaus via Gcc
> :
>
> Hi everyone,
>
> Currently I'm looking into a wrong-code bug and would like to understand
> a certain optimization done by combine during local transformation.
> Without LTO I would simply debug cc1 and step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Arnout Vandecappelle changed:
What|Removed |Added
CC||arnout at mind dot be
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107611
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Bug ID: 107860
Summary: Compilation failure, ambiguous fisttp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91456
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:db206f15f7091382cb981ade3c75f4c3e3559ab8
commit r12-8930-gdb206f15f7091382cb981ade3c75f4c3e3559ab8
Author: Jonathan
Hi everyone,
Currently I'm looking into a wrong-code bug and would like to understand
a certain optimization done by combine during local transformation.
Without LTO I would simply debug cc1 and step through combine. However,
with LTO enabled AFAIK I have to debug lto1 instead. In order to get
On 11/11/2022 21:50, Ramana Radhakrishnan via Gcc-patches wrote:
On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
wrote:
On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
wrote:
On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
On 08/11/2022 18:20, Ramana
> -Original Message-
> From: Andrea Corallo
> Sent: Thursday, November 24, 2022 2:44 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>
> Subject: [PATCH 35/35 V2] arm: improve tests for vsetq_lane*
>
> Kyrylo Tkachov writes:
>
> [...]
>
> >> diff --git
>> How did you test the patch? If you bootstrapped it and ran the
>> testsuite then it's OK.
Yes, i ran testsuite and bootstrapped and everything seemed OK, but i missed
fail of tests gcc.dg/Warray-bounds-34.c and gcc.dg/Warray-bounds-43.c, so Franz
is right. After that I fixed the regexps in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
Andrew Pinski changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107858
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107858
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Kyrylo Tkachov writes:
[...]
>> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c
>> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c
>> index e03e9620528..b5c9f4d5eb8 100644
>> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c
>> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever
Martin Liška writes:
> On 11/8/22 14:22, Gaius Mulley wrote:
>> Martin Liška writes:
>>
>> should be good - I'll complete the rst output in the scripts,
>
> Hi.
>
Hi Martin,
> As you probably noticed, the Sphinx migration didn't go well.
Yes, sorry to see this didn't happen. Thank you for
Hi Jakub,
> * testsuite/libgomp.c-c++-common/icv-4.c: Bugfix.
Better say what exactly you changed in words.
Changed.
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -14153,7 +14153,7 @@ optimize_target_teams (tree target, gimple_seq
*pre_p)
>struct gimplify_omp_ctx *target_ctx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107859
Bug ID: 107859
Summary: Fail to optimize rot13
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #12 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:0c1b0a23f1fe7db6a2e391b7cb78cff90032
commit r13-4291-g0c1b0a23f1fe7db6a2e391b7cb78cff90032
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-11-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107858
Bug ID: 107858
Summary: Variable in generic lambda incorrectly considered to
be a dependent name
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity:
Ping x 2
Ramana
On Thu, 17 Nov 2022, 20:15 Ramana Radhakrishnan,
wrote:
> On Fri, Nov 11, 2022 at 9:50 PM Ramana Radhakrishnan
> wrote:
> >
> > On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
> > wrote:
> > >
> > > On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> > > wrote:
> > > >
>
1 - 100 of 167 matches
Mail list logo
