Ping ?
On 9/9/19 8:34 PM, François Dumont wrote:
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n/equal implementations. The improvements
are:
- activation of algo specialization for __gnu_debug::_Safe_iterator
(w/o _GLIBCXX_DEBUG mode)
- activation of algo specia
On 9/24/19 11:17 AM, Marek Polacek wrote:
This started to ICE with my CWG 2352 fix. In reference_binding, we now bind
directly when the types are similar, not just when they are the same. But even
direct binding can involve a temporary, e.g. for a bit-field, or, as in this
test, for a packed fi
Hi,
Sorry for replying so late due to cauldron conference and other LTO issues
I was working on.
v4 Changes:
1. Rebase to trunk.
2. Remove num_of_ics and use vector's length to avoid redundancy.
3. Update the code in ipa-profile.c to improve review feasibility.
4. Add function has_indirect_ca
Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
inserted as the first instruction of the function.
Insert zero overhead loop instruction into new basic block before the
loop when basic block that precedes the loop is empty.
2019-09-24 Max Filippov
gcc/
* config/x
Hi Iain,
On Tue, Sep 24, 2019 at 08:31:16PM +0100, Iain Sandoe wrote:
> This switches the picbase load and reload patterns to use the 'P' mode
> iterator instead of writing an SI and DI pattern for each (and deletes the
> old patterns). No functional change intended.
> (define_expand "load_mach
The attached patch has been tested on x86_64-*-freebsd. OK to commit?
2019-09-24 Steven G. Kargl
PR fortran/91802
* decl.c (attr_decl1): Check if rank+corank > 15.
2019-09-24 Steven G. Kargl
PR fortran/91802
* gfortran.dg/pr91802.f90: New test.
--
Steve
I
The documentation used to indicate that the inline keyword was only
supported by c99 and c11, whereas in fact it is supported by c99 and all
newer standards.
gcc/ChangeLog
2019-09-24 Palmer Dabbelt
* doc/extended.texi (Alternate Keywords): Change "-std=c11" to "a
later standar
The attached patch has been tested on x86_64-*-freebsd. OK to commit?
2019-09-24 Steven G. Kargl
PR fortran/91864
* gcc/fortran/io.c (match_io_element): An inquiry parameter cannot be
read into.
* gcc/fortran/match.c (gfc_match_allocate): An inquiry parameter
On Wed, 18 Sep 2019 at 20:11, Richard Biener wrote:
>
>
> It shouldn't be neccessary.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> (SLP part testing separately)
>
> Richard.
>
> 2019-09-18 Richard Biener
>
> * tree-vect-loop.c (vect_is_simple_reduction):
> I think this has to depend on the C standards version. I think each C
> standard needs to be read against the edition of ISO 10646 current at
> the time of standards approval (the references are sadly not
> versioned, so the version is implied). Early versions of ISO 10646
> definitely do not h
On Tue, Sep 24, 2019 at 09:07:03PM +0200, Paolo Carlini wrote:
> Hi,
>
> Marek's recent fix prompted an audit of name-lookup.c and I found a few
> additional straightforward places where we should use a more accurate
> location. Tested x86_64-linux.
>
> Thanks, Paolo.
>
> ///
This switches the picbase load and reload patterns to use the 'P' mode
iterator instead of writing an SI and DI pattern for each (and deletes the
old patterns). No functional change intended.
Tested on powerpc-darwin9, powerpc64-linux-gnu,
applied to mainline
thanks
Iain
gcc/ChangeLog:
2019-09-
As a clean-up, we want to be able to use mode iterators in darwin.md.
This patch moves the include point for the Darwin md file until after
the definition of the mode iterators and attrs. No functional change
intended.
Discussed with, and approved by, Segher off-line,
Tested on powerpc-darwin9,
Hi,
Marek's recent fix prompted an audit of name-lookup.c and I found a few
additional straightforward places where we should use a more accurate
location. Tested x86_64-linux.
Thanks, Paolo.
///
/cp
2019-09-24 Paolo Carlini
* name-lookup.c (check_extern_c_co
I committed r276105 fixing these two issues plus one more that
Jeff noticed yesterday.
Martin
On 9/21/19 6:03 PM, Martin Sebor wrote:
The new get_range_strlen_dynamic function has a couple of bugs
where it assumes that the length range bounds it gets back from
get_range_strlen are non-null inte
On Tue, Sep 24, 2019 at 1:24 AM Kyrill Tkachov
wrote:
>
> Hi Matt,
>
> On 9/24/19 5:04 AM, Matt Turner wrote:
> > When -march=native is passed to host_detect_local_cpu to the backend,
> > it overrides all command lines after it. That means
> >
> > $ gcc -march=native -march=armv8-a
> >
> > is tre
When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it. That means
$ gcc -march=native -march=armv8-a
is treated as
$ gcc -march=armv8-a -march=native
Prune joined switches with Negative and RejectNegative to allow
-march=armv8-a to overri
* Eric Botcazou:
> the Universal Character Names accepted by the C family of compilers
> are mapped to those of ISO/IEC 10646, which defines the Universal
> Character Set codespace as the range 0-0x10 inclusive. The
> upper bound is already enforced for identifiers but not for
> literals, so
On Tue, 24 Sep 2019 15:11:43 +0100
Mark Eggleston wrote:
> I didn't realise that's how it worked. That's cleaner. Once fixed OK for
> commit?
> +@item -Wno-overwrite-recursive
> +@opindex @code{Woverwrite-recursive}
> +@cindex warnings, overwrite recursive
> +Do not warn when @option{-fno-auto
On Tue, Sep 24, 2019 at 9:36 AM Szabolcs Nagy wrote:
>
> On 23/09/2019 08:52, Martin Liška wrote:
> > On 9/20/19 7:11 PM, Matthew Malcomson wrote:
> >> The implementation is unlikely to be production-quality since
> >> development on libhwasan is only on its `platform` ABI. This libhwasan
> >> AB
Hi,
sorry for replying so late, I still haven't recovered from two weeks of
traveling and conferences.
On Sat, Sep 21 2019, Richard Sandiford wrote:
> Hi,
>
> Thanks for doing this.
>
> Martin Jambor writes:
>> +/* Analyze function body scan results stored in param_accesses and
>> + param_acce
Hi,
the Universal Character Names accepted by the C family of compilers are mapped
to those of ISO/IEC 10646, which defines the Universal Character Set codespace
as the range 0-0x10 inclusive. The upper bound is already enforced for
identifiers but not for literals, so the following code i
On Tue, Sep 24, 2019 at 07:44:10AM +0200, Bernhard Reutner-Fischer wrote:
> On Mon, 23 Sep 2019 14:52:19 -0500
> "Christian Biesinger via gcc-patches" wrote:
> > From: Christian Biesinger
> > Removes an unused include as a cleanup. Requires updating
> > lots of files who previously relied on this
On 23/09/2019 08:52, Martin Liška wrote:
> On 9/20/19 7:11 PM, Matthew Malcomson wrote:
>> The implementation is unlikely to be production-quality since
>> development on libhwasan is only on its `platform` ABI. This libhwasan
>> ABI requires changes to the system libc so that it calls into libhwa
Yuliang Wang writes:
> Hi,
>
> The C snippets below (signed division/modulo by a power-of-2 immediate
> value):
>
> #define P ...
>
> void foo_div (int *a, int *b, int N)
> {
> for (int i = 0; i < N; i++)
> a[i] = b[i] / (1 << P);
> }
> void foo_mod (int *a, int *b, int N)
> {
>
On 9/24/19 4:34 AM, Martin Liška wrote:
> On 9/24/19 11:14 AM, Thomas Schwinge wrote:
>> Hi!
>>
>> Curious: even if you found the issue on a s390x target, shouldn't this
>> (presumably generic?) test case live in a generic place instead of
>> 'gcc.target/s390/'?
>
> Sure, that's logical and I've j
Hi,
can anybody take a look at v2?
Thanks,
Dmitrij
On Mon, Sep 09, 2019 at 10:03:40PM +0300, Dmitrij Pochepko wrote:
> Hi all.
>
> Please take a look at v2 (attached).
> I changed patch according to review comments. The same testing was performed
> again.
>
> Thanks,
> Dmitrij
>
> On Thu, Se
This started to ICE with my CWG 2352 fix. In reference_binding, we now bind
directly when the types are similar, not just when they are the same. But even
direct binding can involve a temporary, e.g. for a bit-field, or, as in this
test, for a packed field.
convert_like will actually create the
Richard Biener writes:
> On Tue, Sep 24, 2019 at 1:57 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Sep 24, 2019 at 1:11 PM Richard Sandiford
>> > wrote:
>> >>
>> >> Martin Liška writes:
>> >> > Hi.
>> >> >
>> >> > The patch introduces couple of new TREE_CODEs that wi
OK.
On Mon, Sep 23, 2019 at 10:06 PM Marek Polacek wrote:
>
> build_m_component_ref checks if either datum/component it got are erroneous
> but
> they can be turned into the error_mark_node by mark_use as in this case: datum
> is "a" before the call to mark_lvalue_use, but that emits an error an
OK.
On Mon, Sep 23, 2019 at 10:04 PM Marek Polacek wrote:
>
> We can improve various -Wshadow warnings by using DECL_SOURCE_LOCATION
> rather than whatever is in input_location.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-09-23 Marek Polacek
>
> PR c++/91868 - im
On 24/09/2019 14:53, Bernhard Reutner-Fischer wrote:
On Tue, 24 Sep 2019 12:12:04 +0100
Mark Eggleston wrote:
@@ -411,7 +411,7 @@ gfc_post_options (const char **pfilename)
&& flag_max_stack_var_size != 0)
gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites
%<-fmax-stack-
On Tue, 24 Sep 2019 12:12:04 +0100
Mark Eggleston wrote:
> >> @@ -411,7 +411,7 @@ gfc_post_options (const char **pfilename)
> >> && flag_max_stack_var_size != 0)
> >> gfc_warning_now (0, "Flag %<-fno-automatic%> overwrites
> >> %<-fmax-stack-var-size=%d%>",
> >> fla
Hi all,
On 8/22/19 10:16 AM, Kyrill Tkachov wrote:
Hi all,
The optimisation to optimise:
typedef unsigned long long u64;
void bar(u64 *x)
{
*x = 0xabcdef10abcdef10;
}
from:
mov x1, 61200
movk x1, 0xabcd, lsl 16
movk x1, 0xef10, lsl 32
Hi all,
On 9/10/19 1:34 PM, Stam Markianos-Wright wrote:
Hi all,
This is a minor patch that fixes the entry for the fp16fml feature in
GCC's aarch64-option-extensions.def.
As can be seen in the Linux sources here
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/cpuinfo.c#L69
On Tue, Sep 24, 2019 at 03:10:49PM +0200, Richard Biener wrote:
> Hmm yeah.
>
> Note that in principle the domain could be signed so that the
> -1 is more obvious. Also [1:0] would be an equally valid empty
> domain. Not sure if that helps the specific jump-threading case, of
> course...
No, t
On Tue, 24 Sep 2019, Jakub Jelinek wrote:
> On Tue, Sep 24, 2019 at 01:15:46PM +0200, Richard Biener wrote:
> > > build_array_type_nelts is only meaningful for non-zero number of elements,
> > > for 0 it creates weirdo arrays like char D.2358[0:18446744073709551615].
> > > The following patch uses
Hi,
The C snippets below (signed division/modulo by a power-of-2 immediate value):
#define P ...
void foo_div (int *a, int *b, int N)
{
for (int i = 0; i < N; i++)
a[i] = b[i] / (1 << P);
}
void foo_mod (int *a, int *b, int N)
{
for (int i = 0; i < N; i++)
a[i] = b[i] %
On Tue, Sep 24, 2019 at 01:15:46PM +0200, Richard Biener wrote:
> > build_array_type_nelts is only meaningful for non-zero number of elements,
> > for 0 it creates weirdo arrays like char D.2358[0:18446744073709551615].
> > The following patch uses in that case types like the C FE emits for
> > zer
On Tue, Sep 24, 2019 at 1:57 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Sep 24, 2019 at 1:11 PM Richard Sandiford
> > wrote:
> >>
> >> Martin Liška writes:
> >> > Hi.
> >> >
> >> > The patch introduces couple of new TREE_CODEs that will help us to have
> >> > a proper GI
On 9/19/19 10:33 AM, Martin Liška wrote:
> - One needs modified binutils and I that would probably require a configure
> detection. The only way
> which I see is based on ld --version. I'm planning to make the binutils
> submission soon.
The patch submission link:
https://sourceware.org/ml/bin
Richard Biener writes:
> On Tue, Sep 24, 2019 at 1:11 PM Richard Sandiford
> wrote:
>>
>> Martin Liška writes:
>> > Hi.
>> >
>> > The patch introduces couple of new TREE_CODEs that will help us to have
>> > a proper GIMPLE representation of current VECT_COND_EXPR. Right now,
>> > the first argum
Baby-steps towards sanity. My focus is currently vectorizable_reduction
vs. vect_create_epilog_for_reduction - the following aims at simplifying
all the condition reduction special-casing. The real next intermediate
goal is to move all code-generation that is not "epilogue" from
vect_create_epi
On Tue, Sep 24, 2019 at 1:11 PM Richard Sandiford
wrote:
>
> Martin Liška writes:
> > Hi.
> >
> > The patch introduces couple of new TREE_CODEs that will help us to have
> > a proper GIMPLE representation of current VECT_COND_EXPR. Right now,
> > the first argument is typically a GENERIC tcc_expr
On Tue, Sep 24, 2019 at 12:15 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about a refactoring where we should use
> more switch statements rather that if-elseif-elseif
> chains.
>
> I've been testing the patch.
> Ready to be installed after tests?
OK.
Richard.
> Martin
>
> gcc/ChangeLog:
>
On Tue, 24 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> build_array_type_nelts is only meaningful for non-zero number of elements,
> for 0 it creates weirdo arrays like char D.2358[0:18446744073709551615].
> The following patch uses in that case types like the C FE emits for
> zero-length array inste
On Tue, 24 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the following patch decreases number of +/-
> operation when one is inside sign extension, done with undefined overflow,
> and the outer is using wrapping arithmetics.
>
> The :s as well as the outer + are there in order
On 20/09/2019 07:46, Bernhard Reutner-Fischer wrote:
On Thu, 19 Sep 2019 17:46:29 +0200
Tobias Burnus wrote:
Hi Mark,
On 9/19/19 3:40 PM, Mark Eggleston wrote:
The following warning is produced when -fno-automatic and -frecursive
are used at the same time:
f951: Warning: Flag '-fno-automat
Martin Liška writes:
> Hi.
>
> The patch introduces couple of new TREE_CODEs that will help us to have
> a proper GIMPLE representation of current VECT_COND_EXPR. Right now,
> the first argument is typically a GENERIC tcc_expression tree with 2 operands
> that are visited at various places in GIMP
Hi!
build_array_type_nelts is only meaningful for non-zero number of elements,
for 0 it creates weirdo arrays like char D.2358[0:18446744073709551615].
The following patch uses in that case types like the C FE emits for
zero-length array instead (i.e. char D.2358[0:] with forced 0 size).
Bootstra
Hi Thomas, thanks for the review.
On 2019/9/20 12:28 AM, Thomas Schwinge wrote:
This new implementation works by modifying the GIMPLE for child functions
directly at the very start (before, actually) of RTL expansion
That's now near the other end of the pipeline.;-) What's the motivation
for p
Hi!
As mentioned in the PR, the following patch decreases number of +/-
operation when one is inside sign extension, done with undefined overflow,
and the outer is using wrapping arithmetics.
The :s as well as the outer + are there in order to make sure it is actually
beneficial, that we decrease
On 9/24/19 11:14 AM, Thomas Schwinge wrote:
> Hi!
>
> Curious: even if you found the issue on a s390x target, shouldn't this
> (presumably generic?) test case live in a generic place instead of
> 'gcc.target/s390/'?
Sure, that's logical and I've just tested that locally on x86_64-linux-gnu.
Read
Hi.
The patch introduces couple of new TREE_CODEs that will help us to have
a proper GIMPLE representation of current VECT_COND_EXPR. Right now,
the first argument is typically a GENERIC tcc_expression tree with 2 operands
that are visited at various places in GIMPLE code. That said, based on the
Hi.
The patch is about a refactoring where we should use
more switch statements rather that if-elseif-elseif
chains.
I've been testing the patch.
Ready to be installed after tests?
Martin
gcc/ChangeLog:
2019-09-24 Martin Liska
* cfgexpand.c (gimple_assign_rhs_to_tree): Use switch st
On 24/09/19 11:24 +0200, Marc Glisse wrote:
On Tue, 24 Sep 2019, Jonathan Wakely wrote:
On 24/09/19 09:57 +0100, Jonathan Wakely wrote:
On 23/09/19 19:39 +0200, Marc Glisse wrote:
On Mon, 23 Sep 2019, Jonathan Wakely wrote:
If __index_type is a smaller type than size_t, then the result of
s
The following fixes an ICE privately reported to me by Jeff.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-09-24 Richard Biener
* tree-ssa-sccvn.c (vn_reference_lookup_3): Valueize MEM_REF
base.
* gcc.dg/torture/20190924-1.c
PR libstdc++/91871
* testsuite/util/testsuite_hooks.h
(conversion::iterator_to_const_iterator()): Do not return an invalid
iterator. Test direct-initialization and direct-list-initialization
as well as implicit conversion.
Tested x86_64-linux, normal and de
On Tue, 24 Sep 2019, Jonathan Wakely wrote:
On 24/09/19 09:57 +0100, Jonathan Wakely wrote:
On 23/09/19 19:39 +0200, Marc Glisse wrote:
On Mon, 23 Sep 2019, Jonathan Wakely wrote:
If __index_type is a smaller type than size_t, then the result of
size_t(__index_type(-1)) is not equal to size_
Hi!
Curious: even if you found the issue on a s390x target, shouldn't this
(presumably generic?) test case live in a generic place instead of
'gcc.target/s390/'?
Grüße
Thomas
On 2019-06-27T11:21:33+0200, Martin Liška wrote:
> This is quite an obvious changes I've noticed during fuzzing
> of
On 24/09/19 09:57 +0100, Jonathan Wakely wrote:
On 23/09/19 19:39 +0200, Marc Glisse wrote:
On Mon, 23 Sep 2019, Jonathan Wakely wrote:
If __index_type is a smaller type than size_t, then the result of
size_t(__index_type(-1)) is not equal to size_t(-1), but to an incorrect
value such as size_
On 23/09/19 19:39 +0200, Marc Glisse wrote:
On Mon, 23 Sep 2019, Jonathan Wakely wrote:
If __index_type is a smaller type than size_t, then the result of
size_t(__index_type(-1)) is not equal to size_t(-1), but to an incorrect
value such as size_t(255) or size_t(65535). The old implementation o
Hi Matt,
On 9/24/19 5:04 AM, Matt Turner wrote:
When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it. That means
$ gcc -march=native -march=armv8-a
is treated as
$ gcc -march=armv8-a -march=native
Prune joined switches with Negative a
On Mon, Sep 23, 2019 at 6:59 PM Martin Jambor wrote:
>
> Hi,
>
> I am quite surprised I did not catch this before but the new
> ipa-param-manipulation does not copy PARM_DECLs when creating artificial
> thinks (I think it originally did but then I somehow removed during one
> cleanups). Fixed bel
On Mon, Sep 23, 2019 at 4:17 PM Martin Jambor wrote:
>
> Hi,
>
> IPA-SRA asserts that an offset obtained from get_ref_base_and_extent
> is non-negative (after it verifies it is based on a parameter). That
> assumption is invalid as the testcase shows. One could probably also write a
> testcase w
65 matches
Mail list logo
