On Fri, Dec 14, 2018 at 10:59 AM Zhouyi Zhou wrote:
>
> Hello,
>
> Ping for https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00151.html
>
> By the way, are there any GCC open project for volunteer beginners to
>
> do in spare time.
>
> Thanks in advance for your feedback,
>
> Zhouyi
Hello,
On 1/29/19 11:23 AM, Jakub Jelinek wrote:
--- gcc/gimple-fold.c (revision 268086)
+++ gcc/gimple-fold.c (working copy)
@@ -6715,12 +6715,14 @@ fold_array_ctor_reference (tree type, tree ctor,
elt_size = wi::to_offset (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (ctor;
/* When TYPE is
In this PR, instantiating the static thunk returned from the generic lambda
conversion function template was using normal overload resolution, which
meant calling an extra constructor when forwarding its argument. Fixed by
special-casing thunk calls significantly more.
Tested
On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
>
> My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
> happens to be the same problem as 80864 and its many dupes, something I'd
> been meaning to fix for a long time.
>
> Basically, the problem is repeated reshaping
On Mon, Jan 28, 2019 at 11:37 PM Alexandre Oliva wrote:
> On Jan 27, 2019, Jason Merrill wrote:
>
> >> + ??? How do we
> >> + tell apart a partial from a full explicit specialization in a
> >> + non-template context? */
>
> > We don't need to tell them apart here, the caller checks
On Tue, Jan 29, 2019 at 5:54 PM Marek Polacek wrote:
>
> As a consequence of r268343, the following tests need to be updated to
> expect the error in all modes.
>
> Sorry for the breakage.
>
> Tested on x86_64-linux, ok for trunk?
OK, thanks.
On Tue, Jan 29, 2019 at 3:17 PM Segher Boessenkool
wrote:
>
> On Sun, Jan 27, 2019 at 01:53:18PM -0800, Ian Lance Taylor wrote:
> > You need to use a temporary file, such as $@.tmp, for the final sed
> > command, followed by a mv to $@. Otherwise a failure in the sed will
> > leave what appears
PR c++/87996 is a P2 regression reported in December about C++ error
messages for declarations of arrays larger than PTRDIFF_MAX saying
the sizes of the arrays are negative. GCC 7 says they're negative.
The attached patch corrects that by issuing messages that, besides
reflecting the correct
On Tue, Jan 29, 2019 at 02:51:30PM -0800, Andrew Pinski wrote:
> On Tue, Jan 29, 2019 at 2:36 PM Steve Ellcey wrote:
> > So the various tests that started failing with r265398 seem to need
> > different fixes. This particular fix is for the
> > gcc.target/aarch64/lsl_asr_sbfiz.c failure. The
My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
happens to be the same problem as 80864 and its many dupes, something I'd
been meaning to fix for a long time.
Basically, the problem is repeated reshaping of a constructor, once when
parsing, and then again when
On Sun, Jan 27, 2019 at 01:53:18PM -0800, Ian Lance Taylor wrote:
> You need to use a temporary file, such as $@.tmp, for the final sed
> command, followed by a mv to $@. Otherwise a failure in the sed will
> leave what appears to be an up to date file.
Or you just set .DELETE_ON_ERROR, we
On Jan 29, 2019, Alexandre Oliva wrote:
> The single caller does, indeed, but the function does not make that a
> requirement, so others might call it and fail to check it. Should that
> test be moved here too?
Like this... Regstrapped on x86_64-linux-gnu. Ok to install?
[PR87770] test
As a consequence of r268343, the following tests need to be updated to
expect the error in all modes.
Sorry for the breakage.
Tested on x86_64-linux, ok for trunk?
2019-01-29 Marek Polacek
PR testsuite/89110
* g++.dg/other/nontype-1.C: Expect error in all modes.
*
On Tue, Jan 29, 2019 at 2:36 PM Steve Ellcey wrote:
>
> So the various tests that started failing with r265398 seem to need
> different fixes. This particular fix is for the
> gcc.target/aarch64/lsl_asr_sbfiz.c failure. The problem is that the
> instructions we are trying to match to
Hi Steve,
Thanks for the patch, and OK to commit.
Committed to trunk (r268372). Thanks!
I will backport to the affected branches later in the week.
Regards
Thomas
So the various tests that started failing with r265398 seem to need
different fixes. This particular fix is for the
gcc.target/aarch64/lsl_asr_sbfiz.c failure. The problem is that the
instructions we are trying to match to *ashiftsi_extv_bfiz now have
explicit subregs in them where they didn't
On Tue, 29 Jan 2019, Jakub Jelinek wrote:
> Hi!
>
> While gotos across automatic compound literal initialization do
> cross their initialization, I can't think of any way how could code after
> the label to which the goto bypasses it get access to the uninitialized
> compound literal. Even if
On Tue, Jan 29, 2019 at 4:49 PM Jakub Jelinek wrote:
>
> On Tue, Jan 29, 2019 at 04:29:59PM -0500, Jason Merrill wrote:
> > On Tue, Jan 29, 2019 at 1:38 PM Jakub Jelinek wrote:
> > >
> > > Emitting this warning for internal linkage functions makes no sense to me,
> > > the ABI of those functions
On Tue, Jan 29, 2019 at 04:29:59PM -0500, Jason Merrill wrote:
> On Tue, Jan 29, 2019 at 1:38 PM Jakub Jelinek wrote:
> >
> > Emitting this warning for internal linkage functions makes no sense to me,
> > the ABI of those functions is solely under control of the compiler that
> > knows the callee
On Tue, Jan 29, 2019 at 10:12:49PM +0100, Thomas König wrote:
> Hi Steve,
>
> >>PR fortran/57048
> >>* interface.c (gfc_compare_types): If a derived type and an
> >>integer both have a derived type, and they are identical,
> >>this is a C binding type and compares equal.
> >
> >
On Tue, Jan 29, 2019 at 1:38 PM Jakub Jelinek wrote:
>
> Emitting this warning for internal linkage functions makes no sense to me,
> the ABI of those functions is solely under control of the compiler that
> knows the callee as well as all callers and can do anything it wants.
> I've added
Hi Steve,
PR fortran/57048
* interface.c (gfc_compare_types): If a derived type and an
integer both have a derived type, and they are identical,
this is a C binding type and compares equal.
I don't understand this sentence. How can an INTEGER have a
derived
On Tue, Jan 29, 2019 at 08:46:40PM +0100, Uros Bizjak wrote:
>
> When changing trap masks, it is necessary to clear pending traps to
> prevent firing spurious interrupts. Attached patch also optimizes
> set_fpu_trap_exceptions function considerably to only call
> feenableexcept and
On 29/01/19 14:12 -0500, Marek Polacek wrote:
On Tue, Jan 29, 2019 at 07:07:31PM +, Romain GEISSLER wrote:
> Le 29 janv. 2019 à 20:03, Marek Polacek a écrit :
>
> On Fri, Jan 25, 2019 at 03:06:41PM +, Jonathan Wakely wrote:
>
> Indeed. Romain, are you going to submit a followup patch
Hello!
When changing trap masks, it is necessary to clear pending traps to
prevent firing spurious interrupts. Attached patch also optimizes
set_fpu_trap_exceptions function considerably to only call
feenableexcept and fedisableexcept functions each once.
2019-01-29 Uroš Bizjak
*
On Mon, Jan 28, 2019 at 08:49:52PM +0100, Thomas König wrote:
>
> the attached patch fixes a long-time regression where a c_funptr from a
> module could not be found.
>
> The solution is a bit of a hack, but so is our whole implementation of
> the C interop stuff.
>
> Regression-tested. OK for
On Tue, Jan 29, 2019 at 07:07:31PM +, Romain GEISSLER wrote:
> > Le 29 janv. 2019 à 20:03, Marek Polacek a écrit :
> >
> > On Fri, Jan 25, 2019 at 03:06:41PM +, Jonathan Wakely wrote:
> >
> > Indeed. Romain, are you going to submit a followup patch to address this?
> >
> > Marek
>
>
> Le 29 janv. 2019 à 20:03, Marek Polacek a écrit :
>
> On Fri, Jan 25, 2019 at 03:06:41PM +, Jonathan Wakely wrote:
>
> Indeed. Romain, are you going to submit a followup patch to address this?
>
> Marek
Hi,
I submitted the original patch because it was not written by me but by Davide,
On Fri, Jan 25, 2019 at 03:06:41PM +, Jonathan Wakely wrote:
> On 20/10/18 12:18 +0200, Romain Geissler wrote:
> > Hi,
> >
> > I would like to raise again the question of supporting -fuse-ld=ldd. A
> > patch implementing it was already submitted in
> >
Hi!
Emitting this warning for internal linkage functions makes no sense to me,
the ABI of those functions is solely under control of the compiler that
knows the callee as well as all callers and can do anything it wants.
I've added DECL_PRESERVE_P to the test, so if somebody uses used attribute
Hi!
While gotos across automatic compound literal initialization do
cross their initialization, I can't think of any way how could code after
the label to which the goto bypasses it get access to the uninitialized
compound literal. Even if the complit address is taken, it can be assigned
to some
On Tue, Jan 22, 2019 at 06:18:28PM -0700, Martin Sebor wrote:
> PS In GCC 10, unless there is an important use case that escapes
> me, I think GCC should warn for zero-length non-member array
> objects, or perhaps even for internal struct members (those followed
> by another member). Not to avoid
On 28/01/2019 18:00, Thomas Schwinge wrote:
On Fri, 25 Jan 2019 15:09:49 +0100, Gergö Barany
wrote:
OK for openacc-gcc-8-branch?
Yes.
Thanks, committed along with the other patches I posted at the same time
(Rework OpenACC Fortran DO loop initialization, Remove spurious OpenACC
error on
On 1/29/19 5:44 AM, Richard Sandiford wrote:
Martin Sebor writes:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01340.html
This is a straightforward fix for an ICE. I will commit it tomorrow
unless there are suggestions for other changes.
That's not how it works. Please wait for the
In 89089, we were never actually setting DECL_SIZE on an empty data member,
because its type is a POD, so we didn't set it in the maybe-overlapping
section. Fixed by also handling empty types there.
In 88865, we were failing to consider empty data members in
include_empty_classes. Fixed by
This libgo patch by Cherry Zhang fixes sigprof frame counting. If
sigtramp and sigtrampgo are both on stack, n -= framesToDiscard is
executed twice, which should actually run only once. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index:
On Tue, Jan 22, 2019 at 1:43 PM Tom de Vries wrote:
>
> What is an acceptable way to proceed here? I could add a
> libbacktrace_nodwarf.la, and have the test-case add a -DFOR_TESTING or
> some such when compiling dwarf.c, and add the necessary handling in
> dwarf.c conditional on FOR_TESTING.
On Tue, Jan 29, 2019 at 12:24 AM Tom de Vries wrote:
>
> On 27-01-19 22:53, Ian Lance Taylor wrote:
> > On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries wrote:
> >>
> >> On 25-01-19 18:15, Nathan Sidwell wrote:
> >>> On 1/25/19 5:28 AM, Tom de Vries wrote:
>
> This patch fixes it by
Yet another trivial fix for a Solaris libphobos testsuite failure:
FAIL: libphobos.shared/load.d -shared-libphobos -ldl (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/libphobos/testsuite/libphobos.shared/load.d:9:
error: static assert "unimplemented"
I guess this is
This patch fixes two gdc testsuite failures on Solaris:
UNRESOLVED: gdc.test/runnable/dhry.d compilation failed to produce executable
UNRESOLVED: gdc.test/runnable/dhry.d -shared-libphobos compilation failed to
produce executable
gdc.test/runnable/dhry.d:489:16: error: undefined identifier
2019-xx-xx Vineet Gupta
* gcc/config.gcc: Force .init_array for ARC
Signed-off-by: Vineet Gupta
---
Hi,
Thank you for your contribution. I'll push it asap.
Cheers,
Claudiu
Martin Sebor writes:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01340.html
>
> This is a straightforward fix for an ICE. I will commit it tomorrow
> unless there are suggestions for other changes.
That's not how it works. Please wait for the patch to be approved
by someone.
Thanks,
With the set of libphobos Solaris patches just posted, it would become
possible to enable libphobos on Solaris 11/x86 by default.
This is what this patch does.
* It uses a LIBPHOBOS_SUPPORTED variable both in toplevel configure and
libphobos/configure.tgt, following what libvtv does.
* It's
Solaris ld only gained support for section bracketing in Solaris 11.4.
Fortunately, in gdc it is only used for the minfo section, so it's easy
to provide a workaround by adding two additional startup files
drt{begin,end}.o which define __start_minfo and __stop_minfo.
This patch does just that.
On Tue, Jan 29, 2019 at 11:37 AM Andrew Stubbs wrote:
>
> My recent patch to permit GCN testing using an LLVM assembler and linker
> has caused some noise in the log files for libgomp testing.
>
> There are lots of messages like this:
>
>fatal error: GCC is not configured to support
Before Solaris 11.5, struct dl_phdr_info lacked the dlpi_tls_modid
member. While the support might be backported to Solaris 11.4, it
certainly won't to previous Solaris releases. To work around this, I've
used the following patch. Again, it's pretty straightforward.
Point of note:
* On
Here's the patch I mentioned in
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01661.html
to work around an amd64 Solaris ld bug. I'm just posting it for
reference now: until it's clear if a fix will make it into Solaris 11.5
or not, there's no point in applying it yet.
Still, review
My recent patch to permit GCN testing using an LLVM assembler and linker
has caused some noise in the log files for libgomp testing.
There are lots of messages like this:
fatal error: GCC is not configured to support amdgcn-unknown-amdhsa as
offload target
These messages are harmless;
I've successfully been using a late prototype of an implementation of
the dlpi_tls_modid field of struct dl_phdr_info on Solaris 11.5 Beta.
This allowed me to get pretty reasonable test results using
sections_elf_shared.d on Solaris.
This pretty straightforward patch implements this. Only a few
On Tue, 29 Jan 2019 at 11:12, Iain Sandoe wrote:
>
> Hi Christophe,
>
> > On 29 Jan 2019, at 09:58, Christophe Lyon
> > wrote:
> >
> > On Sat, 26 Jan 2019 at 17:43, Iain Sandoe wrote:
> >>
> >> Hi Christophe,
> >>
> >>> On 23 Jan 2019, at 13:16, Christophe Lyon
> >>> wrote:
> >>
> >>>
Hi Christophe,
> On 29 Jan 2019, at 09:58, Christophe Lyon wrote:
>
> On Sat, 26 Jan 2019 at 17:43, Iain Sandoe wrote:
>>
>> Hi Christophe,
>>
>>> On 23 Jan 2019, at 13:16, Christophe Lyon
>>> wrote:
>>
>>> dg-extract-results currently moves lines like
>>> WARNING: program timed out
>>>
On Tue, 29 Jan 2019 at 09:52, Rainer Orth wrote:
>
> I've seen the new gdc.dg/pr89042?.d tests FAIL in a parallel multilib
> bootstrap on i386-pc-solaris2.11:
>
> +FAIL: gdc.dg/pr89042a.d -O0 (test for excess errors)
> +UNRESOLVED: gdc.dg/pr89042a.d -O0 compilation failed to produce
On Sat, 26 Jan 2019 at 17:43, Iain Sandoe wrote:
>
> Hi Christophe,
>
> > On 23 Jan 2019, at 13:16, Christophe Lyon
> > wrote:
>
> > dg-extract-results currently moves lines like
> > WARNING: program timed out
> > at the end of each .exp section when it generates .sum files.
> >
> > This is
I've seen the new gdc.dg/pr89042?.d tests FAIL in a parallel multilib
bootstrap on i386-pc-solaris2.11:
+FAIL: gdc.dg/pr89042a.d -O0 (test for excess errors)
+UNRESOLVED: gdc.dg/pr89042a.d -O0 compilation failed to produce executable
+FAIL: gdc.dg/pr89042a.d -O0 -frelease (test for
On 27-01-19 22:53, Ian Lance Taylor wrote:
> On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries wrote:
>>
>> On 25-01-19 18:15, Nathan Sidwell wrote:
>>> On 1/25/19 5:28 AM, Tom de Vries wrote:
This patch fixes it by passing "" instead of NULL, in the call to
elf_add at line 3083 (for
55 matches
Mail list logo
