2018-05-21 0:19 GMT+02:00 Steve Kargl :
> On Sun, May 20, 2018 at 09:44:47PM +0200, Janus Weil wrote:
>>
>> >> The patch still regtests cleanly. Ok for trunk?
>> >
>> > Patch looks good to me. The only thing that worries me is
>> > whether the patch will cause the SPEC benchmark to throw
>> > an e
PING^1
On 05/11/2018 03:12 PM, Martin Liška wrote:
> On 05/11/2018 11:35 AM, Richard Biener wrote:
>> On Thu, May 10, 2018 at 9:58 AM, Martin Liška wrote:
>>> Hi.
>>>
>>> It's removal of an assert at place where we calculate hash of a type.
>>> For incomplete types, let's skip it.
>>>
>>> Patch c
Pushed.
Thank you for your contribution,
Claudiu
From: Andrew Burgess [andrew.burg...@embecosm.com]
Sent: Wednesday, May 16, 2018 11:08 PM
To: Alexey Brodkin
Cc: gcc-patches@gcc.gnu.org; Claudiu Zissulescu
Subject: Re: [PATCH] ARC: Add multilib support for
>> >> Btw, with the arrival of the F2018 standard, I wonder whether it
>> >> actually makes sense to keep the option -std=f2008ts, or to remove it
>> >> in favor of -std=f2018, since the two Technical Specifications covered
>> >> by this flag are now part of F2018 (and pretty much the main part!).
From: claziss
The EX instruction is base line for both architectures. Reflect this in the
compiler.
OK to apply?
Claudiu
gcc/
2017-05-02 Claudiu Zissulescu
* config/arc/arc.c (atomic_exchangesi): EX instruction is default
for ARC700 and ARCv2.
---
gcc/config/arc/atomic.md
From: Claudiu Zissulescu
An update on how the instructions are scheduled for HS processor.
Ok to apply?
Claudiu
---
gcc/config/arc/arcHS.md | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/gcc/config/arc/arcHS.md b/gcc/config/arc/arcHS.md
index d49b90c
From: claziss
The sync instruction is part of all ARC architectures. Fix this in the compiler.
Ok to apply?
Claudiu
gcc/
2017-05-03 Claudiu Zissulescu
* config/arc/builtins.def (SYNC): SYNC instruction is valid on all
ARC cores.
---
gcc/config/arc/builtins.def | 2 +-
1 fil
From: Claudiu Zissulescu
For ARC700, adding padding if necessary to avoid a mispredict. A
return could happen immediately after the function start. A
call/return and return/return must be 6 bytes apart to avoid
mispredict.
The old implementation was doing this operation very late in the
compil
From: claziss
If no specs file is provided, default to nosys library.
Ok to apply?
Claudiu
gcc/
2017-05-03 Claudiu Zissulescu
* config/arc/elf.h (LINK_GCC_C_SEQUENCE_SPEC): Define.
---
gcc/config/arc/elf.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/config/arc/elf.
Make sure only one operand has an immediate.
OK to apply?
Claudiu
gcc/
2018-03-21 Claudiu Zissulescu
* config/arc/fpu.md (fmasf4): Force operand to register.
(fnmasf4): Likewise.
gcc/testsuite
2018-03-21 Claudiu Zissulescu
* gcc.target/arc/fma-1.c: New test.
---
From: claziss
When we pass an mcpu to the compiler we have two types of (hardware
configuration) flags that are set:
1. Architecture specific, for example code-density is always enabled
for ARCHS architectures. These options are overwriting whatever the
corresponding user options with the preset
From: claziss
QuarkSE has lp_count width set to 16 bits. Update the compiler to
consider it.
Ok to apply?
Claudiu
gcc/
2017-07-11 Claudiu Zissulescu
* config/arc/arc-arch.h (arc_extras): New enum.
(arc_cpu_t): Add field extra.
(arc_cpu_types): Consider the extras.
Hi Martin,
> On 05/18/2018 03:55 PM, Rainer Orth wrote:
>> Hi Martin,
>>
>>> So the patch looks fine, only very very slightly binary is produced. I'm
>>> going to install the patch so that
>>> I can carry on more complex patches based on this one.
>>
>> it seems you didn't properly test the test
On 18/05/18 11:33, Richard Earnshaw (lists) wrote:
On 17/05/18 11:26, Kyrill Tkachov wrote:
Hi all,
We deprecated architecture versions earlier than Armv4T in GCC 6 [1].
This patch removes support for architectures lower than Armv4.
That is the -march values armv2, armv2a, armv3, armv3m are re
On 19/05/18 02:09, James Greenhalgh wrote:
On Mon, May 14, 2018 at 08:38:40AM -0500, Kyrill Tkachov wrote:
Hi all,
This patch implements the usadv16qi and ssadv16qi standard names.
See the thread at on g...@gcc.gnu.org [1] for background.
The V16QImode variant is important to get right as it
On Mon, May 21, 2018 at 12:00 AM, Janus Weil wrote:
>
> Thanks. I have committed this version of the patch as r260433.
This caused:
FAIL: gfortran.dg/graphite/block-2.f -O (test for excess errors)
FAIL: gfortran.dg/graphite/id-19.f -O (test for excess errors)
FAIL: gfortran.dg/graphite/id-
On 17/05/18 16:36 +0100, Jonathan Wakely wrote:
Because path.cc is compiled with -std=gnu++17 the static constexpr
data member is implicitly 'inline' and so no definition gets emitted
unless it gets used in that translation unit. Other translation units
built as C++11 or C++14 still require a nam
Hi again,
On 19/05/2018 15:30, Jason Merrill wrote:
How about doing cp_parser_commit_to_tentative_parse if we see
something that must be a declaration? cp_parser_simple_declaration
has
/* If we have seen at least one decl-specifier, and the next token
is not a parenthesis, then we mus
* src/filesystem/std-ops.cc (absolute): Report an error for empty
paths.
(weakly_canonical(const path&)): Do not call canonical on empty path.
(weakly_canonical(const path&, error_code&)): Likewise.
* testsuite/27_io/filesystem/operations/absolute.cc: Check
Hi,
As reported in PR85804, bump step is wrongly computed for vector(1) load of
single-element group access. This patch fixes the issue by correcting bump
step computation for the specific VMAT_CONTIGUOUS case.
Bootstrap and test on x86_64 and AArch64 ongoing, is it OK?
Thanks,
bin
2018-05-17
On 10/24/2017 10:24 PM, Jason Merrill wrote:
> On Thu, Sep 14, 2017 at 5:22 AM, Martin Liška wrote:
>> On 08/10/2017 09:43 PM, Jason Merrill wrote:
>>> On 07/14/2017 01:35 AM, Martin Liška wrote:
On 05/01/2017 09:13 PM, Jason Merrill wrote:
> On Wed, Apr 26, 2017 at 6:58 AM, Martin Liška
On 05/16/2018 07:55 AM, Richard Biener wrote:
> On Wed, 16 May 2018, Richard Biener wrote:
>
>> On Tue, 15 May 2018, Richard Biener wrote:
>>
>>> On Tue, 15 May 2018, Richard Biener wrote:
>>>
On Tue, 15 May 2018, Richard Biener wrote:
> On Tue, 15 May 2018, Richard Biener wrote:
>>>
On 05/15/2018 04:47 PM, Kugan Vivekanandarajah wrote:
> Hi Richard,
>
> On 15 May 2018 at 19:20, Richard Biener wrote:
>> On Tue, 15 May 2018, Richard Biener wrote:
>>
>>> On Mon, 14 May 2018, Kugan Vivekanandarajah wrote:
>>>
Hi,
Attached patch handles PR63185 when we reach PHI wi
On 05/02/2018 04:05 PM, Jim Wilson wrote:
> This improves the code for a switch statement on targets that sign-extend
> function arguments, such as RISC-V. Given a simple testcase
>
> extern void asdf(int);
> void foo(int x) {
> switch (x) {
> case 0: asdf(10); break;
> case 1: asdf(11); br
On 05/21/2018 01:18 PM, Rainer Orth wrote:
> Hi Martin,
>
>> On 05/18/2018 03:55 PM, Rainer Orth wrote:
>>> Hi Martin,
>>>
So the patch looks fine, only very very slightly binary is produced. I'm
going to install the patch so that
I can carry on more complex patches based on this on
Hi Martin,
>>> Thanks for opened eyes, following patch will fix that.
>>> It's quite obvious, I'll install it right after tests will finish.
>>
>> unfortunately, it didn't fix either issue:
>>
>> * The switchlower -> switchlower1 renames in the dg-final* lines
>> (attached) are still necessary
On Sat, 19 May 2018, Tom G. Christensen wrote:
> Latest results for 7.x
Thanks, Tom! All applied.
Gerald
On 21/05/18 15:00, Rainer Orth wrote:
Hi Martin,
Thanks for opened eyes, following patch will fix that.
It's quite obvious, I'll install it right after tests will finish.
unfortunately, it didn't fix either issue:
* The switchlower -> switchlower1 renames in the dg-final* lines
(attached)
Hello!
Attached patch implements scalar float->unsigned int truncations with AVX512F.
2018-05-21 Uros Bizjak
* config/i386/i386.md (fixuns_truncdi2): New insn pattern.
(fixuns_truncsi2_avx512f): Ditto.
(*fixuns_truncsi2_avx512f_zext): Ditto.
(fixuns_truncsi2): Also enable for
This patch modifies the creation of transient scopes to eliminate potential
premature secondary stack reclamations when there is no suitable transient
context and the scope was intended to manage the secondary stack. Instead,
the logic was changed to accommodate a special case where an assignment w
Symbolization of traceback addresses through shared libraries
requires information on the shared libraries load addresses, which
was at hand on Linuxbut not propagated through the runtime when
caching is enabled. This change fixes this.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-05-2
This patch extends the legality of the GNAT attribute Scalar_Storage_Order,
to apply to formal private types. Previously this extension applied only
in GNAT_Mode, to support instantiations of Ada.Sequential_IO, but it is more
generally useful.
The following must compile quietly:
with Memory_
Symbolization of traceback entries from dwarf info is
failing in multiple cases for addresses originating from
shared libraries.
Part of the problem is a confusion across different functions
regarding the kind of "address" at hand, sometimes full process
runtime addresses (e.g. in traceback entrie
Symbolization of traceback entries from dwarf info was
failing in some cases with shared libraries on ELF targets,
from unexpected overlapping of what we believed were code
regions for distinct modules.
This is caused by the inclusion of all SHF_ALLOC sections in
the set of sections of possible re
This patch ensures that an abstract state declared with simple option
"synchronous" is automatically considered "external".
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-05-21 Hristian Kirtchev
gcc/ada/
* einfo.adb (Is_External_State): An abstract state is also external
This patch enforces what the comment for Has_Discriminant says:
--Has_Discriminants (Flag5)
-- Defined in all types and subtypes.
to avoid semantically undefined calls on non-type entities. It also adapts
other routines to respect this comment.
No user-visible impact.
Tested on x86_64
In some cases, the inlining performed in GNATprove mode leads to a crash,
when inlining a call where a return statement of the inlined function
returns a string literal. Now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-05-21 Yannick Moy
gcc/ada/
* sem_eval.adb (Stati
Explicit External aspect was an equivalant to an implicit default. It was only
needed as a workaround for a frontend bug. (If it meant to serve as
documentation, there should be explicit Effective_Reads and Effective_Writes
set to False too.)
No test, because these changes are semantically neutra
During the special inlining done in GNATprove mode, a call in prefix
notation leads to a spurious error. Now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-05-21 Yannick Moy
gcc/ada/
* sem_ch6.adb (Analyze_Procedure_Call): Refine test to recognize prefix
call n
Any program calling Gnat.Traceback.Symbolic.Enable_Cache for
dwarf based symbolization fails with a segmentation violation
when spawned with an inaccurate argv[0] such that it couldn't
be found on PATH.
argv[0] is most often found on PATH. One plausible case where
it isn't is when argv[0] is a mer
This patch refines the handling of the well-known syntactic ambiguity created
by a function with defaulted parameters that returns an array, so that F (X)
may designate a call to the function, or an indexing of a parameterless call.
This patch handles the case where such a call is itself the prefix
In the frontend inlining used in GNATprove, inlining of a return statement
was using an unchecked type conversion, which could cause a necessary
run-time check on the conversion to be skipped. Now fixed.
There is no impact on compilation.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-05
This patch modifies the semantics of pragma Elaboration_Checks. The pragma
was intended to be a configuration pragma, however its placement was never
verified until now.
The pragma may appear in the following contexts:
* Configuration pragmas file
* Prior to the context clauses of a compil
This patch fixes an omission in the expansion of loops over GNAT-specific
iterable objects. If the source includes an explicit name for the loop,
that name has to be preserved in the expanded code to allow exit statements
to mention it.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-05-21
This patch corrects the part of the access-before-elaboration mechanism which
ensures that the freeze node of a tagged type is within the early call region
of all its overriding bodies to ignore predefined primitives.
-- Source --
-- pack.ads
package Pack with SPARK_Mo
A type conversion may be illegal if the expression in the conversion has a
limited view of a type. This patch expands the error report to indicate the
presence of a limited view, and when the context is a package body it suggests
the addition of a regular with-clause to make the full view available
This patch ensures that aspect specifications which appear on package,
protected, and task body stubs are properly analyzed.
-- Source --
-- pack.ads
package Pack
with SPARK_Mode,
Abstract_State => State
is
-
-- Refine
The compiler warns on an object declaration with default initialization
and an address clause, to indicate that the overlay implied by the address
clause might affect a value elsewhere. The warning is suppressed if the type
carries the Suppress_Initialization aspect. With this patch the compiler
al
GCC maintainers:
I updated the CommitLog for gcc/testsuite/gcc.target/powerpc/altivec-
12.c to clarify the change.
A new test selector for big endian (be) and little endian (le) is added
to specify the platform for the tests to run on independent of the
platform being 32-bit or 64 bit. The vario
On 17 May 2018 at 10:25, Richard Sandiford wrote:
> This patch gets the gimple FE to parse calls to internal functions.
> The only non-obvious thing was how the functions should be written
> to avoid clashes with real function names. One option would be to
> go the magic number of underscores rou
Hi all,
This recently-committed test fails the INS scan for tiny and large memory
models.
That is because instead of the:
make_vector:
adrpx1, a
adrpx0, b
moviv0.4s, 0
ldr s2, [x1, #:lo12:a]
ldr s1, [x0, #:lo12:b]
ins v0.s[2
Hey everyone,
Thomas and I have been working on adding asynchronous I/O to
libgfortran. The patch is almost done, the only thing still missing is
to link libgfortran against libpthread if it exists(which is for some
reason necessary despite using __gthread) and deactivating it if
libpthread d
OK.
On Mon, May 21, 2018 at 8:41 AM, Paolo Carlini wrote:
> Hi again,
>
> On 19/05/2018 15:30, Jason Merrill wrote:
>>
>> How about doing cp_parser_commit_to_tentative_parse if we see
>> something that must be a declaration? cp_parser_simple_declaration
>> has
>>
>>/* If we have seen at leas
On 18/05/18 21:34, Michael Collison wrote:
> This patch improves additional cases of FP to integer conversions.
>
> Example 1:
>
> unsigned long
> f7 (double x)
> {
> return (unsigned) y;
> }
>
>
> At -O2
>
> Trunk generates:
>
> f7:
> fcvtzu w0, d0
> uxtwx0, w0
> ret
On Mon, May 21, 2018 at 12:14:13PM +0200, Janus Weil wrote:
>
> So, here is the promised follow-up patch. It mostly removes
> GFC_STD_F2008_TS and replaces it by GFC_STD_F2018 in a mechanical
> manner. Plus, it fixes the resulting fallout in the testsuite and
> updates the documentation. The non-m
I just committed this patch as trivial.
I must have run tests without rebuilding pre-compiled headers. I'll have
to find out how to build tests without pre-compiled headers to avoid it
in the future.
François
On 20/05/2018 19:06, fdumont at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzill
On 5/17/18 1:57 PM, Segher Boessenkool wrote:
> On Thu, May 17, 2018 at 07:58:20PM +0200, Richard Biener wrote:
>> On May 17, 2018 6:04:36 PM GMT+02:00, Segher Boessenkool
>> wrote:
>>> On Thu, May 17, 2018 at 10:42:46AM -0500, Pat Haugen wrote:
The following patch fixes a problem that resul
C++17 added new overloads to class templates to support
opening files from wide character strings "on systems where
filesystem::path::value_type is not char". This patch adds those
overloads conditional on _wfopen being available, and enables them for
pre-C++17 modes as well.
Add support
On Mon, May 21, 2018 at 9:33 AM, Martin Liška wrote:
> On 10/24/2017 10:24 PM, Jason Merrill wrote:
>> On Thu, Sep 14, 2017 at 5:22 AM, Martin Liška wrote:
>>> On 08/10/2017 09:43 PM, Jason Merrill wrote:
On 07/14/2017 01:35 AM, Martin Liška wrote:
> On 05/01/2017 09:13 PM, Jason Merrill
Hi!
On Fri, May 18, 2018 at 06:22:31PM -0400, Michael Meissner wrote:
> * config/rs6000/rs6000.c (rs6000_init_builtins): Always create
> __ibm128 as a distinct type.
This is not what it does though? It only does that if TARGET_FLOAT128_TYPE?
And it does not make long double a separat
On Mon, May 21, 2018 at 09:00:58AM +0200, Janus Weil wrote:
> 2018-05-21 0:19 GMT+02:00 Steve Kargl :
> > On Sun, May 20, 2018 at 09:44:47PM +0200, Janus Weil wrote:
> >>
> >> >> The patch still regtests cleanly. Ok for trunk?
> >> >
> >> > Patch looks good to me. The only thing that worries me is
On 05/18/2018 07:15 AM, David Malcolm wrote:
> On Fri, 2018-05-18 at 13:11 +0200, Richard Biener wrote:
>> The following adds a simple alloc/free_flag machinery allocating
>> bits from an int typed pool and applies that to bb->flags and edge-
>>> flags.
>> This should allow infrastructure pieces to
Hi Steve,
> The attached patch fixes a few testcases that were missed
> in the original patch. Do you have these already in an
> updated patch, or would you like me to commit my patch?
I saw the message just now and had no time to react yet. Please feel
free to commit your patch.
Thanks,
Janus
On Mon, May 21, 2018 at 09:06:40PM +0200, Janus Weil wrote:
> Hi Steve,
>
> > The attached patch fixes a few testcases that were missed
> > in the original patch. Do you have these already in an
> > updated patch, or would you like me to commit my patch?
>
> I saw the message just now and had no
I've committed the attached patch, which fixes a few testsuite
failures related to changes in how gfortran handles legacy code.
2018-05-21 Steven G. Kargl
* gfortran.dg/graphite/block-2.f: Adjust testcase for new gfortran
warnings for deleted and obsolescent features.
*
On Mon, May 21, 2018 at 12:10:01PM -0700, Steve Kargl wrote:
> On Mon, May 21, 2018 at 09:06:40PM +0200, Janus Weil wrote:
> > Hi Steve,
> >
> > > The attached patch fixes a few testcases that were missed
> > > in the original patch. Do you have these already in an
> > > updated patch, or would y
2018-05-21 21:23 GMT+02:00 Steve Kargl :
> On Mon, May 21, 2018 at 12:10:01PM -0700, Steve Kargl wrote:
>> On Mon, May 21, 2018 at 09:06:40PM +0200, Janus Weil wrote:
>> > Hi Steve,
>> >
>> > > The attached patch fixes a few testcases that were missed
>> > > in the original patch. Do you have thes
Hi,
I noticed a few days ago that the second parameter of the function is
redundant, we can just rely on the return value possibly being
error_mark_node (I even ran the testsuite with the function instrumented
with a gcc_assert (*is_error == (parameters == error_mark_node);
immediately before
This is my attempt to implement P0614R1, a C++20 feature whereby we may now use
an init-statement in a range-based for loop like this:
for (int i = bar (); const auto &x : a)
// ...
The somewhat tricky part was to distinguish a range-based for from an ordinary
for
statement, hence the cp_p
On Mon, May 21, 2018 at 4:53 PM, Uros Bizjak wrote:
> Hello!
>
> Attached patch implements scalar float->unsigned int truncations with AVX512F.
>
> 2018-05-21 Uros Bizjak
>
> * config/i386/i386.md (fixuns_truncdi2): New insn pattern.
> (fixuns_truncsi2_avx512f): Ditto.
> (*fixuns_tr
Actually, scratch this. I found an issue with the current patch. Sorry.
On Mon, May 21, 2018 at 03:50:05PM -0400, Marek Polacek wrote:
> This is my attempt to implement P0614R1, a C++20 feature whereby we may now
> use
> an init-statement in a range-based for loop like this:
...
Marek
On Mon, May 21, 2018 at 09:39:29PM +0200, Janus Weil wrote:
>
> Regarding the libgomp.fortran cases: Those are not included in "make
> check-fortran", right? How do I actually run them? Is this documented
> somewhere?
Good question!
When I want to do a specific check, I do something of the form
On Mon, May 21, 2018 at 1:06 PM, Steve Kargl
wrote:
> On Mon, May 21, 2018 at 09:39:29PM +0200, Janus Weil wrote:
>>
>> Regarding the libgomp.fortran cases: Those are not included in "make
>> check-fortran", right? How do I actually run them? Is this documented
>> somewhere?
>
> Good question!
>
>
On Mon, May 21, 2018 at 01:06:21PM -0700, Steve Kargl wrote:
> On Mon, May 21, 2018 at 09:39:29PM +0200, Janus Weil wrote:
> >
> > Regarding the libgomp.fortran cases: Those are not included in "make
> > check-fortran", right? How do I actually run them? Is this documented
> > somewhere?
>
> Good
> Simple format extension which prints working directory of TU when it was
> compiled. It's requested by LCOV folks.
Can we make that optional, please? Having the coverage results depends on the
current working directory is quite annoying, to say the least.
--
Eric Botcazou
2018-05-21 22:16 GMT+02:00 Jakub Jelinek :
> On Mon, May 21, 2018 at 01:06:21PM -0700, Steve Kargl wrote:
>> On Mon, May 21, 2018 at 09:39:29PM +0200, Janus Weil wrote:
>> >
>> > Regarding the libgomp.fortran cases: Those are not included in "make
>> > check-fortran", right? How do I actually run t
On 05/18/2018 12:15 PM, Martin Sebor wrote:
> Under some apparently rare conditions a DECL can have a non-
> constant size that the fix for bug 85753 committed last week
> into trunk was not prepared for. The attached change removes
> the assumption to avoid the ICE that otherwise results.
>
> Ma
On 05/18/2018 02:09 AM, Richard Sandiford wrote:
> In this PR we have:
>
> c_5 = c_4(D) + 4;
> c_12 = c_5 + 1;
> *c_5 = 2;
> a = 2; // A
> c_21 = c_12 + 1;
> *c_12 = 2;
> a = 2; // B
> c_28 = c_21 + 1;
> *c_21 = 2;
> a = 2;
> c_7 = c_28 + 1;
> *c_2
On 05/17/2018 06:15 AM, Richard Biener wrote:
>
> The previous DSE improvements left us with skipping elements we could
> have possibly removed because I messed up the iterator increment
> upon removal. The following fixes this and also adds another pruning
> opportunity in case the only stmt fee
On 05/17/2018 02:42 AM, Richard Biener wrote:
> On Thu, 17 May 2018, Kyrill Tkachov wrote:
>
>> Hi,
>>
>> Given this is a midend change it's a good idea to CC some of the maintainers
>> of that area.
>> I've copied richi and Honza.
>
> The patch is ok for trunk (it's actually mine...) and for the
OK.
On Mon, May 21, 2018 at 3:50 PM, Marek Polacek wrote:
> This is my attempt to implement P0614R1, a C++20 feature whereby we may now
> use
> an init-statement in a range-based for loop like this:
>
> for (int i = bar (); const auto &x : a)
> // ...
>
> The somewhat tricky part was to di
OK.
On Mon, May 21, 2018 at 3:47 PM, Paolo Carlini wrote:
> Hi,
>
> I noticed a few days ago that the second parameter of the function is
> redundant, we can just rely on the return value possibly being
> error_mark_node (I even ran the testsuite with the function instrumented
> with a gcc_assert
On 05/03/2018 08:15 AM, Tom de Vries wrote:
> Hi,
>
> I'm posting this patch for the record.
>
> I wrote it but haven't found a use for it yet. I find it easier to write
> asm scans for nvptx than rtl ones.
If you do find a use, then consider this pre-approved.
jeff
2018-05-21 22:18 GMT+02:00 Janus Weil :
> I'll take care of fixing the remaining libgomp failures.
Should be done with r260487. Please let me know if you observe any
additional problems.
Cheers,
Janus
On 05/10/2018 03:47 AM, Alexander Monakov wrote:
>
>
> On Mon, 23 Apr 2018, Alexander Monakov wrote:
>
>> This rewrites global register vars doc to reflect that the register is no
>> longer
>> reserved exclusively, but in fact is available for general allocation, and
>> also
>> adds the requir
This patch creates "be" and "le" selectors, which can be used by all
architectures, similar to ilp32 and lp64.
Is this okay for trunk?
Segher
2017-05-21 Segher Boessenkool
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_be): New.
(check_effective_target_le)
Hi Segher,
> This patch creates "be" and "le" selectors, which can be used by all
> architectures, similar to ilp32 and lp64.
>
> Is this okay for trunk?
two issues: I don't find be and le particularly expressive. Maybe
big-endian and little-endian?
Besides, whatever we do, the new keywords nee
On 05/21/2018 01:30 PM, Jeff Law wrote:
> On 05/17/2018 02:42 AM, Richard Biener wrote:
>> On Thu, 17 May 2018, Kyrill Tkachov wrote:
>>
>>> Hi,
>>>
>>> Given this is a midend change it's a good idea to CC some of the maintainers
>>> of that area.
>>> I've copied richi and Honza.
>> The patch is
On 04/12/2018 06:02 PM, Martin Sebor wrote:
> Attached is a minor update that avoids additional duplicate
> warnings exposed by more extensive testing (for PR 85369).
>
> On 04/12/2018 02:52 PM, Martin Sebor wrote:
>> The attached patch makes a small tweak to avoid issuing a duplicate
>> warning f
On 05/02/2018 12:57 AM, Thomas Preudhomme wrote:
> Hi Segher,
>
> As mentionned in the ticket this was my first thought but this means
> making the pattern aware of all the possible way the address could be
> access (PIC Vs non-PIC, Arm Vs Thumb-2 Vs Thumb-1) to decide how many
> scratch registers
On Mon, May 21, 2018 at 11:59:43PM +0200, Rainer Orth wrote:
> Hi Segher,
>
> > This patch creates "be" and "le" selectors, which can be used by all
> > architectures, similar to ilp32 and lp64.
> >
> > Is this okay for trunk?
>
> two issues: I don't find be and le particularly expressive. Maybe
On 05/10/2018 01:26 PM, Martin Sebor wrote:
> GCC 8.1 warns for unbounded (and some bounded) string comparisons
> involving arrays declared attribute nonstring (i.e., char arrays
> that need not be nul-terminated). For instance:
>
> extern __attribute__((nonstring)) char a[4];
>
> int f (voi
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-8.1.0.es.po', has just
The previous version of this patch got confused by
for (int i = 0; n > 0 ? true : false; i++)
// ...
because even though we see a ; followed by a :, it's not a range-based for with
an initializer. I find it very strange that this didn't show up during the
regtest.
To fix this, I had to ug
On Fri, May 18, 2018 at 07:27:15PM -0400, Michael Meissner wrote:
> Here is patch 2 of 2 to make __ibm128 a distinct type. This patch makes the
> long double pack and unpack builtins only work if the long double type is IBM
> extended double. It adds two new builtins to pack and unpack __ibm128 t
Hi Jason,
I'm afraid this change
2018-05-17 Jason Merrill
* line-map.c (linemap_init): Use placement new.
* system.h: #include .
broke bootstrap on systems using libc++ instead of libstdc++ (such
as newer versions of FreeBSD, reported on FreeBSD 11 but could also
be notica
On Mon, 23 Apr 2018, Segher Boessenkool wrote:
>> Can I push this to ibm/gcc-7-branch?
> Don't ask me, I'm not maintainer of that branch. I would point you
> to the wiki page explaining who owns it, but i cannot find that page.
https://gcc.gnu.org/svn.html
Except that the ibm/gcc-7-branch is not
On Mon, May 21, 2018 at 7:34 PM, Marek Polacek wrote:
> The previous version of this patch got confused by
>
> for (int i = 0; n > 0 ? true : false; i++)
> // ...
>
> because even though we see a ; followed by a :, it's not a range-based for
> with
> an initializer. I find it very strange
On Mon, May 21, 2018 at 9:25 PM, Gerald Pfeifer wrote:
> Hi Jason,
>
> I'm afraid this change
>
> 2018-05-17 Jason Merrill
>
> * line-map.c (linemap_init): Use placement new.
> * system.h: #include .
>
> broke bootstrap on systems using libc++ instead of libstdc++ (such
> as n
On Mon, 21 May 2018, Jeff Law wrote:
> Whether or not a global register is saved in the prologue and restored
> in the epilogue is actually a function of the target's prologue/epilogue
> implementation.
>
> So ISTM this paragraph needs to be refined a bit. Essentially it may or
> may not change t
1 - 100 of 102 matches
Mail list logo
