[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #8 from Christian Cornelssen --- Created attachment 42305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42305=edit differences in non-Ada testsuite results when switching from attachment 42124 to attachment 42304

[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #7 from Christian Cornelssen --- I have made the time-consuming effort of building and testing gcc-7.2.0 with varying subsets of the four patchsets proposed with attachment 42124. * Patchset 1/4 copies stack alignment changes

[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #6 from Christian Cornelssen --- Created attachment 42304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42304=edit Patchset 2 from patch-darwin-ppc-2017-01-msg02971.diff, sufficient for non-Ada builds to succeed

[Bug target/82408] cross-compiling for arm64 problems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82408 --- Comment #13 from Peter Bohning --- Okay, amazingly I have a computer again. I tried what you suggested and it didn't work. I need a libstdc++ library for aarch. Like I said several times, I already have the linaro toolchain, what I want

[Bug target/82411] const is not always read-only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411 Segher Boessenkool changed: What|Removed |Added Target|Powerpc*-*-*|powerpc*-*-* --- Comment #4 from

Re: [RFA] [PATCH] Add a warning for invalid function casts

On Tue, Oct 3, 2017 at 3:33 PM, Bernd Edlinger wrote: > Hi! > > I have implemented a warning -Wcast-function-type that analyzes > type casts which change the function signatures. > > I would consider function pointers with different result type > invalid, also if both

Re: [PATCH] C++ warning on vexing parse

On Tue, Oct 3, 2017 at 1:08 PM, Nathan Sidwell wrote: > [non-c++ people on CC, there's a reason ...] > > This patch adds a new warning, concerning unnecessary parentheses on a > declaration. For instance: >prettyprinter (pp); > That's a declaration of a pp variable of type

[Bug tree-optimization/82432] Missed constant propagation of return values of non-inlined static functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82432 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew

[Bug ipa/81323] IPA-VRP doesn't handle return values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug tree-optimization/82432] Missed constant propagation of return values of non-inlined static functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82432 --- Comment #1 from Peter Cordes --- Meant to add https://godbolt.org/g/K9CxQ6 before submitting. And to say I wasn't sure tree-optimization was the right component. I did check that -flto didn't do this optimization either. Is it worth

[Bug tree-optimization/82432] New: Missed constant propagation of return values of non-inlined static functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82432 Bug ID: 82432 Summary: Missed constant propagation of return values of non-inlined static functions Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords:

[Bug target/82411] const is not always read-only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411 --- Comment #3 from Kees Cook --- To clarify, using -mno-sdata means all things are removed from sdata, not just const, yes? I'd like to be able to leave writable stuff there, to avoid any additional performance penalty.

Re: Make tests less istreambuf_iterator implementation dependent

On 04/10/17 18:21 +0200, François Dumont wrote: On 03/10/2017 16:20, Jonathan Wakely wrote: Doesn't the modified test PASS anyway, even without changing how _M_c is used? No it doesn't because the first check for eof capture the 'a' char which is never reseted so after string construction it

Re: [PATCH] Improve alloca alignment

On 10/04/2017 08:53 AM, Eric Botcazou wrote: >> This seems like a SPARC target problem to me -- essentially it's >> claiming a higher STACK_BOUNDARY than it really has. > > No, it is not, I can guarantee you that the stack pointer is always aligned > to > 64-bit boundaries on SPARC, otherwise

Re: [PATCH][AArch64] Add BIC-imm and ORR-imm SIMD pattern

On Wed, 2017-10-04 at 16:41 +0100, Richard Earnshaw (lists) wrote: > On 02/10/17 10:05, Sudi Das wrote: > >  > > 2017-10-02 Sudakshina Das   > > > > * config/aarch64/aarch64-protos.h (enum simd_immediate_check): New > > check type > > for aarch64_simd_valid_immediate. >

gcc-6-20171004 is now available

Snapshot gcc-6-20171004 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171004/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6

[PATCH, rs6000] Process deferred rescans between mini-passes

Hi, The Power8 swap optimization pass contains a mini-pass to replace certain patterns prior to swap optimization proper. In order for this not to distort the dataflow information for swap optimization, we should process all the deferred rescans between the two passes. Currently that is not

[patch, fortran] Set implicit ASYNCHRONOUS attribute

Hello world, the attached patch sets the implicit ASYNCHRONPUS according to F2008, 9.6.2.5: # If a variable is used in an asynchronous data transfer statement as # • an item in an input/output list, # • a group object in a namelist, or # • a SIZE= specifier # the base object of the data-ref is

PING: [libsanitizer, PATCH] Add anitizer_linux_x86_64.lo if __x86_64__ is defined by $CC

On 9/30/17, H.J. Lu wrote: > Since size of "void *" is 4 bytes for x32, check if __x86_64__ is defined > by $CC, instead of > > if test x$ac_cv_sizeof_void_p = x8; then > > to decide wether anitizer_linux_x86_64.lo should be used. > > I am testing this on i686 and x86-64. OK

[Bug c++/80471] (gcc extension) Forwarding-reference `auto` function parameters do not follow the same rules as template functions or generic lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80471 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/80471] (gcc extension) Forwarding-reference `auto` function parameters do not follow the same rules as template functions or generic lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80471 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 21:25:20 2017 New Revision: 253432 URL: https://gcc.gnu.org/viewcvs?rev=253432=gcc=rev Log: 2017-10-04 Paolo Carlini PR

Re: [PATCH] Improve V?TImode shifts (PR target/82370)

On 10/4/17, Jakub Jelinek wrote: > Hi! > > The following patch tweaks the TImode vector shifts similarly > to the earlier vector shift patch, so that for shifts by immediate > we can accept a memory input. Additionally, it removes the vec_shl_* I prefer 2 patches, a separate

[Bug ada/82393] Compilation error on cygwin64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #10 from Eric Botcazou --- > PS : Do you know we certainly live separated by 3,5 km at Toulouse City ? > I live at 35, rue Edmond Rostand 31200 ... :-) OK, this is a small world. :-)

[Bug ada/82393] Compilation error on cygwin64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #9 from Eric Botcazou --- > Trace of check ada runtests You can do 'make mail-report.log' after 'make -k check' to have a report. The results are acceptable although gnat.dg/entry_queues.adb and c380004, which probably come from

[Bug ada/82393] Compilation error on cygwin64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 Eric Botcazou changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned

[Bug c++/78131] Inconsistent evaluation for `constexpr` lambdas in templates between `static_assert`, `if constexpr(…)` and `constexpr` variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78131 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/78131] Inconsistent evaluation for `constexpr` lambdas in templates between `static_assert`, `if constexpr(…)` and `constexpr` variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78131 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 20:58:52 2017 New Revision: 253431 URL: https://gcc.gnu.org/viewcvs?rev=253431=gcc=rev Log: 2017-10-04 Paolo Carlini PR

[Bug c++/54367] [meta-bug] lambda expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 78018, which changed state. Bug 78018 Summary: [C++14] "internal compiler error: Segmentation fault" with templates and lambdas https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78018 What|Removed

[Bug c++/78018] [C++14] "internal compiler error: Segmentation fault" with templates and lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78018 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|andipeer at

[Bug c++/78018] [C++14] "internal compiler error: Segmentation fault" with templates and lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78018 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 20:34:03 2017 New Revision: 253430 URL: https://gcc.gnu.org/viewcvs?rev=253430=gcc=rev Log: 2017-10-04 Paolo Carlini PR

Re: Exhaustive Instructions for Toolchain Generation

On 4 Oct 2017 8:01 pm, "Nathan Sidwell" wrote: On 10/04/2017 02:10 PM, Manuel López-Ibáñez wrote: Incidentally, I don't understand why there is no "Professional Support" > page where we can direct people to find professional support. It could > My recollection is that the FSF

Re: correct attribute ifunc C++ type safety (PR 82301)

On 09/28/2017 08:25 AM, Nathan Sidwell wrote: On 09/24/2017 06:03 PM, Martin Sebor wrote: r253041 enhanced type checking for alias and ifunc attributes to detect declarations of incompatible aliases, or ifunc resolvers that return pointers to functions of an incompatible type. More extensive

[PATCH] Remove useless isa attributes from various sse.md patterns

Hi! While working on the previous patch, I've noticed we have quite a few seemingly useless isa attributes (first I've noticed isa attribute which had one value for all alternatives, which IMHO should just been done in insn condition instead). fma_avx512f isa is only used on insns that have

[PATCH] Improve V?TImode shifts (PR target/82370)

Hi! The following patch tweaks the TImode vector shifts similarly to the earlier vector shift patch, so that for shifts by immediate we can accept a memory input. Additionally, it removes the vec_shl_* expander, because the middle-end has dropped that a few years ago, and merges the left and

[PATCH] Improve AVX512 vector shift patterns (PR target/82370)

Hi! EVEX encoded vector shifts by immediate allow memory operand as input. We handle this right for the sra patterns by having 3 distinct define_insns, one TARGET_AVX512VL with masking, where the non-masked insn names start with *, that have (=v,v,v) and (=v,vm,N) alternatives and

Slides from GNU Tools Cauldron

Hello, all but one videos from this year Cauldron has been edited and are now linked from https://gcc.gnu.org/wiki/cauldron2017 (plugins BoF will appear till end of week). I would also like to update the page with links to slides. If someone beats me on this and adds some or all of them as

Re: Exhaustive Instructions for Toolchain Generation

On 10/04/2017 02:10 PM, Manuel López-Ibáñez wrote: Incidentally, I don't understand why there is no "Professional Support" page where we can direct people to find professional support. It could My recollection is that the FSF explicitly prohibit this. nathan -- Nathan Sidwell

Re: Transform (x >> cst) != 0 to x >= (1 << cst) and (x >> cst) == 0 to x < (1 << cst)

On 3 October 2017 at 14:10, Jeff Law wrote: > On 10/03/2017 03:00 PM, Marc Glisse wrote: >> On Tue, 3 Oct 2017, Jakub Jelinek wrote: >> >>> On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote: Hi, This follow-up patch implements the patterns mentioned in

Re: Exhaustive Instructions for Toolchain Generation

On 04/10/17 00:22, Sandra Loosemore wrote: On 10/03/2017 03:27 PM, R0b0t1 wrote: On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore > wrote: [snip] FAOD, R0b0t1 forwarded mail I deliberately sent off-list back to the list.  I do know

Re: [PATCH] Add sanopt support for UBSAN_PTR.

On Wed, Oct 04, 2017 at 11:05:23AM +0200, Martin Liška wrote: > Following patch adds support for optimizing out unnecessary UBSAN_PTR checks. > It handles separately positive and negative offsets, zero offset is ignored. > Apart from that, we utilize get_inner_reference for local and global >

Re: [C++ PATCH] give builtin types consistent name

On Wed, Oct 4, 2017 at 1:52 PM, Nathan Sidwell wrote: > The builtin type machinery is one of the places were we push decls into :: > under not-their-name. > > There's no real reason for this, and the fix is simple -- create a new > TYPE_DECL if we use a name from the ridpointer

Re: pass manager question

On 10/03/2017 10:45 AM, Sandra Loosemore wrote: On 10/03/2017 05:36 AM, Martin Jambor wrote: Hi, On Mon, Oct 02, 2017 at 01:27:05PM -0600, Sandra Loosemore wrote: Is there an idiom for target-specific back end code to ask the pass manager if a particular pass (e.g., "split1") has already run?

[Bug c++/81236] Crash when calling a template member function from generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81236 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/80935] [C++1z] incorrect error 'uninitialized variable in constexpr function' when conditionally declaring variable inside lambda inside template class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80935 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/80767] Eager instantiation of generic lambda body when not required

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80767 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug driver/31350] gcc -v --help puts some output on std. out, and some on std. error.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31350 Ladislas de Toldi changed: What|Removed |Added CC||ladislas at leka dot io --- Comment

[C++ PATCH] give builtin types consistent name

The builtin type machinery is one of the places were we push decls into :: under not-their-name. There's no real reason for this, and the fix is simple -- create a new TYPE_DECL if we use a name from the ridpointer table. I took the opportunity of reordering record_builtin_type, which was a

[Bug c++/81525] [7 Regression] Invalid codegen with constexpr variable template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug other/82368] [8 regression] with r253275 several new test cases in libbacktrace fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368 --- Comment #6 from seurer at gcc dot gnu.org --- The title is correct, the new failures did show up starting with r253275. I mistyped it in my description and there doesn't appear to be a way to update that, sorry.

[Bug c++/82406] [7 Regression] Rejects a valid snippet

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/82406] [7 Regression] Rejects a valid snippet

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Oct 4 17:47:51 2017 New Revision: 253425 URL: https://gcc.gnu.org/viewcvs?rev=253425=gcc=rev Log: PR c++/82406 - C++17 error with noexcept function type *

[Bug c++/82406] [7 Regression] Rejects a valid snippet

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82406 --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Oct 4 17:47:08 2017 New Revision: 253424 URL: https://gcc.gnu.org/viewcvs?rev=253424=gcc=rev Log: PR c++/82406 - C++17 error with noexcept function type PR

[Bug c++/70029] [8 Regression] ICE with C++11 and -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 --- Comment #17 from Jason Merrill --- Author: jason Date: Wed Oct 4 17:47:08 2017 New Revision: 253424 URL: https://gcc.gnu.org/viewcvs?rev=253424=gcc=rev Log: PR c++/82406 - C++17 error with noexcept function type PR

[Bug middle-end/82407] [8 Regression][meta-bug] qsort_chk fallout tracking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407 Bug 82407 depends on bug 82396, which changed state. Bug 82396 Summary: [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 What

[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 Steve Ellcey changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug ada/82393] Compilation error on cygwin64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #7 from Didier G --- Attached, the trace of ada run tests. Please, feel free to inform me about output files to watch. I will do my best to review and report them. Best Regards, Didier. PS : Do you know we certainly live separated

[Bug ada/82393] Compilation error on cygwin64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #6 from Didier G --- Created attachment 42303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42303=edit Trace of check ada runtests

[Bug c++/54367] [meta-bug] lambda expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 71946, which changed state. Bug 71946 Summary: asm in toplevel lambda function rejected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946 What|Removed |Added

[Bug c++/71946] asm in toplevel lambda function rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/71946] asm in toplevel lambda function rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71946 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 4 17:21:21 2017 New Revision: 253423 URL: https://gcc.gnu.org/viewcvs?rev=253423=gcc=rev Log: /cp 2017-10-04 Paolo Carlini

[Bug tree-optimization/82369] "optimizes" indexed addressing back into two pointer increments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82369 --- Comment #4 from amker at gcc dot gnu.org --- Hmm, with expansion, IVOPTs can find address type uses as: Group 0: Type: ADDRESS Use 0.0: At stmt:_25 = *_6; At pos: *_6 IV struct: Type: const __m128i_u *

[PATCH] remove some unneeded parens

As described in https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00122.html, I found a few places where declarations were excessively parenthesized. These seem to be the uncontroversial cases, so fixing thusly. Applying to trunk. nathan -- Nathan Sidwell 2017-10-04 Nathan Sidwell

Re: Exhaustive Instructions for Toolchain Generation

On 4 October 2017 at 17:45, Jeffrey Walton wrote: For completeness, GCC has a wiki. But I still don't have an account to make an occasional update; and I still don't know how to get an account. I tried to get one in the past but the process was broken so I gave up. >>> >>> 1)

[C++ PATCH] Move mangling alias out of ::

To deal with changes in the ABI that affected manglings, we like pushing decls into :: under their mangled names. This is one of the 3 places we push decls under something not their DECL_NAME, and causes the namespace binding map to not be a simple hash table of DECLs. It also can give rise

Re: Exhaustive Instructions for Toolchain Generation

>>> For completeness, GCC has a wiki. But I still don't have an account to >>> make an occasional update; and I still don't know how to get an >>> account. I tried to get one in the past but the process was broken so >>> I gave up. >> >> 1) create an account >> 2) get your username added to the

Re: [Patch AArch64] Stop generating BSL for simple integer code

On Thu, Jul 27, 2017 at 06:49:01PM +0100, James Greenhalgh wrote: > > On Mon, Jun 12, 2017 at 02:44:40PM +0100, James Greenhalgh wrote: > > [Sorry for the re-send. I spotted that the attributes were not right for the > > new pattern I was adding. The change between this and the first version >

[Committed] S/390: Fix mode in vector merge pattern.

vec_unpacks_hi_v4sf/vec_unpacks_lo_v4sf expand vec_mergeh and vec_mergel patterns also for z13 with V4SF modes so the patterns should better accept this. Fixed by changing the mode iterator to V_128_NOSINGLE which accepts V4SF unconditionally. Committed to mainline. gcc/ChangeLog: 2017-10-04

[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 --- Comment #9 from Wilco --- Author: wilco Date: Wed Oct 4 16:40:44 2017 New Revision: 253419 URL: https://gcc.gnu.org/viewcvs?rev=253419=gcc=rev Log: Revert r253399: PR rtl-optimization/82396 * haifa-sched.c

[Bug tree-optimization/82429] strcpy to stpcpy transformation disabled in strict mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429 --- Comment #2 from joseph at codesourcery dot com --- Strictly, that a program declares stpcpy should be irrelevant if the declaration is outside system headers, because it could declare and define it for some other purpose (even if the

[Bug tree-optimization/82405] Function not inlined for switch and suboptimal assembly is generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82405 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 Loïc Yhuel changed: What|Removed |Added CC||loic.yhuel at gmail dot com --- Comment #4

[Bug c++/82405] Function not inlined for switch and suboptimal assembly is generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82405 --- Comment #11 from Andrew Pinski --- Thinking about this some more, this is a not a hoisting problem but a sinking problem. basically we have: int f(void); int h(void); int g(int a) { if (a) return f() + 10; return h() + 10; } Which

Re: Exhaustive Instructions for Toolchain Generation

On 4 October 2017 at 17:25, Jonathan Wakely wrote: > On 4 October 2017 at 17:14, Jeffrey Walton wrote: >> Maybe some of the first steps is to (1) recognize the information >> management problem, and (2) provide information dissemination that's >> {amicable|consistent|?} with what's occurring in

Re: Exhaustive Instructions for Toolchain Generation

On 4 October 2017 at 17:14, Jeffrey Walton wrote: > Maybe some of the first steps is to (1) recognize the information > management problem, and (2) provide information dissemination that's > {amicable|consistent|?} with what's occurring in 2017. I mean, What does that mean in concrete terms? >

Re: Exhaustive Instructions for Toolchain Generation

On Wed, 4 Oct 2017, Jeffrey Walton wrote: > Of the thousands of hits when searching for the information on a task > like compiling GCC, there's probably a handful of good sources. > Everything else is just crap on the web that someone decided to blog > about. (This is speaking from experience).

[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/82409] Superflous pxor instructions in the generated assembly.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82409 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment

[Bug tree-optimization/82369] "optimizes" indexed addressing back into two pointer increments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82369 --- Comment #3 from amker at gcc dot gnu.org --- Given IR dump before IVOPTs: [15.00%] [count: INV]: _1 = dst_12(D) + bytes_13(D); end_dst_14 = (uintptr_t) _1; srcu_16 = (uintptr_t) src_15(D); dstu_17 = (uintptr_t) dst_12(D); _2 =

Re: Make tests less istreambuf_iterator implementation dependent

On 03/10/2017 16:20, Jonathan Wakely wrote: On 02/10/17 07:43 +0200, François Dumont wrote: On 28/09/2017 23:56, Jonathan Wakely wrote: On 28/09/17 21:59 +0200, François Dumont wrote: The current istreambuf_iterator implementation capture the current streambuf state each time it is tested

[Bug c++/82373] syntax error in error message

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82373 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Oct 4 16:15:36 2017 New Revision: 253418 URL: https://gcc.gnu.org/viewcvs?rev=253418=gcc=rev Log: PR c++/82373 * error.c (dump_function_decl): If show_return, call

Re: Exhaustive Instructions for Toolchain Generation

On Wed, Oct 4, 2017 at 11:25 AM, Joseph Myers wrote: > There are over 25000 words of GCC installation documentation in > install.texi, and that's not even including e.g. libstdc++ configure > options documented elsewhere. Other toolchain components also have such >

Re: [C++ PATCH] Fix comment

On 10/04/2017 11:29 AM, Jason Merrill wrote: On Wed, Oct 4, 2017 at 10:12 AM, Nathan Sidwell wrote: In answering a question about passing non-trivial types through ..., I discovered a misleading comment. It is NOT just like a value parm, because we don't locally copy it.

Re: [PATCH][AArch64] Add BIC-imm and ORR-imm SIMD pattern

On 02/10/17 10:05, Sudi Das wrote: > > Hi Richard > > Thanks, I have made the change to the patch. > > > 2017-10-02 Sudakshina Das > > * config/aarch64/aarch64-protos.h (enum simd_immediate_check): New > check type > for aarch64_simd_valid_immediate. >

[Bug c++/81525] [7 Regression] Invalid codegen with constexpr variable template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #11 from Jason Merrill --- Author: jason Date: Wed Oct 4 15:38:24 2017 New Revision: 253415 URL: https://gcc.gnu.org/viewcvs?rev=253415=gcc=rev Log: PR c++/81525 - broken handling of auto in generic lambda. * pt.c

[Bug ada/82393] Compilation error on cygwin64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82393 --- Comment #5 from Didier G --- OK. Build succeed. Tests in progress ...

[Bug c++/81525] [7 Regression] Invalid codegen with constexpr variable template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #10 from Jason Merrill --- Author: jason Date: Wed Oct 4 15:37:09 2017 New Revision: 253414 URL: https://gcc.gnu.org/viewcvs?rev=253414=gcc=rev Log: PR c++/81525 - broken handling of auto in generic lambda. * pt.c

Re: C++ PATCH for c++/81525, auto and generic lambda

On Wed, Aug 9, 2017 at 3:20 PM, Jason Merrill wrote: > In this testcase, when building up an extra version of N to refer to > when instantiating the generic lambda, we were mistakenly replacing > the 'auto' with a template argument for the generic lambda. > > Tested

[Bug tree-optimization/82429] strcpy to stpcpy transformation disabled in strict mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1

Re: [C++ Patch] PR 71946 ("asm in toplevel lambda function rejected")

OK. On Wed, Oct 4, 2017 at 8:50 AM, Paolo Carlini wrote: > Hi, > > Andrew noticed that the reason we reject entities like inline-asm or GNU's > statement-expressions in the lambda body is simply that we don't set the > parser->in_function_body flag. Thus the below,

Re: [C++ PATCH] Fix comment

On Wed, Oct 4, 2017 at 10:12 AM, Nathan Sidwell wrote: > In answering a question about passing non-trivial types through ..., I > discovered a misleading comment. It is NOT just like a value parm, because > we don't locally copy it. Hmm, I think the error is in the behavior, not

Re: Exhaustive Instructions for Toolchain Generation

There are over 25000 words of GCC installation documentation in install.texi, and that's not even including e.g. libstdc++ configure options documented elsewhere. Other toolchain components also have such documentation. It's true that, as a consequence of the toolchain being made up of

[Bug fortran/82431] [8 Regression] Rejects 416.gamess

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82431 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #2

[Bug testsuite/82412] [8 regression] gfortran.dg/graphite/pr42334-1.f fails starting with r253342

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82412 --- Comment #3 from seurer at gcc dot gnu.org --- Oh, and ISL is what comes from contrib/download_prerequisites. isl-0.18 in this case.

[Bug c++/82424] [8 Regression] ICE in tree check: expected record_type or union_type or qual_union_type, have typename_type in lookup_base, at cp/search.c:203

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82424 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug testsuite/82412] [8 regression] gfortran.dg/graphite/pr42334-1.f fails starting with r253342

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82412 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org

[Bug target/82430] [5/6/7/8 Regression] Suboptimal code generated because of unnecessary "pxor xmm0, xmm0"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82430 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1

Re: [PATCH] Pretty-print GOACC_REDUCTION arguments

Hi Tom! On Tue, 3 Oct 2017 10:56:59 +0200, Tom de Vries wrote: > On 09/27/2017 03:46 PM, Thomas Schwinge wrote: > > On Mon, 25 Sep 2017 16:57:52 +0200, Tom de Vries > > wrote: > >> currently for a GOACC_REDUCTION internal fn call we print: > >>

Re: [PATCH] Fix PR82396: qsort comparator non-negative on sorted output

> We have now had 5 days of no builds for a major target, which is a huge > inconvenience. So I don't think it is reasonable to wait any longer. well, to put things in perspective, you broke the SPARC compiler about one month ago and have done anything AFAIK since then to repair the breakage

Re: [PATCH] Improve alloca alignment

> This seems like a SPARC target problem to me -- essentially it's > claiming a higher STACK_BOUNDARY than it really has. No, it is not, I can guarantee you that the stack pointer is always aligned to 64-bit boundaries on SPARC, otherwise all hell would break loose... > Presumably there's a

  1   2   3   >