On Thu, 6 Apr 2017, David Malcolm wrote:
> OK to commit?
If that's what the standard uses, yes, thanks. (We still may
want to add "C++" in there, unless you feel the context is always
clear enough anyway, which I could well see...)
Gerald
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-04-10 Richard Biener
PR middle-end/80344
* gimplify.c (is_gimple_mem_rhs_or_call): Allow CLOBBERs.
Index: gcc/gimplify.c
===
--- gcc/gi
I am testing the following.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-04-10 Richard Biener
PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.
* g
The following fixes a fortran testcase involving safelen where
store motion needs to be disabled for unanalyzable refs (we don't
know how to transform them). But the safelen case missed to recurse
(because that's only necessary for unanalyzable mems).
Bootstrap / regtest on x86_64-unknown-linux-
On Fri, Apr 07, 2017 at 07:22:23PM +0200, Ulrich Weigand wrote:
> Dominik Vogt wrote:
> > On Fri, Apr 07, 2017 at 04:34:44PM +0200, Ulrich Weigand wrote:
> > > > +; Peephole to combine a load-and-test from volatile memory which
> > > > combine does
> > > > +; not do.
> > > > +(define_peephole2
> >
On Mon, 10 Apr 2017, Richard Biener wrote:
>
> The following fixes a fortran testcase involving safelen where
> store motion needs to be disabled for unanalyzable refs (we don't
> know how to transform them). But the safelen case missed to recurse
> (because that's only necessary for unanalyzabl
On Mon, Apr 10, 2017 at 10:13:01AM +0100, Dominik Vogt wrote:
> On Fri, Apr 07, 2017 at 07:22:23PM +0200, Ulrich Weigand wrote:
> > Dominik Vogt wrote:
> > > On Fri, Apr 07, 2017 at 04:34:44PM +0200, Ulrich Weigand wrote:
> > > > > +; Peephole to combine a load-and-test from volatile memory which
Ping.
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01271.html
Thanks,
Kyrill
On 24/03/17 11:14, Kyrill Tkachov wrote:
Hi all,
This PR complains that the bounds checking error strings contain a string placeholder for
"constant" or "lane"
which makes it hard for translators (who may want to m
Hi all,
Something I've missed during the review of these coprocessor intrinsics
patterns is that the SET source is missing a mode.
So we get warnings during the build process.
This patch just trivially adds the appropriate modes to silence the warning.
Bootstrapped and tested on arm-none-linux
On 04/06/2017 04:17 PM, Segher Boessenkool wrote:
I don't like this cryptic name very much. Maybe you could just use a
longer name and indent differently (break at the "=" for example), or
do a macro around where it is used a lot?
I went with rs6000_vector_type
--
Nathan Sidwell
Hi,
Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE exten
Hi!
I'd like to ping 2 patches:
P2 PR c++/80176
http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
reference binding to static member function
PR debug/80263
http://gcc.gnu.org/ml/gcc-patches/2017-04/msg4.html
avoid emitting sizetype artificial name into debug info
Thanks
On 22/03/2017 10:46:30, Prakhar Bahuguna wrote:
> The GCC documentation in section 6.60.8 ARM Floating Point Status and Control
> Intrinsics states that the FPSCR register can be read and written to using the
> intrinsics __builtin_arm_get_fpscr and __builtin_arm_set_fpscr. However, these
> are mis
On 09/04/17 19:58 -0600, Sandra Loosemore wrote:
On 04/07/2017 03:25 AM, Jonathan Wakely wrote:
This issue caused a lot of build failures during the GCC mass rebuilds
for Fedora, but isn't in the porting to guide yet.
Is this accurate and clear enough for casual readers?
Index: htdocs/gcc-7/p
On 04/10/2017 08:18 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping 2 patches:
P2 PR c++/80176
http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
reference binding to static member function
This smells fishy. There's no reason one cannot have an overload set
containing both static
On Fri, 7 Apr 2017, Jason Merrill wrote:
> On Fri, Apr 7, 2017 at 11:32 AM, Bernd Edlinger
> wrote:
> > On 04/07/17 17:10, Richard Biener wrote:
> >> On April 7, 2017 3:37:30 PM GMT+02:00, Bernd Edlinger
> >> wrote:
> >>> On 04/07/17 08:54, Richard Biener wrote:
> On Thu, 6 Apr 2017, Bernd
On 07/04/17 13:29 +0100, Jonathan Wakely wrote:
This adds another piece of the C++17 library, the std::to_chars and
std::from_chars functions for converting numbers to/from strings. This
only adds the integer support, floating point types will require a lot
more work.
This has only been lightly
On Mon, Apr 10, 2017 at 08:41:28AM -0400, Nathan Sidwell wrote:
> On 04/10/2017 08:18 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping 2 patches:
> >
> > P2 PR c++/80176
> >http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
> >reference binding to static member function
>
>
Hi Prakhar,
Sorry for the delay,
On 22/03/17 10:46, Prakhar Bahuguna wrote:
The GCC documentation in section 6.60.8 ARM Floating Point Status and Control
Intrinsics states that the FPSCR register can be read and written to using the
intrinsics __builtin_arm_get_fpscr and __builtin_arm_set_fpscr.
Hi,
This patch fixes PR80345. It is backport of PR68021 to GCC 5 branch with one
assert statement removed. It also includes test case provided in the PR.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
2017-04-07 Bin Cheng
Backport from mainline
2016-02-10 Bin Cheng
Hi,
This is another try fixing PR80153. It's based on richi's idea which is easier
to understand than my
previous patch. The patch gets base pointer from the first element of pointer
aff_tree, builds result
expression in aff_tree's type unconditionally. With this patch, A) we can do
unconditi
Hi,
This is part 2 patch fixing PR80153, because we now explicitly rely on behavior
that the first element being base pointer of pointer type aff_tree. The
original code removes base pointer from aff_tree without updating aff_tree's
type. Actually, we don't need to use tree-affine at all, we c
On 04/10/2017 09:22 AM, Jakub Jelinek wrote:
and there I see COMPONENT_REF with BASELINK second operand with
BASELINK_FUNCTIONS being an overload only for the methods.
And even if I try overload with mixed methods and static member functions,
lvalue_kind with that is only called when seeing the
On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener wrote:
> So here's my variant of a fix. I constrained the new flag
> TYPE_TYPELESS_STORAGE to arrays and thus hope my localized fix in
> build_cplus_array_type will suffice (if I have time I'll play with
> template instantiation).
Looks good. I wo
This is the second try to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
The first try patch triggered a latent bug and broke one Fortran
testcase on x86-64.
The patch was successfully bootstrapped on x86-64 and tested on
x86-64, ppc64, and aarch64.
Committed as rev. 246808
On Mon, 10 Apr 2017, Jason Merrill wrote:
> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener wrote:
> > So here's my variant of a fix. I constrained the new flag
> > TYPE_TYPELESS_STORAGE to arrays and thus hope my localized fix in
> > build_cplus_array_type will suffice (if I have time I'll play
On Mon, Apr 10, 2017 at 4:35 PM, Bin Cheng wrote:
> Hi,
> This is another try fixing PR80153. It's based on richi's idea which is
> easier to understand than my
> previous patch. The patch gets base pointer from the first element of
> pointer aff_tree, builds result
> expression in aff_tree's
On Mon, Apr 10, 2017 at 4:35 PM, Bin Cheng wrote:
> Hi,
> This is part 2 patch fixing PR80153, because we now explicitly rely on
> behavior that the first element being base pointer of pointer type aff_tree.
> The original code removes base pointer from aff_tree without updating
> aff_tree's t
On Mon, Apr 10, 2017 at 4:30 PM, Bin Cheng wrote:
> Hi,
> This patch fixes PR80345. It is backport of PR68021 to GCC 5 branch with one
> assert statement removed. It also includes test case provided in the PR.
>
> Bootstrap and test on x86_64. Is it OK?
Ok.
Thanks,
Richard.
> Thanks,
> bin
On 04/07/2017 04:30 AM, Martin Liška wrote:
On 04/06/2017 06:44 PM, Jeff Law wrote:
On 03/24/2017 03:29 AM, Martin Liška wrote:
I would like to ping that. I'm not sure what's agreement after I read
discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html
Martin Sebor may know, CC'ing hi
On Mon, Apr 10, 2017 at 5:42 PM, Jeff Law wrote:
> On 04/07/2017 04:30 AM, Martin Liška wrote:
>>
>> On 04/06/2017 06:44 PM, Jeff Law wrote:
>>>
>>> On 03/24/2017 03:29 AM, Martin Liška wrote:
I would like to ping that. I'm not sure what's agreement after I read
discussion in: https
On 03/21/2017 05:32 PM, Alexandre Oliva wrote:
GDB has had a work-around that uses the typedef name as the name of an
anonymous class, struct or union, when introducing them through libcc1's
C++ API. It didn't do that for enums, that remained anonymous, and GCC
warned about using types without l
On 04/07/2017 01:36 AM, Uros Bizjak wrote:
Hello!
Attached patch mitigates:
FAIL: gcc.dg/unroll-7.c scan-rtl-dump loop2_unroll "number of
iterations: .const_int 99"
testsuite failure for x32 target. Loop analysis determines:
Loop 1 is simple:
simple exit 3 -> 4
infinite if: (expr_list
On Apr 7, 2017, at 11:32 AM, Alexandre Oliva wrote:
>
> On Mar 21, 2017, Alexandre Oliva wrote:
>>
>> Ping? https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html
> Ping?
The Objective-C/C++ parts look fine.
On Apr 9, 2017, at 1:53 PM, Volker Reichelt wrote:
>>> +Wextra-semi
>>> +C++ Var(warn_extra_semi) Warning
>>> +Warn about semicolon after in-class function definition.
>>> +
> Right now, the patch enables the warning only for C++.
> Would it make sense to enable it also for ObjC++?
This is rever
On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener wrote:
> On Mon, 10 Apr 2017, Jason Merrill wrote:
>> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener wrote:
>> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
>> > for arrays of unsigned char or std::byte.
>>
>> I th
On Apr 4, 2017, at 6:10 PM, Damian Rouson wrote:
>
> The attached patch modifies the contrib/download_prerequisites script to work
> on macOS.
> Ok for trunk?
Don't know if others would prefer to review... assuming no strong feelings
against...
Ok.
Hello everyone,
Dominique send me this patch written by Paul some time ago. For some
reason it was never committed, so here we go :)
Ok for trunk?
Nicolas
Regression tested for x86_64-pc-linux-gnu.
Changelog:
2017-03-18 Nicolas Koenig
PR fortran/69498
* mo
On Mon, Apr 10, 2017 at 12:32 PM, Mike Stump wrote:
> On Apr 9, 2017, at 1:53 PM, Volker Reichelt wrote:
+Wextra-semi
+C++ Var(warn_extra_semi) Warning
+Warn about semicolon after in-class function definition.
+
>
>> Right now, the patch enables the warning only for C++.
>> Wo
On Apr 6, 2017, at 5:05 AM, Senthil Kumar Selvaraj
wrote:
> builtin-sprintf-warn-10.c fails because the bounds in the warning
> messages expect 4 digit wide exponents i.e. __DBL_MAX_EXP__ > 999.
> For the avr, floats and doubles are both 32 bits wide, __DBL_MAX_EXP__
> == 128, and the max num
I was notified that I hadn't really fixed this PR, because with this test
we were still crashing on the assert in ubsan_instrument_division. The
problem was that ORIG_TYPE was null, so we didn't do the conversion prior
calling ubsan_instrument_division. ORIG_TYPE was null because in this case
we
On Mon, Apr 10, 2017 at 06:55:07PM +0200, Marek Polacek wrote:
> 2017-04-10 Marek Polacek
>
> PR sanitizer/80348
> * typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL. Set
> ORIG_TYPE earlier and not only when shortening.
>
> * g++.dg/ubsan/div-by-zero-3.C:
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376 shows an ICE on invalid
code when using certain flavors of the vec_xxpermdi intrinsic. The root
cause is that we were not checking the parameter for a legal value, and an
illegal value was being provided by the user (only an integer constant
On Mon, Apr 10, 2017 at 07:02:04PM +0200, Jakub Jelinek wrote:
> On Mon, Apr 10, 2017 at 06:55:07PM +0200, Marek Polacek wrote:
> > 2017-04-10 Marek Polacek
> >
> > PR sanitizer/80348
> > * typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL. Set
> > ORIG_TYPE earlier and
Segher Boessenkool writes:
> On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
>> > Or we could just change "blockage" and wait for the next bug report.
>>
>> That's my suggestion, yes.
>>
>> > Alternatively, we can arrange for the bypass functions to not ICE. We
>> > can do that s
On Apr 6, 2017, at 3:40 PM, Daniel Santos wrote:
> This patch merges the changes from libffi upstream which correctly solve
> the Windows DLL load path problem in set_ld_library_path_env_vars and
> restore_ld_library_path_env_vars, thus fixing most PR79867.
Ok.
I checked it in for you, after stu
Hello again,
I forgot to add the test case this patch fixes and to give Paul the
credit. Attached the new test case.
Nicolas
New & improved changelog:
2017-04-10 Nicolas Koenig
Paul Thomas
PR fortran/69498
* module.c (gfc_match_sub
Dear Nicolas,
The reasons are (i) moving country and (ii) the daytime job :-)
I think that in the circumstances somebody else should OK the patch,
although I think that it is perfect in every way possible.
Actually, perhaps it is sufficiently obvious that I would and should
have committed it - O
Hello everyone,
this is a ping for
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01171.html
fold_convert can fail for certain types. It can fail either by
returning a error_mark_node or triggering a gcc_assert depending on the
exact situation.
Both are problematical. This patch checks that we can convert
integer_zero_node to the proper type before calling fold_convert.
Bootstra
Thanks, Paul. Committed as r246823.
Cheers,
Janus
2017-04-09 12:40 GMT+02:00 Paul Richard Thomas :
> Hi Janus,
>
> The patch is OK for trunk.
>
> Thanks
>
> Paul
>
>
> On 7 April 2017 at 17:51, Janus Weil wrote:
>> ping!
>>
>> 2017-03-29 22:25 GMT+02:00 Janus Weil :
>>> Hi all,
>>>
>>> here is
Hi!
The following testcase emits vec_cond_expr not supported by dump_expr
inside of error message.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2017-04-10 Jakub Jelinek
PR c++/80363
* error.c (dump_expr): Handle VEC_COND_EXPR like COND_EX
Hi!
The following testcase ICEs, because when cp_finish_decomp is called
during parsing with processing_template_decl, but decl is not type
dependent, we finalize it at that point and when we try to do it again
during tsubst time, it doesn't find the expected trees (e.g. DECL_VALUE_EXPR
of the exp
Hi!
The http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00031.html change
appears to be IMHO highly undesirable loophole around the lack of
TImode support on 32-bit targets. Those targets return
false from targetm.scalar_mode_supported_p (TImode) for a reason,
while for some arithmetics operation pe
Hi!
As mentioned in the PR, apparently we have some specific handling for
the MMX/SSE/AVX2 shift builtins with *_COUNT function type aliases,
where the count argument (last == second) is not really required to be
constant e.g. for the srai/srli/slli builtins, and is converted as needed.
This patc
On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek wrote:
> - store_decomp_type (v[i], eltype);
> + if (!processing_template_decl)
> + store_decomp_type (v[i], eltype);
This spot shouldn't change; we do want to remember the decltype even
in a template.
> @@ -3935,7 +3935,10
On Mon, Apr 10, 2017 at 04:48:43PM -0400, Jason Merrill wrote:
> On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek wrote:
> > - store_decomp_type (v[i], eltype);
> > + if (!processing_template_decl)
> > + store_decomp_type (v[i], eltype);
>
> This spot shouldn't change; we
2017-04-02 23:52 GMT+03:00 Alexander Ivchenko :
> Hi,
>
> Here is the patch that roughly follows your idea.
> Some comments:
>
> - There are more cases than array_ref overflow. We need to take care
> of component_ref and both underflows/overflows are possible
> - I could not make it work with "0" a
On Mon, Apr 10, 2017 at 12:08:50PM -0500, Bill Schmidt wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376 shows an ICE on invalid
> code when using certain flavors of the vec_xxpermdi intrinsic. The root
> cause is that we were not checking the parameter for a legal value, and an
> illega
Hi Segher,
> On Apr 10, 2017, at 4:31 PM, Segher Boessenkool
> wrote:
>
> On Mon, Apr 10, 2017 at 12:08:50PM -0500, Bill Schmidt wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376 shows an ICE on invalid
>> code when using certain flavors of the vec_xxpermdi intrinsic. The root
>> ca
On Mon, Apr 10, 2017 at 06:38:07PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
> >> > Or we could just change "blockage" and wait for the next bug report.
> >>
> >> That's my suggestion, yes.
> >>
> >> > Alternat
Dominik Vogt wrote:
> So, we could add a special case for const0_rtx that generates the
> LT pattern and does not rely on Combine, and get rid of the
> peephole. I'm not sure this is worthwhile thoug, because the
> peephole has other beneficial effects (as discussed), and until
> we've solved the
On 04/10/2017 01:50 PM, Richard Biener wrote:
> +void *operator new(__SIZE_TYPE__, void *p2) { return p2; }
> +struct B { B(int i_) : i(i_) {} int i; };
> +struct X
> +{
> + unsigned char buf[sizeof (B)];
> +};
Pedantically, shouldn't there be something here to enforce
X's alignment to be at lea
Hello Paul,
I would argue that this is but an elaborate plan to teach a newbie the
ways of the bugzilla and enable him to properly close his first bug ;)
Anyway, committed as r246826.
Thanks for the review.
Nicolas
On 04/10/2017 08:07 PM, Paul Richard Thomas wrote:
Dear Nicolas,
The reas
@@ -972,11 +972,11 @@ get_int_range (tree arg, tree type, HOST_WIDE_INT *pmin,
HOST_WIDE_INT *pmax,
if (range_type == VR_RANGE)
{
HOST_WIDE_INT type_min
- = (TYPE_UNSIGNED (type)
- ? tree_to_uhwi (TYPE_MIN_VALUE (type))
-
Martin L. (CC'd) pointed out to me that the introduction
of the -Wstringop-overflow option has changed the text of
the warning but failed to adjust a couple of dg-bogus
directives in existing tests that used the previous text
as the pattern. r246827 adjusts the pattern to match
the new diagnostic
All,
Attached patch is removing the space after * in many pointer declarations and
references in the files in the io sub-directory. Prompted by a comment from one
our C maintainers. I noticed quite a few comment blocks not done right either,
so since I was there I did those as well.
This is whi
On Mon, Apr 10, 2017 at 10:46 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, apparently we have some specific handling for
> the MMX/SSE/AVX2 shift builtins with *_COUNT function type aliases,
> where the count argument (last == second) is not really required to be
> constant e.g. for
On Tue, Apr 11, 2017 at 7:54 AM, Jerry DeLisle wrote:
> All,
>
> Attached patch is removing the space after * in many pointer declarations and
> references in the files in the io sub-directory.
Hmm, I always considered having a space both before and after the "*"
in declarations to be an idiosync
On 2017.04.10 at 13:20 -0600, Jeff Law wrote:
>
> fold_convert can fail for certain types. It can fail either by returning a
> error_mark_node or triggering a gcc_assert depending on the exact situation.
>
> Both are problematical. This patch checks that we can convert
> integer_zero_node to th
70 matches
Mail list logo
