Hi,
Firefox was patched to build train run w/o LTO and final build with LTO.
This causes problems where LTO and non-LTO builds diverge during early
optimization. This can happen because free_lang_data clears type
inheritance graph which in turn is rebuilt taking into account what
virtual tables
On Thu, Dec 27, 2018 at 12:54:30PM +0100, Dominique d'Humières wrote:
> Hi Steve,
>
> The test gfortran.dg/pr81027.f90 succeeds without the patch.
> Would not it be better to replace
>
> { dg-error "is not permitted in an" }
>
> with something such as
>
> { dg-error "Assumed-shape array" }
>
On Thu, Dec 27, 2018 at 11:24:07AM +, Sudakshina Das wrote:
> With the failure as:
>
> Excess errors:
> /build/src/gcc/libgomp/testsuite/libgomp.fortran/aligned1.f03:55:14:
> Error: Arguments of 'iand' have different kind type parameters at (1)
>
As requested by Jason in the review of the P0482 (char8_t) core language
changes, this patch includes updates to the error messages emitted for
ill-formed cases of array initialization with a string literal. With
these changes, error messages that previously looked something like these:
-
On Thu, Dec 27, 2018 at 12:54:30PM +0100, Dominique d'Humières wrote:
> Hi Steve,
>
> The test gfortran.dg/pr81027.f90 succeeds without the patch. Would not it be
> better to replace
>
> { dg-error "is not permitted in an" }
>
> with something such as
>
> { dg-error "Assumed-shape array" }
>
On Thu, Dec 27, 2018 at 11:24:07AM +, Sudakshina Das wrote:
> > PR fortran/45513
> > PR fortran/81509
> > * gfortran.dg/graphite/id-26.f03: Fix non-conforming use of IAND.
> > * gfortran.dg/pr81509_1.f90: New test.
> > * gfortran.dg/pr81509_2.f90: New test.
> >
> This patch
Hi Paul and Matthew,
I believe it would be good to get this and other MIPS changes covered
in the GCC 9 release notes at https://gcc.gnu.org/gcc-9/changes.html .
Gerald
PS: https://gcc.gnu.org/about.html has background how to go about this.
On Wed, Nov 28, 2018 at 3:18 PM Tom de Vries wrote:
>
> In build_address_map we allocate a unit, and then look for addresses in the
> unit, which we store in the addrs vector, with the elements pointing to the
> unit. However, if we cannot find addresses in the unit, the allocated unit is
> not
On Wed, Nov 28, 2018 at 3:17 PM Tom de Vries wrote:
>
> In the main loop in build_address_map, we first read the abbrevs into a local
> variable abbrevs, and then allocate the corresponding unit, after which we
> assign
> the abbrevs to the unit. This results in dedicated free-upon-failure
>
This patch by Cherry Zhang deletes runtime/export_arm_test.go. The
only thing export_arm_test.go does is to export usplit, which does not
exist in gccgo. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
This patch by Cherry Zhang lets the ARM32 EABI personality function
continue unwinding when called during traceback. On ARM32 EABI,
unlike other platforms, the personality function is called during
_Unwind_Backtrace (libgcc/unwind-arm-common.inc:581). In this case,
simply unwind the frame
On Wed, Nov 28, 2018 at 3:17 PM Tom de Vries wrote:
>
> When failing in build_address_map, we free the unit that's currently being
> handled in the loop, but the ones that already have been allocated are leaked.
>
> Fix this by keeping track of allocated units in a vector, and releasing them
>
On Wed, Nov 28, 2018 at 3:16 PM Tom de Vries wrote:
>
> While upon failure in build_address_map we call free_unit_addrs_vector, this
> does not actually free the addrs vector, but merely the abbrevs of the units
> pointed at by the elements of the addrs vector.
>
> Fix this by adding code to
Previously, "volatile" was allowed. Changing this simplifies the code,
makes things more regular, and makes the C and C++ frontends handle
this the same way.
2018-12-10 Segher Boessenkool
cp/
* parser.c (cp_parser_asm_definition): Do not allow any asm qualifiers
on top-level
2018-12-27 Segher Boessenkool
c/
* c-parser.c (c_parser_asm_statement): Output a warning instead of an
error for const and restrict.
testsuite/
* gcc.dg/asm-qual-1.c: Adjust.
---
gcc/c/c-parser.c | 2 +-
gcc/testsuite/gcc.dg/asm-qual-1.c | 4 ++--
2
Not all qualifiers are asm qualifiers. We can talk about that in a
nicer way than just giving a generic parser error.
This also adds two testcases for C++, that previously were for C only.
2018-12-10 Segher Boessenkool
c/
* c-parser.c (c_parser_asm_statement) : Give
a more
Also as suggested by Jason.
Segher
2018-12-10 Segher Boessenkool
c/
* c-parser.c (c_parser_asm_statement): Keep track of the location each
asm qualifier is first seen; use that to give nicer "duplicate asm
qualifier" messages. Delete 'quals" variable, instead pass
As suggested by Jason.
Segher
2018-12-10 Segher Boessenkool
c/
* c-parser.c (c_parser_asm_statement): Rewrite the loop to work without
"done" boolean variable.
cp/
* parser.c (cp_parser_asm_definition): Rewrite the loop to work without
"done" boolean
The Linux kernel people want a feature that makes GCC pretend some
inline assembler code is tiny (while it would think it is huge), so
that such code will be inlined essentially always instead of
essentially never.
This patch lets you say "asm inline" instead of just "asm", with the
result that
I noticed I accidentally copied a line too many from the "volatile"
handling to the "inline" handling. This fixes it.
Tested on powerpc64-linux {-m32,-m64}; committing as trivial and obvious.
Segher
2018-12-08 Segher Boessenkool
gcc/c/
* c-parser (c_parser_asm_statement)
PR55681 observes that currently only one qualifier is allowed for
inline asm, so that e.g. "volatile asm" is allowed, "const asm" is also
okay (with a warning), but "const volatile asm" gives an error. Also
"goto" has to be last.
This patch changes things so that only "asm-qualifiers" are
Hi!
I'd like to backport the "asm inline" series to 8 branch and 7 branch.
The patches are identical to trunk, except I added a patch 8/8 that
makes these branches not error on code it only warned on before (that
is, C code that uses restrict or const as asm qualifier).
The 7 backport has a
On 11/20/18 11:58 AM, Martin Liška wrote:
> On 10/3/18 11:23 AM, Martin Liška wrote:
>> On 9/25/18 8:48 AM, Martin Liška wrote:
>>> Hi.
>>>
>>> One more tested patch.
>>>
>>> Martin
>>>
>>
>> One more tested patch.
>>
>> Martin
>>
>
> Hi.
>
> One another tested patch that I'm going to install.
>
Hi Steve,
The test gfortran.dg/pr81027.f90 succeeds without the patch. Would not it be
better to replace
{ dg-error "is not permitted in an" }
with something such as
{ dg-error "Assumed-shape array" }
?
Otherwise the patch works as expected.
Thank for the fix.
Dominique
Hi Steve
On 23/12/18 6:49 PM, Steve Kargl wrote:
> This is a re-submission of a patch I submitted 15 months ago.
> See https://gcc.gnu.org/ml/fortran/2017-09/msg00124.html
>
> At that time one reviewer OK'd the patch for committing,
> and one reviewer raised objections to the patch as I
> chose
Hi.
I've tested the revision that I'm planning to cherry pick on x86_64-linux-gnu.
I'm going to install the patch.
Martin
libsanitizer/ChangeLog:
2018-12-27 Martin Liska
* asan/asan_errors.cc (ErrorAllocTypeMismatch::Print): Cherry
pick rL350085.
*
Still on holiday, but this maybe because long double is 64bit on arm32. Real128
may end up being mapped to long double for fortran on armhf ?
Ramana
From: Sudakshina Das
Sent: Thursday, December 27, 2018 8:46:29 AM
To: s...@troutmask.apl.washington.edu; Janne
Hi
On 25/12/18 5:13 PM, Steve Kargl wrote:
> On Tue, Dec 25, 2018 at 09:51:03AM +0200, Janne Blomqvist wrote:
>> On Mon, Dec 24, 2018 at 9:42 PM Steve Kargl <
>> s...@troutmask.apl.washington.edu> wrote:
>>
>>> On Mon, Dec 24, 2018 at 09:29:50PM +0200, Janne Blomqvist wrote:
On Mon, Dec 24,
28 matches
Mail list logo
