On Wed, Mar 7, 2018 at 2:20 AM, Steve Kargl
wrote:
> All,
>
> As everyone knows, gfortran reads source into a trees and
> and at some point she passes those trees to a resolution
> phases. There are instances, for example the new tests,
> where resolution fails to use the character length
> param
On 03/06/2018 01:57 AM, Richard Biener wrote:
> On Tue, Mar 6, 2018 at 4:41 AM, Jeff Law wrote:
>> On 03/05/2018 12:30 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Mon, 5 Mar 2018, Jeff Law wrote:
>>>
>> The single successor test was strictly my paranoia WRT abnormal/EH
>> edges.
>>
PR 84723 is about an ICE caused by GCC accepting the mutually
exclusive attributes target_clones and naked during parsing,
only to then later crash while assuming such conflicts don't
happen.
The attached patch adds an exclusion for the two attributes
to detect when they're both specified on decl
On Tue, Mar 6, 2018 at 5:00 PM, Palmer Dabbelt wrote:
> Thanks. How does this look?
It looks OK. It still doesn't mention compression, but that is
documented other places so it isn't a big deal.
Jim
Hi James,
This patch has to be backported to gcc-7 branch as the build error for
521.wrf with LTO is there too (for the same reason). This patch has
been on trunk for some time now. So, is this OK to backport this
patch gcc-7 branch?
Thanks,
Kugan
On 30 August 2017 at 15:19, Kugan Vivekananda
On Fri, 02 Mar 2018 16:27:41 PST (-0800), Jim Wilson wrote:
On 03/01/2018 01:26 PM, Palmer Dabbelt wrote:
+@item -mrelax
+@itemx -mno-relax
+Take advantage of linker relaxations to reduce the number of instructions
+required to materalize symbol addresses.
materalize->materialize
This is not
In a recent build for hppa64-hp-hpux11.11, the build failed in stage2
due to a warning about the
format used in the ASM_GENERATE_INTERNAL_LABEL macro. This got me
looking at the implementation
in elfos.h. I also realized that there was no good reason to limit the
number of labels to and
The attached change fixes the build of the Debian cpputest package on
hppa. The testsuite
generates a segmentation fault canonicalizing the function pointer
0xdeadbeef. The attached
patch adds a routine from the hppa dynamic linker to check for read
access permission. So,
we are now less like
It seems the patch for PR fortran/83633 cured
PR fortran/64107. I've added the code from
this PR to the test suite to ensure that it
doesn't get broken. Patche attached.
2018-03-06 Steven G. Kargl
PR fortran/64107
* gfortran.dg/pr64107.f90: New test.
--
Steve
Index: gcc/tes
All,
As everyone knows, gfortran reads source into a trees and
and at some point she passes those trees to a resolution
phases. There are instances, for example the new tests,
where resolution fails to use the character length
parameter in declaration statements. The attach patch
seems to cure
Hi!
The C FE in multiple spots checks building_stmt_list_p () to decide if
we are inside of parsing of functions or outside of that.
Unfortunately, that breaks with add_debug_begin_stmt which pushes
DEBUG_BEGIN_STMTs regardless of the scope it appears in; e.g. on the
testcase below it pushes DEBU
On 03/06/2018 01:47 PM, Jakub Jelinek wrote:
> Hi!
>
> As discussed, e.g. gimplification of STATEMENT_LISTs can create extra
> retval.N temporaries for -g and get the counts out of sync, similarly
> the SAVE_EXPR change proposed in the fix for that PR could for decls
> in the statement expressions
On Tue, Mar 06, 2018 at 10:40:14PM +0100, Thomas Koenig wrote:
>
> the attached patch fixes a bug, partly an 8 regression, for
> simplifying an expression containing minloc or maxloc.
>
> The underlying problem was that
>
> integer, dimension(0), parameter :: z=0
>
> ended up as EXPR_CONST
Hi,
On 06/03/2018 21:33, Jason Merrill wrote:
Interesting, that seems like a promising idea. I'm not sure we need
to do this based on an error in a default template arg, though; can we
drop
+ || error_operand_p (TREE_PURPOSE (parameter)))
?
Good point, yes, I believe we can, isn't necessary
Hello world,
the attached patch fixes a bug, partly an 8 regression, for
simplifying an expression containing minloc or maxloc.
The underlying problem was that
integer, dimension(0), parameter :: z=0
ended up as EXPR_CONSTANT even though the rank was one, which
was then passed to the simpl
On 5 February 2018 at 06:49, François Dumont wrote:
> Hi
>
> Here is a patch to fix some pretty printer check errors when running
> those tests with _GLIBCXX_DEBUG.
>
> I introduced a special rendered for the std::forward_list iterator which
> is similar to the one used for the std::list an
On 28/02/18 15:12 +0200, Ville Voutilainen wrote:
>- // Payload for constexpr optionals.
>+ // Payload for optionals with non-trivial destructor.
> templatebool /*_HasTrivialDestructor*/ =
>-is_trivially_destructible<_Tp>::value>
>+is_trivially_destructible<_
Hi!
The following testcases show various reasons why a function definition
with target_clones attribute can't be cloned; instead of ICEing because
node->create_version_clone_with_body returns NULL and we dereference it,
this patch just diagnoses those and ignores the attribute.
Bootstrapped/regte
On Tue, Mar 06, 2018 at 09:51:57PM +0100, Jakub Jelinek wrote:
> Hi!
>
> The C FE in multiple spots checks building_stmt_list_p () to decide if
> we are inside of parsing of functions or outside of that.
>
> Unfortunately, that breaks with add_debug_begin_stmt which pushes
> DEBUG_BEGIN_STMTs reg
On Tue, Mar 06, 2018 at 09:44:07PM +0100, Jakub Jelinek wrote:
> As the following testcase shows on aarch64, the SET_DEST can be a normal
> subreg, not only a paradoxical one or REG.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> preapproved by Segher in the PR, committ
Hi!
As discussed, e.g. gimplification of STATEMENT_LISTs can create extra
retval.N temporaries for -g and get the counts out of sync, similarly
the SAVE_EXPR change proposed in the fix for that PR could for decls
in the statement expressions or addresses thereof get the fancy names
counters out of
On Tue, Mar 06, 2018 at 03:39:36PM -0500, Jason Merrill wrote:
> On Tue, Mar 6, 2018 at 1:13 PM, Marek Polacek wrote:
> > But I'm also wondering about massage_init_elt. It has
> > tree t = fold_non_dependent_expr (init);
> > t = maybe_constant_init (t);
> > but given that fold_non_dependent_e
Hi!
As the following testcase shows on aarch64, the SET_DEST can be a normal
subreg, not only a paradoxical one or REG.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
preapproved by Segher in the PR, committed to trunk.
2018-03-06 Jakub Jelinek
PR target/84710
On Tue, Mar 6, 2018 at 1:13 PM, Marek Polacek wrote:
> In this testcase we have a constexpr function, value_to_char_helper. Its body
> is
>for (size_t i = 0u; i < alphabet_t::value_size; ++i)
> value_to_char[i] = to_char(alphabet.assign_rank(i));
>
> which is genericized to a LOOP_EXPR
Interesting, that seems like a promising idea. I'm not sure we need
to do this based on an error in a default template arg, though; can we
drop
+ || error_operand_p (TREE_PURPOSE (parameter)))
?
Jason
Hi.
I'm sending GCC 7 branch backports I've just tested and regbootstrapped.
I'm going to install that.
Thanks,
Martin
>From 10479fa4d3576b19b58d7ffc0949c2828ab6c2ff Mon Sep 17 00:00:00 2001
From: segher
Date: Fri, 23 Feb 2018 14:17:35 +
Subject: [PATCH 17/17] Backport r257932
gcc/testsuit
Hi again,
On 06/03/2018 19:58, Paolo Carlini wrote:
.. g, consider the patch withdrawn in its detailed form, I have a
new testcase which add some random code after that ill-formed class
and it's mishandled, it ICEs again.
The below avoids the idiotic thinko (I added a testcase for that) and
.. g, consider the patch withdrawn in its detailed form, I have a
new testcase which add some random code after that ill-formed class and
it's mishandled, it ICEs again.
Well, I would still appreciate some feedback about the general idea...
Paolo.
Hi,
not considering the various rather mild error recovery regressions which
we have in this area, I have been working on and off on these issues for
a while, as QoI diagnostic improvements: when something wrong happens
while parsing the template parameter lists we want anyway to keep track
o
In this testcase we have a constexpr function, value_to_char_helper. Its body
is
for (size_t i = 0u; i < alphabet_t::value_size; ++i)
value_to_char[i] = to_char(alphabet.assign_rank(i));
which is genericized to a LOOP_EXPR looking roughly like this:
while (1)
{
if (i > 3)
> this is the breakage of SEH on 64-bit Windows introduced by defaulting to
> the -freorder-blocks-and-partition optimization. It is fixed by:
> 1. Defining ASM_DECLARE_COLD_FUNCTION_NAME &
> ASM_DECLARE_COLD_FUNCTION_SIZE, 2. Emitting a nop in one more case for SEH,
> 3. Splitting the excepti
Hi,
On Tue, 6 Mar 2018, Richard Biener wrote:
> > bb1
> > ret = setjmp(buf)
> >| \ bb-recv
> >|\
> >|ret = setjmp_receiver
> >|/
> > normal /---/
> > path/
> >| /
>
On Mon, Mar 5, 2018 at 3:24 PM, Richard Biener
wrote:
> On Thu, Feb 8, 2018 at 1:41 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>> On 1 February 2018 at 23:21, Richard Biener
>> wrote:
>>> On Thu, Feb 1, 2018 at 5:07 AM, Kugan Vivekanandarajah
>>> wrote:
Hi Richard,
On
Hi!
I'd like to ping this patch, without or with the additional redundant
(match_test "op == const0_rtx")
line removal.
> Bootstrapped/regtested on aarch64-linux (scratch Fedora gcc 8 package build
> with the patch applied), ok for trunk?
>
> 2018-02-27 Jakub Jelinek
>
> PR fortran/845
On 3/5/18 8:55 AM, Segher Boessenkool wrote:
> On Sat, Mar 03, 2018 at 10:55:28PM -0600, Peter Bergner wrote:
>> The simple fix here is to just verify the memory_operand is not an altivec
>> mem operand before calling rs6000_emit_le_vsx_move.
>>
>> This passed bootstrap and regtesting on powerpc64l
On 2/22/18 3:19 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81572
>
> The patch was successfully bootstrapped and tested on ppc64.
Vlad approved the backporting of this patch to GCC 7.
I backported his patch and bootstrap & regtest
On Tue, Mar 6, 2018 at 12:42 AM, Alexandre Oliva wrote:
> On Mar 2, 2018, Jason Merrill wrote:
>
>> On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva wrote:
>>> + gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
>>> + init = fold (convert (type, integer_zero_node));
>
>> Maybe build_zer
On Tue, Mar 6, 2018 at 3:17 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 5 Mar 2018, Jeff Law wrote:
>
>> >>> Actually, without further conditions I don't see how it would be safe
>> >>> for the successor to have multiple preds. We might have this
>> >>> situation:
>> >>>
>> >>> bb1: ret = setjmp
>>
Hi David,
Any news on that patch?
Cheers,
FX
Hi,
On Mon, 5 Mar 2018, Jeff Law wrote:
> >>> Actually, without further conditions I don't see how it would be safe
> >>> for the successor to have multiple preds. We might have this
> >>> situation:
> >>>
> >>> bb1: ret = setjmp
> >>> bb2: x0 = phi
> >> No. Can't happen -- we're still build
On platforms where System'Machine_Overflows is true, the compiler generates a
check only for the lower bound of the output type in a narrowing floating-
point conversion, which means that e.g. the last chance handler will not be
invoked if the value overflows the upper bound of the output type.
It has been broken on the mainline since end of December. The attached
patchlet is copy-and-pasted from the same function in the c-family dir.
Tested on x86/Windows and x86-64/Linux, applied on the mainline.
2018-03-06 Eric Botcazou
* gcc-interface/utils.c (def_builtin_1): Bail out
Pushed Thank you for your review.
Claudiu
On Tue, Mar 06, 2018 at 08:56:14AM +0100, Richard Biener wrote:
> > Maybe a better fix if we run into this would be to make create_tmp_var_raw
> > create DECL_NAMELESS decls and make sure we don't print names of
> > DECL_NAMELESS variables in -fdump-final-insns= dumps?
>
> They are already DECL_IG
On Tue, Mar 6, 2018 at 4:41 AM, Jeff Law wrote:
> On 03/05/2018 12:30 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 5 Mar 2018, Jeff Law wrote:
>>
> The single successor test was strictly my paranoia WRT abnormal/EH
> edges.
>
> I don't immediately see why the CFG would be incorrect
On Mon, Mar 5, 2018 at 9:42 PM, Jakub Jelinek wrote:
> Hi!
>
> If we discover some bad inline-asm during reg-stack processing and we
> error on those, we replace that inline-asm with a (use (const_int 0))
> and therefore the various assumptions of reg-stack pass may not hold.
> Seems we already ha
46 matches
Mail list logo
