Hi:
> Please don't add the -fno- option to the warning tests. As I said,
> I would prefer to either suppress the vectorization for the failing
> cases by tweaking the test code or xfail them. That way future
> regressions won't be masked by the option. Once we've moved
> the warning to a more
On Fri, 24 Sep 2021 17:46:53 +0200
Aldy Hernandez via Gcc-patches wrote:
> p.s. "Did I say 5 weeks? My bad, I meant 5 months."
heh. units (.oO~"xkcd.com/1047/")
> +static unsigned int
> +execute_vrp_threader (function *fun)
> +{
> + hybrid_threader threader;
> + threader.thread_jumps (fun);
Hi Jason,
Sorry for not noticing your response.
>>Unfortunately, your patch breaks
>>
>>template
>>struct A
>>{
>> void f(T);
>>};
>>template
>>void A::f(const T)
>>{ }
1. Perhaps I misunderstand your comment, but my patch does NOT fix this issue.
Neither does current GCC fix this code, if
On 9/24/2021 8:39 PM, liuhongt via Gcc-patches wrote:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580207.html
gcc/ChangeLog:
* doc/extend.texi (Half-Precision): Remove storage only
description for _Float16 w/o avx512fp16.
OK
jeff
On 23.09.21 21:13, Tobias Burnus wrote:
On 20.09.21 09:58, Tobias Burnus wrote:
On 20.09.21 06:01, Sandra Loosemore wrote:
This patch fixes some bugs in handling of assumed-rank arguments
revealed by the TS29113 testsuite, ... giving a bogus error when
passing one as the first argument to the
I have committed the below patch. I've made only cosmetic updates since
version 1
(https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579420.html).
The PRU architecture provides single-cycle access to GPIO pins via
special designated CPU registers - R30 and R31. These two registers can
of
Hello,
Sorry for bumping it again but I guess it was getting overlooked.
I am very junior with mailing list open source contributions so please feel
free to point out if I have inadvertantly done something in an incorrect way.
The archive of the original email can be found at
On 23.09.21 21:47, Harald Anlauf via Fortran wrote:
Dear Fortranners,
we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
expression with an initializer. The intrinsics in question are listed in
On Sep 25 2021, Roger Sayle wrote:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 4acb941..2de7d99 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -3125,7 +3125,7 @@ errors if these functions are not inlined everywhere
> they are called.
> @itemx
This patch introduces new RTX codes to allow the RTL passes and
backends to consistently represent high-part multiplications.
Currently, the RTL used by different backends for expanding
smul3_highpart and umul3_highpart varies greatly,
with many but not all choosing to express this something
Normally Boolean options/flags in GCC take the values zero or one.
This patch tweaks flag_trapping_math to take the values 0 or 65535.
More accurately it introduces a new trapping_math_model enumeration in
flag-types.h, and uses this to allow front-ends to (potentially) control
which expressions
11 matches
Mail list logo
