The attached patch has been tested on x86_64-*-freebsd. There
were no regression. The patch is less then obvious, but simple.
OK to commit?
2019-01-11 Steven G. Kargl
PR fortran/61765
* resolve.c (gfc_verify_binding_labels): Break if-elseif-elseif
structure into independent
On Fri, Jan 11, 2019 at 07:49:54PM +, Richard Sandiford wrote:
> FWIW, I think this is papering over a deeper issue,
Most certainly. At the very least there's the fact that many places
in the compiler that call attr_min_value (via other functions) don't
bother checking for an INT_MAX return.
PR libstdc++/88811
PR libstdc++/83306
* src/filesystem/path.cc: Fix typo. If first path is empty, show []
before second path.
* testsuite/experimental/filesystem/filesystem_error/cons.cc: New
test.
Tested x86_64-linux, committed to trunk.
commit 2
On Fri, Jan 11, 2019 at 11:42:31AM -0700, Jeff Law wrote:
> On 1/10/19 12:19 AM, Alan Modra wrote:
> > bb-reorder is quite seriously broken if get_attr_min_length should
> > return INT_MAX, which it does for hppa on branches with r267666.
> Presumably you're referring to the overflows and such?
Ye
This paper has been included in the C++20 draft, but the changes to add
noexcept can be made unconditionally, to apply for C++11 too.
* include/std/chrono (duration_values::zero(), duration_values::min())
(duration_values::max()): Add noexcept.
(duration::zero(), duration:
* doc/xml/manual/intro.xml: Include new section.
* doc/xml/manual/status_cxx2017.xml: Document more
implementation-defined properties of the library.
* doc/xml/manual/status_cxx2020.xml: Document C++2a status.
* doc/html/*: Regenerate.
Committed to trunk.
c
This patch implements the C++2a proposal to allow incomplete types in
std::reference_wrapper, which was previously undefined.
The change cannot be implemented for earlier standards, because prior to
C++2a std::reference_wrapper has a weak result type, so must inspect the
template argument to see
On 10/01/19 13:49 +, Jonathan Wakely wrote:
The C++2a draft specifies the value 201811L for this, but as an
extension we return the number of elements erased. This is expected to
be standardised, so the macro has the value 201900L until a proper value
is specified in the draft.
* inc
On 1/7/19 4:58 AM, Richard Biener wrote:
> On Mon, Jan 7, 2019 at 11:48 AM Andrew Stubbs wrote:
>>
>> New year ping!
>>
>> The last remaining middle-end patch was already applied, so it's only
>> the backend, config, and testsuite patches remaining to be committed.
>> And, it's mostly only the bac
On Fri, Jan 11, 2019 at 04:23:23PM -0500, Jason Merrill wrote:
> On 1/11/19 4:21 PM, Marek Polacek wrote:
> > On Fri, Jan 11, 2019 at 01:55:09PM -0500, Jason Merrill wrote:
> > > On 1/11/19 11:09 AM, Marek Polacek wrote:
> > > > On Mon, Jan 07, 2019 at 04:59:14PM -0500, Jason Merrill wrote:
> > > >
This patch by Cherry Zhang changes the Go frontend to pad structs
ending with a zero-sized field. For a struct with zero-sized last
field, the address of the field falls out of the object boundary,
which confuses the garbage collector. Pad an extra byte in this case.
Bootstrapped and ran Go tests
On 1/8/19 5:03 AM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
>>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
- /* Clobbering the STACK POINTER register is an error. */
+ /* Clobbered STACK POINTER register is no
On 1/8/19 8:21 AM, Andre Vieira (lists) wrote:
>
>
> On 07/01/2019 22:50, Jeff Law wrote:
>> On 1/7/19 7:42 AM, Andre Vieira (lists) wrote:
>>> Hi,
>>>
>>> This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
>>> The function is supposed to detect whether a register access o
The standard doesn't really talk about an expression depending on the number
of elements of a pack, but that's definitely an important form of template
argument dependence.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (instantiation_dependent_r): A template non-type parameter
The issue here was that we were cp_folding a location wrapper around a
lambda capture proxy before it had been mark_rvalue_used. I considered
adding mark_rvalue_use calls to build_new_op_1, but it seems appropriate to
have them in cp_fold_maybe_rvalue when we know we're trying to produce an
rvalue
On Fri, 2019-01-11 at 14:45 +, Richard Sandiford wrote:
>
> > +
> > +/* Return true for types that could be supported as SIMD return or
> > + argument types. */
> > +
> > +static bool supported_simd_type (tree t)
> > +{
> > + return (FLOAT_TYPE_P (t) || INTEGRAL_TYPE_P (t));
>
> We should
On 1/11/19 4:56 PM, Paolo Carlini wrote:
Hi,
On 11/01/19 22:22, Jason Merrill wrote:
On 1/11/19 4:13 PM, Paolo Carlini wrote:
Hi,
On 11/01/19 19:58, Jason Merrill wrote:
On 1/10/19 9:24 AM, Paolo Carlini wrote:
Hi again,
this one is also matter of consistency with, say, the precise
locati
On 1/6/19 4:34 PM, Martin Sebor wrote:
> Attached is an updated patch with the wording change to the manual
> discussed below and rebased on the top of today's trunk.
>
> Martin
>
> PS Thanks for the additional info, Iain.
>
> On 1/5/19 10:53 AM, Iain Sandoe wrote:
>>
>>> On 5 Jan 2019, at 17:39
Hi,
On 11/01/19 22:22, Jason Merrill wrote:
On 1/11/19 4:13 PM, Paolo Carlini wrote:
Hi,
On 11/01/19 19:58, Jason Merrill wrote:
On 1/10/19 9:24 AM, Paolo Carlini wrote:
Hi again,
this one is also matter of consistency with, say, the precise
location that we use for the error message at th
On Fri, 11 Jan 2019, Martin Sebor wrote:
> gcc/testsuite/ChangeLog:
>
> PR c/88718
> * gcc.dg/inline-40.c: New test.
> * gcc.dg/inline-41.c: New test.
We already have tests inline-40.c and inline-41.c; these need to be
renumbered accordingly.
> + if (add)
> + {
> +
On 1/11/19 4:21 PM, Marek Polacek wrote:
On Fri, Jan 11, 2019 at 01:55:09PM -0500, Jason Merrill wrote:
On 1/11/19 11:09 AM, Marek Polacek wrote:
On Mon, Jan 07, 2019 at 04:59:14PM -0500, Jason Merrill wrote:
On 1/7/19 4:29 PM, Marek Polacek wrote:
This patch fixes bogus -Wredundant-move warn
On 1/11/19 4:13 PM, Paolo Carlini wrote:
Hi,
On 11/01/19 19:58, Jason Merrill wrote:
On 1/10/19 9:24 AM, Paolo Carlini wrote:
Hi again,
this one is also matter of consistency with, say, the precise
location that we use for the error message at the beginning of
check_methods. Indeed, the seq
On Fri, Jan 11, 2019 at 01:55:09PM -0500, Jason Merrill wrote:
> On 1/11/19 11:09 AM, Marek Polacek wrote:
> > On Mon, Jan 07, 2019 at 04:59:14PM -0500, Jason Merrill wrote:
> > > On 1/7/19 4:29 PM, Marek Polacek wrote:
> > > > This patch fixes bogus -Wredundant-move warnings reported in 88692 and
Hi,
On 11/01/19 19:58, Jason Merrill wrote:
On 1/10/19 9:24 AM, Paolo Carlini wrote:
Hi again,
this one is also matter of consistency with, say, the precise
location that we use for the error message at the beginning of
check_methods. Indeed, the sequence of error messages of
g++.dg/inherit
On 12/30/18 9:50 AM, H.J. Lu wrote:
> On Wed, Nov 28, 2018 at 12:21 PM Jan Hubicka wrote:
>>
>>> On 11/28/18 12:48 PM, H.J. Lu wrote:
On Mon, Nov 5, 2018 at 7:29 AM Jan Hubicka wrote:
>
>> On 11/5/18 7:21 AM, Jan Hubicka wrote:
Did you mean "the nearest common domin
On 1/7/19 3:42 PM, Jakub Jelinek wrote:
> Hi!
>
> On Thu, May 31, 2018 at 01:34:19PM -0400, Jason Merrill wrote:
>> Returning error_mark_node from omp_copy_decl and then continuing seems
>> like the problem, then. Would it really be that hard to return an
>> uninitialized variable instead?
>
> T
On 1/8/19 11:35 PM, Sebastian Huber wrote:
> Copy code example for fetch and nand from "Legacy __sync Built-in
> Functions for Atomic Memory Access" to "Built-in Functions for Memory
> Model Aware Atomic Operations".
>
> gcc/
>
> * doc/extend.texi (Built-in Functions for Memory Model Aware
On 1/3/19 9:13 PM, Martin Sebor wrote:
> The attached patch corrects a couple of minor typos in the description
> of -Wmemset-transposed-args. It also tweaks the text a bit for better
> readability.
>
> Martin
>
> gcc-doc-memset-transposed-args.diff
>
> gcc/ChangeLog:
>
> * invoke.texi (
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00139.html
On 1/3/19 9:13 PM, Martin Sebor wrote:
The attached patch corrects a couple of minor typos in the description
of -Wmemset-transposed-args. It also tweaks the text a bit for better
readability.
Martin
The attached patch extends the detection of references to static
variables in inline functions to the function signatures, including
their return type. Since the declaration of a function need not be
yet available at the time the static is referenced (e.g., when it's
referenced in the functions r
On 12/30/18 4:51 AM, Jozef Lawrynowicz wrote:
> There have been some ICEs in the past for msp430-elf with the large
> memory model (20-bit pointers), caused by SET_{DECL,TYPE}_ALIGN being called
> with an argument which resolves to 20 i.e. POINTER_SIZE,
> or the default value of TARGET_VTABLE_ENTRY
Jeff Law writes:
> On 1/10/19 12:19 AM, Alan Modra wrote:
>> bb-reorder is quite seriously broken if get_attr_min_length should
>> return INT_MAX, which it does for hppa on branches with r267666.
> Presumably you're referring to the overflows and such?
>
>
>>
>> I went the wrong way with my min_a
This patch adds code for little endian case of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 267854.
Index: ChangeLog
===
--- ChangeLog (r
On Fri, Jan 11, 2019 at 10:50 AM Jeff Law wrote:
> I think this needs to defer to gcc-10
Ok, will resend when in stage1.
--
Thanks.
-- Max
On 1/7/19 3:51 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in that PR, we have a SI->DImode zero extension and RA happens
> to choose to zero extend from a SImode memory slot which is the low part of
> the DImode memory slot into which the zero extension is to be stored.
> Unfortunately, the
On 1/10/19 9:24 AM, Paolo Carlini wrote:
Hi again,
this one is also matter of consistency with, say, the precise location
that we use for the error message at the beginning of check_methods.
Indeed, the sequence of error messages of g++.dg/inherit/pure1.C reflect
that. Tested x86_64-linux.
On 1/11/19 1:36 PM, Tobias Burnus wrote:
Dear Jason, dear all,
Jason Merrill wrote on 5 Dec 2018:
You can get at the destructor with CLASSTYPE_DESTRUCTOR rather than walking
through TYPE_FIELDS. I'd also check DECL_DEFAULTED_IN_CLASS_P.
I'd also do this in maybe_emit_vtables rather than here,
On 1/11/19 11:09 AM, Marek Polacek wrote:
On Mon, Jan 07, 2019 at 04:59:14PM -0500, Jason Merrill wrote:
On 1/7/19 4:29 PM, Marek Polacek wrote:
This patch fixes bogus -Wredundant-move warnings reported in 88692 and 87882.
To quickly recap, this warning is supposed to warn for cases like
stru
On 1/8/19 3:38 PM, Max Filippov wrote:
> Hello,
>
> I'm implementing MI thunk generation for the xtensa target and I've got
> an issue that when my code generates a constant it is missing in the
> resulting assembly. This happens because a constant pool output happens
> inside the assemble_start_f
Hi Srinath
On 10/01/19 19:20, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch implements the ACLE hint intrinsics (nop,yield,wfe,wfi,sev
> and sevl), for all ARM targets.
>
> The intrinsics specification will be published on the Arm website [1].
>
> [1]
> http://infocenter.arm.com/help/top
On 1/10/19 12:19 AM, Alan Modra wrote:
> bb-reorder is quite seriously broken if get_attr_min_length should
> return INT_MAX, which it does for hppa on branches with r267666.
Presumably you're referring to the overflows and such?
>
> I went the wrong way with my min_attr_value r267666 change. I
On 1/10/19 6:44 AM, Richard Biener wrote:
>
> I am testing the following patch teaching VRP predicate analysis about
>
> __x.5_4 = (long unsigned int) "hello";
> __y.6_5 = (long unsigned int) _3;
> if (__x.5_4 != __y.6_5)
>
> so that we know sth about the relation of the converted entities
Dear Jason, dear all,
Jason Merrill wrote on 5 Dec 2018:
> You can get at the destructor with CLASSTYPE_DESTRUCTOR rather than walking
> through TYPE_FIELDS. I'd also check DECL_DEFAULTED_IN_CLASS_P.
> I'd also do this in maybe_emit_vtables rather than here, so that it only
> happens once per cl
On 1/4/19 3:54 PM, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes ICU miscompilation, where an initial part of a
> buffer is initializer from non-zero terminated string literal (in ICU
> actually from an array of non-zero chars that the FE newly turns into
> non-zero terminated string li
Hi Srinath
On 10/01/19 19:20, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch implements the ACLE hint intrinsics (nop, yield, wfe, wfi,
> sev and sevl), for AArch64.
>
> The instructions are documented in the ArmARM[1] and the intrinsics
> specification will be
> published on the Arm websi
On 1/11/19 6:34 AM, Jakub Jelinek wrote:
> Hi!
>
> The following patch
> 1) mentions (partial) OpenMP 5.0 support and __builtin_convertvector in
>c-family section of gcc-9/changes.html
> 2) mentions C++2a progress in similar way how we've done it in
>gcc-8/changes.html (the list doesn't in
On Fri, 11 Jan 2019, Martin Liška wrote:
> +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix.
> */
Actually, it should be prepending target_system_root, but followed by
target_sysroot_hdrs_suffix rather than target_sysroot_suffix. That is,
this function should be fo
On 1/11/19 9:42 AM, Jakub Jelinek wrote:
> Hi!
>
> Since r264052 i386.h includes insn-attr-common.h, which unfortunately isn't
> installed, because all we install is:
> $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def)
> and thus plugins compiled against installed tree will not work on x86
> if t
Hi!
Since r264052 i386.h includes insn-attr-common.h, which unfortunately isn't
installed, because all we install is:
$(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def)
and thus plugins compiled against installed tree will not work on x86
if they need to include anything that includes tm.h.
Below
On 01/11/2019 04:58 AM, Richard Sandiford wrote:
Hi Vlad,
I think for !WORDS_BIG_ENDIAN the equivalent problem to:
|| !TEST_HARD_REG_BIT (reg_class_contents[rclass],
hard_regno - nregs_diff)))
would be:
|| !TEST_HARD_RE
On Mon, Jan 07, 2019 at 04:59:14PM -0500, Jason Merrill wrote:
> On 1/7/19 4:29 PM, Marek Polacek wrote:
> > This patch fixes bogus -Wredundant-move warnings reported in 88692 and
> > 87882.
> >
> > To quickly recap, this warning is supposed to warn for cases like
> >
> > struct T { };
> >
> >
On 11/01/19 16:51 +0100, Jakub Jelinek wrote:
Hi!
Seems __cpp_lib_is_constant_evaluated should be defined to 201811L
if std::is_constant_evaluated() is implemented.
Ok for trunk?
OK, thanks.
2019-01-11 Jakub Jelinek
* include/std/type_traits (__cpp_lib_is_constant_evaluated): De
Hi!
I've noticed we don't have any feature test macros in the table for C++20,
even when a couple of the features have them defined.
Ok for wwwdocs?
--- htdocs/projects/cxx-status.html.jj 2019-01-11 14:24:06.524979265 +0100
+++ htdocs/projects/cxx-status.html 2019-01-11 16:41:16.650157887 +
Hi!
Seems __cpp_lib_is_constant_evaluated should be defined to 201811L
if std::is_constant_evaluated() is implemented.
Ok for trunk?
2019-01-11 Jakub Jelinek
* include/std/type_traits (__cpp_lib_is_constant_evaluated): Define.
* include/std/version (__cpp_lib_is_constant_eval
On 1/9/19 6:15 PM, Joseph Myers wrote:
> On Wed, 9 Jan 2019, Martin Liška wrote:
>
>> Hi.
>>
>> May I please ping that Joseph. The provided patch should be applicable and
>> I would need help with the proper locations.
>
> I'm not clear if there is a specific question here, or a patch needing
>
PR libstdc++/88802
* include/bits/functional_hash.h (hash): Define
specialization for C++17 (P0513R0, LWG 2817).
* testsuite/20_util/hash/nullptr.cc: New test.
Tested x86_64-linux, committed to trunk.
commit 3ade1f14e79b8bbb4939244e9125f9043de6
Author: Jonatha
Steve Ellcey writes:
> Here is an updated version of the GCC patch to enable SIMD functions on
> Aarch64. There are a number of changes from the last patch.
>
> I reduced the shared code changes, there is still one change in shared code
> (omp-simd-clone.c) to call targetm.simd_clone.adjust from
Hi All,
The test declared the fp16 requirement, but didn't add the options causing it to
fail when the target doesn't have it on by default.
Bootstrapped Regtested on arm-none-Linux-gnueabihf and no issues.
committed under the gcc obvious rules.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
2019-01-
On Fri, 2019-01-11 at 12:30 +0100, Jakub Jelinek wrote:
>
> > Yeah, like you say, this was originally posted in stage 1 and is the
> > last patch in the series. Not committing it would leave the work
> > incomplete in GCC 9. The problem is that we're now in stage 4 rather
> > than stage 3.
> >
Hi!
The following patch
1) mentions (partial) OpenMP 5.0 support and __builtin_convertvector in
c-family section of gcc-9/changes.html
2) mentions C++2a progress in similar way how we've done it in
gcc-8/changes.html (the list doesn't include all features, feel free
to suggest what should
On 1/9/19 9:43 AM, Richard Biener wrote:
> On Tue, 8 Jan 2019, Jakub Jelinek wrote:
>
>> Hi!
>>
>> As mentioned in the PR, if a VECTOR_CST is not VECTOR_CST_STEPPED_P,
>> it is sufficient to recurse just on all the encoded elt, because if
>> the vector has more elts than encoded, all the remaining
On Fri, Jan 11, 2019 at 01:53:21PM +0100, Richard Biener wrote:
> >The canary slot in the stack frame is written in the prologue using
> >MEM_VOLATILE_P store, so we never consider those to be DSEd and is only
> >read
> >in the epilogue, so it shouldn't alias any other stores.
> >Similarly, __stack
On January 10, 2019 11:38:55 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, RTL DSE doesn't do much with
>-fstack-protector*,
>because the stack canary test in the epilogue of instrumented functions
>is a MEM_VOLATILE_P read out of the crtl->stack_protect_guard ssp
>canary
>sl
On January 10, 2019 11:25:59 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>r191883 seems to have introduced a pasto:
>--- trunk/gcc/passes.c 2012/10/01 00:17:52 191882
>+++ trunk/gcc/passes.c 2012/10/01 05:43:06 191883
>@@ -231,27 +231,23 @@
> timevar_push (TV_DUMP);
>if (profile_arc_flag
On Thu, Jan 10, 2019 at 09:56:28PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote:
> >> > "noreturn"... What would that mean, *exactly*? It cannot execute any
> >> > code the compiler can see, so such asm is better of
Segher Boessenkool writes:
>> I think it would act like a noreturn call to an unknown function.
>
> Except it won't behave like a call otherwise (on Power all calls force a
> stack frame, for example; and on all targets noreturn calls do the same
> currently I think?)
I agree no current asm would
On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote:
> >> Bernd Edlinger writes:
> >> > Meanwhile I found out, that the stack clobber has only been ignored up to
> >> > gcc-5 (at leas
On Thu, Jan 10, 2019 at 11:25:59PM +0100, Jakub Jelinek wrote:
> So, in the end, the combiner statistics was emitted in profile_estimate dump
> and on the PR88714 issue suggested there is a difference already in the
> profile_estimate dump, when actually the IL changed only during pre and of
> cour
Hi,
When using a compiler build with:
...
+#define PTX_DEFAULT_VECTOR_LENGTH PTX_CTA_SIZE
...
consider a test-case:
...
int
main (void)
{
#pragma acc parallel vector_length (64)
#pragma acc loop worker
for (unsigned int i = 0; i < 32; i++)
#pragma acc loop vector
for (unsign
Hi,
Move the defition of PTX_CTA_SIZE up in nvptx.c.
Committed to trunk.
Thanks,
- Tom
[nvptx] Move PTX_CTA_SIZE up
2019-01-11 Tom de Vries
* config/nvptx/nvptx.c (PTX_CTA_SIZE): Move up.
---
gcc/config/nvptx/nvptx.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(
Hi,
Before the commit "[libgomp, testsuite, openacc] Don't use const int for
dimensions", the "const int" construct was used to set launch dimensions in
reductions-[1-5].c. In the case of -xc -O0, the const int is implemented as a
variable by the C front-end. Consequently, the nvptx back-end gen
Hi,
Add a test-case that tests the "insufficient resources" fatal in the nvptx
libgomp plugin.
Committed to trunk.
Thanks,
- Tom
[nvptx, testsuite, openacc, libgomp] Add insufficient-resources.c
2019-01-11 Tom de Vries
* testsuite/libgomp.oacc-c-c++-common/insufficient-resources.c:
PR libstdc++/88125
* config/abi/pre/gnu.ver (GLIBCXX_3.4.6): Remove unused duplicate
pattern for std::basic_stringbuf::str().
Tested x86_64-linux, committed to trunk.
commit 561a3110e71ba2dbe91681b6abe10cbf3dfb4288
Author: Jonathan Wakely
Date: Fri Jan 11 11:16:21 201
On Fri, Jan 11, 2019 at 11:22:59AM +, Richard Sandiford wrote:
> Steve Ellcey writes:
> > If this looks good to you can I go ahead and check it in? I know
> > we are in Stage 3 now, but my recollection is that patches that were
> > initially submitted during Stage 1 could go ahead once approv
Steve Ellcey writes:
> OK, I fixed the issues in your last email. I initially found one
> regression while testing. In lra_create_live_ranges_1 I had removed
> the 'call_p = false' statement but did not replaced it with anything.
> This resulted in no regressions on aarch64 but caused a single
>
Hi Steve,
Yes, that's good for trunk.
Thanks
Paul
On Fri, 11 Jan 2019 at 01:16, Steve Kargl
wrote:
>
> An entry-name obtains the elemental attribute from its containing
> procedure. F2018:C1546 prohibits an procedure from having a BIND(C)
> attribute. BIND(C) can appear on the entry-stmt lin
On 11/01/19 10:07 +0100, Rainer Orth wrote:
Hi Jonathan,
this patch broke Solaris bootstrap:
ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol 'std::basic_ostream >::operator<<(decltype(nullptr))': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol 'std::basic_ostream
Hi Christoph,
The arm one is a testism, I have a validated patch that I will commit soon.
The aarch64 one is a big-endian lane ordering issue, I had completely forgotten
to test big-endian,
Patch for that is going through validation now.
Will submit the aarch64 one soon, sorry for the mess, spli
Hi!
As mentioned in the PR, this is a LRA hang introduced with the
r266422 IRA costs change and which went away with r266862 IRA costs change.
Tested on x86_64-linux and i686-linux plus tested with older cc1 from end of
November where it timeouts, committed to trunk as obvious.
2019-01-11 Jakub
Hi Tamar,
On Thu, 10 Jan 2019 at 16:41, Tamar Christina wrote:
>
> Hi Christoph,
>
> It was introduced in a small refactoring after which I only retested the
> testcases I added,which don't trigger the issue.
>
> In any case it's a trivial fix and I'll submit a patch in a bit.
>
> Tamar
>
> ___
Hi Vlad,
Vladimir Makarov writes:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
>
> The patch was bootstrapped and tested on x86-64 and ppc64 (be).
>
> Committed as rev. 267823.
>
> Index: ChangeLog
>
On Fri, Jan 04, 2019 at 11:54:46PM +0100, Jakub Jelinek wrote:
> The following patch fixes ICU miscompilation, where an initial part of a
> buffer is initializer from non-zero terminated string literal (in ICU
> actually from an array of non-zero chars that the FE newly turns into
> non-zero termin
Hi Jonathan,
>>this patch broke Solaris bootstrap:
>>
>>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol 'std::basic_ostream>std::char_traits >::operator<<(decltype(nullptr))': symbol version
>>conflict
>>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol
>>'std::basic_ostream
>>>::operator<<
83 matches
Mail list logo
