On Sat, May 28, 2022 at 2:30 PM Jeff Law via Gcc-patches
wrote:
> On 5/24/2022 11:32 AM, Eric Gallager via Gcc-patches wrote:
> > This patch adds entries for the c++tools, gotools, libbacktrace,
> > libcc1, libcody, liboffloadmic, and libsanitizer directories into the
> > list of toplevel source
Dear Fortranners,
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.
The attached patch introduces a new STAT value LIBERROR_NO_MEMORY
that is returned for
On 4/1/2022 9:20 AM, Joel Holdsworth via Gcc-patches wrote:
gcc/
* config/avr/avr-mcus.def: Add device definitions.
* doc/avr-mmcu.texi: Corresponding changes.
* gcc/config/avr/gen-avr-mmcu-texi.c: Added support for avr
device prefix.
*
On 4/26/2022 8:59 AM, Torsten Duwe via Gcc-patches wrote:
Signed-off-by: Torsten Duwe
---
gcc/ChangeLog:
2022-04-26 Torsten Duwe
* config/avr/avr-mcus.def (AVR_MCU): add definitions for
attiny{4,8,16,32}2{4,6,7}; 4k and 8k flash types use RCALL.
Are these independent of
On 4/1/2022 9:20 AM, Joel Holdsworth via Gcc-patches wrote:
Signed-off-by: Joel Holdsworth
---
gcc/config/avr/avr-devices.cc | 2 --
1 file changed, 2 deletions(-)
These aren't really errant. There was a time when these form feeds were
actually encouraged and you'll find them all over
On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote:
On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote:
"H.J. Lu" writes:
On Wed, May 25, 2022 at 12:30 AM Richard Sandiford
wrote:
"H.J. Lu via Gcc-patches" writes:
On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener
On 5/24/2022 11:32 AM, Eric Gallager via Gcc-patches wrote:
This patch adds entries for the c++tools, gotools, libbacktrace,
libcc1, libcody, liboffloadmic, and libsanitizer directories into the
list of toplevel source directories in sourcebuild.texi. I also
removed the entry for boehm-gc
On 5/27/2022 2:01 AM, Jan Beulich via Gcc-patches wrote:
./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.
libatomic/
As outlined in the BZ the sh is returning cost 2 for various reg->reg
moves. Cost 2 has special meaning to reload and prevents the insns from
being re-recognized. Vlad's patch bumps the cost to 7. Other values
might be better, but given this has been languishing for ~6 months and
there are
On 5/25/2022 11:02 AM, Bruce Korb via Gcc-patches wrote:
Subject:
Vim swap files not ignored
From:
Bruce Korb via Gcc-patches
Date:
5/25/2022, 11:02 AM
To:
gcc-patches@gcc.gnu.org
Hi,
I don't have the keys for write access anymore. This ought to be
applied. Odd that it never has been. :)
Richard Biener writes:
> On Wed, May 25, 2022 at 9:50 PM Gaius Mulley wrote:
>>
>> Richard Biener writes:
>>
>> > So is there a reason to have the 'scaffold' separate from the object
>> > of hello.mod?
>>
>> Perhaps the major advantage is flexibility? But no we can by default
>> produce the
This patch updates the libbacktrace README to a near copy of the one
from github.com/ianlancetaylor/libbacktrace. Committed to mainline.
This fixes GCC PR 105721.
Ian
* README: Update.
6cf19361732bd7f8b41716ef9f4b5c205a3193b8
diff --git a/libbacktrace/README b/libbacktrace/README
index
On Fri, May 27, 2022 at 3:57 PM Andrew MacLeod via Gcc-patches
wrote:
>
> On 5/27/22 15:33, Andi Kleen wrote:
> > Andrew MacLeod via Gcc-patches writes:
> >> diff --git a/gcc/gimple-range-side-effect.cc
> >> b/gcc/gimple-range-side-effect.cc
> >> index 2c8c77dc569..548e4bea313 100644
> >> ---
This comment had got out of sync with reality, partly due to merging
of patches. Updated to reflect the current implementation.
Signed-off-by: Iain Sandoe
gcc/ChangeLog:
* config/darwin.h (REAL_LIBGCC_SPEC): Update the comment block
describing this macro.
---
Am 27.05.22 um 20:31 schrieb Eric Gallager:
On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
wrote:
[...] the first question is: is it reasonable to add support for
GnuCOBOL?
* How would the demangler know it is to be called? Just "best match"
(GnuCOBOL modules always have some
On May 20, 2022, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu. Ok to install?
Ping? https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595356.html
> for gcc/ChangeLog
> * common.opt (multiflags): New.
> * doc/invoke.texi: Document it.
> * gcc.cc
since apparently _aligned_malloc requires freeing with _aligned_free and:
/* Defined if gomp_aligned_alloc doesn't use fallback version
and free can be used instead of gomp_aligned_free. */
#define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied. For uses inside
Several gnatlib* targets perform, with a subshell and sed, the same
GCC_FOR_TARGET pathname transformation that OSCONS_CC performs with
make subst macros. Rename OSCONS_CC to a more general name, and use
it for gnatlib as well.
Tested on x86_64-linux-gnu, checking in.
for gcc/ada/ChangeLog
18 matches
Mail list logo
