Der Harald, hi all,
On 11.08.21 21:25, Harald Anlauf via Fortran wrote:
the checks for the STAT= and ERRMSG= arguments to the coarray SYNC statements
did not properly handle several cases, such as named constants (parameters).
While fixing this, I adjusted the code similarly to what was recentl
cpplib-11.1-b20210207.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/cpplib/de.po
(This file, 'cpplib-11.1-b2021020
As I've mentioned before, the H8/300H can only shift a single bit
position at a time. Naturally this means many shifts are implemented as
loops. There's a variety of special cases that we can do without loops
by using rotates, sub-word moves, etc. The general guidance for the
port has been t
> On Aug 14, 2021, at 5:25 AM, Iain Sandoe wrote:
>
> 1/ please can you either post using a mailer that doesn’t mangle patches or
> put the patch as a plain text attachment
> (pushing to a git branch somewhere public also works for me, but maybe not
> for all reviewers)
> - for small patc
On Fri, Aug 13, 2021 at 2:08 PM Rainer Orth
wrote:
>
> unfortunately, things are considerably worse: syscall.lo fails to build
> and go1 even ICEs:
>
> /vol/gcc/src/hg/master/local/libgo/go/syscall/libcall_posix_utimesnano.go:13:1:
> error: redefinition of ‘UtimesNano’
>13 | func UtimesNano(
On 8/15/21 12:25 AM, Stafford Horne wrote:
On Sun, Aug 15, 2021 at 12:05:37AM +0200, Giulio Benetti wrote:
On 8/15/21 12:03 AM, Stafford Horne wrote:
On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
Hi All,
On 5/1/21 11:11 PM, Stafford Horne wrote:
Changes from v1:
- Added
On Sun, Aug 15, 2021 at 12:05:37AM +0200, Giulio Benetti wrote:
> On 8/15/21 12:03 AM, Stafford Horne wrote:
> > On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
> > > Hi All,
> > >
> > > On 5/1/21 11:11 PM, Stafford Horne wrote:
> > > > Changes from v1:
> > > >- Added patch to
On 8/15/21 12:03 AM, Stafford Horne wrote:
On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
Hi All,
On 5/1/21 11:11 PM, Stafford Horne wrote:
Changes from v1:
- Added patch to enabled cmodle=large on crtstuff
This series fixes some bugs found when linking large binaries, bot
On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
> Hi All,
>
> On 5/1/21 11:11 PM, Stafford Horne wrote:
> > Changes from v1:
> > - Added patch to enabled cmodle=large on crtstuff
> >
> > This series fixes some bugs found when linking large binaries, both in
> > buildroot
> > an
Hi All,
On 5/1/21 11:11 PM, Stafford Horne wrote:
Changes from v1:
- Added patch to enabled cmodle=large on crtstuff
This series fixes some bugs found when linking large binaries, both in buildroot
and glibc testing.
Stafford Horne (2):
or1k: Add mcmodel option to handle large GOTs
or1
Here is an update version of the patch. I now reorder
only the gimplification and not other preparation so that
replacing PLACEHOLDER_EXPRs for Ada should continue
to work. I also removed a call to gimplify_type_sizes
somewhere else, which also caused some similar problemes.
This seems to fix mo
On Fri, Aug 13, 2021 at 07:57:53PM -0400, Michael Meissner wrote:
> On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote:
> > There is a song from Sesame Street: "Which of these is not like the
> > others?" altivec.md seems like an outlier. crypto.md and vsx.md also
> > seem unusual.
>
On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote:
> On Fri, Aug 13, 2021 at 4:24 PM Segher Boessenkool
> wrote:
> > On Fri, Aug 13, 2021 at 02:07:25PM -0400, David Edelsohn wrote:
> > > On Fri, Aug 13, 2021 at 12:08 PM Segher Boessenkool
> > > wrote:
> > > > On Fri, Aug 13, 2021 at
Hi!
The testcase shows another problem, for TARGET_AVX512BW we have a single insn
doing broadcast from the first element, but don't have one for broadcast
of 2nd+ element (so for d->perm[0] we must return false), but for
TARGET_AVX512F && !TARGET_AVX512BW we don't even have support for that other
Hi Matt,
> On 14 Aug 2021, at 09:14, Matt Jacobson via Gcc-patches
> wrote:
>
> When -fobjc-nilcheck is enabled, messages that result in a struct type should
> yield a zero-initialized struct when sent to nil. Currently, the frontend
> crashes when it encounters this situation. This patch f
On Fri, Aug 13, 2021 at 06:22:48PM -0700, apinski--- via Gcc-patches wrote:
> From: Andrew Pinski
>
> Even though this does not change the generated code,
> it does improve the initial RTL generation.
>
> gcc/ChangeLog:
>
> * tree-ssa-math-opts.c (match_arith_overflow):
> Add range
When -fobjc-nilcheck is enabled, messages that result in a struct type should
yield a zero-initialized struct when sent to nil. Currently, the frontend
crashes when it encounters this situation. This patch fixes the crash by
generating the tree for the `{}` initializer.
Tested by running the
18 matches
Mail list logo
