Hi!
On Wed, Nov 06, 2019 at 06:21:34PM +0100, Egeyar Bagcioglu wrote:
> +static const char *
> +record_gcc_command_line_spec_function(int argc ATTRIBUTE_UNUSED, const char
> **argv)
> +{
> + const char *filename = argv[0];
> + FILE *out = fopen (filename, "w");
> + if (out)
> +{
> + f
Hi!
TYPE_EMPTY_P arguments (which right now only x86_64 uses) have
data->entry_parm == data->stack_parm being a stack slot with zero size in
the stack parameter passing area.
The problem with that is that in C++ they should have distinct addresses
from other objects, which is not the case right no
Hi.
The patch makes mklog more robust for a line in patch:
'---param=foo=bar xyz'.
I'm going to install it if there are no objections.
Martin
contrib/ChangeLog:
2019-11-07 Martin Liska
* mklog: The script fails for patches that contain:
'---param=foo=bar xyz'.
---
contrib/
On 11/6/19 6:21 PM, Egeyar Bagcioglu wrote:
Hello,
Hello.
I would like to propose the following patches which introduce a compile option
--record-gcc-command-line. When passed to gcc, it saves the command line option
into the produced object file. The option makes it trivial to trace back
+ adding the author of Annobin to the email thread
On 11/7/19 10:24 AM, Martin Liška wrote:
a) it does not print per function options, which can be modified with
__attribute__ (or pragma):
Compiler is aware of the information (and uses it in inlining (or ICF) for
instance):
cl_optimizatio
Hi.
There's updated version of the merge.sh which is simplified
and only redirected to the new git repository.
I'm going to install the series.
Thanks,
Martin
>From 6aa47fc1eebc512ef8f821bd407978faec3bb0e0 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 5 Nov 2019 19:06:34 +0100
Subject:
On Wed, Nov 6, 2019 at 4:58 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Nov 5, 2019 at 3:27 PM Richard Sandiford
> > wrote:
> >>
> >> vectorizable_assignment handles true SSA-to-SSA copies (which hopefully
> >> we don't see in practice) and no-op conversions that are requi
On Wed, Nov 6, 2019 at 5:06 PM Richard Sandiford
wrote:
>
> The gather and scatter optabs required the vector offset to be
> the integer equivalent of the vector mode being loaded or stored.
> This patch generalises them so that the two vectors can have different
> element sizes, although they sti
Hello.
I've noticed quite some GNU coding style violations with your patch.
Please next time, use something like:
$ git diff HEAD~ > /tmp/patch && ./contrib/check_GNU_style.py /tmp/patch
Thanks,
Martin
On Thu, Nov 7, 2019 at 7:58 AM Hongtao Liu wrote:
>
> Ping!
OK.
Thanks,
Richard.
> On Sat, Nov 2, 2019 at 9:38 PM Hongtao Liu wrote:
> >
> > Hi Jakub:
> > Could you help reviewing this patch.
> >
> > PS: Since this patch is related to vectors(avx512f), and Uros
> > mentioned before that he h
Hi,
this patch implements the OpenACC 2.6 "serial" construct.
It has been tested by running the testsuite with nvptx-none
offloading on x86_64-pc-linux-gnu.
Best regards,
Frederik
8< ---
The `serial' construct (cf. section 2.5.3 of the OpenACC 2.6 standa
Hi Segher,
on 2019/11/7 上午7:49, Segher Boessenkool wrote:
>
> The expander named "one_cmpl3":
>
> Erm. 2, not 3 :-)
>
> (define_expand "one_cmpl2"
> [(set (match_operand:BOOL_128 0 "vlogical_operand")
> (not:BOOL_128 (match_operand:BOOL_128 1 "vlogical_operand")))]
> ""
> "")
>
Hi all,
This patch adds the plumbing for and an implementation of the saturation
intrinsics from ACLE [1], in particular the __ssat, __usat intrinsics.
These intrinsics set the Q sticky bit in APSR if an overflow occurred.
ACLE allows the user to read that bit (within the same function, it's not
Hi all,
This patch implements some more Q-setting intrinsics form the SMLA* group.
These can set the saturation bit on overflow in the accumulation step.
Like earlier, these have non-Q-setting RTL forms as well for when the
Q-bit read
is not needed.
Bootstrapped and tested on arm-none-linux-gn
Hi all,
This patch implements some more Q-bit-setting intrinsics from ACLE.
With the plumbing from patch 1 in place they are a simple builtin->RTL
affair.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Committing to trunk.
Thanks,
Kyrill
2019-11-07 Kyrylo Tkachov
* config/arm/a
Hi all,
This last patch adds the the __ssat16 and __usat16 intrinsics that perform
"clipping" to a particular bitwidth on packed SIMD values, setting the Q bit
as appropriate.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Committing to trunk.
Thanks,
Kyrill
2019-11-07 Kyrylo Tkachov
Hi all,
This patch implements some more Q-setting intrinsics of the
multiply-accumulate
variety, but these are in the SIMD32 family in that they treat their
operands
as packed SIMD values, but that's not important at the RTL level.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Committ
Hi all,
This patch adds in plumbing for the ACLE intrinsics that set the GE bits in
APSR. These are special SIMD instructions in Armv6 that pack bytes or
halfwords into the 32-bit general-purpose registers and set the GE bits in
APSR to indicate if some of the "lanes" of the result have overflow
Thinking about the patch over night, I have now updated it a bit:
Namely, I only add the "if(present-check)" condition, if the original
variable is dereferenced. There is no need for code like
omp_data_arr.c = c == NULL ? NULL : c;
and then, after the libgomp call, code like "c_2 = c == NULL
The AArch64 port defines built-in SVE types at start-up under names
like __SVInt8_t. These types are represented in the front end and
gimple as normal VECTOR_TYPEs and are code-generated as normal vectors.
However, we'd like to stop the frontends from treating them in the
same way as GNU-style ("v
On Nov 7, 2019, Richard Biener wrote:
> A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
> to the LTRANS lto1 invocation plus -dumpbase cc...o
This -auxbase-strip argument is introduced by the gcc driver that runs
lto1, based on the -o (tmp ltrans .o) argument, but this dri
Hi
On Mon, Nov 04 2019, Richard Biener wrote:
> On Fri, 1 Nov 2019, Martin Jambor wrote:
>
>> Hi,
>>
>> I have spent some more time looking into PR 70929, how
>> gimple_check_call_matching_types behaves when LTO-building Firefox to
>> see what could replace it or if we perhaps could remove it.
>>
On Nov 6, 2019, Thomas Schwinge wrote:
>> which is a valid VCG file (you can launch your favorite VCG
>> viewer on it unmodified)
> What should be my "favorite VCG viewer"?
-ENOCLUE, I'm afraid. I honestly don't even know which one Eric used
back when he first attempted to contribute this fea
Bootstrapped & tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-07 Richard Biener
PR tree-optimization/92405
* tree-vect-loop.c (vectorizable_reduction): Appropriately
restrict lane-reducing ops to single stmt chains.
Index: gcc/tree-vect-loop.c
===
On Thu, 7 Nov 2019, Alexandre Oliva wrote:
> On Nov 7, 2019, Richard Biener wrote:
>
> > A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
> > to the LTRANS lto1 invocation plus -dumpbase cc...o
>
> This -auxbase-strip argument is introduced by the gcc driver that runs
> lt
The RTXs used to express an overflow condition check in add/sub/mul are
too complex for if conversion. However, there is code in
noce_emit_store_flag which generates a simple CC compare as the base
for using a conditional load. All we have to do is to provide a
pattern to store the truth value of
Hi,
PR92351 reports a bug in which a wrongly aligned load is generated for
an epilogue of a main loop for which we peeled for alignment. There is
no way to guarantee that epilogue data accesses are aligned when the
main loop is peeling for alignment.
I also had to split vect-peel-2.c as the
On Nov 7, 2019, Richard Biener wrote:
> So how's -dumpbase handled?
It's part of the gcc driver interface, and lto-wrapper passes it to gcc
for -fltrans compilations. -auxbase isn't, so one of the alternatives I
suggested involved our taking auxbase from dumpdir & dumpbase for
-fltrans compila
gcc/ChangeLog:
2019-11-06 Martin Liska
* common.opt: Remove --param and --param= options.
* opt-functions.awk: Mark CL_PARAMS for options
that have Param keyword.
* opts-common.c (decode_cmdline_options_to_array):
Replace --param key=value with --param=
The email thread is follow up of a demo that I made here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02220.html
The patchset converts current param infrastructure to
the option machinery. The parts 3 and 4 are quite
mechanical.
I would appreciate a feedback about what parameters
should be per
gcc/ChangeLog:
2019-11-06 Martin Liska
* Makefile.in: Include params.opt.
* flag-types.h (enum parloops_schedule_type): Add
parloops_schedule_type used in params.opt.
* params.opt: New file.
---
gcc/Makefile.in | 2 +-
gcc/flag-types.h | 11 +
gcc/params.o
gcc/ChangeLog:
2019-11-06 Martin Liska
* common.opt: Remove param_values.
* config/i386/i386-options.c (ix86_valid_target_attribute_p):
Remove finalize_options_struct.
* gcc.c (driver::decode_argv): Do not call global_init_params
and finish_params.
gcc/ChangeLog:
2019-11-06 Martin Liska
* common/common-target.def:
Do not mention set_default_param_value
and set_param_value.
* doc/tm.texi: Likewise.
---
gcc/common/common-target.def | 6 ++
gcc/doc/tm.texi | 4 ++--
2 files changed, 4 inser
gcc/testsuite/ChangeLog:
2019-11-06 Martin Liska
* gcc.dg/completion-3.c: Append = to all expected
results and sort expected output.
* gcc.dg/pr83620.c: Update error message.
* gcc.dg/spellcheck-params-2.c: Likewise.
* gcc.dg/spellcheck-params.c: Likewi
Am 07.11.19 um 10:41 schrieb Martin Liška:
Hello.
I've noticed quite some GNU coding style violations with your patch.
Please next time, use something like:
$ git diff HEAD~ > /tmp/patch && ./contrib/check_GNU_style.py /tmp/patch
Thanks,
Martin
hm, I am actually using GNU style with Emacs..
On 05/11/2019 18:42, Joseph Myers wrote:
> On Tue, 5 Nov 2019, Szabolcs Nagy wrote:
>> GCC currently supports two ways to declare the availability of vector
>> variants of a scalar function:
>>
>> #pragma omp declare simd
>> void f (void);
>>
>> and
>>
>> __attribute__ ((simd))
>> void f (v
On 05/11/2019 13:11, Andrey Konovalov wrote:
> On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson
> wrote:
>>
>> NOTE:
>> --
>> I have defined a new macro of __SANITIZE_HWADDRESS__ that gets
>> automatically defined when compiling with hwasan. This is analogous to
>> __SANITIZE_ADDRESS__ which
On 11/7/19 1:39 PM, Georg-Johann Lay wrote:
Am 07.11.19 um 10:41 schrieb Martin Liška:
Hello.
I've noticed quite some GNU coding style violations with your patch.
Please next time, use something like:
$ git diff HEAD~ > /tmp/patch && ./contrib/check_GNU_style.py /tmp/patch
Thanks,
Martin
h
Am 07.11.19 um 13:49 schrieb Martin Liška:
On 11/7/19 1:39 PM, Georg-Johann Lay wrote:
Am 07.11.19 um 10:41 schrieb Martin Liška:
Hello.
I've noticed quite some GNU coding style violations with your patch.
Please next time, use something like:
$ git diff HEAD~ > /tmp/patch && ./contrib/check_
Hi,
as every year, I went through reasons why types of same ODR name are not
merged in firefox streaming. Here are few problems I caught. Remaining
issues I understand are
1) odr violations (which is OK of course)
2) keyed vtables: sometimes the vtable decl is weak and sometimes it is
exter
Hi Kyrill,
I have rebased the patch on top of current truck.
For resolve_overloaded, I redefined my memtag overloading function to
fit the latest resolve_overloaded_builtin interface.
Regression tested again and survived for aarch64-none-linux-gnu.
Cheers
Dennis
Changelog is updated as followi
On Thu, 7 Nov 2019, Andre Vieira (lists) wrote:
> Hi,
>
> PR92351 reports a bug in which a wrongly aligned load is generated for an
> epilogue of a main loop for which we peeled for alignment. There is no way to
> guarantee that epilogue data accesses are aligned when the main loop is
> peeling
On Thu, 7 Nov 2019, Alexandre Oliva wrote:
> On Nov 7, 2019, Richard Biener wrote:
>
> > So how's -dumpbase handled?
>
> It's part of the gcc driver interface, and lto-wrapper passes it to gcc
> for -fltrans compilations. -auxbase isn't, so one of the alternatives I
> suggested involved our t
Hi,
Rebased the patch on top of Richard Sandiford's patches, with his fixes
I can now allow for vectorization of epilogues after we match simdlen.
This will however not turn on epilogue vectorization in cases where we
specify a desired simdlen that is never matched. This would require
more w
On Thu, Nov 07, 2019 at 02:26:29PM +, Andre Vieira (lists) wrote:
> 2019-11-07 Andre Vieira
>
> * tree-vect-loop.c (vect_analyze_loop): Disable epilogue
> vectorization for loops with SIMDUID set. Enable epilogue
> vectorization for loops with SIMDLEN set after find
On 07/11/2019 14:00, Richard Biener wrote:
On Thu, 7 Nov 2019, Andre Vieira (lists) wrote:
Hi,
PR92351 reports a bug in which a wrongly aligned load is generated for an
epilogue of a main loop for which we peeled for alignment. There is no way to
guarantee that epilogue data accesses are a
Jiufu Guo writes:
Hi Sehger,
I updated the patch as we discussed. This patch does not turn on -fweb
or -frename-registers with -funroll-loops for powerpc.
Thanks for review in advance.
gcc/
2019-11-07 Jiufu Guo
PR tree-optimization/88760
* gcc/config/rs6000/rs6000.opt (-mu
On 11/7/19 10:24 AM, Martin Liška wrote:
On 11/6/19 6:21 PM, Egeyar Bagcioglu wrote:
Hello,
Hello.
Thanks for your detailed reply Martin. You'll find my reply inline.
Since you added Nick Clifton to your following reply, I am adding him to
this email too. He is not only the author of anno
Hi Egeyar,
Thanks for including me in this discussion.
>>> This option is similar to -frecord-gcc-switches.
For the record I will also note that there is -fverbose-asm which
does almost the same thing, but only records the options as comments
in the assembler. They are never converted into data
Richard Biener writes:
> On Tue, Nov 5, 2019 at 3:25 PM Richard Sandiford
> wrote:
>>
>> This patch makes two tweaks to vectorizable_conversion. The first
>> is to use "modifier" to distinguish between promotion, demotion,
>> and neither promotion nor demotion, rather than using a code for
>> so
On Thu, Nov 07, 2019 at 12:00:32PM +0100, Martin Jambor wrote:
> 2019-11-07 Martin Jambor
>
> PR lto/70929
> * cif-code.def (MISMATCHED_ARGUMENTS): Removed.
> * cgraph.h (gimple_check_call_matching_types): Remove
> * cgraph.c (gimple_check_call_args): Likewise.
> (
Hi!
The following patch adds handling of clobbers in store-merging. The intent
is if we have a clobber followed by some stores into the clobbered area,
even if don't store all the bytes in the area, we can avoid masking, because
the non-stored bytes are undefined and in some cases we can even ove
Hi!
GCC does use UTF-16 and UTF-32 for char16_t and char32_t string literals
already, so P1041R4 is I believe already implemented with no changes needed.
While going through P1139R2, I've realized that we weren't handling
"If the value is not representable within 16 bits, the program is ill-forme
On Thu, Nov 7, 2019 at 1:48 PM Matthew Malcomson
wrote:
>
> On 05/11/2019 13:11, Andrey Konovalov wrote:
> > On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson
> > wrote:
> >>
> >> NOTE:
> >> --
> >> I have defined a new macro of __SANITIZE_HWADDRESS__ that gets
> >> automatically defined when
On November 7, 2019 4:14:14 PM GMT+01:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On Tue, Nov 5, 2019 at 3:25 PM Richard Sandiford
>> wrote:
>>>
>>> This patch makes two tweaks to vectorizable_conversion. The first
>>> is to use "modifier" to distinguish between promotion, demotion
Hello,
About a year ago we discussed various possibilities regarding
an issue with the aarch64 selection of r18 as the static chain,
problematic in environments where the OS uses r18 for "private"
reasons. VxWorks uses this permission to use r18 as a pointer to
the current TCB, and Windows does so
On 11/7/19 4:13 PM, Nick Clifton wrote:
Hi Egeyar,
Thanks for including me in this discussion.
This option is similar to -frecord-gcc-switches.
For the record I will also note that there is -fverbose-asm which
does almost the same thing, but only records the options as comments
in the asse
Hi Segher!
On 11/7/19 8:47 AM, Segher Boessenkool wrote:
Hi!
On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
gcc/testsuite/ChangeLog:
2019-11-06 Egeyar Bagcioglu
* lib/target-supports-dg.exp: Define dg-require-target-object-format.
* lib/target-supports-dg.exp
Richard Biener writes:
> On Wed, Nov 6, 2019 at 4:58 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Nov 5, 2019 at 3:27 PM Richard Sandiford
>> > wrote:
>> >>
>> >> vectorizable_assignment handles true SSA-to-SSA copies (which hopefully
>> >> we don't see in practice) a
On 01.11.2019. 11:32, Dragan Mladjenovic wrote:
> On 10.08.2019. 00:15, Joseph Myers wrote:
>> On Fri, 9 Aug 2019, Jeff Law wrote:
>>
2019-08-05 Dragan Mladjenovic
* config.in: Regenerated.
* config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define to 1
for TAR
Shortly after I finished implementing the previous <=> semantics, the
committee decided to remove the *_equality comparison categories, because
they were largely obsoleted by the earlier change that separated operator==
from its original dependency on operator<=>.
Tested x86_64-pc-linux-gnu, apply
Richard Biener writes:
> On Wed, Nov 6, 2019 at 3:01 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Nov 5, 2019 at 3:29 PM Richard Sandiford
>> > wrote:
>> >>
>> >> This patch adds a mode in which the vectoriser tries each available
>> >> base vector mode and picks the
On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
>> gcc/testsuite/ChangeLog:
>> 2019-11-06 Egeyar Bagcioglu
>>
>> * lib/target-supports-dg.exp: Define
dg-require-target-object-
On 11/7/19 6:17 PM, jose.march...@oracle.com wrote:
On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
>> gcc/testsuite/ChangeLog:
>> 2019-11-06 Egeyar Bagcioglu
>>
>>
Hello
On AMD GCN, I encountered the following situation in the following
testcases using the compilation flags '-O2 -ftracer -fsplit-paths':
libgomp.oacc-fortran/reduction-1.f90
libgomp.oacc-fortran/reduction-2.f90
libgomp.oacc-fortran/reduction-3.f90
gcc.c-torture/execute/ieee/pr50310.c
- LR
Hello again Segher!
On 11/7/19 9:03 AM, Segher Boessenkool wrote:
Hi!
On Wed, Nov 06, 2019 at 06:21:34PM +0100, Egeyar Bagcioglu wrote:
+static const char *
+record_gcc_command_line_spec_function(int argc ATTRIBUTE_UNUSED, const char
**argv)
+{
+ const char *filename = argv[0];
+ FILE *out
Clang has a function level attribute,
__attribute__((no_sanitize("hwaddress")))
a feature macro
#if __has_feature(hwaddress_sanitizer)
and a blacklist section
[hwaddress]
https://clang.llvm.org/docs/SanitizerSpecialCaseList.html
I think it makes sense for the compiler to err on the side of
I have rebased this series onto Martin Liska's patches that take the most
recent libhwasan from upstream LLVM.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
I've also cleared up some nomenclature (I had previously used the word 'colour'
a few times instead of the word 'tag' and that cla
Though the library has limited support for x86, we don't have any
support for generating code targeting x86 so there is no point building
for that target.
libsanitizer/ChangeLog:
2019-11-07 Matthew Malcomson
* Makefile.am: Condition building hwasan directory.
* Makefile.in: Re
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HWASAN
sanitizer when compiling libiberty and the lto-plugin.
Also add a function to query whether -fsanitize=hwaddress has been
pas
This patch does tries to tie libhwasan into the GCC build system in the
same way that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
2019-11-07 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan/Makefi
These flags can't be used at the same time as any of the other
sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
The -fsanitize=kernel-hwaddress option is for compiling targeting the
kernel. This flag has defaults that allow compiling KASAN wi
There are four main features to this change:
1) Check pointer tags match address tags.
In the new `hwasan` pass we put HWASAN_CHECK internal functions around
all memory accesses, to check that tags in the pointer being used match
the tag stored in shadow memory for the memory region being used.
Handling stack variables has three features.
1) Ensure HWASAN required alignment for stack variables
When tagging shadow memory, we need to ensure that each tag granule is
only used by one variable at a time.
This is done by ensuring that each tagged variable is aligned to the tag
granule repres
Adding hwasan tests.
Frankly, these could be tidied up a little.
I will be tidying them up while getting feedback on the hwasan introduction.
gcc/testsuite/ChangeLog:
2019-11-07 Matthew Malcomson
* c-c++-common/hwasan/arguments.c: New test.
* c-c++-common/hwasan/halt_on_erro
Hi!
On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote:
> On 11/7/19 9:03 AM, Segher Boessenkool wrote:
> >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length);
> >>+}
> >>+ cmdline[0] = 0;
> >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, 1);
> >>+
> >>+ /* The return val
Before, LRA, we have an insn that sets a TImode pseudo with an integer
constant and a following insn that copies that TImode pseudo to a PTImode
pseudo. During LRA spilling, we generate a new insn that sets a PTImode
pseudo to that constant directly and we ICE because we do not recognize
that as a
From what I understood from recent fix the unordered containers need to
be updated the same way.
I hope you'll appreciate the usage of rvalue forwarding. Containers node
values are moved as soon as _M_assign is called with a rvalue reference
to the source container.
Additionnaly this patch r
OK.
On 11/7/19 3:38 PM, Jakub Jelinek wrote:
Hi!
GCC does use UTF-16 and UTF-32 for char16_t and char32_t string literals
already, so P1041R4 is I believe already implemented with no changes needed.
While going through P1139R2, I've realized that we weren't handling
"If the value is not repres
This fixes the gfortran.dg/continuation_6.f fails testsuite fails with
newer GLIBC.
The continuation line handling assumes that the line number starts at 0
(→ continue_line) and then can be incremented, if needed.
The problem came up with -pre_include, which is used with newer GLIBC to
provi
This test uses -masm=intel, which isn't supported by Darwin, so add the
necessary dg-require-effective-target.
tested on x86_64-darwin16,
applied as obvious to mainline,
thanks
Iain
gcc/testsuite/ChangeLog:
2019-11-07 Iain Sandoe
* gcc.target/i386/pr92258.c: Add dg-requires for mas
When building small programs for MSP430, the impact of the unused
functions pulled in from the CRT libraries is quite noticeable. Most of these
relates to feature that will never be used for MSP430 (Transactional memory,
supporting shared objects and dynamic linking), or rarely used (exception
hand
Given that MSP430 is a resource constrained, embedded target disabling
transactional memory by default is a good idea to save on code size in
the runtime library.
It can still be enabled by passing --enable-tm-clone-registry (although as far
as I understand the feature is fundamentally incompatibl
The code size bloat added by building C++ programs using libraries containing
support for exceptions is significant. When using simple constructs such as
static variables, sometimes many kB from the libraries are unnecessarily
pulled in.
So this patch disable exceptions by default for MSP430 when
The MSP430 target does not need to support dynamic shared objects so
__cxa_atexit does not need to be used - atexit is sufficient.
Newlib atexit is a fine replacement as it also supports registration of more
than 32 functions.
By not using __cxa_atexit, we can define TARGET_LIBGCC_REMOVE_DSO_HAND
Support for the MSP430 -minrt option has been removed from Newlib, since all the
associated behaviour is now dynamic. Initialization code run before main is only
included when needed.
This patch removes the final traces of -minrt from GCC.
-minrt used to modify the linking process in the followin
On Wed, Nov 06, 2019 at 10:46:06AM -0700, Jeff Law wrote:
> BTW, I think there's enough overlap between simplify-rtx and combine
> that if you wanted to maintain simplify-rtx as well that I'd fully
> support it. Thoughts?
I'd be honoured, thanks for the offer!
Segher
On Thu, Nov 07, 2019 at 11:22:12AM +0800, Kewen.Lin wrote:
> One updated patch to enable it everywhere attached.
> 2019-11-07 Kewen Lin
>
> * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Make
> scalar_load, vector_load, unaligned_load and vector_gather_load cost
>
On Nov 7, 2019, Richard Biener wrote:
> (also raises the question why we have both -dumpbase and -auxbase ...)
https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
This was before -dumpdir, however.
Here's the current logic for aux_base_name:
-c or -S with -o [odir/]obase.oext: [odir/]ob
On 11/7/19 7:57 PM, Segher Boessenkool wrote:
Hi!
On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote:
On 11/7/19 9:03 AM, Segher Boessenkool wrote:
+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length);
+}
+ cmdline[0] = 0;
+ ASM_OUTPUT_ASCII(asm_out_file, cmdl
The Library Working Group have approved a change to std::for_each_n that
requires it to handle negative N gracefully, which we were not doing for
random access iterators.
* include/bits/stl_algo.h (for_each_n): Handle negative count.
* testsuite/25_algorithms/for_each/for_each_n_d
Hi!
I've noticed a comment typo in build_vec_delete_1 and when grepping
around if the same typo isn't elsewhere, I found a different typo
elsewhere.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.
2019-11-08 Jakub Jelinek
* ipa-util
On Thu, Nov 07, 2019 at 05:05:16PM +, Jason Merrill wrote:
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C
> @@ -0,0 +1,25 @@
> +// { dg-do run { target c++2a } }
> +
> +#include
> +
> +#define assert(X) do { if (!(X)) __builtin_abort(); } while(0)
> +
> +void f(){}
On Thu, 7 Nov 2019, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
There is one place in the C parser that already handles a subset of
the C2x [[]] attribute syntax: c_parser_transaction_attributes.
This patch factors C2x attribute parsing out of there, extending it to
cover the full C2x attribute syntax (although currently only called
from that one place in the
After the simplify-rtx patch, we can now be asked about conditions we
wouldn't be asked about before. This is perfectly fine, except we
have a little over-eager assert. Remove that one.
I originally had this patch before the simplify-rtx one, but I reordered
them without retesting every step.
Hi!
On Thu, Nov 07, 2019 at 06:17:53PM +0800, Kewen.Lin wrote:
> on 2019/11/7 上午7:49, Segher Boessenkool wrote:
> > The expander named "one_cmpl3":
> >
> > Erm. 2, not 3 :-)
> Ah, sorry I didn't notice we have one cmpl**3** but actually for one
> cmpl**2** expand, a bit surprised. Done. Thank
On Thu, 2019-11-07 at 21:37 +, Jozef Lawrynowicz wrote:
> The code size bloat added by building C++ programs using libraries containing
> support for exceptions is significant. When using simple constructs such as
> static variables, sometimes many kB from the libraries are unnecessarily
> pull
* libsupc++/compare (common_comparison_category)
(common_comparison_category_t): Define for C++20.
* testsuite/18_support/comparisons/common/1.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit cb48e7e6d0bbed9eadc34b4318511f3e05ec1b64
Author: Jonathan Wake
Also process it with Doxygen.
* doc/doxygen/user.cfg.in (INPUT): Add header.
* include/precompiled/stdc++.h: Include header.
Tested powerpc64le-linux, committed to trunk.
commit ed86b7c065df6b33dfee86fba3bee089386ac4a8
Author: Jonathan Wakely
Date: Thu Nov 7 23:20:51 2019 +0
1 - 100 of 107 matches
Mail list logo
