On Wed, 22 Jul 2020, zhoukaipeng (A) wrote:
> Hi,
>
> It is the patch to add "#pragma GCC no_reduc_chain" for pr96053. It
> only completes the front end of C language.
>
> For the testcase, it successfully skipped doing slp by finding sequences
> from reduction chains. Without "#pragma GCC n
Hi Richard,
on 2020/7/22 下午2:38, Richard Biener wrote:
> On Wed, Jul 22, 2020 at 3:26 AM Kewen.Lin wrote:
>>
>> Hi Richard,
>>
>> on 2020/7/21 下午3:57, Richard Biener wrote:
>>> On Tue, Jul 21, 2020 at 7:52 AM Kewen.Lin wrote:
Hi,
This patch is to add the cost modeling for vec
Bootstrap is ok, regression test is ok for i386 backend.
gcc/
PR target/96262
* config/i386/i386-expand.c
(ix86_expand_vec_shift_qihi_constant): Refine.
gcc/testsuite/
* gcc.target/i386/pr96262-1.c: New test.
---
gcc/config/i386/i386-expand.c | 6 +
Hi Martin,
> I have committed this change in r11-2231 after Jeff approved it
> off list last Thursday.
the new gcc.target/i386/memcpy-pr95886.c test FAILs on 32-bit x86
(i386-pc-solaris2.11):
+FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand "const_int
1976943448883713" 1
+FAIL
Hi!
On Wed, Jul 22, 2020 at 09:44:52AM +0800, Kewen.Lin wrote:
> This trivial patch is to rename adjust_vectorization_cost to
> adjust_vect_cost_per_stmt. Hope it's more meaningful, as well
> as to avoid the confusion between the possible to be landed
> function "adjust_vect_cost" and "adjust_ve
Jozef Lawrynowicz writes:
> is_int_mode does not allow MODE_PARTIAL_INT modes, so convert_modes was
> not allowing a constant value to be converted to a MODE_PARTIAL_INT for
> use as operand 2 in patterns such as ashlpsi3. The constant had
> to be copied into a register before it could be used, bu
Hi Martin,
Rainer Orth wrote:
I have committed this change in r11-2231 after Jeff approved it
off list last Thursday.
the new gcc.target/i386/memcpy-pr95886.c test FAILs on 32-bit x86
(i386-pc-solaris2.11):
+FAIL: gcc.target/i386/memcpy-pr95886.c scan-rtl-dump-times expand
"const_int 1976
Jozef Lawrynowicz writes:
> diff --git a/gcc/expmed.c b/gcc/expmed.c
> index e7c03fbf92c..d3a1735d39e 100644
> --- a/gcc/expmed.c
> +++ b/gcc/expmed.c
> @@ -4086,9 +4086,12 @@ expand_sdiv_pow2 (scalar_int_mode mode, rtx op0,
> HOST_WIDE_INT d)
> {
>temp = gen_reg_rtx (mode);
>
Alex Coplan writes:
> Secondly, I wanted to clarify the situation with respect to explicit
> casts; that is, those conversions allowed by gcc_jit_context_new_cast().
> The docs [0] say:
>
> Currently only a limited set of conversions are possible:
> - int <-> float
> - int <-> bool
> - P* <->
[snip...]
> Przemek, if you don't have commit access already, please follow the steps on
> https://gcc.gnu.org/gitwrite.html (happy to sponsor).
Done.
Thank you, Richard, for sponsoring this and all the support!
Kind regards,
Przemek
- Most KASAN function don't need any porting anything in back-end
except asan stack protection.
- However kernel will given shadow offset when enable asan stack
protection, so eveything in KASAN can work if shadow offset is given.
- Verified with x86 and risc-v.
- Verified with RISC-V
Hi Tobias!
On 2020-07-21T17:43:00+0200, Tobias Burnus wrote:
> On 7/21/20 2:18 PM, Jakub Jelinek wrote:
>> [...] shows that we don't really handle critical in such case
>> correctly, because nothing will then try to verify the value after
>> instantiation.
>
> In principle, the compiler is not re
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2020/7/21 下午3:57, Richard Biener wrote:
>> On Tue, Jul 21, 2020 at 7:52 AM Kewen.Lin wrote:
>>>
>>> Hi,
>>>
>>> This patch is to add the cost modeling for vector with length,
>>> it mainly follows what we generate for vector with length in
>>> functions ve
ChangeLog:
2020-07-22 Przemyslaw Wirkus
* MAINTAINERS (Write After Approval): Add myself.
---
diff --git a/MAINTAINERS b/MAINTAINERS
index
d1343d33f1abb4a4bec7deac6c86551b83ecbdf1..300c10edf196d5698ea0fb0f8ee6a8f50a642292
100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -645,6 +645,7
On Wed, Jul 22, 2020 at 11:09:06AM +0200, Thomas Schwinge wrote:
> So I suppose you'll either have to put these testcases into 'libgomp', or
> we'll have to invent something else?
Indeed.
> Jakub, is there a reason why for
> build-tree testing we can't just add '-I[build-tree]/libgomp' etc. in
>
Wei Wentao writes:
> hi,
> This patch fix a typo in languages.texi.
Thanks for the patch, pushed to master.
Richard
>
> Regards!
> weiwt
>
> ---
> gcc/doc/languages.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/doc/languages.texi b/gcc/doc/languages.texi
> i
Hi,
On 2020/7/21 23:30, Richard Sandiford wrote:
> Xiong Hu Luo writes:>> @@ -1872,9 +1872,27 @@
> get_stored_val (store_info *store_info, machine_mode read_mode,
>> {
>> poly_int64 shift = gap * BITS_PER_UNIT;
>> poly_int64 access_size = GET_MODE_SIZE (read_mode) + gap;
>>
On 7/22/20 11:09 AM, Thomas Schwinge wrote:
For build-tree testing, that'll pick up the *system* 'omp.h', thus:
FAIL: c-c++-common/gomp/critical-hint-1.c (test for excess errors)
Excess errors:
[...]/c-c++-common/gomp/critical-hint-1.c:10:33: error:
'omp_sync_hint_none' undeclare
On Wed, Jul 22, 2020 at 11:25:47AM +0200, Tobias Burnus wrote:
> On 7/22/20 11:09 AM, Thomas Schwinge wrote:
>
> > For build-tree testing, that'll pick up the *system* 'omp.h', thus:
> > FAIL: c-c++-common/gomp/critical-hint-1.c (test for excess errors)
> > Excess errors:
> > [...]/
On Wed, Jul 22, 2020 at 11:25:47AM +0200, Tobias Burnus wrote:
> FORTRAN MODULE
> Then I have the question why, e.g., "use openacc_kinds" in
> gfortran.dg/goacc/acc_on_device-2.f95 does work. What's different there?
Because that test defines its own module with that name:
module openacc_kinds
im
On Wed, Jul 22, 2020 at 09:33:47AM +0100, Richard Sandiford wrote:
> Jozef Lawrynowicz writes:
> > is_int_mode does not allow MODE_PARTIAL_INT modes, so convert_modes was
> > not allowing a constant value to be converted to a MODE_PARTIAL_INT for
> > use as operand 2 in patterns such as ashlpsi3.
On Wed, 22 Jul 2020, Kito Cheng wrote:
> - Most KASAN function don't need any porting anything in back-end
>except asan stack protection.
>
> - However kernel will given shadow offset when enable asan stack
>protection, so eveything in KASAN can work if shadow offset is given.
>
> - V
Hi all,
I'd like to submit the following two patches implementing a new AArch64
specific back-end pass that helps optimize branch-dense code, which can
be a bottleneck for performance on some Arm cores. This is achieved by
padding out the branch-dense sections of the instruction stream with
nops.
Hi all,
this second patch implements the AArch64 specific back-end pass
'branch-dilution' controllable by the followings command line options:
-mbranch-dilution
--param=aarch64-branch-dilution-granularity={num}
--param=aarch64-branch-dilution-max-branches={num}
Some cores known to be able to b
On Wed, Jul 22, 2020 at 04:53:00PM +0800, Kito Cheng wrote:
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -344,6 +344,12 @@ asan_shadow_offset ()
>return asan_shadow_offset_value;
> }
>
> +/* Returns Asan shadow offset has been set. */
> +bool asan_shadow_offset_set_p ()
Formatting. Should b
Now moved to libgomp, cf. attachment.
Tobias
On 7/22/20 11:16 AM, Jakub Jelinek wrote:
On Wed, Jul 22, 2020 at 11:09:06AM +0200, Thomas Schwinge wrote:
So I suppose you'll either have to put these testcases into 'libgomp', or
we'll have to invent something else?
Indeed.
Jakub, is there a re
On Wed, Jul 22, 2020 at 3:10 AM Andrea Corallo wrote:
>
> Hi all,
>
> this second patch implements the AArch64 specific back-end pass
> 'branch-dilution' controllable by the followings command line options:
>
> -mbranch-dilution
>
> --param=aarch64-branch-dilution-granularity={num}
>
> --param=aar
luoxhu writes:
> Hi,
>
> On 2020/7/21 23:30, Richard Sandiford wrote:
>> Xiong Hu Luo writes:>> @@ -1872,9 +1872,27 @@
>> get_stored_val (store_info *store_info, machine_mode read_mode,
>>> {
>>> poly_int64 shift = gap * BITS_PER_UNIT;
>>> poly_int64 access_size = GET_MODE_
On Wed, Jul 22, 2020 at 12:03 PM Andrea Corallo wrote:
>
> Hi all,
>
> I'd like to submit the following two patches implementing a new AArch64
> specific back-end pass that helps optimize branch-dense code, which can
> be a bottleneck for performance on some Arm cores. This is achieved by
> paddi
Hello
This test currently fails because some expected 'optimized: assigned OpenACC seq
loop parallelism' messages are not being printed by the compiler. This is
because the '.auto. conflicts with other OpenACC loop specifiers' errors are
generated in the earlier omp-low pass, whereas the messa
"Kewen.Lin via Gcc-patches" writes:
> gcc/ChangeLog
>
> 2020-MM-DD Kewen Lin
>
> * tree-ssa-loop-ivopts.c (get_mem_type_for_internal_fn): Handle
> IFN_LEN_LOAD and IFN_LEN_STORE.
> (get_alias_ptr_type_for_ptr_address): Likewise.
OK, thanks.
(Sorry, hadn't realised that this
On Wed, 22 Jul 2020, Richard Biener wrote:
> On Tue, Jul 21, 2020 at 9:08 PM Patrick Palka via Gcc-patches
> wrote:
> >
> > In the testcase from the PR we are seeing excessive memory use (> 5GB)
> > during constexpr evaluation, almost all of which is due to the call to
> > decl_constant_value in
On 22/07/2020 13:24, Richard Biener via Gcc-patches wrote:
> On Wed, Jul 22, 2020 at 12:03 PM Andrea Corallo
> wrote:
>>
>> Hi all,
>>
>> I'd like to submit the following two patches implementing a new AArch64
>> specific back-end pass that helps optimize branch-dense code, which can
>> be a bott
This test fails due to expected warnings and errors not being emitted by GCC.
The problem is that the 'gang reduction on an orphan loop' error is caught very
early on in the frontends (c/c-typeck.c and cp/semantics.c), so the compiler
aborts before getting to the tree passes that emit the missin
Hi Andrew,
thanks for reviewing I'll work on your comments. Just replying to the
high level questions.
Andrew Pinski writes:
> On Wed, Jul 22, 2020 at 3:10 AM Andrea Corallo wrote:
>>
>> Hi all,
>>
>> this second patch implements the AArch64 specific back-end pass
>> 'branch-dilution' control
> On Jul 18, 2020, at 2:50 PM, Jakub Jelinek via Gcc-patches
> wrote:
>
> Hi!
>
> The following patch adds __builtin_bit_cast builtin, similarly to
> clang or MSVC which implement std::bit_cast using such an builtin too.
> It checks the various std::bit_cast requirements, when not constexpr
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (reverse_iterator): Constrain
converting constructor and converting assignment operator.
Access source iterator's data member directly instead of
calling base().
(move_iterator): Likewise.
* tests
gcc.dg/goacc/loop-processing-1.c fails mainly because the dg-final directive at
the end has been incorrectly split into two lines, which breaks it completely.
The pass that emits the tested tree output is now oaccloops, not oaccdevlow.
'.UNIQUE (OACC_HEAD_MARK, 0, 1, 36)' is also changed to '.U
On сряда, 22 юли 2020 г. 2:04:35 EEST Sunil Pandey via Gcc-patches wrote:
> On Tue, Jul 21, 2020 at 12:50 AM Richard Biener
>
> wrote:
> > On Tue, Jul 21, 2020 at 7:16 AM Sunil Pandey wrote:
> > > On Mon, Jul 20, 2020 at 5:06 AM Richard Biener
> > >
> > > wrote:
> > > > On Sat, Jul 18, 2020 at
On Wed, Jul 22, 2020 at 7:25 AM Dimitar Dimitrov wrote:
>
> On сряда, 22 юли 2020 г. 2:04:35 EEST Sunil Pandey via Gcc-patches wrote:
> > On Tue, Jul 21, 2020 at 12:50 AM Richard Biener
> >
> > wrote:
> > > On Tue, Jul 21, 2020 at 7:16 AM Sunil Pandey wrote:
> > > > On Mon, Jul 20, 2020 at 5:06
The test c-c++-common/goacc/routine-nohost-1.c currently fails because it fails
to find some tree dump output. The problem is that the relevant tree pass is now
oaccloops rather than oaccdevlow.
This patch corrects the requested tree dump. I will be committing this one in
OG10 as 'obvious'.
Richard Biener writes:
> I wonder if such effect of instructions on the pipeline can be modeled
> in the DFA and thus whether the scheduler could issue (always ready)
> NOPs?
I might be wrong but the DFA model should be reasoning in terms of
executed instructions given an execution path, on the
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, July 22, 2020 12:12 AM
> To: Zhongyunde
> Cc: gcc-patches@gcc.gnu.org; Yangfei (A)
> Subject: Re: 答复: [PATCH PR95696] regrename creates overlapping
> register allocations for vliw
>
> Zh
I noticed the mangler's handling of templates could be simplified. We
know template_info is non-null, which is sufficiently boolean -- no need
for an explicit bool return. also some of the internals of
template_args_equal had crept into find_substitution. Let's not do that.
gcc/c
I noticed add_path was calling strlen more than once on the same string.
Let's not do that.
gcc/
* incpath.c (add_path): Avoid multiple strlen calls.
--
Nathan Sidwell
diff --git i/gcc/incpath.c w/gcc/incpath.c
index 8a2bda00f80..8437939bf1e 100644
--- i/gcc/incpath.c
+
This test fails because the "'seq' overrides other OpenACC loop specifiers"
error is not appearing in the compiler output. The C-equivalent version of the
test (c-c++-common/goacc/loop-2-kernels.c) has these tests XFAILed in the commit
'Make new OpenACC kernels conversion the default; adjust and
On 21/07/20 20:08 +, Joseph Myers wrote:
On Tue, 21 Jul 2020, Jonathan Wakely via Gcc-patches wrote:
I also noticed some strings give an underflow error with glibc's
strtod, but are valid for the Microsoft implementation. For example,
this one:
https://github.com/microsoft/STL/blob/master/t
This is a follow up to commit 5c9669a0e6c respectively discussion
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html
In case that an alignment constraint is less than the size of a
corresponding scalar type, ensure that we advance at least by one
iteration. For example, on s390x we h
I noticed the default capture mode and the discriminator both used ints.
That seems excessive. This shrinks them to 8 bits and 16 bits
respectively. I suppose the discriminator could use the remaining 24
bits of an int allocation unit, if we're worried about more that 64K
lambdas per functio
Here are some more places where we can declare variables at the
assignment point, rather than use C89. Also, let's name our variables
by what they contain -- the register allocator is perfectly able to
track liveness for us.
gcc/cp/
* decl.c (decls_match): Move variabl
The testcase gfortran.dg/goacc/routine-module-mod-1.f90 fails due to an extra
'warning: region is worker partitioned but does not contain worker partitioned
code' message in subroutine g_1. subroutine g_1 is marked with '!$acc routine
gang', but the loop inside is only assigned gang vector loop
Hi,
On 2020/7/22 19:05, Richard Sandiford wrote:
> This wasn't really what I meant. Using subregs is fine, but I was
> thinking of:
>
>/* Also try a wider mode if the necessary punning is either not
>desirable or not possible. */
>if (!CONSTANT_P (store_info->rhs)
>
I had to debug structural_comptypes, and its complex if conditions and
tail calling of same_type_p made that hard. I'd hope we can turn the
eqivalent of return boolean_fn () ? true : false; into a tail call of
the boolean. We also were not dealing with TYPEOF_TYPE.
gcc/cp/
I discovered the dump machinery would get confused by filenames
containing '-'. Fixed thusly as obvious.
gcc/
* dumpfile.c (parse_dump_option): Deal with filenames
containing '-'
nathan
--
Nathan Sidwell
diff --git i/gcc/dumpfile.c w/gcc/dumpfile.c
index 9a
We don't need to add CONST_DECLs to a template decl's decl list. Also
made the code flow a bit clearer.
gcc/cp/
* class.c (maybe_add_class_template_decl_list): Don't add
CONST_DECLs.
nathan
--
Nathan Sidwell
diff --git i/gcc/cp/class.c w/gcc/cp/class.c
index 803b33bf
Hi Richard,
Thanks for the review!
on 2020/7/22 下午5:11, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> - else if (LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
>> -{
>> - peel_iters_prologue = 0;
>> - peel_iters_epilogue = 0;
>> + if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
Adds support for the simd and cancel modifier of
'if (: logical_expr)', which is already
supported in C/C++.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Hi Segher,
on 2020/7/22 下午4:26, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 22, 2020 at 09:44:52AM +0800, Kewen.Lin wrote:
>> This trivial patch is to rename adjust_vectorization_cost to
>> adjust_vect_cost_per_stmt. Hope it's more meaningful, as well
>> as to avoid the confusion between th
On Mon, 20 Jul 2020, Patrick Palka wrote:
> On Mon, 20 Jul 2020, Jonathan Wakely wrote:
>
> > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++ wrote:
> > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > >
> > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++ wrote:
> > > > > On Fri,
Hi,
Sorry, please ignore the previously attached file, which isn't the latest one
although almost are the same. The latest tested is attached here.
Sorry for the inconvenience.
BR,
Kewen
on 2020/7/22 下午11:48, Kewen.Lin via Gcc-patches wrote:
>
> It's a great idea, by following your subsequ
Hi!
On Wed, Jul 22, 2020 at 03:53:34PM +0200, Andrea Corallo wrote:
> Andrew Pinski writes:
> > Can you give a simple example of what this patch does?
>
> Sure, this pass simply moves a sliding window over the insns trying to
> make sure that we never have more then 'max_branch' branches for eve
PR96236 shows a problem where we don't correctly store our 512-bit accumulators
correctly in little-endian mode. The patch below detects when we're doing a
little-endian memory access and stores to the correct memory locations.
This passed bootstrap and regtesting with no regressions. Raji verif
luoxhu writes:
> Hi,
>
> On 2020/7/22 19:05, Richard Sandiford wrote:
>> This wasn't really what I meant. Using subregs is fine, but I was
>> thinking of:
>>
>>/* Also try a wider mode if the necessary punning is either not
>> desirable or not possible. */
>>if (!CONSTANT_
Hi!
On Wed, Jul 22, 2020 at 09:26:39AM +0800, Kewen.Lin wrote:
> +/* For some target specific vectorization cost which can't be handled per
> stmt,
> + we check the requisite conditions and adjust the vectorization cost
> + accordingly if satisfied. One typical example is to model shift cost
Hi Peter,
On Wed, Jul 22, 2020 at 12:01:21PM -0500, Peter Bergner wrote:
> PR96236 shows a problem where we don't correctly store our 512-bit
> accumulators
> correctly in little-endian mode. The patch below detects when we're doing a
> little-endian memory access and stores to the correct memor
On Wed, Jul 22, 2020 at 05:52:00PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * gfortran.h (enum gfc_omp_if_kind): Add OMP_IF_CANCEL and OMP_IF_SIMD.
> * openmp.c (OMP_SIMD_CLAUSES): Add OMP_CLAUSE_IF.
> (gfc_match_omp_clauses, resolve_omp_clauses): Handle 'if (simd
A new pragma needs to be documented in extend.texi. Such documentation
should be comprehensible to users who don't know anything about the
internals of GCC or other compilers, so that they can understand when it
would be appropriate to use the pragma in their source code.
--
Joseph S. Myers
j
New insn types should be documented in rtl.texi (I think in the "Insns"
section).
--
Joseph S. Myers
jos...@codesourcery.com
The as-base type never got a name. For modules I needed to give it a
name to serialize properly, and it's useful when debugging the compiler,
so we may as well have it on trunk. There's also a bug where its fields
can have NSDMIs from the main class. This happens to be silent on
trunk, but c
LWG recently decided it should be ill-formed to instantiate std::future
and std::shared_future for types that can't be returned from a function.
This adds static assertions to enforce it (std::future already failed,
but this makes the error more understandable).
LWG 3466 extends that to std::promi
Segher Boessenkool writes:
> Hi!
>
> On Wed, Jul 22, 2020 at 03:53:34PM +0200, Andrea Corallo wrote:
>> Andrew Pinski writes:
>> > Can you give a simple example of what this patch does?
>>
>> Sure, this pass simply moves a sliding window over the insns trying to
>> make sure that we never have m
On 7/22/20 1:00 PM, Segher Boessenkool wrote:
>> gcc/
>> PR target/96236
>> * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Handle
>> little-endian memory ordering.
>>
>> gcc/testsuite/
>> PR target/96236
>> * gcc.target/powerpc/mma-double-test.c: Updat
Hi Richard,
Many thanks for the peer review and feedback. I completely agree that POPCOUNT
and PARITY iterators simplifies things and handle the IFN_ variants. Likewise,
using
integer_type_node as the type of shift constants also matches the idioms used
elsewhere in match.pd and fold. The fo
Hello Joseph, Martin,
Asher Gordon writes:
> Joseph Myers writes:
>
>> I don't see you in the FSF copyright assignment list; could you
>> complete
>> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
>> (unless you're already covered by an employer assignmen
Richard Sandiford writes:
> luoxhu writes:
>> Hi,
>>
>> On 2020/7/22 19:05, Richard Sandiford wrote:
>>> This wasn't really what I meant. Using subregs is fine, but I was
>>> thinking of:
>>>
>>>/* Also try a wider mode if the necessary punning is either not
>>> desirable or not po
Zhongyunde writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Wednesday, July 22, 2020 12:12 AM
>> To: Zhongyunde
>> Cc: gcc-patches@gcc.gnu.org; Yangfei (A)
>> Subject: Re: 答复: [PATCH PR95696] regrename creates overlapping
>> register al
-Warray-bounds fails to trigger when taking the address of an element
of a multi-dimensional array at an index that's equal to the bound of
one of the higher dimensions of the array. The attached simple patch
corrects this shortcoming. I will commit it tomorrow unless there are
suggestions for c
Another missed attribute-visibility-requirement, causing a failure for
e.g. mmix-knuth-mmixware. Committed as obvious.
gcc/testsuite:
* c-c++-common/builtin-has-attribute-4.c: Require visibility.
--- gcc/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c.orig Mon Jan
13 22:30:46
78 matches
Mail list logo
