The manual doesn't document the effects of attribute aligned
with no argument. The __alignof__ section also doesn't discuss
the effect of the operator on functions, and doesn't mention
that it's okay to use void as an argument.
The attached patch adds entries for the attribute form with no
On 10/16/2018 04:35 PM, Jeff Law wrote:
On 10/8/18 5:22 PM, Martin Sebor wrote:
Attached is an updated patch with the INTEGRAL_TYPE_P test added
to detect constant non-integer arguments like (void*)0, and with
quoting made unconditional. I also removed the pretty printer
business to avoid the
Hi,
The intrinsic compatibility headers make use of some deprecated functions for
vector shifts, which are not available in some compilers. For compatibility
reasons, this patch, replaces those with intrinsics guaranteed to be portable.
Bootstrapped and tested on powerpc64le-linux-gnu with no
Jumps are written in RTL as moves to PC. But the latter has no mode,
so we shouldn't try to use it. Since the optimization this routine
does does not really help for jumps at all, let's just skip it.
Committing.
2018-10-24 Segher Boessenkool
PR rtl-optimization/87720
*
On Tue, Oct 23, 2018 at 07:40:04PM -0400, Michael Meissner wrote:
> On Tue, Oct 23, 2018 at 10:22:41PM +, Joseph Myers wrote:
> > Now, you can't use the __ieee128 names with *current* glibc because
> > they aren't exported yet. So is the plan that GCC would later switch to
> > using the
On 10/19/18 9:29 PM, Stafford Horne wrote:
> On Thu, Oct 18, 2018 at 05:55:35PM -0600, Jeff Law wrote:
>> On 10/18/18 2:06 PM, Stafford Horne wrote:
>>> On Thu, Oct 18, 2018 at 03:22:56PM +0200, Sebastian Huber wrote:
Hello,
is there a chance to get the or1k support integrated
On Tue, Oct 23, 2018 at 05:53:15PM -0400, Michael Meissner wrote:
> > > +static tree
> > > +rs6000_mangle_decl_assembler_name (tree decl, tree id)
> > > +{
> > > + if (!TARGET_IEEEQUAD_DEFAULT && TARGET_IEEEQUAD &&
> > > TARGET_LONG_DOUBLE_128
> >
> > Write this is in the opposite order?
> >
On 10/22/18 6:20 PM, Segher Boessenkool wrote:
> Hi peter,
>
> On Mon, Oct 22, 2018 at 06:40:58PM -0500, Peter Bergner wrote:
>> --- gcc/function.c (revision 265399)
>> +++ gcc/function.c (working copy)
>> @@ -6453,6 +6453,13 @@ match_asm_constraints_1 (rtx_insn *insn,
>>||
On 10/23/18 7:30 AM, Thomas Preudhomme wrote:
> Hi,
>
> gcc.dg/sibcall-9.c and gcc.dg/sibcall-10.c give execution failure
> on ARM when compiled with -fPIC due to the PIC access to volatile
> variable v creating an extra spill which causes the frame size of the
> two recursive functions to be
On 10/24/18 7:06 AM, Rainer Orth wrote:
> Between 20181022 (r265393) and 20181023 (r265430), gcc.dg/pr78973-2.c
> began to XPASS on a large number of targets:
>
> +XPASS: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16)
>
> The following patch fixes this by removing the xfail on dg-warning.
On 10/5/18 6:11 AM, Sam Tebbs wrote:
> Hi all,
>
> I recently found what seems to be an error in the options documentation
> (gcc/doc/options.texi) where a list describing how _var_ is set (referring to
> the Var attribute) is written beneath the _Deprecated_ attribute instead. This
> patch moves
On 10/11/18 8:56 PM, Marek Polacek wrote:
Here potential_constant_expression_1 rejects the testcase because the body of
the for loop calls a non-constexpr function. But the range is empty so the
function would never get called.
The trick with evaluating the for-condition doesn't work here,
On Wed, 24 Oct 2018, 17:39 David Malcolm, wrote:
> Manu: are you wiki user "ManuelLopezIbanez", and are you happy to have
> any/all of your gcc wiki edits copied into gcc itself, covered under
> the usual FSF copyright assignment?
>
I'm wiki user "ManuelLopezIbanez". I believe nothing I have
On 10/15/18 12:45 PM, Paolo Carlini wrote:
&& ((TREE_CODE (declspecs->type) != TYPENAME_TYPE
+ && TREE_CODE (declspecs->type) != DECLTYPE_TYPE
&& MAYBE_CLASS_TYPE_P (declspecs->type))
I would think that the MAYBE_CLASS_TYPE_P here should be CLASS_TYPE_P,
and then
On 10/24/2018 11:27 AM, Joseph Myers wrote:
On Wed, 24 Oct 2018, Martin Sebor wrote:
On 10/24/2018 06:22 AM, Joseph Myers wrote:
On Wed, 24 Oct 2018, Martin Sebor wrote:
But if you do want to avoid the attribute on declarations of
these functions regardless it should be safe to add it after
Here is the patch I just committed.
[gcc]
2018-10-24 Michael Meissner
* config/rs6000/rs6000.c (TARGET_MANGLE_DECL_ASSEMBLER_NAME):
Define as rs6000_mangle_decl_assembler_name.
(rs6000_mangle_decl_assembler_name): If the user switched from IBM
long double to
GCC Maintainers:
The scalar_cmp_exp_eq, scalar_cmp_lt, scalar_cmp_gt,
scalar_cmp_unordered are missing support for the _ieee128 arguments.
This patch adds the missing support and a test file for the builtins
for both _ieee128 and double arguments.
I have tested the attached patch on
Hi,
Due to some unfortunate history, not all compilers currently have correct result
types produced for comparison operators on vector types. For compatibility
purposes, this patch replaces those with vec_cmp* built-ins. It also cleans up
some silly type usages and formatting in the affected
Some tests dg-prune-output regex need to be adapted to pass when
versioned namespace is activated.
I preferred to add the version namespace in the regex rather than
removing namespace qualification. Let me know if you would prefer the
other approach.
*
On Wed, 24 Oct 2018, Martin Sebor wrote:
> The attached patch mentions the options that disable the null
> pointer check optimization related to functions declared with
> the nonnull attribute, and that have GCC insert traps when
> it detects null pointer arguments.
This patch is OK.
--
Joseph
On 10/17/18 3:38 PM, Paolo Carlini wrote:
Hi Jakub,
On 17/10/18 19:42, Jakub Jelinek wrote:
On Wed, Oct 17, 2018 at 07:20:53PM +0200, Paolo Carlini wrote:
Hi,
as you probably remember, very close to the release of 8.1.0 we
noticed that
my fix for c++/70808 was causing c++/85553, which
On 10/17/18 6:45 PM, Jakub Jelinek wrote:
As mentioned in the PR, for use in headers for the same reason like we
support __aligned__ form next to aligned (user defining such a macro) this
patch allows to mangle the scope the same way.
In addition to that, it fixes an ICE, where because we
On 10/12/18 12:32 PM, Marek Polacek wrote:
+ EXPLICIT_SPECIFIER is used in case the explicit-specifier, if any, has
+ value-dependent expression. */
static void
cp_parser_decl_specifier_seq (cp_parser* parser,
cp_parser_flags flags,
On 10/23/18 6:08 PM, Martin Sebor wrote:
+ if (cp_parser_parse_definitely (parser))
+{
+ /* If all went well, set OPER to the type. */
+ cp_decl_specifier_seq decl_specs;
+
+ /* Build a trivial decl-specifier-seq. */
+ clear_decl_specs (_specs);
+ decl_specs.type
The attached patch mentions the options that disable the null
pointer check optimization related to functions declared with
the nonnull attribute, and that have GCC insert traps when
it detects null pointer arguments.
Martin
gcc/ChangeLog:
* doc/extend.texi (nonnull): List no-argument form.
On 10/24/2018 03:52 AM, Martin Liška wrote:
On 10/23/18 6:31 PM, Martin Sebor wrote:
On 10/22/2018 07:05 AM, Martin Liška wrote:
On 10/16/18 6:57 PM, James Greenhalgh wrote:
On Mon, Oct 08, 2018 at 05:34:52AM -0500, Martin Liška wrote:
Hi.
I'm attaching updated version of the patch.
Can't
On Wed, 24 Oct 2018, Martin Sebor wrote:
> On 10/24/2018 06:22 AM, Joseph Myers wrote:
> > On Wed, 24 Oct 2018, Martin Sebor wrote:
> >
> > > But if you do want to avoid the attribute on declarations of
> > > these functions regardless it should be safe to add it after
> > > the declaration in
On Tue, Oct 23, 2018 at 4:59 AM Martin Liška wrote:
> However, I still see some minor ICEs, it's probably related to
> decay_conversion in cp_fname_init:
>
> 1) ./xg++ -B.
> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-__func__2.C
>
>
On 10/24/2018 06:24 AM, Joseph Myers wrote:
On Wed, 24 Oct 2018, Martin Sebor wrote:
/* The compiler will optimize based on the knowledge the parameter is
not NULL. This will omit tests. A robust implementation cannot allow
this so when compiling glibc itself we ignore this attribute.
Hi,
The following patch adds a new builtin function for rx ( __builtin_rx_bset)
to make it possible for the user to use BSET whenever necessary.
Please note this builtin function is dedicated only for the variant 32 bit
variant of BSET (when destination is a register).
For the 8 bit variant
On 10/24/2018 10:39 AM, David Malcolm wrote:
On Tue, 2018-10-23 at 18:49 -0600, Martin Sebor wrote:
On 10/23/2018 02:42 PM, David Malcolm wrote:
I want to move material from
https://gcc.gnu.org/wiki/DiagnosticsGuidelines
into the new User Experience Guidelines chapter of our internals
On Tue, 2018-10-23 at 18:49 -0600, Martin Sebor wrote:
> On 10/23/2018 02:42 PM, David Malcolm wrote:
> > I want to move material from
> > https://gcc.gnu.org/wiki/DiagnosticsGuidelines
> > into the new User Experience Guidelines chapter of our internals
> > documentation. I've already update
On Wed, Oct 24, 2018 at 02:27:07PM +0200, Richard Biener wrote:
> If vec_sel is really a bitwise merge then there's no choice but using
> BIT_{AND,IOR,NOT}_EXPR for open-coding it. I suppose the
> original builtin expanded to an UNSPEC because there's nothing
> in RTL besides bitwise operations
On Wed, Oct 24, 2018 at 12:30 PM wrote:
>
> Thanks for the detailed response.
> Sorry to give only a partial reply.
>
> On Tue, Oct 23, 2018 at 02:36:57PM +0100, Richard Earnshaw (lists) wrote:
> > Thanks for posting this. Before we can commit it, however, we need to
> > sort out the authorship
On 10/24/2018 06:22 AM, Joseph Myers wrote:
On Wed, 24 Oct 2018, Martin Sebor wrote:
But if you do want to avoid the attribute on declarations of
these functions regardless it should be safe to add it after
the declaration in the .c file, like so:
__hidden_ver1 (strcmp, __GI_strcmp,
On 10/24/18 4:26 PM, Sam Tebbs wrote:
> On 10/05/2018 01:11 PM, Sam Tebbs wrote:
>
>> Hi all,
>>
>> I recently found what seems to be an error in the options documentation
>> (gcc/doc/options.texi) where a list describing how _var_ is set (referring to
>> the Var attribute) is written beneath the
Bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2018-10-24 Richard Biener
* tree-ssa-sccvn.c (do_rpo_vn): Free rpo_state.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 265463)
On 10/05/2018 01:11 PM, Sam Tebbs wrote:
> Hi all,
>
> I recently found what seems to be an error in the options documentation
> (gcc/doc/options.texi) where a list describing how _var_ is set (referring to
> the Var attribute) is written beneath the _Deprecated_ attribute instead. This
> patch
Hi,
This patch addresses Segher's findings, and also replaces usages of the
deprecated function vec_vcmpgtfp with the equivalent vec_cmpgt.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Also tested in a Clang environment with no regressions. Is this ok for
trunk?
Thanks!
lyze_slp_instance): Adjust.
(vect_schedule_slp_instance): Add short-cut.
* g++.dg/vect/slp-pr87105.cc: Adjust.
* gcc.dg/torture/20181024-1.c: New testcase.
diff --git a/gcc/testsuite/g++.dg/vect/slp-pr87105.cc
b/gcc/testsuite/g++.dg/vect/slp-pr87105.cc
index 1023d915201..9
On Wed, 24 Oct 2018, Jiri Kosina wrote:
> On Tue, 23 Oct 2018, Nicolai Stange wrote:
>
> > let me summarize some results from performance comparisons of Linux
> > kernels compiled with and without certain IPA optimizations.
>
> Thanks a lot for the summary.
>
> So, would it make sense to
On Tue, 23 Oct 2018, Nicolai Stange wrote:
> let me summarize some results from performance comparisons of Linux
> kernels compiled with and without certain IPA optimizations.
Thanks a lot for the summary.
So, would it make sense to submit a patch upstream (with exactly this
justification /
On Wed, Oct 24, 2018 at 3:34 PM Martin Liška wrote:
>
> On 10/23/18 1:19 PM, Richard Biener wrote:
> > On Tue, Oct 23, 2018 at 10:59 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> I've returned to this long-lasting issue after quite some time. Thanks to
> >> Honza I hope
> >> I can now address
On 10/23/18 1:19 PM, Richard Biener wrote:
> On Tue, Oct 23, 2018 at 10:59 AM Martin Liška wrote:
>>
>> Hi.
>>
>> I've returned to this long-lasting issue after quite some time. Thanks to
>> Honza I hope
>> I can now address the root cause which caused output of a string constant
>> when debug
_P () check.
>
> gcc/testsuite/ChangeLog:
>
> 2018-10-24 Ilya Leoshkevich
>
> * gcc.target/s390/20181024-1.c: New test.
That seems to have fixed things. My crosses at least are building again.
jeff
Between 20181022 (r265393) and 20181023 (r265430), gcc.dg/pr78973-2.c
began to XPASS on a large number of targets:
+XPASS: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16)
The following patch fixes this by removing the xfail on dg-warning.
Tested on i386-pc-solaris2.11,
This patch adds a pass that versions loops with variable index strides
for the case in which the stride is 1. E.g.:
for (int i = 0; i < n; ++i)
x[i * stride] = ...;
becomes:
if (stepx == 1)
for (int i = 0; i < n; ++i)
x[i] = ...;
else
for (int i = 0; i <
Hi Maxim,
short after the initial commit there came two more fix-ups in the same function:
$ svn log -r263896
r263896 | law | 2018-08-27 22:31:14 +0200 (Mon, 27 Aug 2018) | 4 lines
* tree-ssa-dse.c (compute_trims):
On 24/10/2018 12:29, co...@sdf.org wrote:
>>> +/* Default to full VFP if -mhard-float is specified. */
>>> +#undef SUBTARGET_ASM_FLOAT_SPEC
>>> +#define SUBTARGET_ASM_FLOAT_SPEC \
>>> + "%{mhard-float:%{!mfpu=*:-mfpu=vfp}} \
>>> + %{mfloat-abi=hard:%{!mfpu=*:-mfpu=vfp}}"
>>
>> Please
On Tue, 23 Oct 2018, Qing Zhao wrote:
>
> > On Oct 23, 2018, at 4:11 AM, Miroslav Benes wrote:
> >>
> >> One question here, what’s the major benefit to prepare the patches
> >> manually?
> >
> > I could almost quote what you wrote below. It is a C file, easy to review
> > and maintain.
On Tue, Oct 23, 2018 at 5:01 PM Martin Liška wrote:
>
> On 10/23/18 12:20 PM, Richard Biener wrote:
> > On Tue, Oct 23, 2018 at 10:37 AM Martin Liška wrote:
> >>
> >> On 10/22/18 4:25 PM, Jakub Jelinek wrote:
> >>> On Mon, Oct 22, 2018 at 04:08:53PM +0200, Martin Liška wrote:
> Very valid
On Tue, Oct 23, 2018 at 11:47 PM Will Schmidt wrote:
>
> Hi all,
> I've been attempting to get early gimple-folding to work with the
> vec_sel intrinsic for powerpc, and I've run into a snag or two such that
> I'm not sure how to best proceed. Code snippet is below, followed by a
> description
On Wed, 24 Oct 2018, Martin Sebor wrote:
> /* The compiler will optimize based on the knowledge the parameter is
>not NULL. This will omit tests. A robust implementation cannot allow
>this so when compiling glibc itself we ignore this attribute. */
> # undef __nonnull
> # define
On Wed, 24 Oct 2018, Martin Sebor wrote:
> But if you do want to avoid the attribute on declarations of
> these functions regardless it should be safe to add it after
> the declaration in the .c file, like so:
>
> __hidden_ver1 (strcmp, __GI_strcmp, __redirect_strcmp)
> __attribute__
_P () check.
>
> gcc/testsuite/ChangeLog:
>
> 2018-10-24 Ilya Leoshkevich
>
> * gcc.target/s390/20181024-1.c: New test.
Ok. Thanks!
Andreas
Thanks for the detailed response.
Sorry to give only a partial reply.
On Tue, Oct 23, 2018 at 02:36:57PM +0100, Richard Earnshaw (lists) wrote:
> Thanks for posting this. Before we can commit it, however, we need to
> sort out the authorship and ensure that all the appropriate copyright
>
MBOL_REF_P (), which was not
added to the new code.
gcc/ChangeLog:
2018-10-24 Ilya Leoshkevich
* config/s390/s390.c (s390_check_qrst_address): Add the missing
SYMBOL_REF_P () check.
gcc/testsuite/ChangeLog:
2018-10-24 Ilya Leoshkevich
* gcc.target/s390/20181024-1.c
It's the test case that is miscompiled.
$ cat nested_struct.c
#include
typedef struct cls_struct_16byte1 {
double a;
float b;
int c;
} cls_struct_16byte1;
typedef struct cls_struct_16byte2 {
int ii;
double dd;
float ff;
} cls_struct_16byte2;
typedef struct cls_struct_combined {
The following fixes data ref analysis giving up forming group accesses
when it encounters duplicates. This most happens during BB vectorization
when inside a single BB two store groups are separated by a stmt that
prevents DSE (or CSE for loads) of duplicates. This is what we for
example see
On 10/23/18 6:31 PM, Martin Sebor wrote:
> On 10/22/2018 07:05 AM, Martin Liška wrote:
>> On 10/16/18 6:57 PM, James Greenhalgh wrote:
>>> On Mon, Oct 08, 2018 at 05:34:52AM -0500, Martin Liška wrote:
Hi.
I'm attaching updated version of the patch.
>>>
>>> Can't say I'm thrilled by
PR complains that we fail to set restrict info on asm operands (and
call arguments and results). The following fixes this.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-10-24 Richard Biener
PR tree-optimization/84013
* tree-ssa-structalias.c
On Wed, 24 Oct 2018, Rainer Orth wrote:
> Hi Eric,
>
> >> I know: a patch to fix this is almost ready, just needs a final round of
> >> testing.
> >
> > OK, thanks for the information.
>
> here's what I've got. It took me two false starts, unfortunately:
>
> * Initially, I just tried linking
Please hold on for the reviews, found a small improvement that could
be done. Am testing it right now, should have something by tonight or
tomorrow.
Best regards,
Thomas
On Tue, 23 Oct 2018 at 13:35, Thomas Preudhomme
wrote:
>
> [Removing Jeff Law since middle end code hasn't changed]
>
> Hi,
>
Hi Eric,
>> I know: a patch to fix this is almost ready, just needs a final round of
>> testing.
>
> OK, thanks for the information.
here's what I've got. It took me two false starts, unfortunately:
* Initially, I just tried linking with LD_OPTIONS='-z nocompstrtab':
-z nocompstrtab
On Wed, 24 Oct 2018 at 00:26, Segher Boessenkool
wrote:
>
> Hi Christophe,
>
> On Tue, Oct 23, 2018 at 03:25:55PM +0200, Christophe Lyon wrote:
> > On Tue, 23 Oct 2018 at 14:29, Segher Boessenkool
> > wrote:
> > > On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
> > > > I have
On Tue, Oct 23, 2018 at 09:45:13PM -0400, Ed Smith-Rowland wrote:
> Greetings,
>
> This is an almost trivial patch to get the correct sign for tgammaq.
Doesn't look trivial to me. What happens if x is a NaN? Or if x is outside
of the range of int?
Generally, libquadmath follows what glibc
Hi:
>
> I have noticed many regressions on arm and aarch64 between 265366 and
> 265408 (this commit is 265398).
>
There are many regressions on mips64el between 265378 and 265420.
r265378 testresults:
https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02935.html
r265420 testresults:
67 matches
Mail list logo
