On 08/21/18 01:23, Martin Sebor wrote:
> On 08/20/2018 04:17 PM, Jeff Law wrote:
>> On 08/18/2018 11:38 AM, Martin Sebor wrote:
>>> On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23,
On 08/20/2018 06:40 PM, Jeff Law wrote:
On 08/17/2018 01:11 AM, Aldy Hernandez wrote:
No change in functionality, just a straight up conversion.
OK for trunk?
curr.patch
gcc/
* wide-int-range.cc (wide_int_range_abs): New.
(wide_int_range_order_set): Rename from wide_int_r
Am Montag, den 20.08.2018, 22:34 + schrieb Joseph Myers:
> On Mon, 20 Aug 2018, Uecker, Martin wrote:
>
> > This is a new version which adds proper changelog entries and
> > a test case (no actual code changes).
>
> Please include the overall description of a change in every version
> submit
On Tue, Aug 21, 2018, 9:08 AM Marek Polacek wrote:
> This patch implements -Wpessimizing-move, a C++-specific warning that warns
> when using std::move in a return statement precludes the NRVO. Consider:
>
> struct T { };
>
> T f()
> {
> T t;
> return std::move(t);
> }
>
> where we could eli
On 08/21/18 04:43, Martin Sebor wrote:
>> I must say that I don't like the return value optimization
>> on the sprintf pass, because it uses knowledge of the glibc implementation
>> of sprintf to do it's job (mind the 4K buffer limit).
>
> Yet again, you don't know what you're talking about. The
On 08/20/18 17:59, Bernd Edlinger wrote:
> On 08/20/18 15:19, Richard Biener wrote:
>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/20/18 13:01, Richard Biener wrote:
On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
wrote:
>
>
>
> On 08/01/18 11:29, Richard Biene
On 08/21/18 01:23, Martin Sebor wrote:
> On 08/20/2018 04:17 PM, Jeff Law wrote:
>> On 08/18/2018 11:38 AM, Martin Sebor wrote:
>>> On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23,
On 08/20/2018 04:22 PM, Jeff Law wrote:
On 08/20/2018 04:16 PM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
now. TYPE_PRECISION (wc
On 08/20/2018 03:31 PM, Bernd Edlinger wrote:
On 08/20/18 22:42, Martin Sebor wrote:
On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
On 08/20/18 16:26, Jeff Law wrote:
On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
On 08/20/18 12:12, Richard Biener wrote:
On Wed, Aug 15, 2018 at 6:39 AM Jeff La
On 08/20/2018 05:36 PM, Ian Lance Taylor wrote:
As a matter of style I don't personally like the pattern in which a
condition has both tests and actions. It's too easy to miss the
action. I would prefer to see this more like the original code:
if (!bad_fn && in != STDIN_FILE_NO)
{
On Mon, 2018-08-20 at 18:54 -0400, Marek Polacek wrote:
> On Mon, Aug 20, 2018 at 05:18:49PM -0400, David Malcolm wrote:
> > As of r263675 it's now possible to tell the diagnostics subsystem
> > that
> > the warning and note are related by using an auto_diagnostic_group
> > instance [1], so please
Jeff alerted me to some build breakage on s390 and spu targets. He's confirmed
this patch unbreaks s390, so I expect spu is also good. Committing to trunk.
Sorry for not deploying grep earlier.
nathan.
--
Nathan Sidwell
2018-08-20 Nathan Sidwell
Jeff Law
* config/s390/s390-c (s390_
On 08/20/2018 04:17 PM, Jeff Law wrote:
On 08/18/2018 11:38 AM, Martin Sebor wrote:
On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
On 08/17/2018 06:14 AM, Joseph Myers wr
On Mon, Aug 20, 2018 at 06:45:37PM -0400, Michael Meissner wrote:
> In this patch earlier to improve switch behavior:
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01957.html
>
> I noticed that the compiler wasn't generating the LWAX instruction. I tracked
> this down to the "extendsi2" insn us
On 08/18/18 20:01, Martin Sebor wrote:
> On 08/17/2018 05:01 PM, Bernd Edlinger wrote:
>> On 08/17/18 22:17, Martin Sebor wrote:
>>> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018
Hi, Paul,
I was trying to repeat this issue on a mips machine today, but failed…
the only mips machines I can access are those in gcc compile farm, I chose
gcc22, but failed to build GCC on this machine.
do you know any other machine in gcc compile farm that can repeat this issue?
thanks a lot
On 08/21/18 00:49, Joseph Myers wrote:
> On Mon, 20 Aug 2018, Jeff Law wrote:
>
>>> If you do that, probably you want to move
>>> fortran/trans-types.c:get_typenode_from_name (which converts the strings
>>> used in target macros such as WCHAR_TYPE to the corresponding types) into
>>> generic code.
On Mon, Aug 20, 2018 at 05:18:49PM -0400, David Malcolm wrote:
> As of r263675 it's now possible to tell the diagnostics subsystem that
> the warning and note are related by using an auto_diagnostic_group
> instance [1], so please can this read:
>
> if (can_do_nrvo_p (arg, functype))
>
Hi,
this simplifies get_format_string in gimple-ssa-sprintf.c
to use c_getstr.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-08-21 Bernd Edlinger
* gimple-ssa-sprintf.c (decl_constant_value): Remove.
(get_format_string): Refer to c_getstr.
d
On Mon, 20 Aug 2018, Jeff Law wrote:
> > If you do that, probably you want to move
> > fortran/trans-types.c:get_typenode_from_name (which converts the strings
> > used in target macros such as WCHAR_TYPE to the corresponding types) into
> > generic code.
> I think we ultimately have to go down
In this patch earlier to improve switch behavior:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01957.html
I noticed that the compiler wasn't generating the LWAX instruction. I tracked
this down to the "extendsi2" insn using the "Y" constraint when it can
optimize a load + sign extend into a sing
On 08/17/2018 01:11 AM, Aldy Hernandez wrote:
> No change in functionality, just a straight up conversion.
>
> OK for trunk?
>
> curr.patch
>
>
> gcc/
>
> * wide-int-range.cc (wide_int_range_abs): New.
> (wide_int_range_order_set): Rename from wide_int_range_min_max.
> * wide
On 08/21/18 00:22, Jeff Law wrote:
> On 08/20/2018 04:16 PM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>
WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
now. TYPE_
On Fri, 3 Aug 2018, Allan Sandfeld Jensen wrote:
> > I think you're changing the wrong place for this. If you want -r to be
> > usable with GCC without using -nostdlib (which is an interesting
> > question), you actually need to change LINK_COMMAND_SPEC (also sometimes
> > overridden for targets)
On Mon, 20 Aug 2018, Uecker, Martin wrote:
> This is a new version which adds proper changelog entries and
> a test case (no actual code changes).
Please include the overall description of a change in every version
submitted. That is, the patch submission message should both include a
descript
On 08/20/2018 04:16 PM, Joseph Myers wrote:
> On Fri, 17 Aug 2018, Jeff Law wrote:
>
>>> WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
>>> As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
>>> now. TYPE_PRECISION (wchar_type_node) / BITS_PER
On 08/18/2018 11:38 AM, Martin Sebor wrote:
> On 08/17/2018 09:32 PM, Jeff Law wrote:
>> On 08/17/2018 02:17 PM, Martin Sebor wrote:
>>> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug
On Fri, 17 Aug 2018, Jeff Law wrote:
> > WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
> > As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
> > now. TYPE_PRECISION (wchar_type_node) / BITS_PER_UNIT is what should be
> > used.
> But that's
Hi Will,
On Mon, Aug 20, 2018 at 04:40:35PM -0500, Will Schmidt wrote:
> This is a follow-up to an earlier patch that enabled gimple folding of
> vec_mergeh and vec_mergel for the float and double data types.
>
> Per feedback from Richard, use the types_compatible_p helper to ensure
> we also cat
Hi
Enable GIMPLE folding of the vec_splat() intrinsic. (v3).
This uses the tree_vec_extract() function out of tree-vect-generic.c
to retrieve the splat value, which is a BIT_FIELD_REF. That function is
made non-static as part of this change.
Testcases are already in-tree.
V2 update
Hi,
This is a follow-up to an earlier patch that enabled gimple folding of
vec_mergeh and vec_mergel for the float and double data types.
Per feedback from Richard, use the types_compatible_p helper to ensure
we also catch any qualified types matching the V2DF_ or V4SF_ types.
Regtests ran cl
On Mon, Aug 20, 2018 at 10:38 AM, Nathan Sidwell wrote:
>
> This is the first of a pair of patches I've had on the modules branch for a
> while. They improve the error behaviour in the case of child failure when
> vfork is the forking mechanism.
>
> This one commonizes the error paths in the pare
On 08/20/18 22:42, Martin Sebor wrote:
> On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
>> On 08/20/18 16:26, Jeff Law wrote:
>>> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
On 08/20/18 12:12, Richard Biener wrote:
> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>
>> On 08/10/
On Mon, 2018-08-20 at 17:08 -0400, Marek Polacek wrote:
> This patch implements -Wpessimizing-move, a C++-specific warning that
> warns
> when using std::move in a return statement precludes the
> NRVO. Consider:
>
> struct T { };
>
> T f()
> {
> T t;
> return std::move(t);
> }
>
> where we
On Mon, Jul 23, 2018 at 2:24 PM, H.J. Lu wrote:
> On Mon, Jun 18, 2018 at 12:26 PM, Joseph Myers
> wrote:
>> On Mon, 18 Jun 2018, Jason Merrill wrote:
>>
>>> On Mon, Jun 18, 2018 at 11:59 AM, Joseph Myers
>>> wrote:
>>> > On Mon, 18 Jun 2018, Jason Merrill wrote:
>>> >
>>> >> > + if (TREE_COD
We often emit logically-related groups of diagnostics.
A relatively simple case is this:
if (warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
inform (guard_loc, "some parts of macro expansion are not guarded by "
"this
This patch implements -Wpessimizing-move, a C++-specific warning that warns
when using std::move in a return statement precludes the NRVO. Consider:
struct T { };
T f()
{
T t;
return std::move(t);
}
where we could elide the copy were it not for the move call; the standard
requires that the
On Fri, Aug 10, 2018 at 11:04:50AM -0500, Segher Boessenkool wrote:
> On Tue, Jul 31, 2018 at 10:39:21AM -0400, Michael Meissner wrote:
> > This patch adds an insn to load a LABEL_REF into a GPR. This is needed so
> > the
> > FWPROP1 pass can convert the load the of the label address from the TOC
On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
On 08/20/18 16:26, Jeff Law wrote:
On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
On 08/20/18 12:12, Richard Biener wrote:
On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
On 08/10/2018 10:56 AM, Martin Sebor wrote:
On 08/08/2018 11:36 PM, Jeff L
Right after I hit the send button I realized that I had forgotten to
remove the definition of __cpp_lib_list_remove_return_type on the Debug
forward_list side.
I haven't plan to define this macro in this context, I prefer to leave
it to normal implementation.
So here is the updated patch.
This patch implements P0646R1 for Debug mode containers.
It fixes tests:
23_containers/forward_list/operations/remove_cxx20_return.cc
23_containers/forward_list/operations/unique_cxx20_return.cc
23_containers/list/operations/remove_cxx20_return.cc
23_containers/list/operations/unique_cxx20_retur
On 20/08/18 13:09 -0400, David Edelsohn wrote:
18_support/new_nothrow.cc relies upon overriding operator new. This is not
enabled by default in libstdc++ on AIX. This patch XFAILs the testcase.
Bootstrapped on powerpc-ibm-aix7.2.0.0
Okay?
OK, thanks.
On 08/13/2018 05:58 PM, Michael Ploujnikov wrote:
> Ping and I've updated the patch since last time as follows:
>
> - unittest scans assembly rather than the constprop dump because its
> forward changed
> - unittests should handle different hosts where any of
> NO_DOT_IN_LABEL, NO_DOLL
On 08/04/2018 07:22 AM, Giuliano Augusto Faulin Belinassi wrote:
> Closes bug #86829
>
> Description: Adds substitution rules for both sin(atan(x)) and
> cos(atan(x)). These formulas are replaced by x / sqrt(x*x + 1) and 1 /
> sqrt(x*x + 1) respectively, providing up to 10x speedup. This identity
On Mon, Aug 20, 2018 at 11:40 AM, Uros Bizjak wrote:
> On Mon, Aug 20, 2018 at 8:19 PM, H.J. Lu wrote:
>> On x86, return address is always popped in word_mode. eh_return needs
>> to put EH return address in word_mode on stack.
>>
>> Tested on x86-64 with x32. OK for trunk and release branches?
>
On 08/20/2018 01:05 PM, David Edelsohn wrote:
> builtin-sprintf-warn-1.c, builtin-sprintf-warn-2.c, and
> builtin-sprintf-11.c now are failing on AIX. I expect that at least part
> of the reason is 32 bit AIX uses 16 bit wchar_t
>
> #ifdef __64BIT__
> typedef unsigned intwchar_t;
> #else
> ty
builtin-sprintf-warn-1.c, builtin-sprintf-warn-2.c, and
builtin-sprintf-11.c now are failing on AIX. I expect that at least part
of the reason is 32 bit AIX uses 16 bit wchar_t
#ifdef __64BIT__
typedef unsigned intwchar_t;
#else
typedef unsigned short wchar_t;
#endif /* __64BIT__ */
Are the
On 08/15/2018 06:57 AM, Tamar Christina wrote:
> Hi All,
>
> This patch fixes an ICE that would happen when extract_low_bits
> is called with modes for which you can't extract a valid subreg.
> e.g. taking a 32 bytes subreg from a 48 byte mode.
>
> The ICE happens because convert_modes which even
On Mon, Aug 20, 2018 at 8:19 PM, H.J. Lu wrote:
> On x86, return address is always popped in word_mode. eh_return needs
> to put EH return address in word_mode on stack.
>
> Tested on x86-64 with x32. OK for trunk and release branches?
OK. Perhaps the testcase should go into g++.dg/torture, sinc
On 08/02/2018 03:17 AM, Chung-Lin Tang wrote:
> 2018-08-02 Chung-Lin Tang
>
> * targhooks.c (std_gimplify_va_arg_expr): Properly handle case of when
>
> TARGET_SPLIT_COMPLEX_ARG is defined.
Thanks. I've committed this to the trunk.
jeff
On 08/07/2018 05:50 AM, marxin wrote:
> This is the most complex patch. It follows original implementation and
> does following improvements that were part of original code:
>
> a) for a node with both children (that don't have children) and only single
> case
> values handled: emit series of 3 c
On Aug 18, 2018, at 1:17 PM, Iain Sandoe wrote:
>
> The point of running dsymutil automatically from collect2 is that it
> (collect2, lto-wrapper, etc) might be generating or using compiler
> temporary files that will be deleted at the end of the link process.
>
> dsymutil requires that it can s
On x86, return address is always popped in word_mode. eh_return needs
to put EH return address in word_mode on stack.
Tested on x86-64 with x32. OK for trunk and release branches?
Thanks.
H.J.
---
gcc/
PR target/87014
* config/i386/i386.md (eh_return): Always update EH return
Hi, Rainer,
thanks a lot to report the issues with mips and sparc platform.
Yes, looks like even on the assembly level, the string scanning still not
reliable on different platforms.
I agree with Jeff’s suggestion to apply different search result for different
platforms.
I will update the tes
Last bit of cleanup in the preprocessor. We only need 2 bits to hold
the node_type enumeration, and 8 bits for the flags.
That leaves several unused bits, which we may as well note.
nathan
--
Nathan Sidwell
2018-08-20 Nathan Sidwell
* include/cpplib.h: Fixup some whitespace.
(cpp_hashnod
This is the first of a pair of patches I've had on the modules branch
for a while. They improve the error behaviour in the case of child
failure when vfork is the forking mechanism.
This one commonizes the error paths in the parent and child to a pair of
single blocks that print or return the
On Mon, 20 Aug 2018, MCC CS wrote:
this patch optimizes ~(~x | y), (~x | y) & (x | ~y) and
(~x | y) ^ (x | ~y).
Thank you. I didn't mean to force you to add the extra transformations to
your patch, but now that they are here, that's good :-)
gcc/
PR tree-optimization/87009
* match.pd: Impr
On Tue, 2018-08-07 at 12:15 -0500, Segher Boessenkool wrote:
> > +/* { dg-final { scan-assembler-not "\[ \t\]stp\tq\[01234567\]" } }
> > */
> That's [0-7] but maybe you find [01234567] more readable here.
Segher, I fixed all the issues you pointed out except this one. Since
there are some uses
On 08/20/18 12:23, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi,
>>
>>
>> I rebased my range computation patch to current trunk,
>> and updated it according to what was discussed here.
>>
>> That means get_range_strlen has already a parameter
>> that is used to diff
On 08/15/2018 10:49 PM, Dimitar Dimitrov wrote:
> ChangeLog:
>
> 2018-07-27 Dimitar Dimitrov
>
> * configure: Regenerate.
> * configure.ac: Add PRU target.
>
> gcc/ChangeLog:
>
> 2018-07-27 Dimitar Dimitrov
>
> * common/config/pru/pru-common.c: New file.
> * confi
18_support/new_nothrow.cc relies upon overriding operator new. This is not
enabled by default in libstdc++ on AIX. This patch XFAILs the testcase.
Bootstrapped on powerpc-ibm-aix7.2.0.0
Okay?
Thanks, David
* testsuite/18_support/new_nothrow.cc: XFAIL on AIX.
Index: 18_support/new_nothrow.cc
Finally, this gets to clean up the convoluted way the preprocessor marks
the type of identifier nodes. Right now it's a combination of a type
field and a pair of flags, which gives rise to some convoluted tests and
remapping for GTY. This patch rationalizes it by using the type field
exclusiv
On 08/20/18 15:19, Richard Biener wrote:
> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/20/18 13:01, Richard Biener wrote:
>>> On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
>>> wrote:
On 08/01/18 11:29, Richard Biener wrote:
>
> Hmm. I think it would be nice
I noticed I'd inadvertently allowed a trailing comma to creep in,
leading to annoying warnings. I'd also missed a few uses of the
cpp_macro_p function and friends. Plus Bernhard had suggested there's a
name for 255 when it's encoding unsigned char range.
Fixed thusly.
nathan
--
Nathan Sidwe
On 08/20/18 16:26, Jeff Law wrote:
> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
>> On 08/20/18 12:12, Richard Biener wrote:
>>> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
On 08/10/2018 10:56 AM, Martin Sebor wrote:
> On 08/08/2018 11:36 PM, Jeff Law wrote:
>> On 08/02/201
> On 20 Aug 2018, at 15:55, Alexander Monakov wrote:
> On Mon, 20 Aug 2018, Iain Sandoe wrote:
>
>> I am seeing excess changes when running
I meant regenerating .. not running..
>> configure, is it possible the regenerated files were missed from this rev?
>>
>> https://gcc.gnu.org/ml/gcc-cv
Hi everyone,
this patch optimizes ~(~x | y), (~x | y) & (x | ~y) and
(~x | y) ^ (x | ~y). Thanks to Marc Glisse
for noticing that the last two weren't optimized.
I'll post the test results soon, it took three hours in
addition to timeouts and I had to terminate it.
Waiting for your comments.
On 08/20/18 16:54, Jeff Law wrote:
> On 08/20/2018 08:52 AM, Bernd Edlinger wrote:
>> On 08/20/18 16:16, Jeff Law wrote:
>>> On 08/20/2018 07:28 AM, Richard Biener wrote:
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
> On 08/20/18 12:41, Richard Biener wrote:
>> On Sun, 19 Aug 2018,
On Mon, 20 Aug 2018, Iain Sandoe wrote:
> I am seeing excess changes when running configure, is it possible the
> regenerated files were missed from this rev?
>
> https://gcc.gnu.org/ml/gcc-cvs/2018-07/msg00172.html
Yes, that change did not regenerate configure scripts. I've also noticed th
On 08/20/2018 08:52 AM, Bernd Edlinger wrote:
> On 08/20/18 16:16, Jeff Law wrote:
>> On 08/20/2018 07:28 AM, Richard Biener wrote:
>>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>>
On 08/20/18 12:41, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi!
On 08/20/18 16:16, Jeff Law wrote:
> On 08/20/2018 07:28 AM, Richard Biener wrote:
>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/20/18 12:41, Richard Biener wrote:
On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> Hi!
>
>
> This fixes a wrong code issue in expand_e
I am seeing excess changes when running configure, is it possible the
regenerated files were missed from this rev?
https://gcc.gnu.org/ml/gcc-cvs/2018-07/msg00172.html
thanks
Iain
On 08/15/2018 10:49 PM, Dimitar Dimitrov wrote:
> The floating point support has been borrowed from C6X libgcc port
> to help with TI PRU toolchain ABI compatibility.
>
> libgcc/ChangeLog:
>
> 2018-07-27 Dimitar Dimitrov
>
> * config.host: Add PRU target.
> * config/pru/asri.c: Ne
On 08/15/2018 10:49 PM, Dimitar Dimitrov wrote:
> gcc/testsuite/ChangeLog:
>
> 2018-07-27 Dimitar Dimitrov
>
> * gcc.target/pru/abi-arg-struct.c: New test.
> * gcc.target/pru/ashiftrt.c: New test.
> * gcc.target/pru/builtins-1.c: New test.
> * gcc.target/pru/builtins-er
On 08/18/2018 03:20 AM, Eric Botcazou wrote:
>> Eric, didn't your patches explicitely handle this case of a non-constant
>> inbetween?
>
> Only if there is no overlap at all, otherwise you cannot do things simply.
>
>> Can you have a look / review here?
>
> Jakub is probably more qualified to gi
On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
> On 08/20/18 12:12, Richard Biener wrote:
>> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>>
>>> On 08/10/2018 10:56 AM, Martin Sebor wrote:
On 08/08/2018 11:36 PM, Jeff Law wrote:
> On 08/02/2018 09:42 AM, Martin Sebor wrote:
>
>
Now that cpp-id-data.h contains a single #include, we can kill it and
have its includers simply point at the sub include. That turns out to
be a single file.
Except of course, the makefile & gty pieces that also need updates, but
mechanical ones.
booted & tested on x86_64-linux, committing
On 08/20/2018 07:28 AM, Richard Biener wrote:
> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/20/18 12:41, Richard Biener wrote:
>>> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>>>
Hi!
This fixes a wrong code issue in expand_expr_real_1 which happens because
a negat
This is a new version which adds proper changelog entries and
a test case (no actual code changes).
Bootstrapped an regression tested on x86_64.
gcc/
* common.opt (flag_trampolines): Change default.
* calls.c (prepare_call_address): Remove check for
flag
The following implements parts of the suggested transforms in PR78655
by making code already in VRP actually trigger. The patch doesn't
handle
void bar (int *x, int a)
{
if (a != 0)
{
int *p = x + a;
if (p == 0)
link_error ();
}
}
because a gets promoted to sizety
On 17/08/18 19:54 +0100, Jonathan Wakely wrote:
On 17/08/18 19:01 +0100, Jonathan Wakely wrote:
On 17/08/18 18:52 +0100, Jonathan Wakely wrote:
+ // The tag parameter ensures that in nested tuples each __tuple_base
+ // is a different type and can use the empty base-class optimisation.
+ tem
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
> On 08/20/18 12:41, Richard Biener wrote:
> > On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> >
> >> Hi!
> >>
> >>
> >> This fixes a wrong code issue in expand_expr_real_1 which happens because
> >> a negative bitpos is actually able to reach extract_bit_f
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
> On 08/20/18 13:01, Richard Biener wrote:
> > On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
> > wrote:
> >>
> >>
> >>
> >> On 08/01/18 11:29, Richard Biener wrote:
> >>>
> >>> Hmm. I think it would be nice if TREE_STRING_LENGTH would
> >>> match char[
On Fri, 17 Aug 2018, Tom de Vries wrote:
> I've rewritten the patch to work generically, not just for DW_AT_upper_bound,
> and to reuse the code already there in add_scalar_info.
>
> OK for trunk?
>
> Thanks,
> - Tom
>
> [debug] Fix handling of vlas in lto
>
> Atm, when running vla-1.c with -O
On Wed, 15 Aug 2018, Tom de Vries wrote:
> Hi,
>
> This patch adds option -greadable-dwarf. In absence of an DW_AT_comment
> attribute,
What's a DW_AT_comment attribute? I don't see this mentioned in the
patch.
> it sets the DW_AT_name attribute of dies that otherwise do not get
> that attrib
The preprocessor has cpp-asserts, a deprecated extension. They look
like macros in that they have a tokenized body, but there's a chain of
them hanging off an assert node, rather than having any parms.
This patch removes their 'answer' struct, and extends cpp_macro to
represent them. the enu
On 08/20/18 12:41, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This fixes a wrong code issue in expand_expr_real_1 which happens because
>> a negative bitpos is actually able to reach extract_bit_field which
>> does all computations with poly_uint64, thus t
On Fri, 10 Aug 2018, Jan Hubicka wrote:
> Hi,
> this patch should fix merging of PIC and PIE options so we always resort
> to the least common denominator of the object files compiled (i.e.
> linking together -fpic and -fPIE will result in -fpie binary).
> Note that we also use information about
On Mon, 13 Aug 2018, Tom de Vries wrote:
> Hi,
>
> With the introduction of early debug, we've added a phase in the compiler
> which
> produces information which is not visible, unless we run the compiler in the
> debugger and call debug_dwarf from dwarf2out_early_finish or some such.
>
> This
On Thu, Jul 26, 2018 at 10:52 PM Martin Sebor wrote:
>
> On 07/26/2018 08:58 AM, Martin Sebor wrote:
> > On 07/26/2018 02:38 AM, Richard Biener wrote:
> >> On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor wrote:
> >>>
> >>> On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
> On Wed, Jul 25, 2018 at 0
* include/std/optional (_Optional_payload): Use variable templates
for conditions in default template arguments and exception
specifications.
(optional): Likewise. Adjust indentation.
(optional::__not_self, optional::__not_tag, optional::_Requires): New
On 08/20/18 13:01, Richard Biener wrote:
> On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
> wrote:
>>
>>
>>
>> On 08/01/18 11:29, Richard Biener wrote:
>>>
>>> Hmm. I think it would be nice if TREE_STRING_LENGTH would
>>> match char[2] and TYPE_SIZE_UNIT even if that is inconvenient
>>> for your
On Mon, 20 Aug 2018, Jan Hubicka wrote:
> Hi,
> this hunk should be obsolette now.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK, can you un-export is_redundant_typedef after this please?
Richard.
> Honza
>
> Index: tree.c
> ==
On Mon, 20 Aug 2018, Jan Hubicka wrote:
> Hi,
> this patch drops types from decl context in free lang data. This is not
> possible
> for field decls (because they are chained by TREE_CHAIN), for variably
> modified
> types (becuase it is used in tree_is_indexable and other places) and for
> virt
Hi,
this hunk should be obsolette now.
Bootstrapped/regtested x86_64-linux, OK?
Honza
Index: tree.c
===
--- tree.c (revision 263586)
+++ tree.c (working copy)
@@ -5542,11 +5565,7 @@ find_decls_types_r (tree *tp, int *ws, v
Hi,
this patch drops types from decl context in free lang data. This is not possible
for field decls (because they are chained by TREE_CHAIN), for variably modified
types (becuase it is used in tree_is_indexable and other places) and for
virtual functions/tables (because it is used by devirt machin
On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger wrote:
>
>
>
> On 08/01/18 11:29, Richard Biener wrote:
> >
> > Hmm. I think it would be nice if TREE_STRING_LENGTH would
> > match char[2] and TYPE_SIZE_UNIT even if that is inconvenient
> > for your check above. Because the '\0' doesn't belong to t
On Mon, 20 Aug 2018, Richard Biener wrote:
> So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> not supported?
Pekka, can you comment? I think you have fallback paths for vector types
only at the moment?
Does BRIG have mult-highpart for 64-bit integers? On 32-bit targets we
On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> Hi!
>
>
> This fixes a wrong code issue in expand_expr_real_1 which happens because
> a negative bitpos is actually able to reach extract_bit_field which
> does all computations with poly_uint64, thus the offset 0x1ff0.
>
> To avoid that
Ping!
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide which pr
1 - 100 of 114 matches
Mail list logo