On Fri, Jan 4, 2019 at 12:00 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because during DIVMOD discovery a is still not
> known to be a constant (otherwise we wouldn't create a DIVMOD), but later on
> before expansion it is replaced with 17 and ix86_expand_divmod_libfunc
>
The attached patch corrects a couple of minor typos in the description
of -Wmemset-transposed-args. It also tweaks the text a bit for better
readability.
Martin
gcc/ChangeLog:
* invoke.texi (-Wmemset-transposed-args): Fix typos, adjust wording.
Index: gcc/doc/invoke.texi
The attached patch avoids dereferencing a null pointer in
maybe_warn_nonstring_arg reported to cause an ICE in pr88659.
Committed in r267569 after bootstrapping and regtesting on
x86_64-linux.
Martin
gcc/ChangeLog:
PR tree-optimization/88659
* calls.c (maybe_warn_nonstring_arg): Avoid
On Thu, Jan 03, 2019 at 07:03:59PM +, Richard Sandiford wrote:
> Richard Sandiford writes:
> > This still seems risky and isn't what the name and function comment
OK, how about this delta from the previous patch to ameliorate the
maintenance risk?
diff --git a/gcc/genattrtab.c
On Thu, Jan 3, 2019 at 3:49 AM Iain Sandoe wrote:
>
> > On 2 Jan 2019, at 13:26, Iain Sandoe wrote:
> >
> >
> >> On 2 Jan 2019, at 13:20, Rainer Orth wrote:
> >>
> >> Gerald Pfeifer writes:
> >>
> >>>
>
> >>>
> >>> I believe that in addition to FreeBSD this probably also fails on
> >>>
Hi!
After upgrading gdb recently gdb ./cc1 etc. asks me to
--Type for more, q to quit, c to continue without paging--
on start, because the stuff it prints by default + all the
File tree.h will be skipped when stepping.
File is-a.h will be skipped when stepping.
File line-map.h will be skipped
Hi!
The following testcase ICEs, because during DIVMOD discovery a is still not
known to be a constant (otherwise we wouldn't create a DIVMOD), but later on
before expansion it is replaced with 17 and ix86_expand_divmod_libfunc
calls emit_library_call_value with GET_MODE (op1) as the mode for the
Hi!
The following testcases ICE on x86_64 and other targets.
The problem is that a function with nested functions returning VLA
structures is inlined (or versioned) so that the variable sizes become
constant, but we still have a MEM_REF[(struct S *) ] = fn ();
where the D.1234 variable has fixed
On 03/01/19 22:07 +, Jonathan Wakely wrote:
On 03/01/19 20:38 +, Jonathan Wakely wrote:
There are a number of UTF-8 characters in comments which add no value
and can be replaced with ASCII equivalents, or removed entirely for the
section sign (U+00A7).
PR libstdc++/88607
Hi!
The prev_offset we push into the vector is supposed to be the end of
the red zone for the variable, it needs to be ASAN_MIN_RED_ZONE_SIZE
aligned, but by aligning it more we can end up with red zone with negative
size. E.g. on the testcase, we have initial frame_offset -8 (because of
Hi!
The following testcase FAILs on 8.x branch, went latent later on on the
trunk and I suppose Alex' i386.c ix86_const_not_ok_for_debug_p change would
have prevented it too.
The problem is in what the comment in const_ok_for_output* says, we don't do
sufficient checking of what kind of
On Thu, Jan 03, 2019 at 06:32:44PM +0100, Marc Glisse wrote:
> > That said, not sure if e.g. using an opaque builtin for the conversion that
> > supportable_convert_operation sometimes uses is better over this ifn.
> > What exact optimization opportunities you are looking for if it is lowered
> >
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html
On 12/20/18 7:51 PM, Martin Sebor wrote:
Jeff, did this and the rest of the discussion answer your question
and if so, is the patch okay to commit?
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html
Martin
On 12/13/18
On Thu, Jan 03, 2019 at 01:36:30PM +0100, Thomas Koenig wrote:
> Hi Jakub,
>
> > In any case, IMHO the test should be removed or XFAILed for now.
>
> thanks for your explanations. I have removed the test case.
You've actually removed a different testcase (which was working fine),
while the
On Jan 2, 2019, at 5:39 AM, Rainer Orth wrote:
>
> It's on the brink, I'd say. The effective-keyword form is shorter and
> more descriptive and can be extended to more targets way more easily.
> Checking 2018-12 testresults, I find failures of the ident-*.c tests on
> hppa2.0w-hp-hpux11.11 and
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00740.html
On 12/18/18 2:42 PM, Martin Sebor wrote:
On 12/11/18 4:19 PM, Jason Merrill wrote:
On 12/11/18 6:08 PM, Martin Sebor wrote:
On 12/11/18 3:52 PM, Marek Polacek wrote:
On Tue, Dec 11, 2018 at 03:46:37PM -0700, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01616.html
(The first sentence in the second paragraph below should have
read "...independently of the question whether leaf should be
accepted on extern declarations.")
On 12/21/18 4:50 PM, Martin Sebor wrote:
The first revision of the patch
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01616.html
(The first sentence in the second paragraph below should have
read "...independently of the question whether leaf should be
accepted on extern declarations.")
On 12/21/18 4:50 PM, Martin Sebor wrote:
The first revision of the patch
On 03/01/19 20:38 +, Jonathan Wakely wrote:
There are a number of UTF-8 characters in comments which add no value
and can be replaced with ASCII equivalents, or removed entirely for the
section sign (U+00A7).
PR libstdc++/88607
* include/bits/forward_list.h: Replace UTF-8
These new facet functions were added to GCC 5.1 but the versions for the
old std::string ABI were never exported from the shared library.
PR libstdc++/88681
* config/abi/pre/gnu.ver: Add missing exports.
* testsuite/22_locale/collate_byname/88681.cc: New test.
*
There are a number of UTF-8 characters in comments which add no value
and can be replaced with ASCII equivalents, or removed entirely for the
section sign (U+00A7).
PR libstdc++/88607
* include/bits/forward_list.h: Replace UTF-8 "ligature fi" character.
*
Richard Sandiford writes:
> Alan Modra writes:
>> If the operands of PLUS are assumed to be insn lengths (reasonable,
>> since you're likely to use PLUS to sum the machine insn lengths of a
>> pattern that conditionally emits multiple machine insns), then it
>> might be better to replace
On Thu, 3 Jan 2019, Jakub Jelinek wrote:
On Thu, Jan 03, 2019 at 11:48:12AM +0100, Marc Glisse wrote:
The following patch adds support for the __builtin_convertvector builtin.
C casts on generic vectors are just reinterpretation of the bits (i.e. a
VCE), this builtin allows to cast
Alan Modra writes:
> On Thu, Jan 03, 2019 at 12:41:52PM +, Richard Sandiford wrote:
>> Alan Modra writes:
>> > +case PLUS:
>> > + current_or = or_attr_value (XEXP (exp, 0));
>> > + if (current_or != -1)
>> > + {
>> > +int n = current_or;
>> > +current_or =
+/* Build a VEC_CONVERT ifn for __builtin_convertvector builtin. */
Can you please document the function arguments and explain how they
are used?
+
+tree
+c_build_vec_convert (location_t loc1, tree expr, location_t loc2, tree type,
+bool complain)
+{
+ if
On 14-12-18 20:58, Tom de Vries wrote:
> 0016-nvptx-Add-vector_length-128-testcases.patch
> * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: New test.
>
> * testsuite/libgomp.oacc-fortran/gemm.f90: New test.
>
On 14-12-18 20:58, Tom de Vries wrote:
> 0012-nvptx-Add-axis_dim.patch
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index 74a0d4b04d9..02ecf12bd84 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -2885,6 +2885,23 @@ struct offload_attrs
>
On 14-12-18 20:58, Tom de Vries wrote:
> 0007-nvptx-consolidate-offloaded-function-attributes-into.patch
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index a3169febbb4..dcfa57d10ca 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -2872,6
Hi,
since Martin in meantime backported the fix for thunk profiling which
trigers the merging bug, I also bacported the patch into GCC 8
as follows.
Bootstrapped/regtested x86_64-linux and tested on Firefox build.
2019-01-03 Jan Hubicka
* ipa-utils.c (scale_ipa_profile_for_fn): Break
Hi,
Add early-out cases for for oacc_min_dims_p and routine_p in
nvptx_goacc_validate_dims, allowing simplification of the rest of the
function.
Committed to trunk.
Thanks,
- Tom
[nvptx] Add early-out cases in nvptx_goacc_validate_dims
2019-01-03 Tom de Vries
*
Hi,
The TARGET_GOACC_VALIDATE_DIMS hook requires an implementation to return a bool
indicating whether the dims parameter has changed.
Factor nvptx_goacc_validate_dims_1 out of nvptx_goacc_validate_dims, and
calculate the return value in nvptx_goacc_validate_dims.
Committed to trunk.
Thanks,
-
Hi Richard,
> On Thu, 3 Jan 2019, Rainer Orth wrote:
>
>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as (both
>> sparc and x86):
>>
>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
>> (0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
>>
On Thu, Jan 03, 2019 at 12:41:52PM +, Richard Sandiford wrote:
> Alan Modra writes:
> > +case PLUS:
> > + current_or = or_attr_value (XEXP (exp, 0));
> > + if (current_or != -1)
> > + {
> > + int n = current_or;
> > + current_or = or_attr_value (XEXP (exp, 1));
> > +
On Thu, 3 Jan 2019, Rainer Orth wrote:
> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as (both
> sparc and x86):
>
> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
> (0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
>
On Thu, 3 Jan 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > The following rectifies a change during hash-map intruction which
> > changed the uncprop operand_equal_p based hash to a pointer-based
> > hash_map. That assumes pointer equality between constants which
> > does not hold
This makes sure we do not regress PR85574 and thus that when
doing LTO bootstrap the generated binaries do not differ from
stage2 to stage3. Note we indepenently verify the object
files which contain just LTO bytecode do not differ (besides
differences in the LTO options sections).
This has
gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as (both
sparc and x86):
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
(0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
[^(].*DW_TAG_lexical_block)[^#/!x]*x1[^#/!]*[#/!] DW_AT_abstract_origin
FAIL:
Richard Biener writes:
> The following rectifies a change during hash-map intruction which
> changed the uncprop operand_equal_p based hash to a pointer-based
> hash_map. That assumes pointer equality between constants which
> does not hold since different (but compatible) typed constants
> can
Jakub Jelinek writes:
> + /* Can't use get_compute_type here, as supportable_convert_operation
> + doesn't necessarily use an optab and needs two arguments. */
> + tree vector_compute_type
> + = type_for_widest_vector_mode (TREE_TYPE (arg_type), mov_optab);
> + unsigned
On 02-01-19 14:20, Rainer Orth wrote:
> Unfortunately, libbacktrace is one of those libraries that don't produce
> Dejagnu-style .sum and .log files, so test failures are buried in the
> make check output and very easily overlooked.
FTR, I've filed PR88002 - "libbacktrace and libiberty tests
Alan Modra writes:
> +case PLUS:
> + current_or = or_attr_value (XEXP (exp, 0));
> + if (current_or != -1)
> + {
> + int n = current_or;
> + current_or = or_attr_value (XEXP (exp, 1));
> + if (current_or != -1)
> + current_or += n;
> + }
> +
Hi Jakub,
In any case, IMHO the test should be removed or XFAILed for now.
thanks for your explanations. I have removed the test case.
Regards
Thomas
On Thu, 3 Jan 2019, Johannes Pfau wrote:
>
> Debugging shows that the access function used to check
> if the input files exist has different behavior in newer msvcr libraries:
> It does return proper results for the 'nul' file in the old msvcrt.dll
> but in newer libraries it returns EINVAL for
The following rectifies a change during hash-map intruction which
changed the uncprop operand_equal_p based hash to a pointer-based
hash_map. That assumes pointer equality between constants which
does not hold since different (but compatible) typed constants
can appear in the IL. For SSA names
On Thu, Jan 03, 2019 at 12:16:31PM +0100, Richard Biener wrote:
> I guess it depends on target capabilities - I think
> __builtin_convertvector is a bit "misdesigned" for pack/unpack. You
> also have to consider a v2di to v2qi conversion which requires
I'm aware of that, I know
> On 2 Jan 2019, at 13:26, Iain Sandoe wrote:
>
>
>> On 2 Jan 2019, at 13:20, Rainer Orth wrote:
>>
>> Gerald Pfeifer writes:
>>
>>>
>>>
>>> I believe that in addition to FreeBSD this probably also fails on
>>> Solaris and Darwin.
>>
>> I cannot test Darwin right now,
>
> I have
I've just updated config.guess and config.sub to the current upstream
versions. This was prompted by PR target/88535 where on Solaris/SPARC
config.guess didn't return the 64-bit configure triplet when a 64-bit
compiler is used, unlike Solaris/x86. This ultimately lead to a
comparison failure.
On Thu, 3 Jan 2019, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds support for the __builtin_convertvector builtin.
> C casts on generic vectors are just reinterpretation of the bits (i.e. a
> VCE), this builtin allows to cast int/unsigned elements to float or vice
> versa or
On Thu, Jan 03, 2019 at 11:48:12AM +0100, Marc Glisse wrote:
> > The following patch adds support for the __builtin_convertvector builtin.
> > C casts on generic vectors are just reinterpretation of the bits (i.e. a
> > VCE), this builtin allows to cast int/unsigned elements to float or vice
> >
On Thu, 3 Jan 2019, Jakub Jelinek wrote:
> Hi!
>
> Some time ago I've changed modified_type_die, so that it doesn't emit
> the internal "sizetype" type as DW_TAG_base_type, but instead emits the
> underlying type (e.g. "long unsigned int" or whatever the target has).
> This PR complains that
Hello list,
I'm currently adding D support to the MinGW targets. As the libphobos
upstream only targets newer msvcr runtime libraries, I tried building
GCC against libmsvcr120. When doing that, the build fails when building
s-selftest-c++:
On Thu, 3 Jan 2019, Jakub Jelinek wrote:
The following patch adds support for the __builtin_convertvector builtin.
C casts on generic vectors are just reinterpretation of the bits (i.e. a
VCE), this builtin allows to cast int/unsigned elements to float or vice
versa or promote/demote them.
Hi,
testing of Firefox has uncovered an ICE which I introduced by the patch
to fix profile of thunks. The problem is that ipa_merge_profile may try
to merge profile of thunks and end up with attempting to touch their
gimple body.
This patch implements merging of profile of thunks and I also
Hi!
Some time ago I've changed modified_type_die, so that it doesn't emit
the internal "sizetype" type as DW_TAG_base_type, but instead emits the
underlying type (e.g. "long unsigned int" or whatever the target has).
This PR complains that when .debug_pubtypes is emitted, we still refer to it
Hi!
The following patch adds support for the __builtin_convertvector builtin.
C casts on generic vectors are just reinterpretation of the bits (i.e. a
VCE), this builtin allows to cast int/unsigned elements to float or vice
versa or promote/demote them. doc/ change is missing, will write it
On Wed, Jan 02, 2019 at 04:31:49PM +0100, Thomas Koenig wrote:
> Hell world,
>
> somebody fixed PR 48543 for us, so I have committed the
> attached test case as obvious and closed the PR. Thanks
> to however did this!
Nobody actually fixed this and the testcase fails e.g. on i686-linux.
The
This patch started off just by adding if_then_else support in
write_attr_value to be able to write a saner expression for powerpc
tls_gdld_nomark length. (*) Then I noticed bit-rot in functions used
to calculate insn_default_length, insn_min_length, and length_unit_log
(which are used by the
On 18-12-18 00:52, Tom de Vries wrote:
> On 14-12-18 20:58, Tom de Vries wrote:
>
>> 0003-openacc-Add-target-hook-TARGET_GOACC_ADJUST_PARALLEL.patch
>
Hi Thomas,
ping. OK for trunk?
Thanks,
- Tom
Steve Ellcey writes:
> Here is an update of this patch. I believe I addressed all of the
> issues you raised. Thanks for the new target.def description, it
> seems much clearer than mine. I did a full build and test on x86 as
> well as aarch64 to make sure that architectures that do not define
On 1/2/19 12:50 PM, Jan Hubicka wrote:
>>
>> Honza, in order to make the test working I would need to backport
>> r267495. Is it a good idea?
>
> Yes, my apologies for the mistake! I should stop looking for failures
> via grep and use test_summary consistently since I tend to miss
> unresolved
60 matches
Mail list logo
