Hi Uros and all:
This patch is about to enable support for AVX512_VP2INTERSECT which will
be in Willow Cove. There are two instructions for AVX512_VP2INTERSECT:
VP2INTERSECTD and VP2INTERSECTQ. More details please refer to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #18 from Keith Thompson ---
Something I probably should have noticed earlier:
Why was this bug closed as a duplicate of bug 11234?
Bug 11234 complains that conversions between function pointer and void*
are accepted. This bug is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90769
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90737
Martin Sebor changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90737
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Thu Jun 6 02:53:01 2019
New Revision: 271985
URL: https://gcc.gnu.org/viewcvs?rev=271985=gcc=rev
Log:
PR c/90737 - [8/9/10 Regression] inconsistent address of a local converted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90769
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90769
--- Comment #1 from Barry Revzin ---
Sorry, more reduced:
#include
enum E {A, B};
struct X
{
template = 0>
constexpr X(int v);
template = 0>
operator OUT() const;
};
#ifdef WORKS
bool operator!=(X const& lhs, int) {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90769
Bug ID: 90769
Summary: Template instantiation recursion when trying to do a
conversion template
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity:
Hi Richard,
Thanks for the review. Attached is the latest patch.
For testcase like cond_arith_1.c, with the patch, gcc ICE in fwprop. I
am limiting fwprop in cases like this. Is there a better fix for this?
index cf2c9de..2c99285 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -1358,6 +1358,15
On Thu, Jun 6, 2019 at 6:18 AM Jeff Law wrote:
>
> On 6/5/19 1:39 AM, Hongtao Liu wrote:
> > Hi Jeff and Jakub:
> > When adding new intrinsics(PR target/89803), i found vfpclassp[sd],
> > vfpclasss[sd] patterns didn't support memory operand which is
> > supported in instructions. So this patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89803
Hongtao.liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
Bug 88918 depends on bug 89803, which changed state.
Bug 89803 Summary: Missing AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89803
What|Removed |Added
In the Go runtime there are specialized fast map routines for certain
kep types. This Go frontend patch by Cherry Zhang lets the compiler
make use of thesefunctions, instead of always using the generic ones.
As we now generate multiple versions of map delete calls, to make
things easier we delay
On Wed, Jun 05, 2019 at 05:02:53PM -0600, Jeff Law wrote:
> On 6/2/19 6:28 AM, Segher Boessenkool wrote:
> > On Sat, Jun 01, 2019 at 11:41:30PM +, Fredrik Hederstierna wrote:
> >> +(define_peephole2
> >> + [(set (match_operand:SI 0 "arm_general_register_operand" "")
> >> +
On 6/3/19 11:01 AM, Yoshinori Sato wrote:
> On Sun, 02 Jun 2019 22:12:37 +0900,
> Oleg Endo wrote:
>>
>> On Sun, 2019-06-02 at 20:26 +0900, Yoshinori Sato wrote:
>>> On Fri, 31 May 2019 09:16:18 +0900,
>>> Jeff Law wrote:
On 5/29/19 12:27 PM, Jeff Law wrote:
> On 5/23/19 6:05 AM,
On 6/2/19 5:26 AM, Yoshinori Sato wrote:
> On Fri, 31 May 2019 09:16:18 +0900,
> Jeff Law wrote:
>>
>> On 5/29/19 12:27 PM, Jeff Law wrote:
>>> On 5/23/19 6:05 AM, Yoshinori Sato wrote:
I ported linux kernel to Renesas RX.
rx-*-elf target output a binary different from the standard
On 6/2/19 6:28 AM, Segher Boessenkool wrote:
> On Sat, Jun 01, 2019 at 11:41:30PM +, Fredrik Hederstierna wrote:
>> +(define_peephole2
>> + [(set (match_operand:SI 0 "arm_general_register_operand" "")
>> + (match_operand:SI 1 "arm_general_register_operand" ""))
>> + (set (reg:CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90662
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Status|UNCONFIRMED
One of my new tests for the strlen/sprintf integration tripped
over an incomplete handling of VLAs by the strlen pass. Where
it can determine the length of a substring at some offset with
other kinds of arrays, the pass fails with VLAs because they
are represented as pointers to arrays.
The
On Wed, 5 Jun 2019, Jeff Law wrote:
> > Thanks for looking into it. FWIW I think the `__pend' symbol will best
> > be still emitted for consistency, however as STT_OBJECT and consequently
> > with no trailing `.insn'.
> If I understand correctly we'd still want to call
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90768
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
On 6/3/19 3:24 PM, Martin Sebor wrote:
> While testing a different -Wreturn-local-addr bug fix/enhancement
> I noticed that in functions that return integers as opposed to
> pointers such as:
>
> intptr_t f (int i) { return (intptr_t) }
>
> the converted address is folded to zero. This can be
On 6/4/19 7:17 AM, Jozef Lawrynowicz wrote:
> This patch implements 64-bit shifts in assembly code. Previously, generic C
> library code from libgcc would be used to perform the shifts, which was much
> more costly in terms of code size.
>
> I observed 700 PASS->FAIL regressions from the GCC
On 6/4/19 3:07 PM, Maciej W. Rozycki wrote:
> On Mon, 3 Jun 2019, Faraz Shahbazker wrote:
>
>> The __pool and __pend symbols are used to mark the beginning and end of
>> inline constant pools in MIPS16 code regions. However if the pool occurs
>> at the boundary of a code region and is not
On 6/1/19 6:30 PM, James Clarke wrote:
> The symbol is exposed to C by dso_handle.h, and since it's a single
> 8-byte pointer, it is just within the threshold for being in the small
> data (or bss) section, so code accessing it will use GP-relative
> addressing. Therefore we must put it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90768
Shawn Landden changed:
What|Removed |Added
Component|middle-end |target
--- Comment #3 from Shawn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90768
Shawn Landden changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90768
--- Comment #1 from Shawn Landden ---
Whoops I got that backwards, converting the bit test to a
greater-than-or-equal-to is better.
On 6/4/19 7:14 AM, Jozef Lawrynowicz wrote:
> This patch reduces code size by disabling the performance optimized,
> "const_variant" of shift library functions when optimization for size is
> enabled.
>
> For the following program, the below code size reduction is observed:
> long a;
>
> int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90768
Bug ID: 90768
Summary: better range analysis for converting lt/gt into bit
tests
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
On 6/4/19 7:11 AM, Jozef Lawrynowicz wrote:
> This patch reduces code size by enabling the emulation of some 16-bit shift
> instructions with the native rotate instructions, when the source operand is
> in
> memory. This is achieved by forcing the source operand into a register.
>
> For the
On 6/4/19 7:07 AM, Jozef Lawrynowicz wrote:
> This patch reduces code size by putting each of the shift library functions
> from
> libgcc in their own section. This means that, for example, a 16-bit logical
> left shift does not result in code to perform a 32-bit logical left shift
> being
>
On 6/5/19 1:39 AM, Hongtao Liu wrote:
> Hi Jeff and Jakub:
> When adding new intrinsics(PR target/89803), i found vfpclassp[sd],
> vfpclasss[sd] patterns didn't support memory operand which is
> supported in instructions. So this patch is about to enable memory
> operands for
On 6/4/19 8:38 AM, Martin Liška wrote:
> Hi.
>
> The patch is about simplification of dump output. Plus it prints
> also a file in which the dump message was emitted.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
>
On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> On Wed, 5 Jun 2019 11:49:21 -0500
> Segher Boessenkool wrote:
> > The documentation says
> >
> > '-pedantic' and other options cause warnings for many GNU C extensions.
> > You can prevent such warnings within one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767
--- Comment #2 from Marek Polacek ---
Regressed with r264250.
On 6/5/19 3:09 AM, Martin Liška wrote:
> Hi.
>
> The patch fixes wrong titles/header in 'Installing GCC' pages.
>
> Tested with make html.
> Ready for trunk?
>
> Martin
>
> gcc/ChangeLog:
>
> 2019-06-05 Martin Liska
>
> PR web/87933
> * doc/install.texi: Fix HTML headers and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90673
--- Comment #6 from Yaro Slav ---
(In reply to Kees Cook from comment #5)
> From the linked code:
>
> missing = copy_from_user(dbg_buff, buf, sizeof(buf));
>
> dbg_buff is a global variable -- is writing to it thread safe?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767
Marek Polacek changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767
Bug ID: 90767
Summary: jumbled error message with this and const
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90673
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90766
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90766
Bug ID: 90766
Summary: strlen(a + i) missing range for arrays of unknown
bound with strings of known length and variable i
Product: gcc
Version: 9.0
Status: UNCONFIRMED
On 6/4/19 9:04 AM, Richard Biener wrote:
> On Tue, Jun 4, 2019 at 3:40 PM Jeff Law wrote:
>>
>> On 6/4/19 5:23 AM, Richard Biener wrote:
>>> On Tue, Jun 4, 2019 at 12:30 AM Jeff Law wrote:
On 6/3/19 7:13 AM, Aldy Hernandez wrote:
> On 5/31/19 5:00 AM, Richard Biener wrote:
>>
This patch to the Go frontend makes call expressions and function
reference expressions inlinable.
We now scan inlinable methods for references to global variables and
functions (I forgot to do that earlier).
We now track all packages mentioned by exports (that should have been
done earlier
After the various discussions, I've evaluated how I think everything can
fit together, so this is my proposal for integration with trunk.
The complete Ranger prototype consists of 5 major components, one of
which is missing/un-implemented as yet :-)
1 - irange - This is the
On Wed, Jun 5, 2019 at 10:42 PM 김규래 wrote:
> > On Wed, Jun 5, 2019 at 9:25 PM 김규래 wrote:
>
> >
> > > Hi, thanks for the detailed explanation.
> > > I think I now get the picture.
> > > Judging from my current understanding, the task-parallelism currently
> works as follows:
> > > 1. Tasks are
On 6/5/19 6:51 AM, Richard Biener wrote:
>
> The following was inspired by Marins work on escapes of locals
> and the discussion there. It teaches points-to analysis that
> the point of function return is special and thus escapes through
> that a) do not influence other points-to solutions, b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90751
--- Comment #5 from Sven Schnelle ---
I can confirm that the patch from Dave fixes the issue for me.
> This issue exists, not just for targets that can have their
> MAX_FIXED_MODE_SIZE more-or-less easily tweaked higher, but also
> for the 'bit-container' targets where it *can't* be set higher.
>
> Let's please DTRT and correct the code here in the middle-end,
> so we don't ICE for those targets
On Wed, 5 Jun 2019 11:49:21 -0500
Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> > I'm assuming it would not be valid to modify the behaviour of __extension__
> > so it can be placed within a declaration, and not just at the
> > beginning.
> On Wed, Jun 5, 2019 at 9:25 PM 김규래 wrote:
>
> > Hi, thanks for the detailed explanation.
> > I think I now get the picture.
> > Judging from my current understanding, the task-parallelism currently works
> > as follows:
> > 1. Tasks are placed in a global shared queue.
> > 2. Workers consume
> From: Richard Biener
> Date: Wed, 29 May 2019 15:04:42 +0200
> On Tue, May 28, 2019 at 5:43 PM Hans-Peter Nilsson
> wrote:
> >
> > TL;DR: instead of capping TYPE_PRECISION of bitsizetype at
> > MAX_FIXED_MODE_SIZE, search for the largest fitting size from
> > scalar_int_mode modes supported
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-64, %rsp
movq16(%rbp), %rax
vmovdqa64 %zmm0, (%rax)
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ide
On 05/06/19 17:43 +0100, Jonathan Wakely wrote:
On 05/06/19 17:22 +0100, Jonathan Wakely wrote:
On 04/06/19 19:19 +0200, François Dumont wrote:
@@ -669,18 +670,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__node_base*
_M_get_previous_node(size_type __bkt, __node_base* __n);
- // Insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449
--- Comment #4 from Marek Polacek ---
(In reply to Marek Polacek from comment #3)
> The testcase in the godbolt link even ICEs with current trunk. I'll open a
> separate PR.
PR90764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764
--- Comment #1 from Marek Polacek ---
Started with r270765.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764
Bug ID: 90764
Summary: [10 Regression] internal compiler error in
build_deduction_guide, at cp/pt.c:27162
Product: gcc
Version: 10.0
Status: UNCONFIRMED
On Wed, 5 Jun 2019 at 19:19, Jason Merrill wrote:
> On 6/5/19 1:29 PM, Nina Dinka Ranns wrote:
> > Ack. Amended change log is below. Changes are :
> > * changed C++ -> c++
> > * fixed the name of added test
> >
> > There are no changes in the diff, but I attached it to this e-mail for
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88483
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Wed, Jun 5, 2019 at 9:25 PM 김규래 wrote:
>
> Hi, thanks for the detailed explanation.
> I think I now get the picture.
> Judging from my current understanding, the task-parallelism currently works
> as follows:
> 1. Tasks are placed in a global shared queue.
> 2. Workers consume the tasks by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449
--- Comment #3 from Marek Polacek ---
The testcase in the godbolt link even ICEs with current trunk. I'll open a
separate PR.
On Thu, Jun 06, 2019 at 03:25:24AM +0900, 김규래 wrote:
> Hi, thanks for the detailed explanation.
> I think I now get the picture.
> Judging from my current understanding, the task-parallelism currently works
> as follows:
> 1. Tasks are placed in a global shared queue.
It isn't a global shared
On Wed, 5 Jun 2019 10:30:41 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On Tue, 4 Jun 2019 23:05:53 +0100, Julian Brown
> wrote:
> > I've pushed a new branch "openacc-gcc-9-branch" to the Git
> > mirror (i.e. as a Git-only branch), for development of OpenACC and
> > related functionality on
On 6/5/19 2:09 PM, Paolo Carlini wrote:
Hi,
On 05/06/19 19:45, Jason Merrill wrote:
On 6/4/19 11:57 AM, Paolo Carlini wrote:
Hi,
On 04/06/19 16:50, Jason Merrill wrote:
On 6/4/19 10:31 AM, Paolo Carlini wrote:
+ permerror (loc, "member functions are implicitly "
+
On 5/31/19 12:20 PM, Jeff Law wrote:
On 5/31/19 9:56 AM, Martin Sebor wrote:
On 5/30/19 5:49 PM, Jeff Law wrote:
So in several places there's a comment which indicates that debugging
dumps and the like do not follow conventions. Presumably you've tried
to keep a narrow scope on the diagnostic
Hi, thanks for the detailed explanation.
I think I now get the picture.
Judging from my current understanding, the task-parallelism currently works as
follows:
1. Tasks are placed in a global shared queue.
2. Workers consume the tasks by bashing the queue in a while loop, just as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90760
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On 6/5/19 1:29 PM, Nina Dinka Ranns wrote:
Ack. Amended change log is below. Changes are :
* changed C++ -> c++
* fixed the name of added test
There are no changes in the diff, but I attached it to this e-mail for
reference.
Applied, thanks!
For future reference it's also customary to add a
> At the same time, merge several related frame computing functions.
> Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
> which allows merging of several loops within prologue and epilogue.
>
> Full regression testing will take some time, but a quick browse
> suggests no change in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Wed Jun 5 18:12:53 2019
New Revision: 271969
URL: https://gcc.gnu.org/viewcvs?rev=271969=gcc=rev
Log:
ChangeLog for PR c++/63149
Modified:
trunk/gcc/cp/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Wed Jun 5 18:11:20 2019
New Revision: 271968
URL: https://gcc.gnu.org/viewcvs?rev=271968=gcc=rev
Log:
PR c++/63149 - wrong auto deduction from braced-init-list
2019-06-04 Nina
Hi,
On 05/06/19 19:45, Jason Merrill wrote:
On 6/4/19 11:57 AM, Paolo Carlini wrote:
Hi,
On 04/06/19 16:50, Jason Merrill wrote:
On 6/4/19 10:31 AM, Paolo Carlini wrote:
+ permerror (loc, "member functions are implicitly "
+ "friends of their class");
Wouldn't it be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
--- Comment #15 from Andrew Pinski ---
(In reply to Eric Gallager from comment #14)
> (In reply to Andrew Pinski from comment #12)
> > I have a patch to tree-ssa-phiopt.c to fix comment #1 though it needs
> > another patch to expr.c to produce
On 6/3/19 6:33 PM, Joseph Myers wrote:
On Sun, 2 Jun 2019, Segher Boessenkool wrote:
Git has an identity (well, two) _per commit_, and there is no way you can
reconstruct people's prefered name and email address (at any point in time,
for every commit separately) correctly. IMO it is much
On 6/5/19 11:06 AM, Paolo Carlini wrote:
Hi,
here certainly we can do better than using input_location. In principle
we could also pass the location of the entity (constructor, destructor,
etc) itself or something else but I think it makes a lot of sense to
simply include
On 6/4/19 11:57 AM, Paolo Carlini wrote:
Hi,
On 04/06/19 16:50, Jason Merrill wrote:
On 6/4/19 10:31 AM, Paolo Carlini wrote:
+ permerror (loc, "member functions are implicitly "
+ "friends of their class");
Wouldn't it be better to use the location of "friend" in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90758
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
Ack. Amended change log is below. Changes are :
* changed C++ -> c++
* fixed the name of added test
There are no changes in the diff, but I attached it to this e-mail for
reference.
Thanks,
Nina
2019-06-04 Nina Dinka Ranns
gcc/cp
PR c++/63149
* pt.c (listify_autos): Use non cv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763
Bug ID: 90763
Summary: vec_xl_len should take constnan
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> I'm assuming it would not be valid to modify the behaviour of __extension__
> so it can be placed within a declaration, and not just at the
> beginning. However, there is minimal documentation on this keyword (it does
> not
>
On 05/06/19 17:22 +0100, Jonathan Wakely wrote:
On 04/06/19 19:19 +0200, François Dumont wrote:
@@ -669,18 +670,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__node_base*
_M_get_previous_node(size_type __bkt, __node_base* __n);
- // Insert node with hash code __code, in bucket bkt if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90762
Bug ID: 90762
Summary: ICE in resolvePropertiesX, at d/dmd/expression.c:251
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Greetings,
It appears that the given sha512 sum for gcc-7.4.0.tar.gz may be incorrect
on at least the following mirrors:
http://mirrors.concertpass.com/
http://www.netgull.com/
https://bigsearcher.com/
Regards,
Farid Parpia IBM Corporation: 710-2-RF28, 2455 South Road,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90761
Bug ID: 90761
Summary: ICE in visit, at d/dmd/dcast.c:883
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90760
Bug ID: 90760
Summary: ICE in set_section, at symtab.c:1573
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
At least with -m32 you need -maltivec if you #include .
Tested on powerpc64-linux {-m32,-m64); committing to trunk.
Segher
2019-06-05 Segher Boessenkool
gcc/testsuite/
* g++.target/powerpc/undef-bool-3.C: Add -maltivec to dg-options.
---
On 04/06/19 19:19 +0200, François Dumont wrote:
Hi
Here is a patch to enhance the _Hashtable extract node API and fix
a FIXME request.
The enhancement to the extract node Api is that extract(const
key_type&) do not call extract(const_iterator) anymore. Doing so we
had to loop again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403
--- Comment #13 from Alex Henrie ---
I filled out all the forms and was approved to contribute code to GCC, but the
patches have still not been reviewed:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00971.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #3 from Tomáš Trnka ---
I think the issue stems from this code in gfc_conv_procedure_call():
/* Deferred length dummies pass the character length by reference
so that the value can be returned. */
if
Hi,
here certainly we can do better than using input_location. In principle
we could also pass the location of the entity (constructor, destructor,
etc) itself or something else but I think it makes a lot of sense to
simply include locations[ds_type_spec] in the computation, seems
consistent
The recent changes to rs6000 "debug" register numbers created a
conflict in libgcc aix unwind support. aix-unwind.h provided
definitions of the DWARF register numbers for its own reference.
After the internal register number changes and the definition of those
register names in rs6000.md, the
tmp/ccYGabNR.s
GNU C11 (GCC) version 7.4.1 20190605 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20181127, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531
--- Comment #9 from Iain Sandoe ---
(In reply to MCCCS from comment #6)
> After reading your comment, I noticed that
> there were two things I forgot to mention:
>
> 1 - availability.h is the file where
> "API_AVAILABLE" is defined for Clang.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24551
--- Comment #4 from Thomas De Schampheleire
---
Could it not be that #14167 is now fixed after fixing #86964 ?
Richard Biener writes:
> On Sat, Jun 1, 2019 at 5:49 PM Richard Sandiford
> wrote:
>>
>> Taking the address of a variable stops us doing var-tracking on it,
>> so that we just use the DECL_RTL instead. This can easily cause wrong
>> debug info for regions of code that would have had correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24551
--- Comment #3 from Eric Gallager ---
(In reply to Richard Biener from comment #2)
> But this meta-bug is about -feliminate-unused-debug-types, not -decls.
oh sorry, I misread, nvm then...
Thanks for the patch and sorry that there was no response.
I've added the C++ maintainers to cc:
nick writes:
> I'm pinging this patch as it's old now and should be applied to fix the bug.
>
> Nick
>
> On 2019-04-08 7:20 p.m., Nicholas Krause wrote:
>> This fixes the caller in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24551
--- Comment #2 from Richard Biener ---
But this meta-bug is about -feliminate-unused-debug-types, not -decls.
1 - 100 of 191 matches
Mail list logo
