On Wed, Nov 30, 2016 at 8:02 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes 3 spots with UB in dwarf2out.c, furthermore the first spot
> results in smaller/better debug info.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2016-11-30 Jakub J
On Thu, Dec 01, 2016 at 08:26:47AM +0100, Jakub Jelinek wrote:
> Isn't this too simplistic? I mean, if you have say dirtype of signed char
> and argmin say 4096 + 32 and argmax say 4096 + 64, (signed char) arg
> has range 32, 64, while I think your routine will yield -128, 127 (well,
> 0 as min an
On Wed, Nov 30, 2016 at 6:59 PM, Jeff Law wrote:
> On 11/30/2016 01:38 AM, Richard Biener wrote:
>>
>> On Tue, Nov 29, 2016 at 5:07 PM, Jeff Law wrote:
>>>
>>> On 11/29/2016 03:23 AM, Richard Biener wrote:
On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote:
>
>
>
>
>
The introduction of the flash_size field in avr_mcu_t rendered the
n_flash field redundant. This patch computes the value of n_flash as
needed from flash_size and cleans up n_flash.
Ok for trunk?
Johann
gcc/
* config/avr/avr-arch.h (avr_mcu_t) [n_flash]: Remove field.
* confi
Hi,
After investigation, I believe PR78559 is a combine issue revealed by tree
level change. Root causes is after replacing CC register use in
undobuf.other_insn, its REG_EQUAL/REG_EQUIV notes are no longer valid because
meaning of CC register has changed in i2/i3 instructions by combine. For
On 11/30/2016 11:46 PM, Martin Sebor wrote:
On 11/24/2016 05:59 AM, Martin Liška wrote:
On 11/24/2016 09:29 AM, Richard Biener wrote:
Please guard with ! TDF_GIMPLE, otherwise the output will not be parseable
with the GIMPLE FE.
RIchard.
Done and verified that and it provides equal dumps for
As described in the PR, we do couple of shifts of a negative value. Fixed in
the patch
and couple of new unit tests are added.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From 61a6b5e0c973bd77341a1053609c7ad331691a9e Mon Sep 17 00:00
Hi all,
and another aftermatch reported by Dominique. Fixing testcase
coarray_lib_alloc_4.f90 for 32-bit. Committed as obvious as r243101. Thanks for
reporting Dominique.
- Andre
On Wed, 30 Nov 2016 16:59:39 +0100
Andre Vehreschild wrote:
> Fixed -> r243034.
>
> - Andre
>
> On Wed, 30 Nov 20
Hi,
As mentioned in PR, the issue seems to be that in
propagate_bits_accross_jump_functions(),
ipa_get_type() returns record_type during WPA and hence we pass
invalid precision to
ipcp_bits_lattice::meet_with (value, mask, precision) which eventually
leads to runtime error.
The attached patch tries
Hi,
We have decided to backport this patch fixing testing for ARMv8-M Baseline to
our embedded-6-branch.
*** gcc/testsuite/ChangeLog ***
2016-07-15 Thomas Preud'homme
* lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
-mfloat-abi=soft option.
(add_optio
Hi,
We have decided to backport this patch to add multilib support for ARM
Cortex-M23 and Cortex-M33 to our embedded-6-branch.
*** gcc/ChangeLog ***
2016-11-30 Thomas Preud'homme
* config/arm/t-rmprofile: Add mappings for Cortex-M23 and Cortex-M33.
Best regards,
Thomas
--- Beg
http://gcc.gnu.org/r243104
Use more SYMBOL_REF_P instead of SYMBOL_REF == GET_CODE (...).
Committed as obvious.
Johann
gcc/
* config/avr/avr.c (avr_print_operand): Use SYMBOL_REF_P if possible.
(avr_handle_addr_attribute, avr_asm_output_aligned_decl_common)
(avr_asm_asm
On Tue, Nov 22, 2016 at 10:38:42AM -0500, David Malcolm wrote:
> On Tue, 2016-11-22 at 15:45 +0100, Jakub Jelinek wrote:
> > On Tue, Nov 22, 2016 at 03:38:04PM +0100, Bernd Schmidt wrote:
> > > On 11/22/2016 02:37 PM, Jakub Jelinek wrote:
> > > > Can't it be done only if xloc.file contains any fanc
Added target avr_tiny filter to 2 tests that are obviously intended to
run on AVR_TINY.
Applied as obvious.
Johann
gcc/testsuite/
* gcc.target/avr/tiny-memx.c: Only perform if target avr_tiny.
* gcc.target/avr/tiny-caller-save.c: Dito.
Index: gcc.target/avr/tiny-caller-save.c
Hi,
this is the third attempt to support ASan odr indicators in GCC. I've
fixed the issue with odr indicator name (now we don't use
ASM_GENERATE_INTERNAL_LABEL and use XALLOCAVEC for avoid overflow).
Also several style issues from previous review were covered.
How does it look now?
Tested and
On Thu, Dec 01, 2016 at 01:25:43PM +0300, Maxim Ostapenko wrote:
> + int len = strlen (IDENTIFIER_POINTER (decl_name))
> + + sizeof ("__odr_asan_") + 1;
Please use size_t len instead of int len. Why the + 1? sizeof ("__odr_asan_")
should be already strlen ("__odr_asan_") + 1.
> + name
On 30/11/16 21:43, Cary Coutant wrote:
> How about if instead of special DW_OP codes, you instead define a new
> virtual register that contains the mangled return address? If the rule
> for that virtual register is anything other than DW_CFA_undefined,
> you'd expect to find the mangled return addr
This looks like a latent problem in the -Wmaybe-uninitialized code
unrelated to my work.
The problem here is a sequence of simplify_preds() followed by
normalize_preds() that I added, but is based on prior art all over the file:
+ simplify_preds (&uninit_preds, NULL, false);
+ unini
On 01/12/16 10:42, Richard Earnshaw (lists) wrote:
On 30/11/16 21:43, Cary Coutant wrote:
How about if instead of special DW_OP codes, you instead define a new
virtual register that contains the mangled return address? If the rule
for that virtual register is anything other than DW_CFA_undefined
On Wed, Nov 30, 2016 at 05:58:13PM +, Joseph Myers wrote:
> On Wed, 30 Nov 2016, James Greenhalgh wrote:
>
> > +@code{_Float16} type defined by ISO/IEC TS18661:3-2005
>
> Add a space after "TS", and it's -3:2015 not :3-2005.
You would think that after 2 months of having the specification sitt
On 24/11/16 15:12, Richard Biener wrote:
On Thu, Nov 24, 2016 at 2:57 PM, Kyrill Tkachov
wrote:
Hi all,
In this bug we have TER during out-of-ssa misbehaving. A minimal example is:
void foo(unsigned a, float b)
{
unsigned c = (unsigned) b; // 1
register unsigned r0 __asm__("r0") =
On 30/11/16 19:29 -0800, Tim Shen wrote:
On Wed, Nov 30, 2016 at 8:27 AM, Jonathan Wakely wrote:
On 26/11/16 21:38 -0800, Tim Shen wrote:
+ template>
struct _Uninitialized;
I'm still unsure that is_literal_type is the right trait here. If it's
definitely right then we should probably *n
In code like the following from KVM:
/* it is a read fault? */
error_code = (exit_qualification << 2) & PFERR_FETCH_MASK;
it would be nicer to write
/* it is a read fault? */
error_code = (exit_qualification & VMX_EPT_READ_FAULT_MASK) ?
PFERR_FETCH_MASK : 0;
ins
Jakub, thank you for review. I'll commit following patch if no issues
occur after regtesting and bootstrapping.
On 01/12/16 13:42, Jakub Jelinek wrote:
On Thu, Dec 01, 2016 at 01:25:43PM +0300, Maxim Ostapenko wrote:
+ int len = strlen (IDENTIFIER_POINTER (decl_name))
+ + sizeof ("_
On 30/11/2016 13:46, Segher Boessenkool wrote:
>if (JUMP_P (use_insn))
> continue;
>
> + /* Also don't substitute into a conditional trap insn -- it can become
> + an unconditional trap, and that is a flow control insn. */
> + if (GET_CODE (PATTERN (use_insn)) == T
On Mon, 28 Nov 2016, Yuri Rumyantsev wrote:
> Richard!
>
> I attached vect dump for hte part of attached test-case which
> illustrated how vectorization of epilogues works through masking:
> #define SIZE 1023
> #define ALIGN 64
>
> extern int posix_memalign(void **memptr, __SIZE_TYPE__ alignment
On 25 November 2016 at 21:17, Jeff Law wrote:
> On 11/25/2016 01:07 AM, Richard Biener wrote:
>
>>> For the tail-call, issue should we artificially create a lhs and use that
>>> as return value (perhaps by a separate pass before tailcall) ?
>>>
>>> __builtin_memcpy (a1, a2, a3);
>>> return a1;
>>>
This patch moves the compile tests that have a hard coded -mmcu=MCU in
their dg-options to a new folder.
The exp driver filters out -mmcu= from the command line options that are
provided by, say, board description files or --tool-opts.
This is needed because otherwise conflicting -mmcu= will
On Thu, Dec 01, 2016 at 10:19:42AM +0100, Richard Biener wrote:
> >> Thinking about this again maybe targets w/o insn-length should simply
> >> always use the 'simple' algorithm instead of the STV one? At least that
> >> might be what your change effectively does in some way?
> >
> > From reading
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 25 November 2016 at 21:17, Jeff Law wrote:
> > On 11/25/2016 01:07 AM, Richard Biener wrote:
> >
> >>> For the tail-call, issue should we artificially create a lhs and use that
> >>> as return value (perhaps by a separate pass before tailcall) ?
On 11/30/2016 11:11 PM, Jakub Jelinek wrote:
I run into the problem that while simplify_replace_rtx if it actually does
copy_rtx (for y) or if it simplifies something through
simplify_gen_{unary,binary,relational,ternary}, the used bits on the newly
created rtxes are cleared, when we fall through
Ping.
On Mon, Nov 21, 2016 at 01:36:47PM +0100, Dominik Vogt wrote:
> On Fri, Nov 11, 2016 at 12:10:28PM +0100, Dominik Vogt wrote:
> > On Mon, Nov 07, 2016 at 09:29:26PM +0100, Bernd Schmidt wrote:
> > > On 10/31/2016 08:56 PM, Dominik Vogt wrote:
> > >
> > > >combine_simplify_rtx() tries to rep
On 12/01/2016 11:12 AM, Dominik Vogt wrote:
diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c
index 77e6b05..5370602 100644
--- a/gcc/print-rtl.c
+++ b/gcc/print-rtl.c
@@ -371,7 +371,10 @@ rtx_writer::print_rtx_operand_code_i (const_rtx in_rtx,
int idx)
if (INSN_HAS_LOCATION (in_insn))
On Thu, Dec 1, 2016 at 12:14 PM, Kyrill Tkachov
wrote:
>
> On 24/11/16 15:12, Richard Biener wrote:
>>
>> On Thu, Nov 24, 2016 at 2:57 PM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> In this bug we have TER during out-of-ssa misbehaving. A minimal example
>>> is:
>>> void foo(unsigned a, flo
On Thu, 1 Dec 2016, Paolo Bonzini wrote:
> In code like the following from KVM:
>
> /* it is a read fault? */
> error_code = (exit_qualification << 2) & PFERR_FETCH_MASK;
>
> it would be nicer to write
>
> /* it is a read fault? */
> error_code = (exit_qualificat
On 30.11.2016 18:26, Jeff Law wrote:
> On 11/30/2016 09:53 AM, Matthias Klose wrote:
>> On 30.11.2016 12:38, Richard Biener wrote:
>>> On Wed, Nov 30, 2016 at 12:30 PM, Matthias Klose wrote:
There's one more fix needed for the case of only having the pkg-config
module
installed whe
On 11/21/2016 01:36 PM, Dominik Vogt wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index b22a274..457fe8a 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5575,10 +5575,23 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode, int
in_dest,
{
rtx cop1 = const0_rtx;
On Thu, Dec 1, 2016 at 12:03 PM, Aldy Hernandez wrote:
> This looks like a latent problem in the -Wmaybe-uninitialized code unrelated
> to my work.
>
> The problem here is a sequence of simplify_preds() followed by
> normalize_preds() that I added, but is based on prior art all over the file:
>
>
Hopefully one last patch for UB in combine.c:
combine.c:12561:14: runtime error: left shift of negative value -9
Fixed by casting to unsigned, as usual.
Tested on ppc64le.
OK for trunk?
Thanks.
PR rtl-optimization/78596
* combine.c (simplify_comparison): Cast to unsigned to av
On 11/30/2016 09:24 PM, David Malcolm wrote:
gcc/ChangeLog:
* read-md.c (have_error): New global, copied from errors.c.
(fatal): New function, copied from errors.c.
I would have expected the function to go into diagnostic.c, but actually
there are already various functions of
On Thu, Dec 1, 2016 at 11:07 AM, Prathamesh Kulkarni
wrote:
> Hi,
> As mentioned in PR, the issue seems to be that in
> propagate_bits_accross_jump_functions(),
> ipa_get_type() returns record_type during WPA and hence we pass
> invalid precision to
> ipcp_bits_lattice::meet_with (value, mask, pre
Using bootstrap-ubsan gcc to build mplayer shows:
tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow:
288230376151711743 * 64 cannot be represented in type 'long int'
Here signed und unsigned integers are mixed in a division resulting in
bogus results: (-83 + 64ULL -1) / 64UL
On 1 December 2016 at 17:40, Richard Biener wrote:
> On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>
>> On 25 November 2016 at 21:17, Jeff Law wrote:
>> > On 11/25/2016 01:07 AM, Richard Biener wrote:
>> >
>> >>> For the tail-call, issue should we artificially create a lhs and use that
>> >>> as
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 1 December 2016 at 17:40, Richard Biener wrote:
> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >
> >> On 25 November 2016 at 21:17, Jeff Law wrote:
> >> > On 11/25/2016 01:07 AM, Richard Biener wrote:
> >> >
> >> >>> For the tail-call, is
On 1 December 2016 at 18:26, Richard Biener wrote:
> On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>
>> On 1 December 2016 at 17:40, Richard Biener wrote:
>> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 25 November 2016 at 21:17, Jeff Law wrote:
>> >> > On 11/25/2016 01:07 AM,
Hi!
On Thu, Dec 01, 2016 at 09:47:51AM +, Bin Cheng wrote:
> After investigation, I believe PR78559 is a combine issue revealed by tree
> level change. Root causes is after replacing CC register use in
> undobuf.other_insn, its REG_EQUAL/REG_EQUIV notes are no longer valid because
> meanin
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 1 December 2016 at 18:26, Richard Biener wrote:
> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >
> >> On 1 December 2016 at 17:40, Richard Biener wrote:
> >> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> On 25 November 2
On Thu, Dec 01, 2016 at 12:24:37PM +0100, Paolo Bonzini wrote:
>
>
> On 30/11/2016 13:46, Segher Boessenkool wrote:
> >if (JUMP_P (use_insn))
> > continue;
> >
> > + /* Also don't substitute into a conditional trap insn -- it can
> > become
> > +an unconditional trap, and
On 1 December 2016 at 18:38, Richard Biener wrote:
> On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>
>> On 1 December 2016 at 18:26, Richard Biener wrote:
>> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 1 December 2016 at 17:40, Richard Biener wrote:
>> >> > On Thu, 1 Dec 2016
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 1 December 2016 at 18:38, Richard Biener wrote:
> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >
> >> On 1 December 2016 at 18:26, Richard Biener wrote:
> >> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> On 1 December 20
Hi Richard,
I tested your fix for the patch with ubsan stage-1 built gcc, and it
fixes the error.
Is it OK to commit if bootstrap+test passes on x86_64-unknown-linux-gnu ?
Thanks,
Prathamesh
2016-12-01 Richard Biener
Prathamesh Kulkarni
PR middle-end/78629
* vec.h
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> Hi Richard,
> I tested your fix for the patch with ubsan stage-1 built gcc, and it
> fixes the error.
> Is it OK to commit if bootstrap+test passes on x86_64-unknown-linux-gnu ?
Ok.
Richard.
On 11/11/2016 10:15 PM, David Malcolm wrote:
+ /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so that
+ flag_self_test contains the path to the selftest subdirectory of the
+ source tree (without a trailing slash). Copy it up to
+ path_to_selftest_files, to avoid self
On Thu, Dec 01, 2016 at 01:34:29PM +0100, Markus Trippelsdorf wrote:
> Hopefully one last patch for UB in combine.c:
>
> combine.c:12561:14: runtime error: left shift of negative value -9
>
> Fixed by casting to unsigned, as usual.
>
> Tested on ppc64le.
> OK for trunk?
Sure, but please fix th
Should changing minor version of the library be enough?
diff --git a/libmpx/mpxrt/libtool-version b/libmpx/mpxrt/libtool-version
index 7d99255..736d763 100644
--- a/libmpx/mpxrt/libtool-version
+++ b/libmpx/mpxrt/libtool-version
@@ -3,4 +3,4 @@
# a separate file so that version updates don't invo
Thanks Richard for your comments.
You asked me about possible performance improvements for AVX2 machines
- we did not see any visible speed-up for spec2k with any method of
masking, including epilogue masking and combining, only on AVX512
machine aka knl.
I will answer on your question later.
Be
Hi,
On 10 November 2016 at 15:10, Christophe Lyon
wrote:
> On 10 November 2016 at 11:05, Richard Earnshaw
> wrote:
>> On 09/11/16 21:29, Christophe Lyon wrote:
>>> Hi,
>>>
>>> PR 78253 shows that the handling of weak references has changed for
>>> ARM with gcc-5.
>>>
>>> When r220674 was commit
This adds to the documentation a hint how to set up a linker description
file that avoids progmem altogether any without the usual overhead of
locating read-only data in RAM. The proposed linker description file is
completely transparent to the compiler, and no start-up code has to be
adjusted
Good catch, Alan, this one is my fault. I'll handle the backports to the 5 and
6 branches.
Bill
> On Dec 1, 2016, at 12:34 AM, Alan Modra wrote:
>
> I'm committing this one as obvious once my powerpc64le-linux bootstrap
> and regression check completes. It fixes hundreds of rtl checking
> te
On Thu, Dec 1, 2016 at 1:49 PM, Markus Trippelsdorf
wrote:
> Using bootstrap-ubsan gcc to build mplayer shows:
>
> tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow:
> 288230376151711743 * 64 cannot be represented in type 'long int'
>
> Here signed und unsigned integers are m
On 11/11/2016 10:15 PM, David Malcolm wrote:
#include "gt-aarch64.h"
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6c608e0..0dda786 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
I think we should separate out the target specific tests so as to give
port
On Thu, 1 Dec 2016, Yuri Rumyantsev wrote:
> Thanks Richard for your comments.
>
> You asked me about possible performance improvements for AVX2 machines
> - we did not see any visible speed-up for spec2k with any method of
Spec 2000? Can you check with SPEC 2006 or CPUv6?
Did you see performa
The attached patch fixes the setmem_long-1.c S/390 backend test.
Adding a " in the scan-assembler pattern is necessary because of a
recent change in print-rtl.c.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog-setmem-long-test
* gcc.target/s390/md/setmem_lon
Hi Jeff,
>> The following patch has passed x86_64-pc-linux-gnu bootstrap without
>> regressions; i386-pc-solaris2.12 and sparc-sun-solaris2.12 bootstraps
>> are currently running.
>>
>> Ok for mainline if they pass?
> Yes. Sorry for not getting back to you sooner.
no worries; I've been on vacati
Hi,
In PR78561, we try to make use of stale constant pool offset data when
making decisions as to whether to output an alignment directive after
the AArch64 constant pool. The offset data goes stale as we only ever
increment it when adding new constants to the pool (it represents an
upper bound on
Hi,
There's no functional change in this patch, just a rename.
The size recorded in "offset" is only ever incremented as we add new items
to the constant pool. But this information can become stale where those
constant pool entries would not get emitted.
Thus, it is only ever an upper bound on
Hi,
In PR78561, we try to make use of stale constant pool offset data when
making decisions as to whether to output an alignment directive after
the AArch64 constant pool. The offset data goes stale as we only ever
increment it when adding new constants to the pool (it represents an
upper bound o
On Thu, Dec 01, 2016 at 01:33:17PM +0100, Bernd Schmidt wrote:
> On 11/21/2016 01:36 PM, Dominik Vogt wrote:
> >diff --git a/gcc/combine.c b/gcc/combine.c
> >index b22a274..457fe8a 100644
> >--- a/gcc/combine.c
> >+++ b/gcc/combine.c
> >@@ -5575,10 +5575,23 @@ combine_simplify_rtx (rtx x, machine_m
Hi all,
This patch refactors the code used in call, call_value, sibcall,
sibcall_value expanders.
Before the change, the logic is following:
call expander --> call_internal --> call_reg/call_symbol
call_vlaue expander--> call_value_internal-->
call_value_reg/call_valu
As subject.
Newlib doesn't have sigsetjmp, so the test fails for our newlib-based
testruns. Confirmed that this adjusted test would still have ICE'd
without r242958.
Committed as obvious as revision 243116.
Thanks,
James
---
2016-12-01 James Greenhalgh
* gcc.dg/pr78582.c (main): Ca
Hello,
On Wed, Nov 30, 2016 at 02:09:19PM +0100, Martin Jambor wrote:
> On Tue, Nov 29, 2016 at 10:17:02AM -0700, Jeff Law wrote:
> >
> > ...
> >
> > So it seems that rather than an assert that we should just not walk down a
> > self-referencing DECL_ABSTRACT_ORIGIN.
> >
>
> ...
>
> So I wonder
On 11/30/2016 09:09 PM, Martin Sebor wrote:
What I think this tells us is that we're not at a place where we're
clean. But we can incrementally get there. The warning is only
catching a fairly small subset of the cases AFAICT. That's not unusual
and analyzing why it didn't trigger on those cas
A number of the "variant" testcases fail to build on AIX and targets
that use stabs. The failure looks like:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956:
internal compiler error: tree check: expected field_decl, have
template_decl in int_bit_position, at tree.h:5396
which oc
So, let's use another testcase, -O2 -W -Wall -fno-tree-vrp -fno-tree-ccp
and again UB in it:
volatile bool e;
volatile int x;
int
main ()
{
x = 123;
*(char *)&e = x;
bool f = e;
x = __builtin_snprintf (0, 0, "%d", f);
}
This will store 1 into x, while without -fprintf-return-value it wou
The following patch series adds some patterns for enhanced use of
the r[ixo]sbg instructions on S/390.
- 0001-* fixes some test regressions with the existing risbg
patterns that are broken because of recent trunkt changes.
- 0002-* adds new patterns for the r[xo]sbg instructions and an
SI
On Thu, Dec 01, 2016 at 05:26:16PM +0100, Dominik Vogt wrote:
> The following patch series adds some patterns for enhanced use of
> the r[ixo]sbg instructions on S/390.
>
> - 0001-* fixes some test regressions with the existing risbg
>patterns that are broken because of recent trunkt changes.
On Thu, Dec 01, 2016 at 05:26:16PM +0100, Dominik Vogt wrote:
> The following patch series adds some patterns for enhanced use of
> the r[ixo]sbg instructions on S/390.
>
> - 0001-* fixes some test regressions with the existing risbg
>patterns that are broken because of recent trunkt changes.
On 11/23/2016 03:13 PM, Jakub Jelinek wrote:
> On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote:
>> I started review process in libsanitizer: https://reviews.llvm.org/D26965
>> And I have a question that was asked in the review: can we distinguish
>> between load and store
>> in case o
On 12/01/2016 02:48 AM, Martin Liška wrote:
On 11/30/2016 11:46 PM, Martin Sebor wrote:
On 11/24/2016 05:59 AM, Martin Liška wrote:
On 11/24/2016 09:29 AM, Richard Biener wrote:
Please guard with ! TDF_GIMPLE, otherwise the output will not be
parseable
with the GIMPLE FE.
RIchard.
Done and
On Dec 1, 2016, at 3:54 AM, Georg-Johann Lay wrote:
>
> This patch moves the compile tests that have a hard coded -mmcu=MCU in their
> dg-options to a new folder.
>
> The exp driver filters out -mmcu= from the command line options that are
> provided by, say, board description files or --tool-
2016-12-01 17:28 GMT+03:00 Georg-Johann Lay :
> This adds to the documentation a hint how to set up a linker description
> file that avoids progmem altogether any without the usual overhead of
> locating read-only data in RAM. The proposed linker description file is
> completely transparent to the
Okay, thanks for the clarification. One other question though.
Why would the probability be near zero? In the absence of any
hints the expression 2 != sprintf(d, "%i", 12) should have
a very high probability of being true, near 100% in fact.
I ask because the test I referenced tries to verify t
2016-12-01 12:26 GMT+03:00 Georg-Johann Lay :
> The introduction of the flash_size field in avr_mcu_t rendered the n_flash
> field redundant. This patch computes the value of n_flash as needed from
> flash_size and cleans up n_flash.
>
> Ok for trunk?
>
> Johann
>
> gcc/
> * config/avr/avr
On 17/11/16 10:42, Kyrill Tkachov wrote:
> Hi Andre,
>
> On 09/11/16 10:11, Andre Vieira (lists) wrote:
>> Hi,
>>
>> Refactor NEON builtin framework such that it can be used to implement
>> other builtins.
>>
>> Is this OK for trunk?
>>
>> Regards,
>> Andre
>>
>> gcc/ChangeLog
>> 2016-11-09 Andre
On 09/11/16 10:11, Andre Vieira (lists) wrote:
> Hi,
>
> This patch refactors the implementation of the ARM ACLE CRC builtins to
> use the builtin framework.
>
> Is this OK for trunk?
>
> Regards,
> Andre
>
> gcc/ChangeLog
> 2016-11-09 Andre Vieira
>
> * config/arm/arm-builtins.c (arm_uns
On 12/01/2016 05:04 AM, Segher Boessenkool wrote:
On Thu, Dec 01, 2016 at 10:19:42AM +0100, Richard Biener wrote:
Thinking about this again maybe targets w/o insn-length should simply
always use the 'simple' algorithm instead of the STV one? At least that
might be what your change effectively d
On 12/01/2016 09:49 AM, Martin Sebor wrote:
Okay, thanks for the clarification. One other question though.
Why would the probability be near zero? In the absence of any
hints the expression 2 != sprintf(d, "%i", 12) should have
a very high probability of being true, near 100% in fact.
I ask be
Hi,
When considering a candidate for rematerialization, LRA verifies if the
candidate clobbers a live register before going forward with the
rematerialization (see code starting with comment "Check clobbers do not kill
something living."). To do this check, the set of live registers at any giv
On 12/01/2016 12:51 AM, Jakub Jelinek wrote:
On Wed, Nov 30, 2016 at 06:14:14PM -0700, Martin Sebor wrote:
On 11/30/2016 12:01 PM, Jakub Jelinek wrote:
Hi!
This patch fixes some minor nits I've raised in the PR, more severe issues
left unresolved there.
Bootstrapped/regtested on x86_64-linux
> James Greenhalgh writes:
> The patch set has been bootstrapped and tested on aarch64-none-linux-gnu and
> x86-64-none-linux-gnu without any issues. I've also cross-tested it for
> aarch64-none-elf and build-tested it for rs6000 (though I couldn't run the
> testsuite as I don't have a test en
Sure - but then you maybe instead want to check for op being in
range [0, max-of-signed-type-of-op] instead? So similar to
expr_not_equal_to add a expr_in_range helper?
Your function returns true for sizetype vars even if it might be
effectively signed, like for
sizetype i_1 = -4;
i_2 = i_1 +
On 12/01/2016 09:15 AM, David Edelsohn wrote:
A number of the "variant" testcases fail to build on AIX and targets
that use stabs. The failure looks like:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956:
internal compiler error: tree check: expected field_decl, have
template_de
Hi all,
I am sorry, but the initial mail as well as Dominique answer puzzles me:
David: I do expect to
write (*,*) any
not being compilable at all, because "any" is an intrinsic function and I
suppose that gfortran is not able to print it. At best it gives an address. So
am I right to
On 11/30/2016 09:09 PM, Martin Sebor wrote:
What I think this tells us is that we're not at a place where we're
clean. But we can incrementally get there. The warning is only
catching a fairly small subset of the cases AFAICT. That's not unusual
and analyzing why it didn't trigger on those cas
On Thu, Dec 1, 2016 at 1:25 PM, Jeff Law wrote:
> On 12/01/2016 09:15 AM, David Edelsohn wrote:
>>
>> A number of the "variant" testcases fail to build on AIX and targets
>> that use stabs. The failure looks like:
>>
>> /tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956:
>> internal
On 12/01/2016 11:41 AM, David Edelsohn wrote:
On Thu, Dec 1, 2016 at 1:25 PM, Jeff Law wrote:
On 12/01/2016 09:15 AM, David Edelsohn wrote:
A number of the "variant" testcases fail to build on AIX and targets
that use stabs. The failure looks like:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-
Dump sent privately.
Yes, I meant "x".
AIX defaults to 32 bit.
- David
On Thu, Dec 1, 2016 at 1:31 PM, Andre Vehreschild wrote:
> Hi all,
>
> I am sorry, but the initial mail as well as Dominique answer puzzles me:
>
> David: I do expect to
>
> write (*,*) any
>
> not being compilable
As of https://golang.org/cl/32917 we can put slice initializers in the
.data section. The program can still change the values in those
slices. That means that if the slice elements can contain pointers,
we need to register the entire initializer as a GC root.
This would be straightforward except
I've committed the attached patch, which converts a gcc_assert()
to a conditional express tha may call gfc_internal_error().o
2016-12-01 Steven G. Kargl
PR fortran/78279
* dependency.c (identical_array_ref): Convert gcc_assert to conditional
and gfc_internal_error.
201
On 12/01/2016 08:29 AM, James Greenhalgh wrote:
Hi,
There's no functional change in this patch, just a rename.
The size recorded in "offset" is only ever incremented as we add new items
to the constant pool. But this information can become stale where those
constant pool entries would not get
1 - 100 of 138 matches
Mail list logo
