On 10/12/18 16:55, Jeff Law wrote:
> On 9/15/18 2:43 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is an update on my strlen range patch (V7). Again re-based and
>> retested to current trunk.
>>
>> I am aware that Martin wants to re-factor the interface of get_range_strlen
>> and have no objections
> Thanks for that. I had found and (at least partly) analyzed the same,
> but had not yet prepared a patch. I'm confirming that this works as
> expected when configuring with "--with-sysroot=" (that is, empty).
You're welcome.
> Can we get this onto release branches, too?
That's an oldish regr
For some newlib sources, pdp11 doloop_end was creating problems because it was
handed a QImode operand when it only wants HImode. This patch cures that, and
also adds addqi3 and subqi3 patterns to help with that case.
Committed.
paul
ChangeLog:
2018-10-12 Paul Koning
* co
Hi Segher,
> On 8 Oct 2018, at 04:42, Olivier Hainque wrote:
>
>> I think it looks fine. Okay for trunk after some testing.
>
> I can't get a pristine mainline to build on our powerpc-linux
> host - SEGVs from the newly built cc1 during libgcc. Updated
> ulimits helped a bit, investigating ...
Hi!
Belatedly...
On Thu, 10 May 2018 11:36:01 +0200, Eric Botcazou wrote:
> This fixes an annyoing regression introduced in 2012 by [...]
> The result is that, if you configure --with-sysroot with a value that happens
> to be identical to the start of the default C++ path in the install tree,
Hi,
This patch addresses SLSR bug PR87473. The underlying problem here is that
create_add_on_incoming_edge contains code to handle a phi_arg that is equal
to the base expression of the PHI candidate, where the increment assigned to
the incoming arc should be zero minus the index expression of the
Hi Kyrill,
Thanks for your feedback!
> On 12 Oct 2018, at 05:50, Kyrill Tkachov wrote:
>
> CC'ing the aarch64 maintainers as they'll have to approve it.
> I'm guessing you've tested this in the usual way (bootstrap and test)?
Sorry, I failed to mention the testing indeed. We don't
have a nativ
This patch does a bit more refactoring to yesterday's cleanup. Rather
than have cp_parser_translation_unit use cp_parser_declaration_seq_opt,
I break out the guts of the latter function to
cp_parser_toplevel_declaration, and call that from both places.
Further, the implicit_extern_c processin
On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
wrote:
>
> > fc is built with:
> >mov r0, #0
> >movtr0, 24448
> > so r0=0x5f80 (1.8446744E19) which looks ok
>
> this is correct. My x86_64 yields the same value
>
> > but then cosatanf is computed as (ie t
On Fri, 12 Oct 2018 at 17:57, Jeff Law wrote:
>
> On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > Hello
> > What is the output of these functions on such arch? Since the
> > test didn't fail for the sinatan counterpart, an possible explanation
> > would be that the calculati
Hi!
I've backported following 8 patches from gcc-8-branch to
gcc-6-branch, bootstrapped/regtested and committed to gcc-6-branch.
Jakub
2018-10-12 Jakub Jelinek
Backported from mainline
2018-07-16 Jakub Jelinek
PR c++/3698
PR c++/86208
* cp-g
On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote:
> [re this thread "ToT build failure?":
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
>
> On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote:
> > On Thu, Jul 06, 2017 at 01:45:42PM -0400, David Malcolm wrote:
> > > Given
> fc is built with:
>mov r0, #0
>movtr0, 24448
> so r0=0x5f80 (1.8446744E19) which looks ok
this is correct. My x86_64 yields the same value
> but then cosatanf is computed as (ie there's not call to cosatanf()):
>movwr3, #48430
>movtr3, 45883
>
[re this thread "ToT build failure?":
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote:
> On Thu, Jul 06, 2017 at 01:45:42PM -0400, David Malcolm wrote:
> > Given that the previous status quo of the selftests was to require
> > the
On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> > Please consider that as currently GCC over-estimates length of such asms,
> > branches around them are emitted as long-range jumps more often than needed,
> > which should be a problem we'd want to solve, because the whole reason this
> > is being
On Fri, Oct 12, 2018 at 07:57:12PM +0300, Alexander Monakov wrote:
> > I don't agree at all. Sure it is not very many lines to implement this,
> > but it will make the semantics of inline assembler even stranger than it
> > already is.
> >
> > I also don't think it will be very useful.
> >
> > T
On 10/12/18 10:38 AM, Peter Bergner wrote:
> On 10/11/18 3:51 PM, Vladimir Makarov wrote:
>> I think it has a sense because even if LRA has the same problem, it will be
>> hard to fix it in reload and LRA. Nobody worked on reload pass for a long
>> time and it is not worth to fix it because we are
On 10/12/2018 04:14 AM, Nikolai Merinov wrote:
Hello,
In https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01795.html mail I
suggested patch to have ability to control behavior of
"__attribute__((warning))" in case when option "-Werror" enabled. Usage
example:
#include
int a() __attribute__((warn
On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> > For instance by introducing special tokens like %[ %] that demarkate
> > portion of the asm that shouldn't be counted:
>
> This potentially conflicts with targetm.asm_out.print_operand_punct_valid_p
> (and it does in fact conflict for microblaze).
Hi,
On 12/10/18 14:55, Jason Merrill wrote:
BTW, I would discourage you from messing much with the concepts code
at this point, as a major overhaul should be coming soon.
Agreed: we have good news from Andrew!
By the way, over the last days, outside trivial parsing issues, I
noticed a rather
On 10/11/18 3:51 PM, Vladimir Makarov wrote:
> I think it has a sense because even if LRA has the same problem, it will be
> hard to fix it in reload and LRA. Nobody worked on reload pass for a long
> time and it is not worth to fix it because we are moving from reload.
[snip]
> In any case, the p
Hi all,
ifcvt will created versioned loop and it will permissively generate
scalar COND_ ifn.
If in the loop vectorize pass, COND_ could not get vectorized,
the if-converted loop should be abandoned when the target doesn't support
such ifn.
As currently, COND_ is only used by aarch64 sve extens
On Fri, Oct 12, 2018 at 02:26:45AM -0400, Jason Merrill wrote:
> On Thu, Oct 11, 2018 at 8:25 PM Marek Polacek wrote:
> >
> > On Thu, Oct 11, 2018 at 11:35:23AM -0400, Jason Merrill wrote:
> > > > + /* [dcl.fct.spec]
> > > > + "the constant-expression, if supplied, shall be a
> > >
Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
I noticed that _Bit_reference == and < operators could be made inline
friend too. Do you want me to include this change in the patch ?
* include/bits/stl_bvector.h (_Bit_iterator_base::operator==): Replace
member m
Hi Tobias,
Build and regtested on x86-64-linux.
OK for the trunk and - after a grace time - for GCC 6, 7 and 8?
Thanks for taking this on so quickly! I don't think that this will
result in any missed optimizations.
Ok.
Thomas
On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> Hello
> What is the output of these functions on such arch? Since the
> test didn't fail for the sinatan counterpart, an possible explanation
> would be that the calculation of the sqrf, sqrt and sqrtl (lines
> 62-64) yielded a nu
Hello
What is the output of these functions on such arch? Since the
test didn't fail for the sinatan counterpart, an possible explanation
would be that the calculation of the sqrf, sqrt and sqrtl (lines
62-64) yielded a number that is far behind of what it should be.
However, I am still not su
On Fri, 12 Oct 2018 at 16:14, Jeff Law wrote:
>
> On 10/12/18 8:11 AM, Christophe Lyon wrote:
> > On Fri, 12 Oct 2018 at 13:27, Richard Biener
> > wrote:
> >>
> >> On Fri, Oct 12, 2018 at 10:08 AM Christophe Lyon
> >> wrote:
> >>>
> >>> On Thu, 11 Oct 2018 at 23:07, Jeff Law wrote:
>
> >>
On Fri, Oct 12, 2018 at 08:59:00AM -0400, Jason Merrill wrote:
> On Fri, Oct 12, 2018 at 4:10 AM Jakub Jelinek wrote:
> >
> > On Thu, Oct 11, 2018 at 09:39:51PM -0400, Marek Polacek wrote:
> > > Running make check-c++ RUNTESTFLAGS=dg.exp=decomp31.C will yield
> > > # of unsupported tests
On 10/11/2018 10:43 PM, Eric Gallager wrote:
On 10/11/18, Martin Sebor wrote:
The manual says that:
The packed attribute specifies that a variable or structure
field should have the smallest possible alignment--one byte
for a variable, and one bit for a field...
The variable part doe
Hi!
I've backported following 9 patches from gcc-8-branch to
gcc-7-branch, bootstrapped/regtested and committed to gcc-7-branch.
Jakub
2018-10-12 Jakub Jelinek
Backported from mainline
2018-07-16 Jakub Jelinek
PR c++/3698
PR c++/86208
* cp-g
On 9/15/18 2:43 AM, Bernd Edlinger wrote:
> Hi,
>
> this is an update on my strlen range patch (V7). Again re-based and
> retested to current trunk.
>
> I am aware that Martin wants to re-factor the interface of get_range_strlen
> and have no objections against, but I'd suggest that to be a foll
Here's a proposed "User Experience Guidelines" section for our
internals manual
It's a mixture of proposed policy, together with notes on how to
implement the recommendations.
Thoughts?
gcc/ChangeLog:
* Makefile.in (TEXI_GCCINT_FILES): Add ux.texi.
* doc/gccint.texi: Include ux.t
Hello.
I don't think there is a need for overflow handling here because
the argument is bound by the argument of the sqrt function :-)
Since we have to compute sqrt (1 - x*x), the input is only valid
if 1 - x*x >= 0, implying that -1 <= x <= 1. For any x outside of this
set, the sqrt will
In the front-end optimization for matmul, we call lbound() for each matrix
argument to obtain the shift to the 0-based loop variables.
If the first argument is a PARAMETER, it appears initially as EXPR_VARIABLE
and has associated ref->u.ar for the AR_FULL and ref->u.ar.as contains the
bounds.
Run
On 10/12/18 8:11 AM, Christophe Lyon wrote:
> On Fri, 12 Oct 2018 at 13:27, Richard Biener
> wrote:
>>
>> On Fri, Oct 12, 2018 at 10:08 AM Christophe Lyon
>> wrote:
>>>
>>> On Thu, 11 Oct 2018 at 23:07, Jeff Law wrote:
On 10/9/18 5:29 PM, Giuliano Augusto Faulin Belinassi wrote:
>
On Fri, 12 Oct 2018 at 13:27, Richard Biener wrote:
>
> On Fri, Oct 12, 2018 at 10:08 AM Christophe Lyon
> wrote:
> >
> > On Thu, 11 Oct 2018 at 23:07, Jeff Law wrote:
> > >
> > > On 10/9/18 5:29 PM, Giuliano Augusto Faulin Belinassi wrote:
> > > > Fixed all issues pointed in the previous iterat
Thanks for the commit, for fixing the formatting issues and for writing the
detailed ChangeLog entry.
Sorry for those issues; all looks good now - there are only whitespace
diffs between trunk and my patched version.
My tests pass, including the test code attached to the bug report.
Will
IIRC I c
On Fri, Oct 12, 2018 at 03:45:41PM +0300, Alexander Monakov wrote:
> On Fri, 12 Oct 2018, Segher Boessenkool wrote:
>
> > 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 es
> On Oct 11, 2018, at 11:01 PM, Jeff Law wrote:
>
> On 10/11/18 3:09 PM, Paul Koning wrote:
>> Updated with an additional item I just debugged.
>>
>> Since the code that uses the doloop_end pattern does not check the operand
>> mode as given in the pattern, the pattern itself may need to do
>
> BTW, I would discourage you from messing much with the concepts code
> at this point, as a major overhaul should be coming soon.
>
Major overhaul:
https://github.com/asutton/gcc (branch is concepts; we're about 2 weeks
back from trunk).
Unfortunately, I we haven't been following GCC commit d
On Fri, Oct 12, 2018 at 08:13:51AM -0500, Segher Boessenkool wrote:
> On Fri, Oct 12, 2018 at 02:38:52PM +0200, Jakub Jelinek wrote:
> > On Fri, Oct 12, 2018 at 12:21:06PM +, Segher Boessenkool wrote:
> > > The Linux kernel people want a feature that makes GCC pretend some
> > > inline assemble
On Fri, Oct 12, 2018 at 02:38:52PM +0200, Jakub Jelinek wrote:
> On Fri, Oct 12, 2018 at 12:21:06PM +, Segher Boessenkool wrote:
> > 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
On Fri, Oct 12, 2018 at 4:10 AM Jakub Jelinek wrote:
>
> On Thu, Oct 11, 2018 at 09:39:51PM -0400, Marek Polacek wrote:
> > Running make check-c++ RUNTESTFLAGS=dg.exp=decomp31.C will yield
> > # of unsupported tests3
> > because the test (as the only one in cpp1z/) uses
> > "dg-do
On Thu, Oct 11, 2018 at 4:31 PM Paolo Carlini wrote:
>
> On 11/10/18 20:36, Jason Merrill wrote:
> > On Wed, Oct 3, 2018 at 8:18 AM Paolo Carlini
> > wrote:
> >> a simple issue, we weren't correctly implementing 7.5.7.4 on the
> >> terminating semicolon. Tested x86_64-linux.
> > If the missing s
On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> 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.
I do apologize for being qu
On Fri, Oct 12, 2018 at 12:21:06PM +, Segher Boessenkool wrote:
> 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.
Just a
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 th
On 11/10/18 14:34, Christophe Lyon wrote:
> Use local binding rules to decide whether we can use GOTOFFFUNCDESC to
> compute the function address.
>
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> gcc/
> * config/arm/arm.c (arm_local_funcdesc_p): New function.
> (legi
On 11/10/18 14:34, Christophe Lyon wrote:
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> gcc/
> * config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Handle
> FDPIC.
> (thumb1_compute_save_core_reg_mask): Likewise.
The hunk for this bit is missing.
>
> diff
On 11/10/18 14:34, Christophe Lyon wrote:
> The main difference with existing support is that function addresses
> are function descriptor addresses instead. This means that all code
> dealing with function pointers now has to cope with function
> descriptors instead.
>
> For the same reason, Linu
Hello all,
"When an ALLOCATE statement is executed for an array with no
allocate-shape-spec-list, the bounds of source-expr determine
the bounds of the array." (F2018, 9.7.1.2 (6))
That seems to work fine for arrays which have an array descriptor.
However, as the current code shows, it fails fo
On Fri, Oct 12, 2018 at 10:08 AM Christophe Lyon
wrote:
>
> On Thu, 11 Oct 2018 at 23:07, Jeff Law wrote:
> >
> > On 10/9/18 5:29 PM, Giuliano Augusto Faulin Belinassi wrote:
> > > Fixed all issues pointed in the previous iteration.
> > > There is now a significant change regarding how the sin(at
On 11/10/18 14:34, Christophe Lyon wrote:
> In FDPIC, we need to make sure __do_global_dtors_aux and frame_dummy
> are referenced by their address, not by pointers to the function
> descriptors.
>
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> * libgcc/crtstuff.c: Add support fo
On 10/12/2018 05:56 AM, Alexandre Oliva wrote:
> On Oct 11, 2018, JonY <10wa...@gmail.com> wrote:
>
>> On 10/11/2018 02:57 AM, NightStrike wrote:
>>>
>>> Except that options typically don't get removed, just deprecated. It
>>> seems cleaner to me to drop mingw from the name and make it default to
This implementation is very incomplete (see the various TODO comments
in the code) but rather than keeping it out of tree any longer I'm
committing it to trunk. This will allow others to experiment with it
and (I hope) work on finishing it. Either way we'll ship somehing for
gcc 9. It works OK for
On 11/10/18 14:34, Christophe Lyon wrote:
> The FDPIC register is hard-coded to r9, as defined in the ABI.
>
> We have to disable tailcall optimizations if we don't know if the
> target function is in the same module. If not, we have to set r9 to
> the value associated with the target module.
>
>
Hello,
In https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01795.html mail I suggested patch to have ability
to control behavior of "__attribute__((warning))" in case when option "-Werror"
enabled. Usage example:
#include
int a() __attribute__((warning("Warning: `a' was used")));
int a() { retu
On 11/10/18 14:34, Christophe Lyon wrote:
> In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> for executables rather than shared libraries by default.
>
> We also make sure to use the --fdpic assembler o
On 11/10/18 14:34, Christophe Lyon wrote:
> The new arm-uclinuxfdpiceabi target behaves pretty much like
> arm-linux-gnueabi. In order the enable the same set of features, we
> have to update several configure scripts that generally match targets
> like *-*-linux*: in most places, we add *-uclinux*
On 11/10/18 14:34, Christophe Lyon wrote:
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> gcc/
> * config/arm/arm.opt: Add -mfdpic option.
> * doc/invoke.texi: Add documentation for -mfdpic.
This is OK (once the rest of the series is approved).
R.
>
> diff --git a
Hi Olivier,
On 10/10/18 22:40, Olivier Hainque wrote:
Hello,
The aarch64 "platform register" r18 is currently
unconditionally used as a scratch register by gcc.
Working on a VxWorks port for this arch (that we
plan to contribute soon), we discovered that VxWorks
has an internal use of this reg
On 11/10/18 19:37, Wilco Dijkstra wrote:
> Here is the same version again with an extra test added:
>
> The popcount expansion uses SIMD instructions acting on 64-bit values.
> As a result a popcount of a 32-bit integer requires zero-extension before
> moving the zero-extended value into an FP re
> These are the easy ones (they default to reload):
>
> bergner@pike:~/gcc/gcc-fsf-mainline/gcc/config$ grep -r TARGET_LRA_P | grep
> false | sort alpha/alpha.c:#define TARGET_LRA_P hook_bool_void_false
> avr/avr.c:#define TARGET_LRA_P hook_bool_void_false
> bfin/bfin.c:#define TARGET_LRA_P hook_b
Hi Martin,
> On 10/9/18 11:03 AM, Rainer Orth wrote:
>> Hi Martin,
>>
>>> rename from gcc/testsuite/g++.dg/ext/pr82625.C
>>> rename to gcc/testsuite/g++.target/i386/pr82625.C
>>> index 59b174f8c51..0eb70baed5e 100644
>>> --- a/gcc/testsuite/g++.dg/ext/pr82625.C
>>> +++ b/gcc/testsuite/g++.target/
On Thu, Oct 11, 2018 at 09:39:51PM -0400, Marek Polacek wrote:
> Running make check-c++ RUNTESTFLAGS=dg.exp=decomp31.C will yield
> # of unsupported tests3
> because the test (as the only one in cpp1z/) uses
> "dg-do compile { target c++17 }" which doesn't work (yet?). This patch
>
On Thu, 11 Oct 2018 at 23:07, Jeff Law wrote:
>
> On 10/9/18 5:29 PM, Giuliano Augusto Faulin Belinassi wrote:
> > Fixed all issues pointed in the previous iteration.
> > There is now a significant change regarding how the sin(atan(x))
> > constant is calculated, as now it checks for which values
On Fri, 12 Oct 2018 at 07:47, Christophe Lyon
wrote:
>
> On Fri, 12 Oct 2018 at 05:37, Jeff Law wrote:
> >
> > On 10/8/18 11:12 AM, will wray wrote:
> > > Hi,
> > >
> > > A PR to fix Bug 87364 - Pretty print of enumerator never prints the id,
> > > always falls back to C-style cast output
> > >
>
68 matches
Mail list logo
