https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77328
--- Comment #4 from Eric Gallager ---
(In reply to Martin Sebor from comment #3)
> GCC 8 and 9 output for the test case is slightly different (underlining the
> sprintf argument is a nice improvement) but still not what it should be:
>
>
On 10/30/19 7:29 PM, Jakub Jelinek wrote:
On Tue, Oct 29, 2019 at 04:26:14PM -0400, Jason Merrill wrote:
I think type_initializer_zero_p should return false if
CLASSTYPE_NON_AGGREGATE; we can't expect that value-initialization will have
the intended effect in that case.
That indeed works for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84810
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Thu Oct 31 02:31:48 2019
New Revision: 277655
URL: https://gcc.gnu.org/viewcvs?rev=277655=gcc=rev
Log:
PR c++/84810 - constraints on lambdas
Attached is a patch that adds parsing of the
On 10/30/19 7:20 AM, Jeff Chapman wrote:
Hello,
Attached is a patch that adds parsing of the optional requires-clause in a
lambda-expression and lambda-declarator. Additionally, shorthand constraints
from the template-parameter-list are now actually applied and constrain the
synthesized
Segher Boessenkool writes:
> Hi!
>
> On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote:
>> In this patch, loop unroll adjust hook is introduced for powerpc. In this
>> hook,
>> we can do target related hueristic adjustment. For this patch, we tunned for
>> O2 to unroll small loops with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 92268, which changed state.
Bug 92268 Summary: [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #8 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #5)
> >Then how can I build a new version of GCC on MinGW? :(
>
> Wait for the bug to fixed. Bugs happen. Most people compiling the trunk
> don't build using mingw. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299
--- Comment #2 from Andrew Pinski ---
Where are you getting these testcases from? If they are from a "standards
complaincy" test, then I think you need to write to them about being broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147
--- Comment #2 from Matthias Klose ---
this is not about powerpc64le-linux-gnu(64bit little endian), but
powerpc-linux-gnu (32bit, big endian).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299
Bug ID: 92299
Summary: The expression X / abs (X) is simplified to 1 even
when the variable X is 0
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #7 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #5)
> >Then how can I build a new version of GCC on MinGW? :(
>
> Wait for the bug to fixed. Bugs happen. Most people compiling the trunk
> don't build using mingw. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #9 from Jason Merrill ---
Author: jason
Date: Thu Oct 31 02:01:16 2019
New Revision: 277654
URL: https://gcc.gnu.org/viewcvs?rev=277654=gcc=rev
Log:
PR c++/92268 - hard error satisfying return-type-requirement
Previously we
Previously we would put the template arguments for the concept-check in a
TEMPLATE_ID and then also pass them to constraints_satisfied_p, which meant
that we would try to normalize the concept-check with the fully instantiated
arguments, leading to sadness. Simply not passing the args to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298
Bug ID: 92298
Summary: The expression X / X is simplified to 1 even when the
variable X is 0
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #6 from Jim Wilson ---
Looking at some other targets. ARM has movcc but not 128-bit long double.
Aaarch has movcc and 128-bit long double, but has 128-bit load/store so this is
only 4 instructions. mips64, powerpc64, and sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #6 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Most likely the reduced testcase is just:
> > #pragma push_macro("__has_builtin")
> >
> > --- CUT ---
> > > I did finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #5 from Andrew Pinski ---
>Then how can I build a new version of GCC on MinGW? :(
Wait for the bug to fixed. Bugs happen. Most people compiling the trunk don't
build using mingw. You are the bleading edge with compiling on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #4 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #3 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Andrew Pinski changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297
Bug ID: 92297
Summary: The expression 0 / X is simplified to 0 even when the
variable X is 0
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #1 from fdlbxtqi ---
Here are the patches I am using from msys2.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Bug ID: 92296
Summary: GCC build ICE on MinGW-w64. internal compiler error:
Segmentation fault #pragma
push_macro("__has_builtin")
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92286
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
wrote:
> The sched2 pass undoes some of the addresses generated by the RISC-V
> shorten_memrefs code size optimization (patch 1/2) and consequently increases
> code size. This patch prevents sched-deps.c from changing an address if it is
> expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
Bug ID: 92295
Summary: Inefficient vector constructor
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
FYI the testcase I'm using to test the patch. Some of the functions
get smaller, some of them get bigger, and some don't change in size
but should when compiled for an rv64 target.
Jim
void
store1z (int *array)
{
array[200] = 0;
array[201] = 0;
array[202] = 0;
array[203] = 0;
}
void
On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
wrote:
> This patch aims to allow more load/store instructions to be compressed by
> replacing a load/store of 'base register + large offset' with a new load/store
> of 'new base + small offset'. If the new base gets stored in a compressed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147
--- Comment #1 from Gaius Mulley ---
I've just seen gm2 master branch build successfully
on powerpc64le-unknown-linux-gnu (make -j 24).
It is currently running the regression tests - looks like it will fail on
15 tests - 6 more than the amd64
(6
Playing with the PR92284 test case revealed two issues related to
gfc_desc_to_cfi_desc:
* Access of uninitialized memory – copying the array bounds (in
libgfortran) does not make sense for unallocted allocatables and
nullified pointers. Hence, check for ".data == NULL".
* There is a memory
On Tue, Oct 29, 2019 at 04:26:14PM -0400, Jason Merrill wrote:
> I think type_initializer_zero_p should return false if
> CLASSTYPE_NON_AGGREGATE; we can't expect that value-initialization will have
> the intended effect in that case.
That indeed works for this testcase and doesn't break anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92218
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-gnu-linux, |powerpc*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
Kenman Tsang changed:
What|Removed |Added
CC||kentsangkm at gmail dot com
--- Comment
Hi!
On Wed, Oct 30, 2019 at 02:02:44AM -0500, Xiong Hu Luo wrote:
> -finline-functions is enabled by default for O2 since r276469, update the
> test cases that inline small functions caused instruction number difference.
> --- a/gcc/testsuite/gcc.target/powerpc/pr79439-1.c
> +++
On 10/30/19 4:06 PM, Joseph Myers wrote:
> On Wed, 30 Oct 2019, Joseph Myers wrote:
>
>> This appears to have broken the build for Arm.
>
> And probably bfin and c6x as well, based on grep, but my bot only covers
> glibc targets so doesn't test those.
>
bfin and c6x are definitely affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
a.h.jaffe at gmail dot com changed:
What|Removed |Added
CC||a.h.jaffe at gmail dot com
Hi!
On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote:
> In this patch, loop unroll adjust hook is introduced for powerpc. In this
> hook,
> we can do target related hueristic adjustment. For this patch, we tunned for
> O2 to unroll small loops with small unroll factor (2 times), for
On Wed, 30 Oct 2019, Joseph Myers wrote:
> This appears to have broken the build for Arm.
And probably bfin and c6x as well, based on grep, but my bot only covers
glibc targets so doesn't test those.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, Oct 30, 2019 at 04:26:17PM -0400, Jason Merrill wrote:
> OK.
>
Thanks, committed.
> > Now, for the accepts invalid issues.
> > From what I
This appears to have broken the build for Arm.
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/arm/arm.c: In function 'arm_pcs
arm_get_pcs_model(const_tree, const_tree)':
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/arm/arm.c:5959:4: error:
'cgraph_local_info' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274
--- Comment #4 from joseph at codesourcery dot com ---
It's actually generic to anything using make; make is designed around
strings that get passed to the shell / split on spaces, rather than having
a generic escape mechanism for special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #19 from Jakub Jelinek ---
Author: jakub
Date: Wed Oct 30 21:55:12 2019
New Revision: 277649
URL: https://gcc.gnu.org/viewcvs?rev=277649=gcc=rev
Log:
PR c++/91369 - Implement P0784R7: constexpr new
* constexpr.c
On Wed, 30 Oct 2019 at 18:31, Rainer Emrich wrote:
>
> svn: E170013: Unable to connect to a repository at URL
> 'svn://gcc.gnu.org/svn/gcc/trunk'
> svn: E210002: Network connection closed unexpectedly
I think the server throttles the anon svn connections, and that can
make them time out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022
--- Comment #4 from Jonathan Wakely ---
Oh, and I removed __cpp_lib_constexpr from today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022
--- Comment #3 from Jonathan Wakely ---
(In reply to emsr from comment #2)
> I think we're done.
> The __cpp_lib_constexpr may not do anything or may not be in the newest
> drafts anymore. We should probably kill it. I was very confused as
On Tue, Oct 29, 2019 at 11:57:40PM +0100, Jakub Jelinek wrote:
> On Tue, Oct 29, 2019 at 05:40:11PM -0500, Segher Boessenkool wrote:
> > On Tue, Oct 29, 2019 at 06:15:31PM +0100, Jakub Jelinek wrote:
> > There already are a lot of different ways to get information about the
> > execution
On 10/24/19 7:47 AM, Jakub Jelinek wrote:
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
So, do you prefer to do it the other way during build_cxx_call?
It seems more straightforward.
I've tried this approach, but am running into issues:
1) the normal constructors aren't an
Iain Sandoe wrote:
> Iain Sandoe wrote:
>
>> Martin Sebor wrote:
>>
>>> On 10/20/2019 07:27 AM, Iain Sandoe wrote:
Martin Sebor wrote:
> On 10/19/19 2:56 AM, Iain Sandoe wrote:
>> Andreas Schwab wrote:
>>> On Okt 19 2019, Iain Sandoe wrote:
>>>
This test has
Hello List,
This is off-topic here, but I would be interested in free-lance
developing of GCC plugins (working remotely mostly from home, near
Paris, France) for clients or corporations in the Euro zone.
If some of you is interested by having me as a sub-contractor, please
contact me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022
--- Comment #2 from emsr at gcc dot gnu.org ---
I think we're done.
The __cpp_lib_constexpr may not do anything or may not be in the newest drafts
anymore. We should probably kill it. I was very confused as people were going
back and forth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
fdlbxtqi changed:
What|Removed |Added
Resolution|WORKSFORME |INVALID
--- Comment #11 from fdlbxtqi ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
fdlbxtqi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #3 from Bernd Edlinger ---
Author: edlinger
Date: Wed Oct 30 20:29:21 2019
New Revision: 277643
URL: https://gcc.gnu.org/viewcvs?rev=277643=gcc=rev
Log:
2019-10-30 Bernd Edlinger
* doc/invoke.texi (-Wshadow,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236
--- Comment #1 from Jason Merrill ---
It would also be helpful to explain for
static_assert (!Int);
On 10/24/19 5:11 AM, Jakub Jelinek wrote:
Hi!
Jonathan has showed me a testcase with std::allocator::{,de}allocate
and std::construct_at which FAILs with the current constexpr new
implementation.
There are two problems that make the testcase rejected, and further issues
(not addressed by this
On 10/30/19 2:31 PM, Georg-Johann Lay wrote:
> Hi, have the cc0 backends been deprecated?
>
> I didn't follow the lists for some time... At least neither v9 or v10
> release notes caveats mention such deprecation, neither is there
> respective PRs for the cc0 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208
--- Comment #4 from Tobias Burnus ---
Author: burnus
Date: Wed Oct 30 20:01:36 2019
New Revision: 277639
URL: https://gcc.gnu.org/viewcvs?rev=277639=gcc=rev
Log:
Fortran] PR 92208 don't use function-result dummy variable as actual argument
On 10/30/19 1:49 PM, Bill Seurer wrote:
> On 10/30/19 1:29 PM, Rainer Emrich wrote:
>> svn: E170013: Unable to connect to a repository at URL
>> 'svn://gcc.gnu.org/svn/gcc/trunk'
>> svn: E210002: Network connection closed unexpectedly
>>
>
> I can ping gcc.gnu.org but if I tracert/traceroute to
For the MSP430 target, the concepts of a dynamic linker and shared objects are
not applicable. The target is generally resource constrained and if someone
wanted to use a dynamic linker (maybe as an academic curiosity) on one of the
more powerful devices I expect it would have to be written from
On 10/30/19 1:29 PM, Rainer Emrich wrote:
svn: E170013: Unable to connect to a repository at URL
'svn://gcc.gnu.org/svn/gcc/trunk'
svn: E210002: Network connection closed unexpectedly
I can ping gcc.gnu.org but if I tracert/traceroute to it I get:
24 server1.sourceware.org (209.132.180.131)
On 10/12/19 2:10 PM, Bernd Edlinger wrote:
On 10/11/19 6:31 PM, Jason Merrill wrote:
On 10/10/19 2:06 PM, Bernd Edlinger wrote:
On 10/10/19 7:49 PM, Jason Merrill wrote:
On 10/10/19 10:42 AM, Bernd Edlinger wrote:
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the
On October 30, 2019 7:16:43 PM GMT+01:00, "Andre Vieira (lists)"
wrote:
>Hi,
>
>In this patch I turn epilogue vectorization on by default for all
>targets. After some discussions I decided to take the following testing
>
>approach:
>
>1) I have disabled epilogue vectorization for all tests that
On 10/30/19 9:30 AM, Marek Polacek wrote:
On Wed, Oct 30, 2019 at 10:58:57AM +0100, Jakub Jelinek wrote:
On Fri, Oct 25, 2019 at 10:44:18AM -0400, Marek Polacek wrote:
That is... sneaky. I guess I/we need to test with
--enable-symvers=gnu-versioned-namespace every now and then.
Indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #4 from seurer at gcc dot gnu.org ---
I retested and the ICE part only occurs on a BE system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70320
Jozef Lawrynowicz changed:
What|Removed |Added
CC||jozefl.gcc at gmail dot com
---
A cleanup I noticed while working on operator<=>.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/cxx-pretty-print.c | 48 ++-
1 file changed, 2 insertions(+), 46 deletions(-)
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index
John Paul Adrian Glaubitz schrieb:
Hello!
For anyone who isn't aware of it yet, there is an ongoing BountySource campaign
for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that
it can be kept in gcc versions beyond version 11.
Hi, have the cc0 backends been
> On Oct 30, 2019, at 2:24 PM, Jeff Law wrote:
>
> On 10/30/19 2:12 AM, Richard Biener wrote:
>> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
>>
>> I think the wiki has better examples. That said, I wonder how much can
>> be automated here, for example when just considering CCmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #5 from Bill Schmidt ---
For 32-bit big-endian PowerPC (using the 32-bit ELF ABI), the same code
generation is provided by GCC and Clang. I.e., here's the code generation for
Clang with -O2 -m32 -mbig-endian, using 6.0.0-1ubuntu2:
Hi Tobias,
OK for the trunk and GCC 9?
As far as I can see, this looks good.
So, OK for trunk. If it later turns out that there are problems
caused by this, I suspect we will hear about them soon enough :-)
Thanks for taking this on!
Regards
Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274
--- Comment #3 from Andrew Pinski ---
(In reply to Heiko Eißfeldt from comment #2)
> IMHO there are better structured alternatives available (for example the
> schily build system from schilytools (sourceforge)).
NOTE GCC is not the only issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92134
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92134
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Wed Oct 30 18:49:59 2019
New Revision: 277636
URL: https://gcc.gnu.org/viewcvs?rev=277636=gcc=rev
Log:
PR c++/92134 - constinit malfunction in static data member.
I wasn't
Hi!
On Wed, Oct 23, 2019 at 05:42:45PM +0800, Kewen.Lin wrote:
> Following the previous one 2/3, this patch is to update the
> vector conversions between fixed point and floating point
> with different element unit sizes, such as: SP <-> DI, DP <-> SI.
> (vsx_xvcvdp[su]xws): New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
Wilco changed:
What|Removed |Added
Target||aarch64
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92254
--- Comment #5 from Dmitry G. Dyachenko ---
very strange
r277625 FAIL for me for testcase from c#1 and for original problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
Bug ID: 92294
Summary: alias attribute generates incorrect code
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 10/24/19 6:30 PM, Marek Polacek wrote:
I wasn't properly setting LOOKUP_CONSTINIT in grokfield and so we didn't
detect a non-const initializer.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
2019-10-24 Marek Polacek
PR c++/92134 - constinit malfunction in static
On 10/24/19 5:50 PM, Marek Polacek wrote:
I noticed that for code like
struct S {
int *foo : 3;
};
we generate nonsensical
r.C:2:8: error: function definition does not declare parameters
2 | int *foo : 3;
It talks about a function because after parsing the declspecs of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278
--- Comment #8 from Dmitry G. Dyachenko ---
r277625 PASS for me for testcase from c#0 and for original problem.
Thank you
On 10/24/19 3:24 PM, Marek Polacek wrote:
When fixing c++/91889 (r276251) I was assuming that we couldn't have a ck_qual
under a ck_ref_bind, and I was introducing it in the patch and so this
+ if (next_conversion (convs)->kind == ck_qual)
+ {
+ gcc_assert (same_type_p (TREE_TYPE
svn: E170013: Unable to connect to a repository at URL
'svn://gcc.gnu.org/svn/gcc/trunk'
svn: E210002: Network connection closed unexpectedly
signature.asc
Description: OpenPGP digital signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #7 from Jason Merrill ---
Created attachment 47136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47136=edit
patch for the simple case
This untested patch fixes my testcase and Jon's, though not the more complex
case. Not
On 10/30/19 2:12 AM, Richard Biener wrote:
> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> I think the wiki has better examples. That said, I wonder how much can
> be automated here, for example when just considering CCmode (m68k has
> setcc IIRC) then for example all define_insns like
>
Hi,
In this patch I turn epilogue vectorization on by default for all
targets. After some discussions I decided to take the following testing
approach:
1) I have disabled epilogue vectorization for all tests that failed due
to scan-tree-dump failures inside:
- gcc.dg/vect
-
On Wed, 30 Oct 2019, Alexandre Oliva wrote:
> On Oct 28, 2019, Joseph Myers wrote:
>
> > We have a test in the testsuite that all option help text consistently
> > ends with '.' (see gcc.misc-tests/help.exp). I'd have expected these
> > options, lacking that '.', to cause that test to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206
--- Comment #8 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you! I can confirm that the patch resolved the issue.
On 10/30/19 11:57 AM, John Paul Adrian Glaubitz wrote:
> On 10/30/19 6:52 PM, Gunther Nikl wrote:
>> Richard Sandiford wrote:
>>> FWIW it's already possible to do the transform you mention with:
>>>
>>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>>
>>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM
Hi!
On Wed, Oct 23, 2019 at 05:40:35PM +0800, Kewen.Lin wrote:
> For those fixed point <-> floating point vector conversion with
> same element unit size, such as: SP <-> SI, DP <-> DI, it's fine
> to use the existing RTL operations like any_fix/any_float for them.
>
> This patch is to update
Hi!
On Wed, Oct 23, 2019 at 05:39:14PM +0800, Kewen.Lin wrote:
> I noticed that vsx_xvcdpsp and vsx_xvcvdpsp are almost the same,
> and vsx_xvcdpsp looks replaceable with vsx_xvcvdpsp since it's only
> called by gen_*.
Okay for trunk. Thanks!
Segher
> 2019-10-23 Kewen Lin
>
> *
1 - 100 of 304 matches
Mail list logo
