Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-12.1-b20220213.sv.po'
On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote:
> > Hi, Ruoyao,
> >
> > (I might not be able to reply to this thread till next Wed due to a
> > short vacation).
> >
> > First, some comments on opening bugs against Gcc:
> >
On Fri, 11 Mar 2022, Roger Sayle wrote:
+(match vec_same_elem_p
+ CONSTRUCTOR@0
+ (if (uniform_vector_p (TREE_CODE (@0) == SSA_NAME
+? gimple_assign_rhs1 (SSA_NAME_DEF_STMT (@0)) : @0
Ah, I didn't remember we needed that, we don't seem to be very consistent
about i
I have *NOT* pushed this yet, looking for feedback:
It appears redhat.com has lost Fedora mailing list archives, which are
now at lists.fedoraproject.org using completely different tooling.
Jakub, is there a better way than the patch below?
Gerald
diff --git a/htdocs/gcc-4.3/porting_to.html b/h
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-12.1-b20220213.fr.po',
My recent testcase for PR c++/84964.C stress tests the middle-end by
attempting to pass a UINT_MAX sized structure on the stack. Although
my fix to PR84964 avoids the ICE after sorry() on x86_64 and similar
targets, a related issue still exists on powerpc64 (and similar
ACCUMULATE_OUTGOING_ARGS/A
Hi!
The following testcase ICEs on powerpc-linux, because lra_substitute_pseudo
substitutes (const_int 1) into a subreg operand. First a subreg of subreg
of a reg appears in a debug insn (which surely is invalid outside of
debug insns, but in debug insns we allow even what is normally invalid in
Hi!
These intrinsics are supposed to do an unaligned may_alias load
of a 16-bit or 32-bit value and store it as the first element of
a 128-bit integer vector, with all other elements cleared.
The current _mm_storeu_* implementation implements that correctly, uses
__*_u types to do the store and e
Hi!
We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it calls
cp_parser_skip_to_pragma_eol, which call
My sincere apologies for the breakage, but alas handling SImode in the
recently added "xorl;movb -> movzbl" peephole2 turns out to be slightly
more complicated that just using SWI48 as a mode iterator. I'd failed
to check the machine description carefully, but the *zero_extendsi2
define_insn is c
On Fri, Mar 11, 2022 at 05:51:05PM -0500, Michael Meissner wrote:
> On Fri, Mar 11, 2022 at 02:51:23PM -0600, Segher Boessenkool wrote:
> > On Fri, Mar 11, 2022 at 08:42:27PM +, Joseph Myers wrote:
> > > The version of this patch applied to GCC 10 branch (commit
> > > 641b407763ecfee5d4ac86d8f
Hi!
On 2022-03-12T15:54:31+0100, I wrote:
> On 2022-03-01T17:46:20+0100, I wrote:
>> On 2022-01-13T10:54:16+0100, I wrote:
>>> On 2019-05-08T14:51:57+0100, Julian Brown wrote:
- The "addressable" bit is set during the kernels conversion pass for
variables that have "create" (alloc)
Hi!
On 2022-03-01T17:46:20+0100, I wrote:
> On 2022-01-13T10:54:16+0100, I wrote:
>> On 2019-05-08T14:51:57+0100, Julian Brown wrote:
>>> - The "addressable" bit is set during the kernels conversion pass for
>>>variables that have "create" (alloc) clauses created for them in the
>>>synth
Hi!
On 2021-05-21T21:29:19+0200, I wrote:
> I've pushed "[OpenACC privatization] Largely extend diagnostics and
> corresponding testsuite coverage [PR90115]" to master branch in commit
> 11b8286a83289f5b54e813f14ff56d730c3f3185
To demonstrate that later changes don't vs. how they do change things
Hi!
On 2022-03-12T13:38:38+0100, I wrote:
> On 2020-11-13T23:22:30+0100, I wrote:
>> On 2019-02-01T00:59:30+0100, I wrote:
>>> I've just pushed the attached nine patches to openacc-gcc-8-branch:
>>> OpenACC 'kernels' construct changes: splitting of the construct into
>>> several regions.
>>
>> Now
Hi!
On 2020-11-13T23:22:30+0100, I wrote:
> On 2019-02-01T00:59:30+0100, I wrote:
>> I've just pushed the attached nine patches to openacc-gcc-8-branch:
>> OpenACC 'kernels' construct changes: splitting of the construct into
>> several regions.
>
> Now, slightly more polished, I've pushed to maste
On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote:
> Hi, Ruoyao,
>
> (I might not be able to reply to this thread till next Wed due to a
> short vacation).
>
> First, some comments on opening bugs against Gcc:
>
> I took a look at the bug reports PR104817 and PR104820:
> https://gcc.gnu.org/bug
Hi!
On 2022-02-17T13:33:45+0100, I wrote:
> On 2019-10-18T14:28:18+0200, I wrote:
>> On 2019-10-06T15:32:34-0700, Julian Brown wrote:
>>> This patch adds a function to pretty-print OpenACC clause names from
>>> OMP_CLAUSE_MAP_KINDs, for error output.
>>
>> Indeed talking about (OpenMP) 'map' clau
18 matches
Mail list logo
