The assert I added with the -fstrict-overflow transition is too strict
when facing with generic folding thus the following removes it again.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-08-01 Richard Biener
PR tree-optimization/81297
*
Hi!
I'd like to ping the aarch64/arm parts of the
http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01511.html
vec_init/vec_extract patch. The generic part of the patch
has been approved by Richard, and the other config/*/ parts have
either been approved by their respective maintainers, or I'm going
t
On Mon, 31 Jul 2017, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes a couple of issues in optimize_range_tests_var_bound.
> One is that if we have ranges[i].in_p, we should be inverting the comparison
> rather than just swapping or not swapping operands. Then because
> we want to handle only LT
Hi All,
Previously I allowed 0s unconditionally through aarch64_can_const_movi_rtx_p
because we should always be able to use movi with 0 regardless of the mode.
However this was causing issues when a vector contained a 0 element and
another value which was too complex for a movi. In theory this s
On Tue, Aug 01, 2017 at 09:06:38AM +0200, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the aarch64/arm parts of the
> http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01511.html
> vec_init/vec_extract patch. The generic part of the patch
> has been approved by Richard, and the other config/*/ part
On 25/07/17 10:14, Jakub Jelinek wrote:
> Hi!
>
> The following patch adjusts the vec_init and vec_extract optabs, so that
> they don't have in the expander names just the vector mode, but also another
> mode, for vec_extract the mode of the result and for vec_init the mode of
> the elts of the ve
On Mon, Jul 31, 2017 at 4:03 PM, Bill Schmidt
wrote:
>
>> On Jul 31, 2017, at 8:19 AM, Bill Schmidt
>> wrote:
>>
>> That would certainly be much simpler! I'll regstrap it and test it on the
>> other
>> occurrence I've found to be certain.
>
> Unfortunately, this fails bootstrap:
>
> /home/wsch
On Mon, Jul 31, 2017 at 4:12 PM, Bin Cheng wrote:
> Hi,
> This simple patch fixes the ICE by not setting has_max_use_after flag for
> store-store chain because there is no use at all.
> Bootstrap and test on x86_64 and AArch64 ongoing. Is it OK if no failure?
Ok.
Richard.
> Thanks,
> bin
> 201
On Mon, Jul 31, 2017 at 4:14 PM, Bin Cheng wrote:
> Hi,
> This simple patch fixes the ICE by rewriting into loop closed ssa form in case
> of any store-store chain. We maybe able to avoid that for some cases that
> eliminated stores only store loop invariant values, but only with more checks
> wh
Part#2. Document -finstrument-control-flow and notrack attribute.
0002-Part-2.-Document-finstrument-control-flow-and-notrac.patch
Description: 0002-Part-2.-Document-finstrument-control-flow-and-notrac.patch
Part#3. Add tests for -finstrument-control-flow and notrack attribute.
0003-Part-3.-Add-tests-for-finstrument-control-flow-and-n.patch
Description: 0003-Part-3.-Add-tests-for-finstrument-control-flow-and-n.patch
Part#1. Add generic part for Intel CET enabling.
The spec is available at
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
High-level design.
--
A proposal is to introduce a target independent flag
-finstrument-control-
Part#5. Add x86 CET documentation.
0005-Part-5.-Add-x86-CET-documentation.patch
Description: 0005-Part-5.-Add-x86-CET-documentation.patch
Part#7. Enable building libgcc with CET options.
Enable building libgcc with CET options by default on Linux/x86 if
binutils supports CET v2.0.
It can be disabled with --disable-cet. It is an error to configure
GCC with --enable-cet if bintuiils doesn't support CET v2.0.
0007-Part-7.-Enable-bui
Part#6. Add x86 tests for Intel CET implementation.
0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation.patch
Description: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation.patch
Part#9. Enable bootstrap GCC with CET flags.
0009-Part-9.-Enable-bootstrap-GCC-with-CET-flags.patch
Description: 0009-Part-9.-Enable-bootstrap-GCC-with-CET-flags.patch
Part#4. Update x86 backend to enable Intel CET.
All platforms except i386 will report the error and do no
instrumentation with -finstrument-control-flow option. i386 will provide
the implementation based on a specification published by Intel for a new
technology called Control-flow Enforcement Tec
Part#8. Add Intel CET support for EH in libgcc.
Control-flow Enforcement Technology (CET), published by Intel, introduces
the Shadow Stack feature, which ensures a return from a function is done
to exactly the same location from where the function was called. When EH
is present the control-flow tr
On Tue, Aug 1, 2017 at 2:00 AM, Steve Ellcey wrote:
> Here is a second set of patches to fix tests that started failing
> with the patch for PR 80925. It uses the same testsuite changes
> I did for no-section-anchors-vect-69.c and section-anchors-vect-69.c
> on new set of gcc.dg/vect/vect-* tests
Committed as revision r250762.
Dominique
On Tue, Aug 1, 2017 at 2:11 AM, Martin Sebor wrote:
> On 07/31/2017 05:11 PM, Trevor Saunders wrote:
>>
>> On Mon, Jul 31, 2017 at 04:58:15PM -0600, Martin Sebor wrote:
>>>
>>> On 07/31/2017 03:34 PM, Trevor Saunders wrote:
On Mon, Jul 31, 2017 at 02:56:40PM -0600, Martin Sebor wrote:
>>
On Tue, Aug 1, 2017 at 1:24 AM, Segher Boessenkool
wrote:
> This series creates pattern_cost and insn_cost functions that together
> replace the existing insn_rtx_cost function.
>
> pattern_cost is like the old insn_rtx_cost function; insn_cost takes
> an actual rtx_insn * as input, not just a pat
Sorry about the delayed response but looking at the above discussion, should I
conclude that this is a valid tree simplification?
I am pasting the diff of the assembly that AArch64 generates with the test case
that I added. I see fewer instructions generated with the patch.
--- pr80131-1.s
On Tue, Aug 1, 2017 at 4:27 AM, Martin Sebor wrote:
> Richard,
>
> in discussing this work Jeff mentioned that your comments on
> the tree-ssa-alias.c parts would be helpful. When you have
> a chance could you please give it a once over and let me know
> if you have any suggestions or concerns?
On 13 July 2017 at 10:46, Iain Buclaw wrote:
> On 24 June 2017 at 19:23, Iain Buclaw wrote:
>> Hi,
>>
>> Just doing an update of the patch series, rebased against trunk, and
>> applied changes as requested by every comment so far.
>>
>> Notes on changes have been made on each patch where applicab
On Tue, Aug 1, 2017 at 11:23 AM, Richard Biener
wrote:
> On Tue, Aug 1, 2017 at 4:27 AM, Martin Sebor wrote:
>> Richard,
>>
>> in discussing this work Jeff mentioned that your comments on
>> the tree-ssa-alias.c parts would be helpful. When you have
>> a chance could you please give it a once ov
On Tue, Jul 25, 2017 at 8:26 AM, Richard Biener
wrote:
> On Mon, Jul 24, 2017 at 10:43 AM, Bin Cheng wrote:
>> Hi,
>> This is a followup patch to PR81388's fix. According to Richi,
>> POINTER_TYPE_OVERFLOW_UNDEFINED was added in -fstrict-overflow
>> warning work. Given:
>> A) strict-overflow
On Tue, Aug 01, 2017 at 08:35:06AM +0100, Tamar Christina wrote:
> Hi All,
>
> Previously I allowed 0s unconditionally through aarch64_can_const_movi_rtx_p
> because we should always be able to use movi with 0 regardless of the mode.
>
> However this was causing issues when a vector contained a 0
On Mon, Jun 26, 2017 at 11:49 AM, Tamar Christina
wrote:
> Hi,
>
> With the changes in the patches the testsuite had a minor update in the
> assembler scan.
> I've posted the patch but will assume it's OK based on the previous OK for
> trunk and
> the fact that this can fall in the obvious rule.
On Thu, Jul 27, 2017 at 03:21:01PM +0100, James Greenhalgh wrote:
> On Thu, Jul 27, 2017 at 02:26:03PM +0200, Richard Biener wrote:
> > On Thu, Jul 27, 2017 at 2:08 PM, Jakub Jelinek wrote:
> > > On Thu, Jul 27, 2017 at 01:54:21PM +0200, Richard Biener wrote:
> > >> --- gcc/common.opt (revis
When working on PR81181 I ran into some things I wanted to clean up
several times. First a few PRE cleanups done for the fix. Second,
the fake exit edges we add for infinite loops happen to start from
loop headers rather than latches which is somewhat confusing and
making PRE dataflow order more
ping
From: Wilco Dijkstra
Sent: 26 July 2017 14:46
To: GCC Patches; James Greenhalgh
Cc: nd
Subject: [PATCH][AArch64] Remove '*' from movsi/di/ti patterns
Remove the remaining uses of '*' from the movsi/di/ti patterns.
Using '*' in alternatives is typically incorrect at it tells the registe
ping
From: Wilco Dijkstra
Sent: 25 July 2017 14:58
To: GCC Patches; James Greenhalgh; Jeff Law
Cc: nd
Subject: [PATCH][AArch64] Simplify frame layout for stack probing
This patch makes some changes to the frame layout in order to simplify
stack probing. We want to use the save of LR as a p
ping
Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>
> > I note this is still marked as an RFC, are you now proposing it as a
> > patch to be merged to trunk?
>
> Absolutely. It was marked as an RFC to get some comments - I thought it
> may be controversial to separate the frame po
ping
From: Wilco Dijkstra
Sent: 17 January 2017 15:14
To: Richard Earnshaw; GCC Patches; James Greenhalgh
Cc: nd
Subject: Re: [PATCH v3][AArch64] Fix symbol offset limit
Here is v3 of the patch - tree_fits_uhwi_p was necessary to ensure the size of a
declaration is an integer. So the
ping
This patch further improves aarch64_legitimate_constant_p. Allow all
integer, floating point and vector constants. Allow label references
and non-anchor symbols with an immediate offset. This allows such
constants to be rematerialized, resulting in smaller code and fewer stack
sp
ping
From: Wilco Dijkstra
Sent: 20 July 2017 13:49
To: GCC Patches; James Greenhalgh
Cc: nd
Subject: [PATCH][AArch64] Improve addressing of TI/TFmode
In https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01125.html Jiong
pointed out some addressing inefficiencies due to a recent change in
regcpr
On 07/31/2017 09:21 AM, Martin Liška wrote:
On 07/26/2017 07:45 PM, Jeff Law wrote:
On 07/12/2017 07:38 AM, Martin Liška wrote:
Hi.
Following patch adds -lspp when one uses -mstack-protector-guard=global.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be
On Mon, 31 Jul 2017, Maxim Kuvyrkov wrote:
> I don't see an easy way to correctly differentiate between "attribute"
> nops and "bundle" nops, so XFAILing these tests on ia64 seems like a
> valid approach.
Make sense, given that the use of Itanium has gone done drastically.
Gerald
On Tue, 1 Aug 2017, Richard Biener wrote:
>
> When working on PR81181 I ran into some things I wanted to clean up
> several times. First a few PRE cleanups done for the fix. Second,
> the fake exit edges we add for infinite loops happen to start from
> loop headers rather than latches which is
On Aug 01 2017, Gerald Pfeifer wrote:
> On Mon, 31 Jul 2017, Maxim Kuvyrkov wrote:
>> I don't see an easy way to correctly differentiate between "attribute"
>> nops and "bundle" nops, so XFAILing these tests on ia64 seems like a
>> valid approach.
>
> Make sense, given that the use of Itanium h
On Tue, Aug 1, 2017 at 12:08 PM, James Greenhalgh
wrote:
>
> On Thu, Jul 27, 2017 at 03:21:01PM +0100, James Greenhalgh wrote:
>> On Thu, Jul 27, 2017 at 02:26:03PM +0200, Richard Biener wrote:
>> > On Thu, Jul 27, 2017 at 2:08 PM, Jakub Jelinek wrote:
>> > > On Thu, Jul 27, 2017 at 01:54:21PM +0
On Thu, Jul 27, 2017 at 11:36 PM, Richard Sandiford
wrote:
> This is a minimal-ish backport of the fix for PR80769. The trunk version
> also replaced open-coded instances of get_next_strinfo with calls to the
> new function. It also added asserts in various other places to try to
> ensure that r
Hello!
Naked functions should not sibcall, since in naked functions epilogue
point (placed just above sibcal insn) is unreachable and marked with a
trap insn.
2017-08-01 Uros Bizjak
PR target/81639
* config/i386/i386.c (ix86_funciton_naked): New prototype.
(ix86_function_ok_for_si
On Wed, Jun 7, 2017 at 12:38 PM, Tamar Christina
wrote:
> Hi All,
>
>
> This patch lays the ground work to fix the immediate moves for floats
> to use a combination of mov, movi, fmov instead of ldr and adrp to load
> float constants that fit within the 16-bit limit of movz.
>
> The idea behind it
Hi Bin,
> Hi,
> I saw below failure after svn+ssh://gcc.gnu.org/svn/gcc/trunk@250672
>
> FAIL: gcc.target/aarch64/advsimd-intrinsics/vcvt_high_1.c -O1
> (internal compiler error)
This should be fixed by r 250766
Cheers,
Tamar
>
> Regression in patch updates?
>
> Thanks,
> bin
> >
> > OK fo
Using -O -masm=intel following testcase (gcc.target/i386/addr-space-2.c):
--cut here--
int test(void)
{
int __seg_fs *f = (int __seg_fs *)16;
int __seg_gs *g = (int __seg_gs *)16;
return *f + *g;
}
--cut here--
compiles to:
mov eax, DWORD PTR gs:ds:16
add eax, DWORD
I am testing the following pair of patches (first for trunk, 2nd for GCC 7
branch) to fix PR81633. On trunk recent refactoring made the PR71752
change obsolete, on the branch the patch installs the simpler originally
suggested patch which works within the constraints vect_get_slp_defs
is used on
Hi All,
The big-endian tests were failing because it failed to take into account that
in order to generate mov/movk pairs for doubles the bit order are different from
le.
I have updated the tests with conditional results for both endianness.
Committed as r250770.
Regtested on aach64-none-linux-
On Mon, Jun 26, 2017 at 11:50 AM, Tamar Christina
wrote:
> Hi all,
>
> Here's the re-spun patch.
> Aside from the grouping of the split patterns it now also uses h register for
> the fmov for HF when available,
> otherwise it forces a literal load.
>
> Regression tested on aarch64-none-linux-gnu
On Sat, 15 Apr 2017, Gerald Pfeifer wrote:
> On Sat, 8 Apr 2017, Ionut Vatavu wrote:
>> I would like to announce a new mirror in Germany Gunzenhausen:
>>
>> http://www.bothelp.net/mirrors/gcc - updated daily by rsync
> This is now part of our mirrors list per the patch below.
And here is an updat
>
> Given review comment already pointed out big-endian issue and patch was
> updated to address it, I would expect reg-test on a big-endian target before
> applying patch, right?
The patch spent 6 months in external review.
Given that, I simply forgot to rerun big endian before the commit as I d
On 07/27/2017 01:48 PM, Richard Biener wrote:
On Thu, Jul 27, 2017 at 12:12 PM, Martin Liška wrote:
Hello.
As reported in mentioned PR, we segfault in gcov tool when one uses -a. It's
caused by fact
that vectors blocks and block_lists have indices kept in sync and as one
removes an element
f
On Tue, Aug 1, 2017 at 12:51 PM, Tamar Christina
wrote:
>>
>> Given review comment already pointed out big-endian issue and patch was
>> updated to address it, I would expect reg-test on a big-endian target before
>> applying patch, right?
>
> The patch spent 6 months in external review.
> Given t
Hi,
Sorry this fix is incorrect, I have reverted the patch to address the rest of
the
Big endian failures.
Sorry,
Tamar
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tamar Christina
> Sent: 01 August 2017 12:43
> To: gc
Hi Richard,
> On Jul 31, 2017, at 11:58 , Richard Earnshaw (lists)
> wrote:
>
>> Regarding removal of old ABI support, which release were you
>> targeting ?
>>
>> On the VxWorks front, where we adapt to what the system toolchains
>> do, it will mean dropping support for VxWorks versions prior
> On Aug 1, 2017, at 1:40 AM, Jakub Jelinek wrote:
>
> Hi!
>
> On Mon, Jul 31, 2017 at 02:42:21PM -0500, Bill Schmidt wrote:
>>> On Jul 31, 2017, at 11:27 AM, Jakub Jelinek wrote:
>>> On Mon, Jul 31, 2017 at 11:19:26AM -0500, Bill Schmidt wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?i
> On Aug 1, 2017, at 3:46 AM, Richard Biener wrote:
>
> On Mon, Jul 31, 2017 at 4:03 PM, Bill Schmidt
> wrote:
>>
>>> On Jul 31, 2017, at 8:19 AM, Bill Schmidt
>>> wrote:
>>>
>>> That would certainly be much simpler! I'll regstrap it and test it on the
>>> other
>>> occurrence I've found
Hello,
libgcc/config/vxlib*.c implement parts-of/helpers-for the gthreads API
to support EH services for VxWorks.
This patch adjusts config/t-vxworks to add them to LIB2ADDEH instead
of modifying LIB2ADD, so the object files get bundled together with the
other EH related modules.
Tested by verif
> On Aug 1, 2017, at 1:52 PM, Andreas Schwab wrote:
>
> On Aug 01 2017, Gerald Pfeifer wrote:
>
>> On Mon, 31 Jul 2017, Maxim Kuvyrkov wrote:
>>> I don't see an easy way to correctly differentiate between "attribute"
>>> nops and "bundle" nops, so XFAILing these tests on ia64 seems like a
>>>
The following adds optab checks to see whether the target prefers
vector from vector extracts or integer from punned integer vector
extracts. But instead of falling back to elementwise operation
we fall back to the vector from vector extract path as spilling
the vector to extract from and then do
Hello,
libgcc/config/t-vxworks twists LIBGCC2_INCLUDE to workaround a problem of
header file name conflicts between the system headers and gcc headers during
libgcc builds:
# This ensures that the correct target headers are used; some
# VxWorks system headers have names that collide with GCC's
#
The following fixes another case of endless compute_antic iteration
in PRE. After a lengthy four-eyes discussion here we concluded that
the way clean () operates on expressions rather than values can
cause oscillation in the dataflow problem.
Thus we have to delay it (at the cost of some interme
On Aug 01 2017, Maxim Kuvyrkov wrote:
> Do you know a reliable way of checking whether target can issue nops in
> simple code?
Try inspecting one of the rtl dumps.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"
On Tue, Aug 1, 2017 at 2:02 PM, Martin Liška wrote:
> On 07/27/2017 01:48 PM, Richard Biener wrote:
>>
>> On Thu, Jul 27, 2017 at 12:12 PM, Martin Liška wrote:
>>>
>>> Hello.
>>>
>>> As reported in mentioned PR, we segfault in gcov tool when one uses -a.
>>> It's caused by fact
>>> that vectors b
On Fri, Jul 28, 2017 at 3:15 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Fri, Jul 28, 2017 at 12:55 PM, Richard Sandiford
>> wrote:
>>> Bin Cheng writes:
Hi,
This simple patch fixes the ICE by adding LTGT in
vec_cmp pattern.
I also modified the original test cas
On Tue, Aug 01, 2017 at 03:19:28PM +0200, Richard Biener wrote:
> + if (lvectype != vectype)
> + {
> + tree tem = make_ssa_name (lvectype);
> + gimple *pun= gimple_build_assign (tem, build1
> + (VIEW_CONVERT_EXPR, lvectyp
On Aug 1, 2017, at 7:44 AM, Bill Schmidt wrote:
>
>>
>> On Aug 1, 2017, at 3:46 AM, Richard Biener
>> wrote:
>>
>> On Mon, Jul 31, 2017 at 4:03 PM, Bill Schmidt
>> wrote:
>>>
On Jul 31, 2017, at 8:19 AM, Bill Schmidt
wrote:
That would certainly be much simpler! I'll
Hello,
As mentioned in the thread rooted at
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00720.html,
the arm-vxworks port needs refreshing. As mentioned earlier in other vxworks
related threads, it was on my list of things to do and this patch implements
a first batch of changes to this effect.
Hi,
this patch simplifies the nvtpx/slp* test-cases by using signed loop
iteration variables, in order to work around PR81635.
Committed.
Thanks,
- Tom
Simplify nvptx/slp* test-cases
Use signed loop iteration variable in nvtpx/slp* test-cases to work around
PR tree-optimizaion/81635.
2017-0
On Tue, Aug 1, 2017 at 3:50 PM, Bill Schmidt
wrote:
> On Aug 1, 2017, at 7:44 AM, Bill Schmidt wrote:
>>
>>>
>>> On Aug 1, 2017, at 3:46 AM, Richard Biener
>>> wrote:
>>>
>>> On Mon, Jul 31, 2017 at 4:03 PM, Bill Schmidt
>>> wrote:
> On Jul 31, 2017, at 8:19 AM, Bill Schmidt
> w
On 08/01/2017 03:46 PM, Richard Biener wrote:
On Tue, Aug 1, 2017 at 2:02 PM, Martin Liška wrote:
On 07/27/2017 01:48 PM, Richard Biener wrote:
On Thu, Jul 27, 2017 at 12:12 PM, Martin Liška wrote:
Hello.
As reported in mentioned PR, we segfault in gcov tool when one uses -a.
It's caused
On Mon, Jul 31, 2017 at 11:31:44AM -0400, David Malcolm wrote:
> On Mon, 2017-07-31 at 16:14 +0200, Marek Polacek wrote:
> > This patch improves the diagnostic of -Wsign-compare for ?: by also
> > printing
> > the types, similarly to my recent patch. But we can do even better
> > here if we
> > ac
Hello,
On top of previous changes reworking the arm-vxworks support
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00085.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00075.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00078.html
This patch adds a variant implementation of _clear_
> On Aug 1, 2017, at 16:31 , Olivier Hainque wrote:
>
> This patch adds a variant implementation of _clear_cache
> for arm-vxworks*, needed for proper functioning of trampolines
> on targets with separate instruction/data caches.
Forgot to mention:
Tested by verifying success of an in-house bu
Hi,
I would like to kindly remind you of the following patches,
which are already waiting for over 6 months:
[PATCH, ARM] correctly encode the CC reg data flow
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01351.html
[PATCH, ARM] Further improve stack usage in sha512 (PR 77308)
https://gcc.gnu.o
On Mon, 2017-07-31 at 19:46 -0400, tbsaunde+...@tbsaunde.org wrote:
> From: Trevor Saunders
>
> For most of the history of this see
> https://sourceware.org/ml/gdb-patches/2016-10/msg00223.html
> The changes are mostly s/gdb/gtl/g
>
> include/ChangeLog:
>
> 2017-07-29 Trevor Saunders
>
>
Hi All,
real_to_target seems to return the order of the elements in the array
differently depending on the endiannes. This undoes the endianness when
combining the values back to a HOST_WIDE_INT.
Regtested on aach64-none-linux-gnu and aarch64_be-none-linux-gnu and no issues.
Thanks,
Tamar
gcc/
On Mon, Jul 31, 2017 at 03:53:42PM +0100, Jonathan Wakely wrote:
> This __has_bultin check only exists for Clang, so should be replaced
> by the correct __is_identifier check, not left there in addition to
> it.
I see. Actually I've guessed so, and thank you for clarifying it.
I'm attaching a repl
Hello world,
here is a slight update on the patch, with the following changes:
Fixed one ICE (yes, there was one)
Added a bit to the documentation to recommend to edit
function pointers
Translates c_size_t into ssize_t now - we only have a signed
type, unsigned makes little sense.
OK for trun
Am 24.07.2017 um 23:27 schrieb Thomas Koenig:
Hello world,
the attached patch fixes the PR; patch and test case are rather
self-explanatory.
Regression-testing as I write this. OK for trunk if it passes?
Regards
Thomas
OK?
Regards
Thomas
Hi Fritz,
This is a simple patch. The original intent was for -fdec to set
-fd-lines-as-comments by default if flag_d_lines was unspecified by
the user. However, currently flag_d_lines is interrogated in
set_dec_flags(), usually before its final value is determined. The
attached patch fixes this
Hi Fritz,
Regtests on x86_64-redhat-linux. OK for trunk?
Patch looks good in principle; I really find all these DEC extensions
strange, but if they are needed for old code, why not?
Just one point:
+ gfc_error ("%s not allowed outside STRUCTURE at %C", "%FILL");
This should ha
Description:
* This patch provides an initial support for DWARF debug sections in XCOFF.
Tests:
* AIX: Build: SUCCESS
- build made by means of gmake.
ChangeLog:
* xcoff.c: Initial support for DWARF debug sections in XCOFF.
Cordialement,
Tony Reix
Bull - ATOS
IBM Coop Architect & Technic
On Wed, Jul 19, 2017 at 11:59 PM, Martin Liška wrote:
> Hello.
>
> Following patch does sharing of expansion for mem{p,}cpy and also strpcy
> (with a known constant as source)
> so that we use same type of expansion (direct insns emission, direct emission
> with a loop instruction and
> library
I pushed this patch to openacc-gcc-7-branch that fixes an ICE in
libgomp.oacc-c/asyncwait-2.c caused by the recent async backport from
gomp-4_0-branch. Before, expand_omp_target was expecting the wait clause
argument to be a constant value. This patch teaches that function to be
more flexible and a
On Aug 1, 2017, at 8:50 AM, Bill Schmidt wrote:
>
> On Aug 1, 2017, at 7:44 AM, Bill Schmidt wrote:
>>
>>>
>>> On Aug 1, 2017, at 3:46 AM, Richard Biener
>>> wrote:
>>>
>>> On Mon, Jul 31, 2017 at 4:03 PM, Bill Schmidt
>>> wrote:
> On Jul 31, 2017, at 8:19 AM, Bill Schmidt
On Tue, Aug 01, 2017 at 08:40:28AM +0200, Jakub Jelinek wrote:
> Here is the variant patch. In addition to fixing the ICE for vec_ld, for
> vec_st it just moves the premature computation of aligned to the point where
> it is used and that is after we've also verified that the types of the call
> a
On Wed, Jul 26, 2017 at 06:41:23AM -0500, Segher Boessenkool wrote:
> > That is to follow aarch64 iterator naming convention, where they have
>
> Ugh, for some reason I thought this was in rs6000/ as well. I have
> fresh coffee now. Sorry.
Apparently I broke power bootstrap with this, because t
On 01/08/2017 00:08, Joseph Myers wrote:
On Wed, 26 Jul 2017, Jeff Law wrote:
TYPE_SIZE, according to my understanding, should be a tree for the size
of the expression in bits.
The problem is for msp430 that size varies depending on where it's used.
ie, in a register an object might have a b
richi's LTO debug patch mentioned in a comment that __dso_handle
didn't have a proper DECL_CONTEXT; this fixes that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b96b9abccb1afd301fb907dcfb327ffac05998b1
Author: Jason Merrill
Date: Mon Jul 31 16:46:46 2017 -0400
* decl.c (d
Hi Thomas,
This reminds me of project that I once started to translate fortran
into C using a similar option. I gave up in the end because I found it
more convenient to use a tree dump and modify the declarations by
hand. In respect of your query about suggestions, how about outputting
non_interop
Hi Thomas,
This is 'obvious, I think. Yes, OK for trunk.
Thanks
Paul
On 1 August 2017 at 16:09, Thomas Koenig wrote:
> Am 24.07.2017 um 23:27 schrieb Thomas Koenig:
>>
>> Hello world,
>>
>> the attached patch fixes the PR; patch and test case are rather
>> self-explanatory.
>>
>> Regression-t
HI Paul,
This reminds me of project that I once started to translate fortran
into C using a similar option. I gave up in the end because I found it
more convenient to use a tree dump and modify the declarations by
hand. In respect of your query about suggestions, how about outputting
non_interop
Hi all,
This is a rewrite of contrib/mklog in Python. I started adding features
suggested by Trevor some time ago but this quickly turned into a full
rewrite of existing Perl mklog and then I decided to just fully rewrite
it in Python (given that this has been requested several times).
The
On Jun 24, 2017, at 10:52 AM, Iain Buclaw wrote:
> Added a few extra comments for procedures, altering dmd2dg to write
> out flags converted to dejagnu in-place, instead on newlines.
>
> In the other testsuite patch, added new tests to accompany fixes that
> have been made since the last patch.
Add some tests for implementing interrupt handlers with naked attribute.
OK for trunk?
H.J.
---
* gcc.dg/guality/pr25967-1.c: New test.
* gcc.dg/guality/pr25967-2.c: Likewise.
* gcc.dg/torture/pr25967-1.c: Likewise.
* gcc.dg/torture/pr25967-2.c: Likewise.
---
gcc/
(Unchanged since v1; already approved by Marek, assuming rest is approved)
gcc/c-family/ChangeLog:
* c-common.c (c_parse_error): Add rich_location * param, using it
rather implicitly using input_location.
* c-common.h (c_parse_error): Add rich_location * param.
gcc/testsui
On Wed, 2017-07-12 at 09:13 -0400, Trevor Saunders wrote:
> On Tue, Jul 11, 2017 at 11:24:45AM -0400, David Malcolm wrote:
> > +/* Some tokens naturally come in pairs e.g.'(' and ')'.
> > + This class is for tracking such a matching pair of symbols.
> > + In particular, it tracks the location o
Changed in v2:
* Renamed template argument to traits_t; eliminated subclasses, just
using traits struct.
* Moved enum constants into struct bodies (string constants can't be
without constexpr, which isn't available in C++98).
* Fixed typo.
OK for trunk?
gcc/c/ChangeLog:
* c-parser.c
1 - 100 of 125 matches
Mail list logo
