This patch by Than McIntosh fixes the Go frontend to compare parse
methods when indexing interface types for export. This change fixes a
bug in which two interface types were being incorrectly commoned
(considered identical) in the initial stages of writing out types to
export data. The indexer
This patch to the Go frontend by Than McIntosh adds a new debugging
helper function debug_go_type. This is intended to display the
contents of a Type object in a way useful to debugging a run of the
compiler. Prior to this the only useful alternative for debugging
types was invoking the
On Tue, 12 Mar 2019, Hans-Peter Nilsson wrote:
> When is it appropriate to make the user add -latomic to link
> their program? Perhaps different answers for fortran and C++.
> I'm guessing "always when using any atomic construct" for C.
I think we should link with --as-needed -latomic
Richard,
Thanks for your comment. Yes, it is like kind of jump threading with
knowledge of loop structure. And what is rough time for GCC 10?
Regards,
Feng
From: Richard Biener
Sent: Tuesday, March 12, 2019 4:31:49 PM
To: Feng Xue OS
Cc:
Regarding this sometimes-add--latomic(-in-testsuite) that is
revisited:
When is it appropriate to make the user add -latomic to link
their program? Perhaps different answers for fortran and C++.
I'm guessing "always when using any atomic construct" for C.
I had a grep-look in gcc/doc before
On Sun, Mar 10, 2019 at 10:19:03PM +0100, Harald Anlauf wrote:
> The code in the testcase died due to a run-time bounds-check
> generated slightly too early, leading to a crash for deferred
> character length. Moving the character length check after the
> assignment solves the issue.
>
>
On Tue, Mar 12, 2019 at 10:42:21PM +0100, Thomas Koenig wrote:
>
> the attached patch fixes three very closely related 7/8/9 regressions.
> The common root cause of these PRs was that , if a binding label
> existed, gfc_get_extern_function_decl first looked for that name
> in the global symbol
On Tue, Mar 12, 2019 at 11:19:07PM +0100, Thomas Koenig wrote:
> Hi Harald,
>
> > how about the attached version? It is quite verbose and produces
> > messages like
> >
> > Error: Expected list of 'lower-bound-expr:' or list of
> > 'lower-bound-expr:upper-bound-expr' at (1)
>
> I think this
Hi,
This patch moves the one -fsantize=undefined test to a new ubsan test
directory, guarded by check_effective_target_fsanitize_undefined.
Another recent change to gdc_include_flags left one variable unused,
also noticed that flags was never explicitly returned. Both have been
fixed up.
On Tue, 12 Mar 2019 at 20:57, Rainer Orth wrote:
>
> Hi Iain,
>
> > On Tue, 12 Mar 2019 at 18:27, Uros Bizjak wrote:
> >>
> >> Attached patch fixes libstdc++ includes for multilib d testsuite and
> >> fixes runnable/cppa.d testsuite failure with 32bit multilib on
> >> x86_64-linux-gnu.
> >>
> >>
On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> I like this idea. I have prototyped something, I created 'vector_asm'
> as an aarch64 attribute because I couldn't find where to put global
> attributes like __simd__. Does anyone know where these are listed?
On 2019-03-12 7:05 p.m., Jonathan Wakely wrote:
> On 12/03/19 23:01 +, Joseph Myers wrote:
>> On Mon, 11 Mar 2019, Jonathan Wakely wrote:
>>
>>> +proc add_options_for_libatomic { flags } {
>>> + if { [istarget hppa*-*-hpux*] } {
>>> + return "$flags -L../../libatomic/.libs -latomic"
On Tue, 2019-03-12 at 14:17 +, Joseph Myers wrote:
>
> On Tue, 12 Mar 2019, Richard Biener wrote:
>
> > It shouldn't be difficult to provide an alias from the glibc side, no?
> > How does x86 avoid this issue?
>
> There are static-only wrappers in libmvec_nonshared.a to work around the
>
Hi,
This patch merges the D front-end implementation with dmd upstream 19b1454b5.
Backports fixes for many ICEs that occurred when using the vector
.array property in both CTFE and code generation passes.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r269627.
On 12/03/19 23:01 +, Joseph Myers wrote:
On Mon, 11 Mar 2019, Jonathan Wakely wrote:
+proc add_options_for_libatomic { flags } {
+if { [istarget hppa*-*-hpux*] } {
+ return "$flags -L../../libatomic/.libs -latomic"
+}
It's generally inappropriate to hardcode such
On 12/03/19 22:49 +, Joseph Myers wrote:
On Tue, 5 Mar 2019, Jonathan Wakely wrote:
The midpoint and lerp functions for floating point types come straight
from the P0811R3 proposal, with no attempt at optimization.
I don't know whether P0811R3 states different requirements from the
On Mon, 11 Mar 2019, Jonathan Wakely wrote:
> +proc add_options_for_libatomic { flags } {
> +if { [istarget hppa*-*-hpux*] } {
> + return "$flags -L../../libatomic/.libs -latomic"
> +}
It's generally inappropriate to hardcode such ../../libatomic/.libs paths
without making sure
On Tue, 5 Mar 2019, Jonathan Wakely wrote:
> The midpoint and lerp functions for floating point types come straight
> from the P0811R3 proposal, with no attempt at optimization.
I don't know whether P0811R3 states different requirements from the public
P0811R2, but the implementation of
Hi Harald,
how about the attached version? It is quite verbose and produces
messages like
Error: Expected list of 'lower-bound-expr:' or list of
'lower-bound-expr:upper-bound-expr' at (1)
I think this way of specifying error messages
+#define BOUNDS_SPEC_LIST "list of %"
...
+
Hello world,
the attached patch fixes three very closely related 7/8/9 regressions.
The common root cause of these PRs was that , if a binding label
existed, gfc_get_extern_function_decl first looked for that name
in the global symbol table for that function and used its backend_decl.
If there
On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
> On 3/12/19 3:59 PM, Marek Polacek wrote:
> > As Barry explained in the PR, lambda capture is one of
> >
> >simple-capture ...[opt]
> >...[opt] init-capture
> >
> > where init-capture requires an initializer. Here we have
>
On 3/12/19 3:59 PM, Marek Polacek wrote:
As Barry explained in the PR, lambda capture is one of
simple-capture ...[opt]
...[opt] init-capture
where init-capture requires an initializer. Here we have
[...xs...]
which is ill-formed as it's mingling both of these.
As Barry explained in the PR, lambda capture is one of
simple-capture ...[opt]
...[opt] init-capture
where init-capture requires an initializer. Here we have
[...xs...]
which is ill-formed as it's mingling both of these.
Bootstrapped/regtested on x86_64-linux, ok for trunk? Or should
This makes an attempt at fixing the most annoying parts of the GIMPLE
FE unit testing - the lack of proper CFG preservation and hoops you
need to jump through to make the CFG and SSA builders happy.
Due to this the __GIMPLE specifiers takes two new flags, "cfg"
for GIMPLE-with-a-CFG and "ssa"
Hi Iain,
> On Tue, 12 Mar 2019 at 18:27, Uros Bizjak wrote:
>>
>> Attached patch fixes libstdc++ includes for multilib d testsuite and
>> fixes runnable/cppa.d testsuite failure with 32bit multilib on
>> x86_64-linux-gnu.
>>
>>
>> 2019-03-12 Uroš Bizjak
>>
>> PR d/87824
>> *
On Tue, 12 Mar 2019 at 18:27, Uros Bizjak wrote:
>
> Attached patch fixes libstdc++ includes for multilib d testsuite and
> fixes runnable/cppa.d testsuite failure with 32bit multilib on
> x86_64-linux-gnu.
>
>
> 2019-03-12 Uroš Bizjak
>
> PR d/87824
> * lib/gdc.exp
Attached patch fixes libstdc++ includes for multilib d testsuite and
fixes runnable/cppa.d testsuite failure with 32bit multilib on
x86_64-linux-gnu.
2019-03-12 Uroš Bizjak
PR d/87824
* lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
On 3/12/19 2:20 AM, Richard Biener wrote:
On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor wrote:
A -Warray-bounds enhancement committed last year into GCC 9
introduced an assumption that the MEM_REF type argument has
a size. The test case submitted in PR89662 does pointer
addition on void*, in
Hi,
This patch is a second fix for PR d/87866, as dmd front-end function
FileName::canonicalName could be called during the semantic pass of
import("file") expressions, so still requires that realpath() be
redefined.
Bootstrapped and ran D2 testsuite on x86_64-linux-gnu.
Committed to trunk as
on 2019/3/12 下午11:22, Bill Schmidt wrote:
> On 3/12/19 9:29 AM, Bill Schmidt wrote:
>> On 3/12/19 7:57 AM, Kewen.Lin wrote:
>>> Hi,
>>>
>>> As the comments from Richard and Segher (Thanks!), I've made some
>>> changes by adding some checks and extensions.
>>> *) Check whether vector type
On 3/12/19 9:29 AM, Bill Schmidt wrote:
> On 3/12/19 7:57 AM, Kewen.Lin wrote:
>> Hi,
>>
>> As the comments from Richard and Segher (Thanks!), I've made some
>> changes by adding some checks and extensions.
>> *) Check whether vector type available on target machine,
>> *) Check whether
On 3/12/19 3:17 PM, Steve Kargl wrote:
> On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote:
>> On 3/11/19 6:23 PM, Steve Kargl wrote:
>>> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
> Hi.
>
> I
Hi,
Thanks Christophe! I have committed a backport of r269499 including the
testism fix r269596 to gcc-8 branch in r269613.
gcc/ChangeLog:
2019-03-12 Andre Vieira
Backport from mainline
2019-03-08 Andre Vieira
* config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add
On 3/12/19 7:57 AM, Kewen.Lin wrote:
> Hi,
>
> As the comments from Richard and Segher (Thanks!), I've made some
> changes by adding some checks and extensions.
> *) Check whether vector type available on target machine,
> *) Check whether vector operation available on target machine,
>
On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote:
> On 3/11/19 6:23 PM, Steve Kargl wrote:
> > On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
> >> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> I would like to add %' into __gcc_gfc__ in
On Tue, 12 Mar 2019, Richard Biener wrote:
> It shouldn't be difficult to provide an alias from the glibc side, no?
> How does x86 avoid this issue?
There are static-only wrappers in libmvec_nonshared.a to work around the
GCC limitation (not included in the shared library, so less efficient
Hi,
This patch merges the D front-end implementation with dmd upstream 7423993c9.
Backports a fix for extern(C++) mangling for substituted basic types
that are target-specific. Introduces a new method that currently does
nothing, but could in future make use of flag_abi_version as
extern(C++)
Hi,
As the comments from Richard and Segher (Thanks!), I've made some
changes by adding some checks and extensions.
*) Check whether vector type available on target machine,
*) Check whether vector operation available on target machine,
*) Extend the vector operation support to
Hi,
I have forgot to add a newline in cgraph_node dumping that I added last
week (the patch to partially address PR 88235). When discussing this,
we agreed with Honza that if we dump that a node is a former thunk, we
should also dump the various info in the thunk sub-structure that
On 12.03.19 11:02, Robin Dapp wrote:
> This fixes a newly introduced test failure.
>
>
> ---
>
> 2019-03-12 Robin Dapp
>
> * gcc.target/s390/memset-1.c: Do not require stcy.
>
Ok. Thanks!
Andreas
On 12.03.19 11:00, Robin Dapp wrote:
>> Please adjust the year and the author in gcc/config/s390/3906.md. Ok with
>> that change.
>
> Changed that and also simplified the longrunning checks.
>
> gcc/ChangeLog:
>
> 2019-03-12 Robin Dapp
>
> * config/s390/s390.c
On 12.03.19 11:22, Robin Dapp wrote:
> Hi,
>
> this patch sets the inlining parameters for z13 and later to rather
> aggressive values in response to PR85103 that caused performance
> regressions in SPEC2006's sjeng and gobmk benchmarks.
>
> Regards
> Robin
>
> --
>
> gcc/ChangeLog:
>
>
Hi Sudi,
On 2/22/19 10:45 AM, Sudakshina Das wrote:
Hi
This patch documents the addition of the new Armv8.5-A and corresponding
extensions in the gcc-9/changes.html.
As per https://gcc.gnu.org/about.html, I have used W3 Validator.
Is this ok for cvs?
Thanks
Sudi
Index:
Hi Steve,
> > Technically the ICE is a regression, but since it happens on invalid
> > code only, backporting is not essential IMHO (but might still be
> > useful). Ok for trunk? And 8-branch?
>
> Looks good to me with a minor suggestion. See below.
thanks for the comments. Updated patch
On Mon, Mar 04, 2019 at 11:35:50PM +0100, Jakub Jelinek wrote:
> 2019-03-04 Jakub Jelinek
>
> PR debug/89498
> * dwarf2out.c (size_of_die): For dw_val_class_view_list always use
> DWARF_OFFSET_SIZE.
> (value_format): For dw_val_class_view_list never use
On Tue, Mar 12, 2019 at 04:32:35AM -0300, Alexandre Oliva wrote:
> When location lists are referenced in DW_AT_location attributes by an
> absolute address in DW_FORM_sec_offset, the corresponding
> DW_AT_GNU_locviews attribute can be a DW_FORM_sec_offset with an
> absolute address as well.
Note,
On Mon, Mar 04, 2019 at 10:04:01AM +0100, Jakub Jelinek wrote:
> The first one uses constraints and no C code in the output, I believe it is
> actually more expensive for compile time, because if one just reads what
> constrain_operands needs to do for another constraint, it is quite a lot.
> I've
Hi,
this is just an error recovery ICE but maybe we can fix it in time for
9.1.0, like c++/89488, which is somehow related. Indeed, the problem is
again a !DEFERRED_NOEXCEPT_SPEC_P gcc_assert triggering where, earlier,
process_subob_fn had maybe_instantiate_noexcept returning false (in
On 3/11/19 6:23 PM, Steve Kargl wrote:
> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
>> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
>>> Hi.
>>>
>>> I would like to add %' into __gcc_gfc__ in order to handle:
>>>
>>> ./xgcc -B. /tmp/module.ii -Wformat -c
>>>
Hi,
this patch sets the inlining parameters for z13 and later to rather
aggressive values in response to PR85103 that caused performance
regressions in SPEC2006's sjeng and gobmk benchmarks.
Regards
Robin
--
gcc/ChangeLog:
2019-03-12 Robin Dapp
* config/s390/s390.c
This fixes a newly introduced test failure.
---
2019-03-12 Robin Dapp
* gcc.target/s390/memset-1.c: Do not require stcy.
diff --git a/gcc/testsuite/gcc.target/s390/memset-1.c b/gcc/testsuite/gcc.target/s390/memset-1.c
index 3e201df1aed..9463a77208b 100644
---
On 12.03.19 10:58, Jakub Jelinek wrote:
> 2019-03-12 Jakub Jelinek
>
> PR target/52726
> * config/s390/s390.md (tabort): Use %wd instead of
> HOST_WIDE_INT_PRINT_DEC in error message, reword to avoid two capital
> letters and periods.
> * config/tilepro/tilepro.c
> Please adjust the year and the author in gcc/config/s390/3906.md. Ok with
> that change.
Changed that and also simplified the longrunning checks.
gcc/ChangeLog:
2019-03-12 Robin Dapp
* config/s390/s390.c (LONGRUNNING_THRESHOLD): Remove.
(s390_is_fpd): Add.
Hi!
These are the only remaining cases of gcc-internal-format diagnostics using
HOST_WIDE_INT_PRINT*. That is wrong because the string depends on the exact
host, and xgettext doesn't handle it anyway, so in gcc.pot the messages are
truncated at the spot where HOST_WIDE_INT_PRINT* appears. See
Steve Ellcey writes:
> Richard,
>
> I don't necessarily disagree with anything in your comments and long
> term I think that is the right direction, but I wonder if that level of
> change is appropriate for GCC Stage 4 which is where we are now. Your
> changes would require fixes in shared code,
Hi.
This is one more enhancement of JSON intermediate format export. Apart from
that, I also improved documentation of the format and gcov-dump output.
Patch survives gcov.exp regression tests. I'm going to install the patch
after some time.
Thanks,
Martin
gcc/ChangeLog:
2019-03-11 Martin
Hi.
The patch is about simplification and usage of enum types. ENDP integer
does not make much sense in this usage.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed after stage1 opens?
Thanks,
Martin
2019-03-11 Martin Liska
*
On 3/11/19 4:51 PM, Martin Sebor wrote:
> On 3/11/19 2:13 AM, Martin Liška wrote:
>> Hi.
>>
>> The patch adds a lot of option name wrapping in string format messages. I
>> added a new contrib
>> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot
>> file and reports
>>
On Tue, Mar 12, 2019 at 09:33:40AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote:
> > I think this needs to be fixed on the glibc side - if glibc advertises
> >
> > float expf (float, float)
> >
On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote:
> I think this needs to be fixed on the glibc side - if glibc advertises
>
> float expf (float, float)
> __attribute__((simd(notinbranch),alias("__expf_finite"))
>
> or so then you of course have to provide an implementation that
On Tue, Mar 12, 2019 at 7:20 AM Feng Xue OS wrote:
>
> This patch is composed to implement a loop transformation on one of its
> conditional statements, which we call it semi-invariant, in that its
> computation is impacted in only one of its branches.
>
> Suppose a loop as:
>
> void f
On Mon, Mar 11, 2019 at 11:39 PM Steve Ellcey wrote:
>
> This is a proposed GCC patch that allows targets to modify the names of
> the libmvec routines that get called. Currently, if you build ToT GCC
> on Aarch64 and include this glibc patch:
>
>
On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor wrote:
>
> A -Warray-bounds enhancement committed last year into GCC 9
> introduced an assumption that the MEM_REF type argument has
> a size. The test case submitted in PR89662 does pointer
> addition on void*, in which the MEM_REF type is void*,
On Mar 9, 2019, Alexandre Oliva wrote:
> On Mar 9, 2019, Jakub Jelinek wrote:
>> If so, then all we need is likely my patch + some documentation change,
>> though not sure where exactly it should be documented, some Wiki we refer
>> in include/dwarf2.def, or what?
> Hmm, I was thinking of
This patch is composed to implement a loop transformation on one of its
conditional statements, which we call it semi-invariant, in that its
computation is impacted in only one of its branches.
Suppose a loop as:
void f (std::map m)
{
for (auto it = m.begin (); it != m.end ();
On March 11, 2019 11:32:38 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>All other expand_builtin* calls in builtins.c return NULL or return
>const0_rtx or return without ICEing when arg validation fails, but
>these
>two and as the testcases show, it can happen on invalid (at runtime)
>testcases.
66 matches
Mail list logo
