On Mon, 2023-10-02 10:55:25 +0800, Kito Cheng wrote:
> Hi Gerald:
>
> Thanks for reporting this issue, I just realized multidimensional
> arrays are gawk extensions, could you try the attached patch to see if
> it can resolve the issue?
With your new patch, it works for me again using `mawk`
Hi, Tobias,
Sorry for the late reply.
I has been on vacation after Cauldron, and will be back to work in the mid of
Oct. will look at this issue at that time.
Qing
> On Sep 25, 2023, at 2:24 PM, Tobias Burnus wrote:
>
> Hi all,
>
> I stumbled over this as I found the wording in the release
Hi Gerald:
Thanks for reporting this issue, I just realized multidimensional
arrays are gawk extensions, could you try the attached patch to see if
it can resolve the issue?
On Mon, Oct 2, 2023 at 4:56 AM Gerald Pfeifer wrote:
>
> On Sun, 1 Oct 2023, Kito Cheng wrote:
> > Committed to trunk,
On Tue, 15 Aug 2023 at 15:06, Jeff Law wrote:
>
> On 8/15/23 03:16, juzhe.zh...@rivai.ai wrote:
> > The new patch looks reasonable to me now. Thanks for fixing it.
> >
> > Could you append testcase after finishing test infrastructure ?
> > I prefer this patch with testcase after infrastructure.
Add proper hints for implicit declaration of strerror.
The results could be confusing depending on the other included headers.
These example messages are from compiling a trivial program to print the
string for an errno value. It only includes stdio.h (cstdio for C++).
Before:
$
Committed as obvious (RE doesn't compile without patch, and I know
what I meant when I wrote it).
commit 5f3da480e7541a9c29d655dccb2463fc5f3cf2c4
Author: Joern Rennecke
Date: Sun Oct 1 22:46:43 2023 +0100
Fix typo in add_options_for_riscv_v, add_options_for_riscv_zfh,
On Sun, 1 Oct 2023, Kito Cheng wrote:
> Committed to trunk, thanks Feng :)
Hmm, my nightly FreeBSD 12 tester now fails as follows:
nawk -f /scratch/tmp/gerald/GCC-HEAD/gcc/opt-functions.awk \
-f /scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk \
-f
From: Andrew Pinski
The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the
From: Frederik Harwath
This patch adds support for the OMP_LOOP_TRANS tree node, internal
OpenMP clauses representing loop transformations, and the
omp_transform_loops pass to lower them.
gcc/ChangeLog:
* Makefile.in (OBJS): Add omp-transform-loops.o.
* gimple-pretty-print.cc
This series of patches is an update of Frederik's previous loop
transformation patch set, previously posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614564.html
that has been updated to resolve conflicts with my set of
imperfectly-nested loops patches and other changes on
From: Frederik Harwath
OMP_CLAUSE_TILE will be used for the OpenMP 5.1 loop transformation
construct "omp tile".
gcc/ChangeLog:
* tree-core.h (enum omp_clause_code): Rename OMP_CLAUSE_TILE.
* tree.h (OMP_CLAUSE_TILE_LIST): Rename to ...
(OMP_CLAUSE_OACC_TILE_LIST): ...
Hi Andre,
All is well that ends well! Thanks for working on this.
Regards
Paul
On Sat, 30 Sept 2023 at 14:16, Andre Vehreschild wrote:
>
> Hi all,
>
> back porting to gcc-13 unfortunately caused a regression due to
> gfc_deallocate_with_status() having a different parameter count. This is
From: Sergei Trofimovich
r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile"
exposed check failures in cases when gcc produces uninitialized profile
probabilities. In case of PR/111559 uninitialized profile is generated
by edges executed 0 times reported by IPA profile:
From: Andrew Pinski
The issue here is that when backprop tries to go
and strip sign ops, it skips over ABSU_EXPR but
ABSU_EXPR not only does an ABS, it also changes the
type to unsigned.
Since strip_sign_op_1 is only supposed to strip off
sign changing operands and not ones that change types,
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
In some cases, for writing
On 10/1/23 08:26, Stefan Schulze Frielinghaus wrote:
FWIW, I should definitely have caught this hunk earlier -- we've gone the
rounds in this same space (GEN_INT vs gen_int_mode) elsewhere.
Again, sorry for the long wait.
jeff
No worries at all. At least I have learned something new :)
I'll add it to our nightly. Just to be sure I’ll let you know asap it's
status.
Roger, you can always use Synopsys free nsim simulator which you can find it on
Synopsys website.
Thanks,
Claudiu
-Original Message-
From: Jeff Law
Sent: Saturday, September 30, 2023 1:02 AM
To: Roger
On Fri, Sep 29, 2023 at 01:01:57PM -0600, Jeff Law wrote:
>
>
> On 8/10/23 07:04, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> > completely missed the fact that the normal form of a generated constant for
> > a
>
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
In some cases, for writing
From: Alejandro Colomar
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
On Sun, Oct 01, 2023 at 09:37:59AM +0200, Martin Uecker wrote:
>
> (I shortened the recipient list)
>
> Am Sonntag, dem 01.10.2023 um 02:55 +0200 schrieb Alejandro Colomar:
>
> > >
> ...
> > I ran the tests, and get some unexpected failure. I used dg-warning,
> > but maybe I used it wrong?
Committed to trunk, thanks Feng :)
On Sat, Sep 30, 2023 at 3:34 AM Jeff Law wrote:
>
>
>
> On 9/12/23 03:18, Feng Wang wrote:
> > New patch add some comments and update docs for this new usage.
> > ---
> > Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)"
> > to generate MASK
(I shortened the recipient list)
Am Sonntag, dem 01.10.2023 um 02:55 +0200 schrieb Alejandro Colomar:
> >
...
> I ran the tests, and get some unexpected failure. I used dg-warning,
> but maybe I used it wrong? Here's the output:
>
> ```
> output is:
>
23 matches
Mail list logo
