[RFC, C] add warning for unpromoted bit-field uses

We had a request from a customer to add a warning to the C front end to diagnose cases where bit-fields larger than an int are used in shift expressions; confusingly, the operation is done in the precision of the bit-field size rather than its declared type. This is a symptom of a larger probl

Re: [PATCH][11/n] Merge from match-and-simplify, bit patterns from forwprop

On Thu, Nov 6, 2014 at 12:55 AM, Richard Biener wrote: > > This merges patterns implementing the bitwise patterns from > tree-ssa-forwprop.c. I've removed duplicate functionality from > fold-const.c as I found them, some may be still lurking in the > depths. > > This also fixes a bug in genmatch

__float128 typeinfo

Hello, I am digging out https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00637.html It isn't completely clear if the libstdc++ part was accepted or not. I won't commit immediately (waiting on another patch), but I'd like to be ready. The front-end part is included for reference, both versions w

Re: [ping] libatomic: Fix sub-word CAS synthesis on LP64 targets

Thank you for approving the patch. I neglected to mention that I do not have write access. Would you or someone else be so kind as to commit this? On Fri, Nov 7, 2014 at 5:20 AM, Richard Henderson wrote: > On 11/06/2014 09:24 PM, Andrew Waterman wrote: >> 2014-10-23 Andrew Waterman >> >> *

Re: [PATCH] Don't bootstrap libcc1

Dominique, That is curious. I wouldn't have thought that the compiler selection would have had such a radical effect on the linkage flags emitted for the build directories. Jack On Sat, Nov 8, 2014 at 4:59 PM, Dominique d'Humières wrote: > >> Le 8 nov. 2014 à 22:55, Jack Howart

[PATCH] Reset contexts in possible_polymorphic_call_targets properly

Hi in a patch I work on I store ipa_polymorphic_call_contexts in a vector and thus they do not get properly constructed, merely memset to zero. This means that I happen to be using "know nothing" contexts which have their outer_type set to NULL but the various flags are also false, unlike in the p

Re: [PATCH] Don't bootstrap libcc1

> Le 8 nov. 2014 à 22:55, Jack Howarth a écrit : > > Iain, > Any idea why this isn't failing universally? On all of the > machines tested here with 'make bootstrap', the linkage of libcc1.so > finds > the necessary libstdc++ from the set of flags... > > -L/sw/src/fink.build/gcc50-5.0.0-1000

Re: [PATCH] Don't bootstrap libcc1

Iain, Any idea why this isn't failing universally? On all of the machines tested here with 'make bootstrap', the linkage of libcc1.so finds the necessary libstdc++ from the set of flags... -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/sw/src

Re: [PATCH] Don't bootstrap libcc1

On 8 Nov 2014, at 15:41, Jakub Jelinek wrote: > On Sat, Nov 08, 2014 at 04:31:28PM +0100, Dominique d'Humières wrote: >> I am still unable to bootstrap darwin14 without revision r216964 reverted. >> Executing the simplified command >> >> /opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/ >> -L/

Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap

On 11/08/14 09:16, Iain Sandoe wrote: Hi Jeff, On 7 Nov 2014, at 20:28, Jeff Law wrote: On 11/06/14 06:01, Evgeny Stupachenko wrote: Now I see that equiv reload could be special for PIC register. Let's apply more conservative patch. Darwin bootstrap passed with the patch applied on r216304 (

Re: [PATCH] Don't bootstrap libcc1

Dominique, I thought from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773#c1 that you were having clean bootstraps on darwin. I have tested x86_64-apple-darwin11/12/13/14 without issues in the creation of libcc1.0 % otool -L libcc1.0.so libcc1.0.so: /sw/lib/gcc5.0/lib/libstdc++.6.dylib (c

Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap

Hi Jeff, On 7 Nov 2014, at 20:28, Jeff Law wrote: > On 11/06/14 06:01, Evgeny Stupachenko wrote: >> Now I see that equiv reload could be special for PIC register. Let's >> apply more conservative patch. >> >> Darwin bootstrap passed with the patch applied on r216304 (along with >> already commit

[patch, ARM] Add support for crtfastmath.o

This patch adds support to the ARM backend to avoid denormals by setting the VFP flush-to-zero bit when linking with -ffast-math and similar options. The mechanism used to accomplish this is a constructor in libgcc that is conditionally linked in via STARTFILE_SPEC; it's basically identical to

Re: [PATCH] Don't bootstrap libcc1

On Sat, Nov 08, 2014 at 04:31:28PM +0100, Dominique d'Humières wrote: > I am still unable to bootstrap darwin14 without revision r216964 reverted. > Executing the simplified command > > /opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/ > -L/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/

Re: [PATCH] Don't bootstrap libcc1

I am still unable to bootstrap darwin14 without revision r216964 reverted. Executing the simplified command /opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/ -L/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -o .libs/libcc1.0.so .libs/findcomp.o -static-libstdc++ -static-libgc

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On Sat, 2014-11-08 at 13:07 +0100, Richard Biener wrote: > On Fri, Nov 7, 2014 at 10:01 PM, Richard Biener > wrote: > > On Fri, Nov 7, 2014 at 4:21 PM, David Malcolm wrote: > >> gcc/ChangeLog.gimple-classes: > >> * tree-ssa-tail-merge.c (same_succ_hash): Add checked cast. > >> (gi

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote: > To be constructive here - the above case is from within a > GIMPLE_ASSIGN case label > and thus I'd have expected > > case GIMPLE_ASSIGN: > { > gassign *a1 = as_a (s1); > gassign *a2 = as_a (s2); >

[x86, 4/n] Replace builtins with vector extensions

Hello, this patch uses &|^ for 128 bit integer vectors. I am doing the operations in type __v2du because __builtin_ia32_pand128 was apparently taking __v2di arguments, but using __v4su or any other should be equivalent. Even __int128 would in principle be ok, but since it is not usually stored

[x86, 3/n] Replace builtins with vector extensions

Hello, this patch mechanically extends +-* for integer vectors of size 256 and 512 (the previous patch only handled 128). Regtested together with the next patch. 2014-11-10 Marc Glisse * config/i386/avxintrin.h (__v4du, __v8su, __v16hu, __v32qu): New typedefs. * conf

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On Fri, Nov 7, 2014 at 10:01 PM, Richard Biener wrote: > On Fri, Nov 7, 2014 at 4:21 PM, David Malcolm wrote: >> gcc/ChangeLog.gimple-classes: >> * tree-ssa-tail-merge.c (same_succ_hash): Add checked cast. >> (gimple_equal_p): Add checked casts. >> --- >> gcc/ChangeLog.gimple-cla

Re: [GRAPHITE, PATCH] Loop unroll and jam optimization

On Sat, Nov 8, 2014 at 12:32 AM, Mircea Namolaru wrote: > Hello, > > This is the patch for unroll and jam optimizations. It is based on the > code written by Tobias from graphite-optimize-isl.c (the code was > unreachable till now) extended and enabled it via a new option > -floop-unroll-jam. Wh

Re: [PR tree-optimization/61515] Fix poor compile-time behaviour in tree-ssa-threadedge.c

On Sat, Nov 8, 2014 at 12:00 AM, Jeff Law wrote: > > When we thread across a backedge, we have to do invalidations of > equivalences. This changes the method by which we identify which objects > need invalidation. Previously we'd walk all the SSA_NAMEs and see if any > had a current value that n

[PATCH] Fix PR56480 aka DR374. Allow explicit specialization in enclosing namespace.

DR374: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#374 allows explicit specialization of templates in the enclosing namespace. This is implemented by consolidating check_specialization_namespace and check_explicit_instantiation_namespace into a new function and pedwarning only for

Ping: FR-V rtx iterator patches

Ping for these FR-V patches: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02645.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02646.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02647.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02648.html which convert callers of for_each_rtx to

Re: [patch sdbout]: Fix ICE on -debug testsuite test const2.C for coff

Hi Jeff, 2014-11-07 21:03 GMT+01:00 Jeff Law : > On 11/06/14 12:37, Kai Tietz wrote: >> >> Hi, >> >> This fixes recent fallout of debug-tests on Windows target for sdbout >> (coff) caused by an ICE. >> >> ChangeLog >> >> 2014-11-06 Kai Tietz >> >> * sdbout.c (sdbout_symbol): Eliminate regi

[PATCH driver/36312] should refuse to overwrite input file with output file

This patch is a minor variant of the one approved here: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00246.html fixing the problem with linker parameters (which are stored in infiles). https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00391.html The only part that has changed, and thus requires ap

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On Fri, Nov 07, 2014 at 10:01:45PM +0100, Richard Biener wrote: > Just a comment as these patches flow by - I think this is a huge step > backwards from "enforcing" s1/s2 being a gimple_assign inside > gimple_assign_rhs1 to this as_a boilerplate at _each_ callsite! FWIW, I feel the same way. Mor

Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap

> So that code creates a set of conflicts which, if I'm reading correctly, > will prevent the PIC value from living in a register at all. Which > ought to result in it being dumped into the stack and being reloaded for > each use. Which ought to be safe (modulo the liveness bug Vlad is > working

Re: [GRAPHITE, PATCH] Loop unroll and jam optimization

On Sat, Nov 08, 2014 at 12:32:05AM +0100, Mircea Namolaru wrote: > Hello, > > This is the patch for unroll and jam optimizations. It is based on the > code written by Tobias from graphite-optimize-isl.c (the code was > unreachable till now) extended and enabled it via a new option > -floop-unrol

Re: [PR c/52952] More precise locations within format strings

On 7 November 2014 22:39, Joseph Myers wrote: >> Neither Per nor Tom are active in GCC anymore. If the FE maintainers >> do not feel comfortable reviewing line-map changes, could you nominate >> Dodji as line-map maintainer if he is willing to accept it? I think he >> is currently the person that