Multiprecision Arithmetic Builtins

[Oleg Endo]

Hi all,

I was thinking of adding some SH specific builtin functions for the
addc, subc and negc instructions.  

Are there any plans to add clang's target independent multiprecision
arithmetic builtins (http://clang.llvm.org/docs/LanguageExtensions.html)
to GCC?

A while ago clang's checked arithmetic builtins were added to GCC.  So
just in case, I wanted to check before introducing target specific
builtins.

Cheers,
Oleg

[Bug other/67659] ICE: Linux kernel/rcu/tree.c:3261:6

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67659

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-21
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
(In reply to Nathan McSween from comment #0)
> ICE while compiling linux kernel, at kernel/rcu/tree.c:3261:6 using latest
> git as of sunday 2015-09-20

Please provide all required information, as instructed in [1].

[1] https://gcc.gnu.org/bugs/

[SH][committed] Remove SH5/SH64 documentation

[Oleg Endo]

Hi,

As announced here https://gcc.gnu.org/ml/gcc/2015-08/msg00101.html this
patch removes some SH5/SH64 related documentation.
Tested with make info dvi pdf.
Committed as r227959.

Cheers,
Oleg

gcc/ChangeLog:
* doc/invoke.texi (SH Options): Undocument SH5/SH64 related
options.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 227958)
+++ gcc/doc/invoke.texi	(working copy)
@@ -983,16 +983,12 @@
 -m3  -m3e @gol
 -m4-nofpu  -m4-single-only  -m4-single  -m4 @gol
 -m4a-nofpu -m4a-single-only -m4a-single -m4a -m4al @gol
--m5-64media  -m5-64media-nofpu @gol
--m5-32media  -m5-32media-nofpu @gol
--m5-compact  -m5-compact-nofpu @gol
 -mb  -ml  -mdalign  -mrelax @gol
--mbigtable -mfmovd -mhitachi -mrenesas -mno-renesas -mnomacsave @gol
+-mbigtable -mfmovd -mrenesas -mno-renesas -mnomacsave @gol
 -mieee -mno-ieee -mbitops  -misize  -minline-ic_invalidate -mpadstruct @gol
 -mspace -mprefergot  -musermode -multcost=@var{number} -mdiv=@var{strategy} @gol
 -mdivsi3_libfunc=@var{name} -mfixed-range=@var{register-range} @gol
--mindexed-addressing -mgettrcost=@var{number} -mpt-fixed @gol
--maccumulate-outgoing-args -minvalid-symbols @gol
+-maccumulate-outgoing-args @gol
 -matomic-model=@var{atomic-model} @gol
 -mbranch-cost=@var{num} -mzdcbranch -mno-zdcbranch @gol
 -mcbranch-force-delay-slot @gol
@@ -20805,33 +20801,6 @@
 @option{-dsp} to the assembler.  GCC doesn't generate any DSP
 instructions at the moment.
 
-@item -m5-32media
-@opindex m5-32media
-Generate 32-bit code for SHmedia.
-
-@item -m5-32media-nofpu
-@opindex m5-32media-nofpu
-Generate 32-bit code for SHmedia in such a way that the
-floating-point unit is not used.
-
-@item -m5-64media
-@opindex m5-64media
-Generate 64-bit code for SHmedia.
-
-@item -m5-64media-nofpu
-@opindex m5-64media-nofpu
-Generate 64-bit code for SHmedia in such a way that the
-floating-point unit is not used.
-
-@item -m5-compact
-@opindex m5-compact
-Generate code for SHcompact.
-
-@item -m5-compact-nofpu
-@opindex m5-compact-nofpu
-Generate code for SHcompact in such a way that the
-floating-point unit is not used.
-
 @item -mb
 @opindex mb
 Compile code for the processor in big-endian mode.
@@ -21006,68 +20975,10 @@
 @item -mdiv=@var{strategy}
 @opindex mdiv=@var{strategy}
 Set the division strategy to be used for integer division operations.
-For SHmedia @var{strategy} can be one of: 
+@var{strategy} can be one of: 
 
 @table @samp
 
-@item fp 
-Performs the operation in floating point.  This has a very high latency,
-but needs only a few instructions, so it might be a good choice if
-your code has enough easily-exploitable ILP to allow the compiler to
-schedule the floating-point instructions together with other instructions.
-Division by zero causes a floating-point exception.
-
-@item inv
-Uses integer operations to calculate the inverse of the divisor,
-and then multiplies the dividend with the inverse.  This strategy allows
-CSE and hoisting of the inverse calculation.  Division by zero calculates
-an unspecified result, but does not trap.
-
-@item inv:minlat
-A variant of @samp{inv} where, if no CSE or hoisting opportunities
-have been found, or if the entire operation has been hoisted to the same
-place, the last stages of the inverse calculation are intertwined with the
-final multiply to reduce the overall latency, at the expense of using a few
-more instructions, and thus offering fewer scheduling opportunities with
-other code.
-
-@item call
-Calls a library function that usually implements the @samp{inv:minlat}
-strategy.
-This gives high code density for @code{m5-*media-nofpu} compilations.
-
-@item call2
-Uses a different entry point of the same library function, where it
-assumes that a pointer to a lookup table has already been set up, which
-exposes the pointer load to CSE and code hoisting optimizations.
-
-@item inv:call
-@itemx inv:call2
-@itemx inv:fp
-Use the @samp{inv} algorithm for initial
-code generation, but if the code stays unoptimized, revert to the @samp{call},
-@samp{call2}, or @samp{fp} strategies, respectively.  Note that the
-potentially-trapping side effect of division by zero is carried by a
-separate instruction, so it is possible that all the integer instructions
-are hoisted out, but the marker for the side effect stays where it is.
-A recombination to floating-point operations or a call is not possible
-in that case.
-
-@item inv20u
-@itemx inv20l
-Variants of the @samp{inv:minlat} strategy.  In the case
-that the inverse calculation is not separated from the multiply, they speed
-up division where the dividend fits into 20 bits (plus sign where applicable)
-by inserting a test to skip a number of operations in this case; this test
-slows down the case of larger dividends.  @samp{inv20u} assumes the case of a such
-a small dividend to be unlikely, and @samp{inv20l} assumes it to be likely.
-
-@end table
-
-For targets other than SHmedia 

[Bug libstdc++/67647] [6 regression] boostrap FAIL with --disable-libstdcxx-dual-abi

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67647

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
  Component|bootstrap   |libstdc++
   Target Milestone|--- |6.0

[Bug c++/67650] undef reference with -fdevirtualize

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
Honza - can you please look at the few devirt issues we still have on trunk and
the gcc 5 branch?

[Bug middle-end/67662] -fsanitize=undefined cries wolf for X - 1 + X when X is 2**30

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67662

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
  /* With undefined overflow we can only associate constants with one
 variable, and constants whose association doesn't overflow.  */
  if ((POINTER_TYPE_P (atype) && POINTER_TYPE_OVERFLOW_UNDEFINED)
  || (INTEGRAL_TYPE_P (atype) && !TYPE_OVERFLOW_WRAPS (atype)))
{
...
  /* The only case we can still associate with two variables
 is if they are the same, modulo negation and bit-pattern
 preserving conversions.  */
  if (!operand_equal_p (tmp0, tmp1, 0))
ok = false;

but that's only if they cancel out.  I think the above code is mine, thus,
mine.

[Bug rtl-optimization/20211] autoincrement generation is poor

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

Oleg Endo  changed:

   What|Removed |Added

 Target||sh*-*-*
 CC||olegendo at gcc dot gnu.org

--- Comment #40 from Oleg Endo  ---
Just hit this PR by accident.  I wonder how many address mode related PRs are
hanging around there...

I hope that the AMS pass will help.  The current branch is
https://github.com/erikvarga/gcc

[Bug sanitizer/67662] New: -fsanitize=undefined cries wolf for X - 1 + X when X is 2**30

[eggert at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67662

Bug ID: 67662
   Summary: -fsanitize=undefined cries wolf for X - 1 + X when X
is 2**30
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36358=edit
Test program illustrating the bug

I uncovered this bug while trying to use -fsanitize=undefined on the tzcode
source.

gcc -fsanitize=undefined (x86-64) reports an error at runtime for the
expression 'X - 1 + X' when X is 2**30, even though that expression does not
overflow. To reproduce the problem, compile and run the attached program u.c
with:

gcc -fsanitize=undefined -static-libubsan -O2 u.c
./a.out

It's a valid program that does not overflow, but the output I get is:

u.c:5:31: runtime error: signed integer overflow: 1073741824 + 1073741824
canno\
t be represented in type 'int'
u.c:5:7: runtime error: signed integer overflow: -2147483648 - 1 cannot be
repr\
esented in type 'int'

There is a similar problem with 2**62 and 'long long'.

[Bug middle-end/67662] -fsanitize=undefined cries wolf for X - 1 + X when X is 2**30

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67662

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-21
  Component|sanitizer   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This is a reassociation issue inside fold-const.  Basically we change x - 1 + x
to x + x - 1 which is invalid as it introduces an overflow which was not there
before.  (This is why we need an addition tree where overflow is defined).

[Bug target/66867] Suboptimal code generation for atomic_compare_exchange

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867

Alan Modra  changed:

   What|Removed |Added

 Target||powerpc64*-*-*, x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-21
 CC||amodra at gmail dot com
Summary|Suboptimal code generation  |Suboptimal code generation
   |for C11 |for atomic_compare_exchange
   |atomic_compare_exchange_str |
   |ong_explicit()  |
 Ever confirmed|0   |1

--- Comment #2 from Alan Modra  ---
Confirmed.  Here's another related testcase showing unnecessary stack memory
writes and reads on both powerpc64le and x86_64.

int test2 (int *ptr, int value, int comparand)
{
  __atomic_compare_exchange_n (ptr, , value,
   false, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
  return comparand;
}

Re: [PR middle-end/60832] Do not convert widest_int to tree just for printing it.

[Richard Biener]

On Sun, 20 Sep 2015, Manuel López-Ibáñez wrote:

> In do_warn_aggressive_loop_optimizations, we convert to a tree just to print a
> widest_int. Apart from overly complicated, this results in printing '3u'
> instead of just '3'.
> 
> Unfortunately, adding a printf-like conversion specifier would require making
> pretty-print.c link with wide-int.cc, which will include a lot of new
> dependencies into several other programs (gcov-tool for example). It would be
> possible to add the conversion specifier to every FE pretty-printer, but this
> still would require updating c-format.c, which is far from trivial. A simpler
> approach is to convert to a string rather than to a tree.

I'd add the pretty printer overloads to wide-int-print.[ch], but yes
it would require a change in c-format.c.

> In addition, "iteration 3 invokes undefined behavior within this loop"
> seems to me clearer than  "iteration 3 invokes undefined behavior;
> containing loop".
> 
> Boot in x86_64-linux-gnu
> 
> OK?

Ok.  Let's remember this case and if more of these pop up try working
on a "proper" solution.

Thanks,
Richard.

> gcc/testsuite/ChangeLog:
> 
> 2015-09-20  Manuel López-Ibáñez  
> 
> PR middle-end/60832
> * gcc.dg/pr53265.c: Update.
> 
> gcc/ChangeLog:
> 
> 2015-09-20  Manuel López-Ibáñez  
> 
> PR middle-end/60832
> * tree-ssa-loop-niter.c (do_warn_aggressive_loop_optimizations):
> Print i_bound without converting it to a tree.
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609

--- Comment #7 from Rich Felker  ---
Created attachment 36359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36359=edit
preprocessed source still affected by the bug

Oddly I'm still experiencing this bug for some functions but not others, even
with the patch applied. I've attached preprocessed output of a file which is
being miscompiled: the reference to __do_cleanup_push wrongly binds locally,
but the reference to __do_cleanup_pop is overridable like it should be.

[Bug target/67474] [6 regression] tree-vect-loop.c:2759:1: error: insn does not satisfy its constraints breaks ARM bootstrap

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67474

--- Comment #1 from Mikael Pettersson  ---
Still occurs with gcc-6-20150920.

[Bug middle-end/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67651

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-21
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
We optimize this since GCC 3.4 and -fno-delete-null-pointer-checks already
doesn't have any effect on that.  GCC 3.3 wasn't able to optimize this with
any setting of this flag.

@item -fdelete-null-pointer-checks
@opindex fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that
no code or data element resides at address zero.
This option enables simple constant
folding optimizations at all optimization levels.  In addition, other
optimization passes in GCC use this flag to control global dataflow
analyses that eliminate useless checks for null pointers; these assume
that a memory access to address zero always results in a trap, so
that if a pointer is checked after it has already been dereferenced,
it cannot be null.

Note however that in some environments this assumption is not true.
Use @option{-fno-delete-null-pointer-checks} to disable this optimization
for programs that depend on that behavior.

This option is enabled by default on most targets.  On Nios II ELF, it
defaults to off.  On AVR and CR16, this option is completely disabled.


so confirmed.  Note that GIMPLE optimizers are fine and we end up expanding
from

main ()
{
  int _1;

  :
  if (&_vector_table == 0B)
goto ;
  else
goto ;

  :

  :
  # _1 = PHI <1(2), 2(3)>
  return _1;

But RTL generation already fucks this up:

;; Generating RTL for gimple basic block 2

;; if (&_vector_table == 0B)

(nil)

...

;;
;; Full RTL generated for this function:
;;
(note 1 0 5 NOTE_INSN_DELETED)
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;  prev block 0, next block 1, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   ENTRY [100.0%]  (FALLTHRU)
(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 5 4 2 NOTE_INSN_FUNCTION_BEG)
(insn 4 2 10 2 (set (reg:SI 87 [ D.1844 ])
(const_int 2 [0x2])) t.c:10 -1
 (nil))
(insn 10 4 14 2 (set (reg:SI 88 [  ])
(reg:SI 87 [ D.1844 ])) -1
 (nil))
(insn 14 10 15 2 (set (reg/i:SI 0 ax)
(reg:SI 88 [  ])) t.c:12 -1
 (nil))
(insn 15 14 0 2 (use (reg/i:SI 0 ax)) t.c:12 -1
 (nil))
;;  succ:   EXIT [100.0%]  (FALLTHRU)


Because of

simplify_const_relational_operation (code=EQ, mode=DImode, op0=0x76a06168, 
op1=0x768d3480)
at /space/rguenther/src/svn/trunk/gcc/simplify-rtx.c:4840
5088  /* Some addresses are known to be nonzero.  We don't know
5089 their sign, but equality comparisons are known.  */
5090  if (nonzero_address_p (trueop0))
5091{
5092  if (code == EQ || code == LEU)
5093return const0_rtx;

on (symbol_ref:DI ("_vector_table") [flags 0x40] )

/* Return true if X is an address that is known to not be zero.  */

bool
nonzero_address_p (const_rtx x)
{
  const enum rtx_code code = GET_CODE (x);

  switch (code)
{
case SYMBOL_REF:
  return !SYMBOL_REF_WEAK (x);

which misses a check on flag_delete_null_pointer_checks.  Fixing that fixes the
bug.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 28791, which changed state.

Bug 28791 Summary: sh64-elf -mdiv= options bitrot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28791

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug libobjc/24714] objc/execute/bf-10.m and others fail on sh64-elf

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24714

Oleg Endo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||olegendo at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Oleg Endo  ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html

[Bug target/28791] sh64-elf -mdiv= options bitrot

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28791

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||olegendo at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Oleg Endo  ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html

[PATCH] Fix PR67651

[Richard Biener]

The following fixes a very old bug in RTL nonzero_address_p which fails
to consider -fno-delete-null-pointer-checks.  Fixing that makes the
testcase

extern unsigned int _vector_table;

int main(void)
{
  unsigned int *vector_base = &_vector_table;

  if (vector_base == 0) {
  return 1;
  } else {
  return 2;
  }
}

not optimize the check with that flag.  We appearantly never got this
right, so I'll install this on trunk only.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Richard.

2015-09-21  Richard Biener  

PR middle-end/67651
* rtlanal.c (nonzero_address_p): SYMBOL_REFs may have zero
address with -fno-delete-null-pointer-checks.

Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 227899)
+++ gcc/rtlanal.c   (working copy)
@@ -723,7 +723,7 @@ nonzero_address_p (const_rtx x)
   switch (code)
 {
 case SYMBOL_REF:
-  return !SYMBOL_REF_WEAK (x);
+  return flag_delete_null_pointer_checks && !SYMBOL_REF_WEAK (x);
 
 case LABEL_REF:
   return true;

Re: [PATCH tree-inline] do not say "called from here" with UNKNOWN_LOCATION

[Richard Biener]

On Fri, Sep 18, 2015 at 8:47 PM, Manuel López-Ibáñez
 wrote:
> And now with the patch.
>
> On 18 September 2015 at 20:40, Manuel López-Ibáñez
>  wrote:
>> In https://sourceware.org/ml/libc-alpha/2014-12/msg00300.html, we give a
>> "called from here" note without actually having a location, which looks
>> strange. I haven't been able to generate such a testcase. In this patch, we
>> assert this cannot happen when checking and simply skip the extra note in
>> release mode.
>>
>> Boot on x86_64-linux-gnu
>>
>> OK?

Hmm.

input_location is set from the call stmt:

  /* FIXME: instantiate_decl isn't called by inlinable_function_p.  */
  saved_location = input_location;
  input_location = gimple_location (stmt);

it would be nice to get rid of that.

If the call is artificially generated it might have no location so I
think the assert
is bogus.  Also in the case of UNKNOWN_LOCATION it would be nice to at
least note the function we are failing to inline to (thus, use
DECL_SOURCE_LOCATION
of cfun->decl).  So better add a diag_location and compute that upfront to avoid
repeating the check.

Did you investigate the glibc case on whether caller or callee are artificial?

Richard.

>>
>> gcc/testsuite/ChangeLog:
>>
>> 2015-09-18  Manuel López-Ibáñez  
>>
>> * gcc.target/i386/inline_error.c (int bar): Use dg-message for note.
>> * gcc.target/i386/pr57756.c (static __inline int caller): Likewise.
>> * gcc.target/i386/pr59789.c (f1): Likewise.
>> * gcc.target/i386/intrinsics_5.c (__m128i foo): Likewise.
>> * gcc.target/i386/intrinsics_6.c: Likewise.
>> * gcc.dg/winline-5.c (int t): Likewise.
>> * gcc.dg/winline-9.c (t): Likewise.
>> * gcc.dg/always_inline2.c (q): Likewise.
>> * gcc.dg/winline-2.c (inline int t): Likewise.
>> * gcc.dg/winline-6.c: Likewise.
>> * gcc.dg/winline-10.c (void g): Likewise.
>> * gcc.dg/pr49243.c (void parse): Likewise.
>> * gcc.dg/always_inline3.c (q2): Likewise.
>> * gcc.dg/winline-3.c: Likewise.
>> * gcc.dg/winline-7.c (inline void *t): Likewise.
>>
>> gcc/ChangeLog:
>>
>> 2015-09-18  Manuel López-Ibáñez  
>>
>> * tree-inline.c (expand_call_inline): Use inform for extra note.
>> Do not give "called from here" with UNKNOWN_LOCATION.

[Bug c++/67663] New: ambiguous namespace/class name not reported as error

[andreim77 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67663

Bug ID: 67663
   Summary: ambiguous namespace/class name not reported as error
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreim77 at yahoo dot com
  Target Milestone: ---

#include 

struct a {
static const int i=0;
};

namespace x {
namespace a {
int i;
}
}

using namespace x;

int main()
{
a::i=1;
std::cout << "i = " << a::i;
return 0;
}

no error with GCC

clang report:
main.cpp:17:5: error: 'a' is not a class, namespace, or enumeration
a::i=1;
^
main.cpp:17:5: error: reference to 'a' is ambiguous
a::i=1;
^
main.cpp:3:8: note: candidate found by name lookup is 'a'
struct a {
   ^
main.cpp:8:15: note: candidate found by name lookup is 'x::a'
namespace a {
  ^
main.cpp:18:28: error: 'a' is not a class, namespace, or enumeration
std::cout << "i = " << a::i;
   ^
main.cpp:18:28: error: reference to 'a' is ambiguous
std::cout << "i = " << a::i;
   ^
main.cpp:3:8: note: candidate found by name lookup is 'a'
struct a {
   ^
main.cpp:8:15: note: candidate found by name lookup is 'x::a'
namespace a {
  ^
main.cpp:20:2: error: no newline at end of file [-Werror,-Wnewline-eof]
}
 ^
5 errors generated.

[Bug c/67661] New: Wrong warning when declare VLAs: operation on 'b' may be undefined [-Wsequence-point]

[leechung at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661

Bug ID: 67661
   Summary: Wrong warning when declare VLAs: operation on 'b' may
be undefined [-Wsequence-point]
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leechung at 126 dot com
  Target Milestone: ---

The following code produces a warning: operation on 'b' may be
undefined.[-Wsequence-point]

int x = 0, y [++ x], z [++ x];

But N1570 6.8 says:
A block allows a set of declarations and statements to be grouped into one
syntactic unit. The initializers of objects that have automatic storage
duration, and the variable length array declarators of ordinary identifiers
with block scope, are evaluated and the values are stored in the objects
(including storing an indeterminate value in objects without an initializer)
each time the declaration is reached in the order of execution, as if it were a
statement, and within each declaration in the order that declarators appear.

and 6.7.6 says:
A full declarator is a declarator that is not part of another declarator. The
end of a full declarator is a sequence point.

Re: [v3 patch] refactoring - pull out common data members as _Context

[Tim Shen]

Hi,

As the changes grow
(https://github.com/innocentim/gcc/commits/master), it's getting
harder to rebase them onto svn trunk. Can we start slowly reviewing
and checking these in? Should I post them one by one to the lis?

These patches typically break one giant piece of code (mainly
_Executor::_M_dfs) into different smaller ones and fix mostly known
issues and standard conformance issues.


-- 
Regards,
Tim Shen

[Bug middle-end/67639] ICE at -O1 and above on x86_64-linux-gnu in expand_gimple_basic_block, at cfgexpand.c:5697

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67639

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-21
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We shouldn't even get to expanding a BB if there were errors.

Of course the issue is (again - dup?) that the "invalid register name" error
is emitted during expansion rather than during parsing.

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609

--- Comment #8 from Rich Felker  ---
Perhaps hold off on worrying about this; it's only happening with -mfdpic (with
my forward-port of the fdpic patch applied) so it's possible that the bug is on
my end in code that's not in upstream gcc. I'll follow up on this more later.

[Bug target/67636] [6 Regression][SH] gcc.target/sh/pr54236-1.c failures

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67636

Richard Biener  changed:

   What|Removed |Added

Version|unknown |6.0
   Target Milestone|--- |6.0

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67649

--- Comment #1 from Richard Biener  ---
You are using -O3 -march=native it seems.  Note that the error doesn't make
much sense to me.

[PATCH] [ARM] Replacing variable swaps that use a temporary variable with a call to std::swap in gcc/config/arm/arm.c

[Bilyan Borisov]

Replacing variable swaps that use a temporary variable with a call to 
std::swap. Tested against arm-none-eabi target including a variant with neon 
enabled.

2015-XX-XX  Bilyan Borisov  

* config/arm/arm.c (thumb_output_move_mem_multiple): Replaced
operands[4] operands[5] swap with std::swap, removed tmp variable.
(arm_evpc_neon_vzip): Replaced in0/in1 and
out0/out1 swaps with std::swap, removed x variable.
(arm_evpc_neon_vtrn): Replaced in0/int1 and
out0/out1 swaos with std::swap, removed x variable.
(arm_expand_vec_perm_const_1): Replaced
d->op0/d->op1 swap with std::swap, removed x variable.
(arm_evpc_neon_vuzp): Replaced in0/in1 and
out0/out1 swaps with std::swap, removed x variable.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index fa4e083adfe215b5820237f3cc6b449dbdefc778..dc549fe470e5a82d740cf8014057ee2cc1d54085 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -25362,17 +25362,12 @@ thumb_load_double_from_address (rtx *operands)
 const char *
 thumb_output_move_mem_multiple (int n, rtx *operands)
 {
-  rtx tmp;
-
   switch (n)
 {
 case 2:
   if (REGNO (operands[4]) > REGNO (operands[5]))
-	{
-	  tmp = operands[4];
-	  operands[4] = operands[5];
-	  operands[5] = tmp;
-	}
+	std::swap (operands[4], operands[5]);
+
   output_asm_insn ("ldmia\t%1!, {%4, %5}", operands);
   output_asm_insn ("stmia\t%0!, {%4, %5}", operands);
   break;
@@ -27885,7 +27880,7 @@ static bool
 arm_evpc_neon_vuzp (struct expand_vec_perm_d *d)
 {
   unsigned int i, odd, mask, nelt = d->nelt;
-  rtx out0, out1, in0, in1, x;
+  rtx out0, out1, in0, in1;
   rtx (*gen)(rtx, rtx, rtx, rtx);
 
   if (GET_MODE_UNIT_SIZE (d->vmode) >= 8)
@@ -27929,14 +27924,14 @@ arm_evpc_neon_vuzp (struct expand_vec_perm_d *d)
   in1 = d->op1;
   if (BYTES_BIG_ENDIAN)
 {
-  x = in0, in0 = in1, in1 = x;
+  std::swap (in0, in1);
   odd = !odd;
 }
 
   out0 = d->target;
   out1 = gen_reg_rtx (d->vmode);
   if (odd)
-x = out0, out0 = out1, out1 = x;
+std::swap (out0, out1);
 
   emit_insn (gen (out0, in0, in1, out1));
   return true;
@@ -27948,7 +27943,7 @@ static bool
 arm_evpc_neon_vzip (struct expand_vec_perm_d *d)
 {
   unsigned int i, high, mask, nelt = d->nelt;
-  rtx out0, out1, in0, in1, x;
+  rtx out0, out1, in0, in1;
   rtx (*gen)(rtx, rtx, rtx, rtx);
 
   if (GET_MODE_UNIT_SIZE (d->vmode) >= 8)
@@ -27996,14 +27991,14 @@ arm_evpc_neon_vzip (struct expand_vec_perm_d *d)
   in1 = d->op1;
   if (BYTES_BIG_ENDIAN)
 {
-  x = in0, in0 = in1, in1 = x;
+  std::swap (in0, in1);
   high = !high;
 }
 
   out0 = d->target;
   out1 = gen_reg_rtx (d->vmode);
   if (high)
-x = out0, out0 = out1, out1 = x;
+std::swap (out0, out1);
 
   emit_insn (gen (out0, in0, in1, out1));
   return true;
@@ -28089,7 +28084,7 @@ static bool
 arm_evpc_neon_vtrn (struct expand_vec_perm_d *d)
 {
   unsigned int i, odd, mask, nelt = d->nelt;
-  rtx out0, out1, in0, in1, x;
+  rtx out0, out1, in0, in1;
   rtx (*gen)(rtx, rtx, rtx, rtx);
 
   if (GET_MODE_UNIT_SIZE (d->vmode) >= 8)
@@ -28134,14 +28129,14 @@ arm_evpc_neon_vtrn (struct expand_vec_perm_d *d)
   in1 = d->op1;
   if (BYTES_BIG_ENDIAN)
 {
-  x = in0, in0 = in1, in1 = x;
+  std::swap (in0, in1);
   odd = !odd;
 }
 
   out0 = d->target;
   out1 = gen_reg_rtx (d->vmode);
   if (odd)
-x = out0, out0 = out1, out1 = x;
+std::swap (out0, out1);
 
   emit_insn (gen (out0, in0, in1, out1));
   return true;
@@ -28264,14 +28259,11 @@ arm_expand_vec_perm_const_1 (struct expand_vec_perm_d *d)
   if (d->perm[0] >= d->nelt)
 {
   unsigned i, nelt = d->nelt;
-  rtx x;
 
   for (i = 0; i < nelt; ++i)
 	d->perm[i] = (d->perm[i] + nelt) & (2 * nelt - 1);
 
-  x = d->op0;
-  d->op0 = d->op1;
-  d->op1 = x;
+  std::swap (d->op0, d->op1);
 }
 
   if (TARGET_NEON)

[Bug target/58866] sh64: Wrong genmultilib invocation

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58866

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Oleg Endo  ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html

Re: [ARM] Fix PR middle-end/65958

[Eric Botcazou]

> On targets using thumb1, I can see:
> - the new test failing (you should probably add a dg-skip or an
> effective-target directive)

OK, I have added:

/* { dg-skip-if "" { arm_thumb1 } } */

as in the ivopts-orig_biv-inc.c test.

> - gcc.dg/pr48134.c now fails, saying:
> sorry, unimplemented: -fstack-check=specific for THUMB1
> while the error message is the same as for your new test, I'm
> wondering why/how it actually passed before your patch?

Yeah, it's a bug, -fstack-check=specific should have been rejected before for 
all ARM targets since it was not implemented.  Will fix.

-- 
Eric Botcazou

[Bug target/37633] [4.9/5/6 Regression] wrong register use on sh64

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||olegendo at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #17 from Oleg Endo  ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html

Re: [PATCH] 2015-09-03 Benedikt Huber <benedikt.hu...@theobroma-systems.com> Philipp Tomsich <philipp.toms...@theobroma-systems.com>

[Marcus Shawcroft]

Hi,

Thanks for your work on this.  There are a bunch of predominantly
style nits in line below.  My none nit comments on this patch are:

This should be left turned off for all cores where we have not seen
benchmark numbers to indicate that this optimization is a benefit, we
can take patches for each core in the future once numbers are
available.

Given the absence of numbers for some of the cores and the significant
impact on one core this should remain disabled by default on generic.

We don't necessarily want a proliferation of user orientated tuning
options without good reason, instead the per core default tuning
behaviour should make the right choice per core, hence I think -mrecip
should be dropped.  We already have the -moverride= mechanism to
provide a developer orientated mechanism to override the per core
tuning flag.

Further comments inline

Thanks

/Marcus

On 7 September 2015 at 11:40, Benedikt Huber
 wrote:


--- a/gcc/config/aarch64/aarch64-tuning-flags.def
+++ b/gcc/config/aarch64/aarch64-tuning-flags.def
@@ -29,4 +29,5 @@
  AARCH64_TUNE_ to give an enum name. */

 AARCH64_EXTRA_TUNING_OPTION ("rename_fma_regs", RENAME_FMA_REGS)
+AARCH64_EXTRA_TUNING_OPTION ("mrecip_default_enabled", MRECIP_DEFAULT_ENABLED)

This name is exposed via the -moverride=tune= option, perhaps a
better name would be:
+AARCH64_EXTRA_TUNING_OPTION ("recip_sqrt", RECIP_SQRT)


> +/* Add builtins for reciprocal square root. */
> +void
> +aarch64_add_builtin_rsqrt (void)
> +{
> +  tree fndecl = NULL;
> +  tree ftype = NULL;
> +
> +  tree V2SF_type_node = build_vector_type (float_type_node, 2);
> +  tree V2DF_type_node = build_vector_type (double_type_node, 2);
> +  tree V4SF_type_node = build_vector_type (float_type_node, 4);
> +
> +  ftype = build_function_type_list (double_type_node, double_type_node, 
> NULL_TREE);

Line length exceeds 80 characters.

> +  fndecl = add_builtin_function ("__builtin_aarch64_rsqrt_df",
> +ftype, AARCH64_BUILTIN_RSQRT_DF, BUILT_IN_MD, NULL, NULL_TREE);
> +  aarch64_builtin_decls[AARCH64_BUILTIN_RSQRT_DF] = fndecl;
> +
> +  ftype = build_function_type_list (float_type_node, float_type_node, 
> NULL_TREE);

Line length exceeds 80 characters.

> +/* Function to expand reciprocal square root builtins. */
> +static rtx
> +aarch64_expand_builtin_rsqrt (int fcode, tree exp, rtx target)
> +{
> +  rtx pat;
> +  tree arg0 = CALL_EXPR_ARG (exp, 0);
> +  rtx op0 = expand_normal (arg0);
> +
> +  enum insn_code c;
> +
> +  switch (fcode)
> +{
> +  case AARCH64_BUILTIN_RSQRT_DF:
> +c = CODE_FOR_rsqrt_df2; break;

Leading blocks of 8 spaces should be TAB's, likewise the rest of the patch.

> +/* Return builtin for reciprocal square root. */
> +tree
> +aarch64_builtin_rsqrt (unsigned int fn, bool md_fn)

Blank line between function comments and function, likewise through
the rest of the patch please.

> diff --git a/gcc/config/aarch64/aarch64-opts.h 
> b/gcc/config/aarch64/aarch64-opts.h
> index bf6bb7b..f8e79cb 100644
> --- a/gcc/config/aarch64/aarch64-opts.h
> +++ b/gcc/config/aarch64/aarch64-opts.h
> @@ -73,4 +73,11 @@ enum aarch64_code_model {
>AARCH64_CMODEL_LARGE
>  };
>
> +/* Each core can have -mrecip enabled or disabled by default. */
> +enum aarch64_mrecip {

{ on new line please.

> +  AARCH64_MRECIP_OFF = 0,
> +  AARCH64_MRECIP_ON,
> +  AARCH64_MRECIP_DEFAULT,

Trailing , will give a "comma at end of enumerator list" warning every
time this file is included,  drop the comma please.

> +/* Function to decide when to use
> + * reciprocal square root builtins. */

Drop the leading * on follow on comment lines, here and elsewhere in
the patch please.

> +/* Select reciprocal square root initial estimate
> + * insn depending on machine mode. */
> +rsqrte_type get_rsqrte_type (enum machine_mode mode)

New line between type and function name please, likewise for other
instance in this patch.

> +  for (int i = 0; i < iterations; ++i)
> +{
> +  rtx x1 = gen_reg_rtx (mode);
> +  rtx x2 = gen_reg_rtx (mode);
> +  rtx x3 = gen_reg_rtx (mode);
> +  emit_set_insn (x2, gen_rtx_MULT (mode, x0, x0));
> +
> +  emit_insn ((*get_rsqrts_type (mode)) (x3, xsrc, x2));
> +
> +  emit_set_insn (x1, gen_rtx_MULT (mode, x0, x3));
> +  x0 = x1;
> +}
> +
> +  emit_move_insn (dst, x0);
> +  return;

Superflous return, drop it please.

> +#undef TARGET_BUILTIN_RECIPROCAL
> +#define TARGET_BUILTIN_RECIPROCAL aarch64_builtin_reciprocal
> +

The rest of these TARGET_* defines are in alphabetical order, please
insert the new one in order.

> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> +
> +mlow-precision-recip-sqrt
> +Common Var(flag_mrecip_low_precision_sqrt) Optimization
> +Run fewer approximation steps to reduce latency and precision.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi

> +@item -mlow-precision-recip-sqrt
> +@item -mno-low-precision-recip-sqrt
> +@opindex 

[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch

[davem at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622

--- Comment #4 from davem at gcc dot gnu.org ---
I've decided the revert LRA support for now.  Debugging this failure is going
to be extremely time consuming, and in the meantime it's better to have the
build working properly.

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

[H.J. Lu]

On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel  wrote:
> - Original Message -
>> From: "H.J. Lu via cfe-dev" 
>> To: "GCC Development" , cfe-...@lists.llvm.org
>> Sent: Monday, September 21, 2015 11:27:18 AM
>> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
>>
>> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu 
>> wrote:
>> > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu 
>> > wrote:
>> >>> To implement interrupt and exception handlers for x86 processors,
>> >>> a
>> >>> compiler should support:
>> >>>
>> >>> 1. void * __builtin_ia32_interrupt_data (void)
>> >>
>> >> I got a feedback on the name of this builtin function.  Since
>> >> it also works for 64-bit,  we should avoid ia32 in its name.
>> >> We'd like to change it to
>> >>
>> >> void * __builtin_interrupt_data (void)
>> >>
>> >
>> > Here is the updated spec.
>> >
>>
>> This updated spec adds
>>
>>unsigned int __builtin_exception_error (void)
>>unsigned long long int __builtin_exception_error (void)
>>
>> This function returns the exception error code pushed onto the stack
>> by
>> processor.  Its return value is 64 bits in 64-bit mode and 32 bits in
>> 32-bit mode.  This function can only be used in exception handler.
>>
>> It also changes the definition of
>>
>> void * __builtin_interrupt_data (void)
>>
>> so that it returns a pointer to the data layout pushed onto stack
>> by processor for both interrupt and exception handlers.
>>
>>
>> --
>> H.J.
>> ---
>> The interrupt and exception handlers are called by x86 processors.
>>  X86
>> hardware pushes information onto stack and calls the handler.  The
>> requirements are
>>
>> 1. Both interrupt and exception handlers must use the 'IRET'
>> instruction,
>> instead of the 'RET' instruction, to return from the handlers.
>> 2. All registers are callee-saved in interrupt and exception
>> handlers.
>> 3. The difference between interrupt and exception handlers is the
>> exception handler must pop 'ERROR_CODE' off the stack before the
>> 'IRET'
>> instruction.
>>
>> The design goals of interrupt and exception handlers for x86
>> processors
>> are:
>>
>> 1. No new calling convention in compiler.
>> 2. Support both 32-bit and 64-bit modes.
>> 3. Flexible for compilers to optimize.
>> 4. Easy to use by programmers.
>>
>> To implement interrupt and exception handlers for x86 processors, a
>> compiler should support:
>>
>> 1. void * __builtin_interrupt_data (void)
>>
>> This function returns a pointer to the return address pushed onto the
>> stack by processor.
>>
>> The __builtin_frame_address builtin isn't suitable for interrupt and
>> exception handlers since it returns the stack frame address on the
>> callee side and compiler may generate a new stack frame for stack
>> alignment.
>>
>> 2. unsigned int __builtin_exception_error (void)
>>unsigned long long int __builtin_exception_error (void)
>>
>> This function returns the exception error code pushed onto the stack
>> by
>> processor.  Its return value is 64 bits in 64-bit mode and 32 bits in
>> 32-bit mode.  This function can only be used in exception handler.
>
> Instead of adding more builtins for these, why not simply model this by 
> giving the handler function a non-trivial signature? So, for example, the 
> interrupt handler would be:
>
>  void handler(void *);
>
> and the exception handler would be:
>
>   void handler(size_t);
>

Since x86 interrupt/exception handlers don't conform to any x86 psABI,
you need to modify compiler to generate proper codes for

void handler(void *);

Please take a look at interrupt/exception handlers section in Intel SDM
vol 3.

-- 
H.J.

Re: [PATCH tree-inline] do not say "called from here" with UNKNOWN_LOCATION

[Manuel López-Ibáñez]

On 21 September 2015 at 12:29, Richard Biener
 wrote:
> On Mon, Sep 21, 2015 at 11:59 AM, Manuel López-Ibáñez
>  wrote:
>> On 21 September 2015 at 10:18, Richard Biener
>>  wrote:
>>> input_location is set from the call stmt:
>>>
>>>   /* FIXME: instantiate_decl isn't called by inlinable_function_p.  */
>>>   saved_location = input_location;
>>>   input_location = gimple_location (stmt);
>>>
>>> it would be nice to get rid of that.
>>
>> I could replace all uses of input_location in this function by
>> gimple_location(stmt) as I noted in the comments. Would that be ok if
>> it works? I'm not sure I can prove that input_location is not used
>> behind the scenes for some other purpose (all the more reason to kill
>> input_location once and for all). Friends, don't let friends use
>> input_location in new code!
>
> Yeah...  not sure how to check but to look for any changes in
> generated cc1/cc1plus
> debug info.  You could also try making it invalid (-1?) and hope
> libcpp would eventually
> blow up if that is used.
>

It does blow up with:

/home/manuel/test2/227965M/build/gcc/gnat1 -gnatwa -quiet -nostdinc
-dumpbase s-mudido.adb -auxbase-strip s-mudido.o -O2 -Wextra -Wall
-fpic -g -gnatpg -mtune=generic -march=x86-64 -gnatO s-mudido.o
s-mudido.adb -o /tmp/ccNQpzNF.s

at:

B =>SET_EXPR_LOCATION (mod, EXPR_LOC_OR_LOC (val, input_location));

#0  internal_get_tmp_var (val=0x75dfdc40, pre_p=0x7fffdaf0,
post_p=, is_formal=) at
/home/manuel/test2/src/gcc/gimplify.c:540
#1  0x00c00efd in gimplify_expr
(expr_p=expr_p@entry=0x7fffdaf8, pre_p=pre_p@entry=0x7fffdaf0,
post_p=0x7fffd9a0, post_p@entry=0x0, gimple_test_f=, fallback=fallback@entry=1) at
/home/manuel/test2/src/gcc/gimplify.c:9040
#2  0x00c19b67 in gimple_regimplify_operands
(stmt=0x76074be0, gsi_p=gsi_p@entry=0x7fffdbb0) at
/home/manuel/test2/src/gcc/gimplify-me.c:252
#3  0x00e8cbe3 in copy_bb (id=id@entry=0x7fffde40,
bb=bb@entry=0x760eb548,
frequency_scale=frequency_scale@entry=1,
count_scale=count_scale@entry=1) at
/home/manuel/test2/src/gcc/tree-inline.c:1798
#4  0x00e8e039 in copy_cfg_body (new_entry=0x0,
exit_block_map=0x75dff340, entry_block_map=0x760d4c30,
frequency_scale=1, count=, id=0x7fffde40) at
/home/manuel/test2/src/gcc/tree-inline.c:2716
#5  copy_body (id=0x7fffde40, count=,
frequency_scale=1, entry_block_map=0x760d4c30,
exit_block_map=0x75dff340, new_entry=0x0) at
/home/manuel/test2/src/gcc/tree-inline.c:2955
#6  0x00e94f71 in expand_call_inline (id=0x7fffde40,
stmt=, bb=) at
/home/manuel/test2/src/gcc/tree-inline.c:4693
#7  gimple_expand_calls_inline (id=0x7fffde40, bb=)
at /home/manuel/test2/src/gcc/tree-inline.c:4833
#8  optimize_inline_calls (fn=) at
/home/manuel/test2/src/gcc/tree-inline.c:4973
#9  0x014c503c in inline_transform (node=0x7644ccf0) at
/home/manuel/test2/src/gcc/ipa-inline-transform.c:545
#10 0x00d54bac in execute_one_ipa_transform_pass
(ipa_pass=0x2656340, node=0x7644ccf0) at
/home/manuel/test2/src/gcc/passes.c:2197
#11 execute_all_ipa_transforms () at /home/manuel/test2/src/gcc/passes.c:2238
#12 0x00a99bc8 in cgraph_node::expand
(this=this@entry=0x7644ccf0) at
/home/manuel/test2/src/gcc/cgraphunit.c:1976
#13 0x00a9b44e in expand_all_functions () at
/home/manuel/test2/src/gcc/cgraphunit.c:2119
#14 symbol_table::compile (this=this@entry=0x7642b0a8) at
/home/manuel/test2/src/gcc/cgraphunit.c:2472
#15 0x00a9da63 in symbol_table::compile (this=0x7642b0a8)
at /home/manuel/test2/src/gcc/cgraphunit.c:2536
#16 symbol_table::finalize_compilation_unit (this=0x7642b0a8) at
/home/manuel/test2/src/gcc/cgraphunit.c:2562
#17 0x00e17d90 in compile_file () at
/home/manuel/test2/src/gcc/toplev.c:508
#18 0x0069e8a4 in do_compile () at
/home/manuel/test2/src/gcc/toplev.c:1973
#19 toplev::main (this=this@entry=0x7fffe0a0, argc=argc@entry=21,
argv=argv@entry=0x7fffe198) at
/home/manuel/test2/src/gcc/toplev.c:2080
#20 0x006a0bd7 in main (argc=21, argv=0x7fffe198) at
/home/manuel/test2/src/gcc/main.c:39

For some extra reason val does not have a location:

(gdb) p debug_tree(val)
 
sizes-gimplified asm_written nonaliased-component BLK size
 unit size 
align 8 symtab -166627696 alias set 32 canonical type
0x75fca2a0 domain  context

pointer_to_this 
reference_to_this  chain >
asm_written public unsigned DI
size 
unit size 
align 64 symtab -166626736 alias set 41 canonical type 0x75fca540>

arg 0 
nothrow
arg 0 
visited var def_stmt
R.94_159 = .builtin_alloca_with_align (iftmp.93_10, 8);

version 159
ptr-info 0x75d7d5a0>
arg 1 
s-mudido.adb:156:24>>

Arguably, gimple_location (stmt) is probably 

Re: [PATCH] Add new hooks ASM_OUTPUT_START_FUNCTION_HEADER ...

[Trevor Saunders]

On Mon, Sep 21, 2015 at 12:31:58PM +0100, Dominik Vogt wrote:
> This patch adds to new backend hooks
> ASM_OUTPUT_START_FUNCTION_HEADER and
> ASM_OUTPUT_END_FUNCTION_FOOTER that may be defined to emit
> assembly code at the very start or end of a function.  This
> functionality is needed by the patch that ports the "target"
> attribute and pragma to S/390.  (I'll post that patch shortly, and
> in a different thread.)

obligatory question, why are we adding new target macros instead of
using hooks?  Especially in a place like this where the caller is very
unlikely to be at all hot.

thanks!

Trev

[Bug target/67675] New: [SH] Improve __builtin_strcmp alignment test

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675

Bug ID: 67675
   Summary: [SH] Improve __builtin_strcmp alignment test
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

If the alignments of both input pointers to __builtin_strcmp are not at least 4
bytes, code is emitted to do a run-time check:

int foo1 (const char* x, const char* y)
{
  return __builtin_strcmp (x, y);
}

_foo1:
mov r4,r0
or  r5,r0  // OR pointers
tst #3,r0  // check if both are 4 byte aligned
bf.s.L9

If one of the pointers is 4 byte aligned, the OR can be omitted, because we
need to check only one pointer's alignement.  For example:

int foo2 (const char* x, const char* y)
{
  return __builtin_strcmp (__builtin_assume_aligned (x, 4), y);
}

or also:

struct S
{
  int a, b, c;
  char s[64];// this array will be always 4 byte aligned.
};

int foo4 (struct S* x)
{
  return __builtin_strcmp (x->s, "1234");
}

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[miyuki at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67649

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch

[davem at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622

davem at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from davem at gcc dot gnu.org ---
Trunk should be bootstrapping properly again.

Re: [PATCH] Fix PR66952

[Christophe Lyon]

On 23 July 2015 at 13:17, Richard Biener  wrote:
> On Thu, 23 Jul 2015, Kyrill Tkachov wrote:
>
>>
>> On 23/07/15 10:02, Andreas Schwab wrote:
>> > Richard Biener  writes:
>> >
>> > > Index: gcc/testsuite/gcc.dg/torture/pr66952.c
>> > > ===
>> > > --- gcc/testsuite/gcc.dg/torture/pr66952.c(revision 0)
>> > > +++ gcc/testsuite/gcc.dg/torture/pr66952.c(working copy)
>> > > @@ -0,0 +1,28 @@
>> > > +/* { dg-do run } */
>> > > +
>> > > +int a = 128, b;
>> > > +
>> > > +static int
>> > > +fn1 (char p1, int p2)
>> > > +{
>> > > +  return p1 < 0 || p1 > 1 >> p2 ? 0 : p1 << 1;
>> > This is broken, p1 can never be < 0.
>>
>> Just mark the chars as signed chars?
>> The testcase passes for me with that change.
>
> Ah - I always forget to double-check such testcases with both
> -fsinged-char and -funsigned-char...
>
> Will fix.
>

Hi Richard,

I looks like you forgot to backport r226104 too (which forces use of
signed chars).

Christophe.

> Richard.

[PATCH, i386, AVX-512] Fix splitter for `not-xor' logic.

[Kirill Yukhin]

Hello Uroš,

This simple patch fixes mode (to iterator) in
splitter for `not-xor' logic.

Bootstrapped & reg-tested on trunk.

Is it ok for trunk?

Is it ok for gcc-5-branch? (if tested accordingly)

(I have no idea how to reference to define_split in
ChangeLog entry)

gcc/
* gcc/config/i386/i386.md (define_split not/xor SWI1248x): Use
iterator instead of fixed modes..

--
Thanks, K

commit fc8c797375b4fc8fc155070ccfcca52497991c48
Author: Kirill Yukhin 
Date:   Fri Sep 18 16:10:06 2015 +0300

AVX-512. Fix kxnor insn splits.

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 7808705..f7230f0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -8565,11 +8565,11 @@
(clobber (reg:CC FLAGS_REG))]
   "TARGET_AVX512F && reload_completed"
[(parallel [(set (match_dup 0)
-   (xor:HI (match_dup 0)
-   (match_dup 1)))
+   (xor:SWI1248x (match_dup 0)
+ (match_dup 1)))
   (clobber (reg:CC FLAGS_REG))])
 (set (match_dup 0)
-(not:HI (match_dup 0)))])
+(not:SWI1248x (match_dup 0)))])

 ;;There are kortrest[bdq] but no intrinsics for them.
 ;;We probably don't need to implement them.

[Bug middle-end/60832] add pretty-printer code for double-int/wide-int

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60832

--- Comment #3 from Manuel López-Ibáñez  ---
Created attachment 36361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36361=edit
add %Wi %Wu %Wd for pretty-printing wides_int

This fails bootstrap at:

libcommon.a(pretty-print.o): In function `pp_format(pretty_printer*,
text_info*)':
/home/manuel/test1/src/gcc/pretty-print.c:543: undefined reference to
`print_dec(generic_wide_int const&, char*,
signop)'
/home/manuel/test1/src/gcc/pretty-print.c:573: undefined reference to
`print_dec(generic_wide_int const&, char*,
signop)'
collect2: error: ld returned 1 exit status
make: *** [gcov] Error 1

pretty-print.c is used all over the place and adding a dependency on
wide-int.cc will bring gmp and other stuff that is currently  not used (nor
linked with) various helper programs. If wide-int is only printed in the
middle-end, perhaps it is sufficient to add it to default_tree_printer.
Otherwise, it needs to be added to every FE. This is not difficult just
tedious. The difficult part is the c-format.c changes (I wish someone would fix
https://gcc.gnu.org/PR47781 so we can use a simpler syntax to define our custom
specifiers; in addition to the positive synergies it will bring with other GNU
projects that use custom specifiers and wish to use -Wformat).

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657

--- Comment #11 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Oleg Endo from comment #1)
> > Thanks for reporting.  I was a bit confused ... the attached source is not
> > cselib.c (which is a GCC file) but rather the problematic jidctflt.c
> 
> Oops, my bad, sorry!

No problem.

> 
> (In reply to Oleg Endo from comment #8)
> > BTW, I'd recommend not specifying -ffloat-store on SH.  It doesn't affect FP
> > precision (unlike on x86) and just creates slower code.
> 
> Ok, I will send a bug report to the maintainers of libjpeg-turbo regarding
> this, using your comment as reference.

Instead, they might want to try -ffast-math for the FP code...

> (In reply to Oleg Endo from comment #9)
> > No new failures on sh-elf for make -k check
> > RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-
> > mb,-m4a/-ml,-m4a/-mb}"
> 
> Sounds good, thanks!

I'd be surprised if it caught anything.  After all, this bug has not been
detected by the testsuite nor by the GCC 5 bootstrap.  I guess I'll just commit
it to trunk and GCC 5 branch.

[Bug c/67667] erroneous type argument for unary operator one's complement

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67667

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 67668 ***

[Bug c/67668] erroneous type argument for unary operator one's complement

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67668

--- Comment #1 from Jonathan Wakely  ---
*** Bug 67667 has been marked as a duplicate of this bug. ***

Re: [PATCH][AArch64] Use preferred aliases for CSNEG, CSINC, CSINV

[Kyrill Tkachov]

Hi Andrew,

On 12/09/15 02:15, Andrew Pinski wrote:

On Tue, Sep 1, 2015 at 6:08 PM, Kyrill Tkachov  wrote:

Hi all,

The ARMv8-A reference manual says:
"CNEG , , 
is equivalent to
CSNEG , , , invert()
and is the preferred disassembly when Rn == Rm && cond != '111x'."

That is, when the two input registers are the same we can use the shorter
CNEG mnemonic
with the inverse condition instead of the longer CSNEG instruction.
Similarly for the
CSINV and CSINC instructions, they have shorter CINV and CINC forms.
This patch adjusts the output templates to emit the preferred shorter
sequences when possible.

The new mnemonics are just aliases, they map down to the same instruction in
the end, so there
are no performance or behaviour implications. But it does make the assembly
a bit more readable
IMO, since:
"cnegw27, w9, le"
can be simply read as "if the condition is less or equal negate w9" instead
of the previous:
"csnegw27, w9, w9, gt" where you have to remember which of the input
registers is negated.


Bootstrapped and tested on aarch64-linux-gnu.
Ok for trunk?

I really think this kind of special casing is not correct and does not
belong in the compiler.  The main reason it complicates the back-end
more than the benefit of easier of reading the assembly code.


.
The complication is an extra if-else statement with
explicit strings on each arm i.e. there's no snprintf trickery.
I tend to read a lot of the generated assembly when performing assembly
comparisons while working on performance patches and I find that having
the cneg from with two register operands and the negate condition is quicker
to parse than the full csneg form where I need to remember that extra bit
of info that the condition there must be inverted to get the negation condition.

If you feel very strongly against this I can withdraw this patch, but I'd 
rather have it in.
FWIW, clang also emits the CNEG when it can AFAICS, though I admit that's not 
necessarily a strong
argument for this change.

Kyrill



Thanks,
Andrew Pinski


Thanks,
Kyrill

2015-09-01  Kyrylo Tkachov  

 * config/aarch64/aarch64.md (csinc3_insn): Use CINC
 mnemonic when possible.
 (*csinv3_insn): Use CINV mnemonic when possible.
 (csneg3_insn): USE CNEG mnemonic when possible.

2015-09-01  Kyrylo Tkachov  

 * gcc.target/aarch64/abs_1.c: Update scan-assembler checks
 to allow cneg.
 * gcc.target/aarch64/cond_op_imm_1.c: Likewise.  Likewise for cinv.
 * gcc.target/aarch64/mod_2.c: Likewise.

[Bug c++/67669] Wrong works fwrite or fread or both

[beyzman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67669

--- Comment #2 from Bernard  ---
The same source compiled for UBUNTU works well.

[SH][committed] Adjust pr64345-1.c testcase for SH2A

[Oleg Endo]

Hi,

There have been some changes to the generated bitfiddling code for SH2A
and the test case caught them.  Those changes are good, and the test
case can be adjusted accordingly.

Tested on sh-elf with
make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim\{-m2a/-mb}"

Committed as r227971.

Cheers,
Oleg

gcc/testsuite/ChangeLog:
PR target/64345
* gcc.target/sh/pr64345-1.c: Adjust expected insn counts for SH2A.
Index: gcc/testsuite/gcc.target/sh/pr64345-1.c
===
--- gcc/testsuite/gcc.target/sh/pr64345-1.c	(revision 227970)
+++ gcc/testsuite/gcc.target/sh/pr64345-1.c	(working copy)
@@ -10,10 +10,10 @@
 /* { dg-final { scan-assembler-times "shlr\t" 8 { target { ! sh2a } } } }  */
 
 /* { dg-final { scan-assembler-times "tst" 442 { target { sh2a } } } }  */
-/* { dg-final { scan-assembler-times "bld" 276 { target { sh2a } } } }  */
+/* { dg-final { scan-assembler-times "bld" 285 { target { sh2a } } } }  */
 /* { dg-final { scan-assembler-times "cmp/pz" 6 { target { sh2a } } } }  */
-/* { dg-final { scan-assembler-times "shll\t" 4 { target { sh2a } } } }  */
-/* { dg-final { scan-assembler-times "shlr\t" 8 { target { sh2a } } } }  */
+/* { dg-final { scan-assembler-times "shll\t" 3 { target { sh2a } } } }  */
+/* { dg-final { scan-assembler-times "shlr\t" 0 { target { sh2a } } } }  */
 
 /* { dg-final { scan-assembler-times "and\t#1" 32 } }  */
 

[Bug sanitizer/64906] -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64906

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-21
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |5.3
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I'll have a look.

Re: [PATCH tree-inline] do not say "called from here" with UNKNOWN_LOCATION

[Manuel López-Ibáñez]

On 21 September 2015 at 12:29, Richard Biener
 wrote:
>>> least note the function we are failing to inline to (thus, use
>>> DECL_SOURCE_LOCATION
>>> of cfun->decl).  So better add a diag_location and compute that upfront to 
>>> avoid
>>> repeating the check.
>>
>>error ("inlining failed in call to always_inline %q+F: %s", fn,
>>   cgraph_inline_failed_string (reason));
>>
>> The call is using '+F', thus the location is set to some location
>> related to F, depending on which *_printer function is active at that
>> moment. cp_printer uses location_of, and default_tree_printer uses
>> DECL_SOURCE_LOCATION. Is the default_tree_printer always used at this
>> point? If yes, I completely agree we should use an explicit
>> DECL_SOURCE_LOCATION. The meaning of '+' is not only opaque but it
>> breaks #pragma GCC diagnostic.
>
> But it prints the location of the function we failed to inline.  I
> want to retain
> at least an approximation to the location of the call, which is the location
> of the function we inline _to_.

I think I misunderstood you. Do you mean something like?

if (gimple_location (stmt) != UNKNOWN_LOCATION)
inform (gimple_location (stmt), "called from here");
else
inform (DECL_SOURCE_LOCATION (cfun->decl), "called from this function");


Cheers,

Manuel.

Re: [AArch64][PATCH 2/5] Make BIC, other logical instructions, available. (was: Add BIC instruction.)

[Matthew Wahab]

On 18/09/15 09:05, James Greenhalgh wrote:

On Thu, Sep 17, 2015 at 05:40:48PM +0100, Matthew Wahab wrote:

Hello,

ARMv8.1 adds atomic swap and atomic load-operate instructions with
optional memory ordering specifiers. This patch adds an expander to
generate a BIC instruction that can be explicitly called when
implementing the atomic__fetch pattern to calculate the value to
be returned by the operation.



Why not make the "*_one_cmpl_3" pattern
named (remove the leading *) and call that in your atomic__fetch
patterns as:

   and_one_cmpl_3

I'd rather that than to add a pettern that simply expands to the same
thing.


I overlooked that pattern when I was trying to find the bic emitter. I've attached an 
updated patch.


Tested as part of the series for aarch64-none-linux-gnu with native bootstrap 
and
make check. Also tested for aarch64-none-elf with cross-compiled
check-gcc on an ARMv8.1 emulator with +lse enabled by default.

Ok for trunk?
Matthew

2015-09-21  Matthew Wahab  

* config/aarch64/aarch64.md
(_one_cmpl_3): Make a named
pattern.

>From 0e2ae8739d70e4d1c14fa848f67847b1ecf94f71 Mon Sep 17 00:00:00 2001
From: Matthew Wahab 
Date: Mon, 17 Aug 2015 17:48:27 +0100
Subject: [PATCH 2/5] Make BIC, other logical instructions, available for use.

Change-Id: Ibef049bfa1bfe5e168feada3dc358f28383e6410
---
 gcc/config/aarch64/aarch64.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 88ba72e..72384ce 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3392,7 +3392,7 @@
   [(set_attr "type" "logics_reg")]
 )
 
-(define_insn "*_one_cmpl_3"
+(define_insn "_one_cmpl_3"
   [(set (match_operand:GPI 0 "register_operand" "=r")
 	(LOGICAL:GPI (not:GPI
 		  (SHIFT:GPI
-- 
2.1.4

Re: [libcpp/C PATCH] Handle lines encoded into several maps in linemap_position_for_loc_and_offset

[Marek Polacek]

On Sun, Aug 23, 2015 at 06:07:13PM +0200, Manuel López-Ibáñez wrote:
> linemap_position_for_loc_and_offset() tries to generate a location_t
> encoding a column offset from the current location, for example, point
> to a certain character inside a string. This is trivial to do when the
> new location "fits within" the map of the original location. However,
> it may happen that the (long) line corresponding to the original
> location is encoded in several maps, thus the new location should
> actually be encoded in a subsequent map from the original location.
> This patch detects this case and adjusts the map correspondingly.
> 
> (This shows that the line-map representation is quite wasteful in this
> case, because line-maps always start at column 0. That is, map[0]
> highest location may encode up to line 8 column 80, then
> map[1]->start_location starts encoding at line 8 column 0. Thus, there
> are two location_t values that point to the same source location.)
> 
> No new testcase since Marek found out this when tackling PR c/66415
> (https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00411.html). This
> change just fixes the column number.
> 
> Bootstrapped & regtested on x86-64-linux-gnu.
> 
> OK?

Ok, thanks.

Marek

[Bug c/67652] liboffloadmic/runtime/offload_engine.cpp:176: strange expression in sizeof ?

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67652

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-21
 CC||iverbin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
That certainly looks wrong.

[Bug c/67652] liboffloadmic/runtime/offload_engine.cpp:176: strange expression in sizeof ?

[iverbin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67652

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |iverbin at gcc dot 
gnu.org

--- Comment #2 from iverbin at gcc dot gnu.org ---
Thanks, I will fix it.

[Bug c++/67669] New: Wrong works fwrite or fread or both

[beyzman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67669

Bug ID: 67669
   Summary: Wrong works fwrite or fread or both
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beyzman at gmail dot com
  Target Milestone: ---

Created attachment 36365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36365=edit
Example of file to be processed

The program below is intended to replace every symbol with code \x00 by symbol
\x20 in some file.
The program was compiled by g++ for Windows from MinGW packet.
In the example attached there is symbols with code \x00 after every symbols
'j'.
It is intended that after program is executed, there will be symbols with code
\x20 after every symbol 'j'. But it is not so.
If I decomment 2 lines commented, the programm works as intended.



//#include 
#include 
#pragma hdrstop
#define min(a, b)  (((a) < (b)) ? (a) : (b))

int main(int argc, char *argv[])
{
   FILE *f;
   int pos;
   const int bufSize = 10;
   int length;
   int piece;
   int i;
   int ret;
   int chSw = 0;
   const char *fileName = argv[1];
   char *buf;
   if (argc < 1) printf("USAGE:  02space.exe \nReplaces every symbol
\\0x00 by space\n");
   f = fopen(fileName,"rb+");
   if (!f)
   {
   printf("Can not open file %s",argv[1]);
   return -1;
   }
   fseek(f,0,SEEK_END);
   length = ftell(f);
   rewind (f);
   ret = 0;
   buf = new char[bufSize];
   for(piece = (int)(min(bufSize,length)); length > 0;
 length -= piece,piece = (int)(min(bufSize,length)))
   {
 ++ret;
 pos = ftell(f)  ;
 fread(buf,piece,1,f);
 chSw = 0;
 for (i = 0; i < piece; ++i)
 {
 if (buf[i] == '\x00')
 {
 buf[i] = ' ';
 chSw = 1;
 }
 }

 if (chSw)
 {

   fseek(f,pos,SEEK_SET);
   fwrite(buf,piece,1,f);
//   fseek(f,pos,SEEK_SET);
//   fread(buf, piece, 1,f);
 }
   }

   delete [] buf;
   fclose(f);
   return 0;
}

Re: [PATCH] New attribute to create target clones

[Bernd Schmidt]

On 08/27/2015 01:18 PM, Evgeny Stupachenko wrote:

Based on RFC:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01322.html

The patch implement an extension to Function Multiversioning that
allows to clone a function for multiple targets.
__attribute__((target_clones("avx","arch=slm","default")))
int foo ()
...

Will create 3 clones of foo(). One optimized with -mavx, one optimized
with -march=slm, and one with default optimizations.
And will create ifunc resolver that calls appropriate clone (same as
in Function Multiversioning).


The general question is - do we want this, given that it seems to 
introduce no functionality that can't be had with the existing 
multiversioning? You could always compile the same source file to 
multiple objects with different defines for the target optimization, or 
include a file containing the multiversioned function multiple times 
with changing #defines.


Some comments on the patch itself:

> diff --git a/gcc/testsuite/gcc.dg/mvc1.c b/gcc/testsuite/gcc.dg/mvc1.c
> new file mode 100644
> index 000..ab1e0f5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/mvc1.c
> @@ -0,0 +1,27 @@
> +/* { dg-do run { target i?86-*-* x86_64-*-* } } */
> +/* { dg-options "-O2" } */

Target-specific tests should go into gcc.target/i386.


+  else if (lookup_attribute ("target_clones", DECL_ATTRIBUTES (*node)))
+   {
+ warning (OPT_Wattributes,
+  "%qE attribute ignored as it conflict with target_clones",
+  name);
+ *no_add_attrs = true;
+   }


Bad grammar ("conflicts"), and apparently you're supposed to use %qs 
even for known attribute names. Look at the code immediately before this 
and copy it. Similar issues throughout.



+  for (e = node->callers; e ;e = (e == NULL) ? e_next : e->next_caller)


It looks like this could be simplified if you immediately assign
  e_next = e->next_caller
and then always use e_next.

Trying to test it, I get (compiling with -O2 on x86_64-linux):

mvc1.c: In function ‘main’:
mvc1.c:18:1: error: virtual definition of statement not up-to-date
 main ()
 ^
_2 = foo.ifunc ();
mvc1.c:18:1: internal compiler error: verify_ssa failed


Bernd

Re: [AArch64][PATCH 2/5] Make BIC, other logical instructions, available. (was: Add BIC instruction.)

[James Greenhalgh]

On Mon, Sep 21, 2015 at 12:12:21PM +0100, Matthew Wahab wrote:
> On 18/09/15 09:05, James Greenhalgh wrote:
> > On Thu, Sep 17, 2015 at 05:40:48PM +0100, Matthew Wahab wrote:
> >> Hello,
> >>
> >> ARMv8.1 adds atomic swap and atomic load-operate instructions with
> >> optional memory ordering specifiers. This patch adds an expander to
> >> generate a BIC instruction that can be explicitly called when
> >> implementing the atomic__fetch pattern to calculate the value to
> >> be returned by the operation.
> >>
> >
> > Why not make the "*_one_cmpl_3" pattern
> > named (remove the leading *) and call that in your atomic__fetch
> > patterns as:
> >
> >and_one_cmpl_3
> >
> > I'd rather that than to add a pettern that simply expands to the same
> > thing.
> 
> I overlooked that pattern when I was trying to find the bic emitter. I've 
> attached an 
> updated patch.
> 
> Tested as part of the series for aarch64-none-linux-gnu with native bootstrap 
> and
> make check. Also tested for aarch64-none-elf with cross-compiled
> check-gcc on an ARMv8.1 emulator with +lse enabled by default.
> 
> Ok for trunk?
> Matthew

OK.

Thanks,
James

> 
> 2015-09-21  Matthew Wahab  
> 
>   * config/aarch64/aarch64.md
>   (_one_cmpl_3): Make a named
>   pattern.
> 

> From 0e2ae8739d70e4d1c14fa848f67847b1ecf94f71 Mon Sep 17 00:00:00 2001
> From: Matthew Wahab 
> Date: Mon, 17 Aug 2015 17:48:27 +0100
> Subject: [PATCH 2/5] Make BIC, other logical instructions, available for use.
> 
> Change-Id: Ibef049bfa1bfe5e168feada3dc358f28383e6410
> ---
>  gcc/config/aarch64/aarch64.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 88ba72e..72384ce 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -3392,7 +3392,7 @@
>[(set_attr "type" "logics_reg")]
>  )
>  
> -(define_insn "*_one_cmpl_3"
> +(define_insn "_one_cmpl_3"
>[(set (match_operand:GPI 0 "register_operand" "=r")
>   (LOGICAL:GPI (not:GPI
> (SHIFT:GPI
> -- 
> 2.1.4
> 

[Bug tree-optimization/67607] Failure to perform constant folding through type conversion

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607

--- Comment #3 from Marc Glisse  ---
Created attachment 36362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36362=edit
shortening

The shortening case seems much easier and does not require VRP information.

Calling get_range_info from match.pd is not done now (not sure if it would be a
good idea or not), so the widening case may have to be written separately in
VRP.

Re: [Patch/ccmp] Cost instruction sequences to choose better expand order

[Bernd Schmidt]

On 09/18/2015 05:21 PM, Jiong Wang wrote:


Current conditional compare (CCMP) support in GCC aim to optimize
short circuit for cascade comparision, given a simple conditional
compare candidate:

   if (a == 17 || a == 32)

[...]

The problem is current implementation always expand t0 first, then
t1. While the expand order need to consider the rtx costs, because "cmp"
and "ccmp" may have different restrictions that the expand order will
result in performance differences.

For example on AArch64, "ccmp" only accept immediate within -31 ~ 31
while "cmp" accept wider range, so if we expand "a == 32" in the second
step, then it will use "ccmp", and thus an extra "mov reg, 32"
instruction is generated because "32" is out of the range. While if we
expand "a == 32" first, then it's fine as "cmp" can encoding it.


I've played with this patch a bit with an aarch64 cross compiler. First 
of all - it doesn't seem to work, I get identical costs and the swapping 
doesn't happen. Did you forget to include a rtx_cost patch?


I was a little worried about whether this would be expensive for longer 
sequences of conditions, but it seems like it looks only at leafs where 
we have two comparisons, so that cost should be minimal. However, it's 
possible there's room for improvement in code generation. I was curious 
and looked at a slightly more complex testcase


int
foo (int a)
{
  if (a == 17 || a == 32 || a == 47 || a == 53 || a == 66 || a == 72)
return 1;
  else
return 2;
}

and this doesn't generate a sequence of ccmps as might have been 
expected; we only get pairs of comparisons merged with a bit_ior:


  D.2699 = a == 17;
  D.2700 = a == 32;
  D.2701 = D.2699 | D.2700;
  if (D.2701 != 0) goto ; else goto ;
  :
  D.2703 = a == 47;
  D.2704 = a == 53;
  D.2705 = D.2703 | D.2704;
  if (D.2705 != 0) goto ; else goto ;

and the ccmp expander doesn't see the entire thing. I found that a 
little surprising TBH.



Bernd

[Bug libstdc++/67647] [6 regression] boostrap FAIL with --disable-libstdcxx-dual-abi

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67647

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed now, thanks for the report.

Re: Multiprecision Arithmetic Builtins

[Florian Weimer]

On 09/21/2015 08:09 AM, Oleg Endo wrote:
> Hi all,
> 
> I was thinking of adding some SH specific builtin functions for the
> addc, subc and negc instructions.  
> 
> Are there any plans to add clang's target independent multiprecision
> arithmetic builtins (http://clang.llvm.org/docs/LanguageExtensions.html)
> to GCC?

Do you mean these?



Is there something else that is missing?

-- 
Florian Weimer / Red Hat Product Security

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657

--- Comment #13 from Oleg Endo  ---
Author: olegendo
Date: Mon Sep 21 13:14:45 2015
New Revision: 227970

URL: https://gcc.gnu.org/viewcvs?rev=227970=gcc=rev
Log:
gcc/
Backport from mainline
2015-09-21  Oleg Endo  

PR target/67657
* config/sh/sh.c (sh_remove_overlapping_post_inc,
sh_peephole_emit_move_insn): Add new functions.
* config/sh/sh-protos.h (sh_remove_overlapping_post_inc,
sh_peephole_emit_move_insn): Declere them.
* config/sh/sh.md: Use them in various peephole2 patterns.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh-protos.h
branches/gcc-5-branch/gcc/config/sh/sh.c
branches/gcc-5-branch/gcc/config/sh/sh.md

Re: [C++] Coding rule enforcement

[Daniel Gutson]

On Tue, Sep 15, 2015 at 3:31 PM, Jason Merrill  wrote:
> On 09/15/2015 01:20 PM, Manuel López-Ibáñez wrote:
>>
>> On 15/09/15 15:26, Richard Biener wrote:
>>>
>>> On Tue, Sep 15, 2015 at 3:02 PM, Nathan Sidwell  wrote:

 Jason,
 somme of our customers have 'interesting' C++ coding rules, they'd
 like to
 have the compiler enforced.  They want to disable:

 1) namespace definitions
 2) template declarations
 3) multiple inheritance
 4) virtual inheritance

 But they want to use the STL.  This patch implements 4 new flags,
 intended
 to be use in the -fno-FOO form.  They're only active outside of system
 header files.
>>
>>
>> If these are quite specific coding rules, wouldn't this be something
>> ideal for a plugin rather than implemented in the compiler proper?
>>
>> One can implement warnings with plugins (in python if desired!)
>>
>>
>> http://gcc-python-plugin.readthedocs.org/en/latest/basics.html#generating-custom-errors-and-warnings
>>
>>
>> Compiler plugins that implement specific coding rules are quite common,
>> alas, using clang not GCC:
>> https://wiki.documentfoundation.org/Development/Clang_plugins
>>
>> It would be more generally useful to extend GCC to fully support this
>> type of plugins.
>
>
> Good point.

FWIW, we could make this plugin in 2 weeks (w already have static
checkers as plugins for our customers). I understand Nathan that you
may have some deadlines, but if we could have the opportunity to
implement it, we could accomplish a clean isolation of a particular
business needs (despite I acknowledge that a warning about virtual
inheritance may be useful for a broader audience). OTOH, a plugin can
receive arguments, such as a configuration file which could point to
specific sources or hints about where to apply the warning, or a
suppression file, both things useful for large legacy code. IMVHO I
think this is a superior solution.
Please let me know if we could collaborate to get both a better gcc
and a better static checker.


>
> Jason
>
>



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson

Re: [PATCH, ARM]: Fix static interworking call

[Christophe Lyon]

On 21 September 2015 at 12:55, Christian Bruel  wrote:
> Hi Christophe,
>
>> It seems you committed the 1st version of your patch.
>
>
> Not sure what version you are talking about. I committed what was posted
> (https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01260.html) at revision
> #227880.

I thought you had modified it, after Richard's comments.

>
>> However, it fails if one forces a armv5t target, because, as Richard
>> said -mfloat-abi=hard is not supported on Thumb1.
>
>
> sure, but the testcase was for thumb2. It's just that the thumb1 check in
> the dg-skip-if is indeed useless. I'll fix this.
>
>>
>> It tried to remove -mfloat-abi=hard, and I noticed that only 1 'blx'
>> is generated when using soft or softfp.
>>
>> I expect this to be fixed by the linker anyway, but it may mean there
>> is still something wrong.
>
>
> This is expected. For thumb1, such static calls interwork are still done by
> the linker.
> For consistency IMHO we could also resolve static interwork thumb1 calls in
> the compiler, but that would be another issue.
> This failure was only for thumb2 (this having -march=armv7-a in the
> dg-options). (See https://sourceware.org/bugzilla/show_bug.cgi?id=17505)
>
> Hope that clarifies,
>
Yes, thanks.

> thanks
>
> Christian

Re: [AArch64][PATCH 1/5] Use atomic instructions for swap and fetch-update operations.

[Matthew Wahab]

On 18/09/15 08:58, James Greenhalgh wrote:

On Thu, Sep 17, 2015 at 05:37:55PM +0100, Matthew Wahab wrote:



diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index 65d2cc9..0e71002 100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -27,6 +27,7 @@
  UNSPECV_ATOMIC_CMPSW  ; Represent an atomic compare swap.
  UNSPECV_ATOMIC_EXCHG  ; Represent an atomic exchange.
  UNSPECV_ATOMIC_CAS; Represent an atomic CAS.
+UNSPECV_ATOMIC_SWP ; Represent an atomic SWP.
  UNSPECV_ATOMIC_OP ; Represent an atomic operation.
  ])

@@ -122,19 +123,19 @@
  )

  (define_insn_and_split "aarch64_compare_and_swap_lse"
-  [(set (reg:CC CC_REGNUM) ;; bool out
+  [(set (reg:CC CC_REGNUM)
  (unspec_volatile:CC [(const_int 0)] UNSPECV_ATOMIC_CMPSW))
-   (set (match_operand:GPI 0 "register_operand" "=") ;; val out
-(match_operand:GPI 1 "aarch64_sync_memory_operand" "+Q"))   ;; memory
+   (set (match_operand:GPI 0 "register_operand" "=")
+(match_operand:GPI 1 "aarch64_sync_memory_operand" "+Q"))
 (set (match_dup 1)
  (unspec_volatile:GPI
-  [(match_operand:GPI 2 "aarch64_plus_operand" "rI")   ;; expect
-   (match_operand:GPI 3 "register_operand" "r");; desired
-   (match_operand:SI 4 "const_int_operand")  ;; is_weak
-   (match_operand:SI 5 "const_int_operand")  ;; mod_s
-   (match_operand:SI 6 "const_int_operand")] ;; mod_f
+  [(match_operand:GPI 2 "aarch64_plus_operand" "rI")
+   (match_operand:GPI 3 "register_operand" "r")
+   (match_operand:SI 4 "const_int_operand")
+   (match_operand:SI 5 "const_int_operand")
+   (match_operand:SI 6 "const_int_operand")]


I'm not sure I understand the change here, those comments still look helpful
enough for understanding the pattern, what have a I missed?


That was part of an attempt to clean up some code. It's unnecessary and I've dropped 
the change.


Attached is the updated patch with some other changes:
- Simplified the atomic_exchange expander in line with reviews for
  other patches in the series.
- Removed the CC clobber from aarch64_atomic_exchange_lse, it was
  over-cautious.
- Added a missing entry to the change log (noting a whitespace fix).

Ok for trunk?
Matthew

gcc/
2015-09-21  Matthew Wahab  

* config/aarch64/aarch64-protos.h (aarch64_gen_atomic_ldop):
Declare.
* config/aarch64/aarch64.c (aarch64_emit_atomic_swap): New.
(aarch64_gen_atomic_ldop): New.
(aarch64_split_atomic_op): Fix whitespace and add a comment.
* config/aarch64/atomics.md (UNSPECV_ATOMIC_SWP): New.
(aarch64_compare_and_swap_lse): Fix some whitespace.
(atomic_exchange): Replace with an expander.
(aarch64_atomic_exchange): New.
(aarch64_atomic_exchange_lse): New.
(aarch64_atomic_): Fix some whitespace.
(aarch64_atomic_swp): New.


gcc/testsuite/
2015-09-21  Matthew Wahab  

* gcc.target/aarch64/atomic-inst-ops.inc: (TEST_MODEL): New.
(TEST_ONE): New.
* gcc.target/aarch64/atomic-inst-swap.c: New.


>From 31226dce8d36be98ca95d9165d4147a3bf84d180 Mon Sep 17 00:00:00 2001
From: Matthew Wahab 
Date: Fri, 7 Aug 2015 17:18:37 +0100
Subject: [PATCH 1/5] Add atomic SWP instruction

Change-Id: I87bf48526cb11e65edd15691f5eab20446e418c9
---
 gcc/config/aarch64/aarch64-protos.h|  1 +
 gcc/config/aarch64/aarch64.c   | 46 +-
 gcc/config/aarch64/atomics.md  | 71 --
 .../gcc.target/aarch64/atomic-inst-ops.inc | 13 
 gcc/testsuite/gcc.target/aarch64/atomic-inst-swp.c | 44 ++
 5 files changed, 170 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/atomic-inst-swp.c

diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index ff19851..eba4c76 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -378,6 +378,7 @@ rtx aarch64_load_tp (rtx);
 void aarch64_expand_compare_and_swap (rtx op[]);
 void aarch64_split_compare_and_swap (rtx op[]);
 void aarch64_gen_atomic_cas (rtx, rtx, rtx, rtx, rtx);
+void aarch64_gen_atomic_ldop (enum rtx_code, rtx, rtx, rtx, rtx);
 void aarch64_split_atomic_op (enum rtx_code, rtx, rtx, rtx, rtx, rtx, rtx);
 
 bool aarch64_gen_adjusted_ldpstp (rtx *, bool, enum machine_mode, RTX_CODE);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4d2126b..dc05c6e 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11185,11 +11185,54 @@ aarch64_split_compare_and_swap (rtx operands[])
 aarch64_emit_post_barrier (model);
 }
 
+/* Emit an 

Re: [PR middle-end/60832] Do not convert widest_int to tree just for printing it.

[Manuel López-Ibáñez]

On 21 September 2015 at 09:24, Richard Biener  wrote:
> On Sun, 20 Sep 2015, Manuel López-Ibáñez wrote:
>
>> In do_warn_aggressive_loop_optimizations, we convert to a tree just to print 
>> a
>> widest_int. Apart from overly complicated, this results in printing '3u'
>> instead of just '3'.
>>
>> Unfortunately, adding a printf-like conversion specifier would require making
>> pretty-print.c link with wide-int.cc, which will include a lot of new
>> dependencies into several other programs (gcov-tool for example). It would be
>> possible to add the conversion specifier to every FE pretty-printer, but this
>> still would require updating c-format.c, which is far from trivial. A simpler
>> approach is to convert to a string rather than to a tree.
>
> I'd add the pretty printer overloads to wide-int-print.[ch], but yes
> it would require a change in c-format.c.

That is not enough, some conversion specifier parser needs to handle
the new codes. The one in pretty-print.c is used all over the place
and adding a dependency on wide-int.cc will bring gmp and other stuff
that is currently  not used (nor linked with) various helper programs.
If wide-int is only printed in the middle-end, perhaps it is
sufficient to add it to default_tree_printer. Otherwise, it needs to
be added to every FE. This is not difficult just tedious. The
difficult part is the c-format.c changes (I wish someone would fix
https://gcc.gnu.org/PR47781 so we can use a simpler syntax to define
our custom specifiers; in addition to the positive synergies it will
bring with other GNU projects that use custom specifiers and wish to
use -Wformat).

>> OK?
>
> Ok.  Let's remember this case and if more of these pop up try working
> on a "proper" solution.

Sure, I added my WIP patch to the PR, but I don't plan to keep working on it.

Cheers,

Manuel.

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657

--- Comment #9 from Oleg Endo  ---
(In reply to Oleg Endo from comment #7)
> Created attachment 36357 [details]
> Proposed patch
> 
> Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
> value loaded from memory, AFAIR), it doesn't make sense to keep the
> post-inc, as the result will be overwritten anyway.  The patch catches those
> cases in the peepholes and removes the post-inc.  I'm now testing this on
> sh-elf.

No new failures on sh-elf for make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

Re: [AArch64][PATCH 5/5] Use atomic load-operate instructions for update-fetch patterns.

[Matthew Wahab]

On 17/09/15 17:54, Matthew Wahab wrote:

ARMv8.1 adds atomic swap and atomic load-operate instructions with
optional memory ordering specifiers. This patch uses the ARMv8.1
load-operate instructions to implement the atomic__fetch patterns.

The approach is to use the atomic load-operate instruction to atomically
load the data and update memory and then to use the loaded data to
calculate the value that the instruction would have stored. The
calculation attempts to mirror the operation of the atomic instruction.
For example, atomic_and_fetch is implemented with an atomic
load-bic so the result is also calculated using a BIC instruction.


[...]


2015-09-17  Matthew Wahab  

 * config/aarch64/aarch64-protos.h (aarch64_gen_atomic_ldop):
 Adjust declaration.
 * config/aarch64/aarch64.c (aarch64_emit_bic): New.
 (aarch64_gen_atomic_load_op): Adjust comment.  Add parameter
 out_result.  Update to support update-fetch operations.
 * config/aarch64/atomics.md (aarch64_atomic_exchange_lse):
 Adjust for change to aarch64_gen_atomic_ldop.
 (aarch64_atomic__lse): Likewise.
 (aarch64_atomic_fetch__lse): Likewise.
 (atomic__fetch): Change to an expander.
 (aarch64_atomic__fetch): New.
 (aarch64_atomic__fetch_lse): New.

gcc/testsuite
2015-09-17  Matthew Wahab  

 * gcc.target/aarch64/atomic-inst-ldadd.c: Add tests for
 update-fetch operations.
 * gcc.target/aarch64/atomic-inst-ldlogic.c: Likewise.



Attached an updated patch that takes into account the review comments and changes for 
the rest of the series.


The changes in this patch:
- Updated emit_bic for changes in the earlier patch.
- Simplified the patterns used in the new expanders.
- Dropped CC clobber from the _lse patterns.

Tested the series for aarch64-none-linux-gnu with native bootstrap and
make check. Also tested for aarch64-none-elf with cross-compiled
check-gcc on an ARMv8.1 emulator with +lse enabled by default.

Ok for trunk?
Matthew

2015-09-21  Matthew Wahab  

* config/aarch64/aarch64-protos.h (aarch64_gen_atomic_ldop):
Adjust declaration.
* config/aarch64/aarch64.c (aarch64_emit_bic): New.
(aarch64_gen_atomic_ldop): Adjust comment.  Add parameter
out_result.  Update to support update-fetch operations.
* config/aarch64/atomics.md (aarch64_atomic_exchange_lse):
Adjust for change to aarch64_gen_atomic_ldop.
(aarch64_atomic__lse): Likewise.
(aarch64_atomic_fetch__lse): Likewise.
(atomic__fetch): Change to an expander.
(aarch64_atomic__fetch): New.
(aarch64_atomic__fetch_lse): New.

gcc/testsuite
2015-09-21  Matthew Wahab  

* gcc.target/aarch64/atomic-inst-ldadd.c: Add tests for
update-fetch operations.
* gcc.target/aarch64/atomic-inst-ldlogic.c: Likewise.


>From abd313723964e90b6e7d7785b646c657f6b072f9 Mon Sep 17 00:00:00 2001
From: Matthew Wahab 
Date: Mon, 17 Aug 2015 11:27:18 +0100
Subject: [PATCH 5/5] Use atomic instructions for update-fetch patterns.

Change-Id: I5eef48586fe904f0d2df8c581fb3c12a4a2d9c78
---
 gcc/config/aarch64/aarch64-protos.h|   2 +-
 gcc/config/aarch64/aarch64.c   |  72 +++--
 gcc/config/aarch64/atomics.md  |  55 +-
 .../gcc.target/aarch64/atomic-inst-ldadd.c |  53 ++---
 .../gcc.target/aarch64/atomic-inst-ldlogic.c   | 118 ++---
 5 files changed, 241 insertions(+), 59 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 76ebd6f..dd8ebcc 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -380,7 +380,7 @@ void aarch64_split_compare_and_swap (rtx op[]);
 void aarch64_gen_atomic_cas (rtx, rtx, rtx, rtx, rtx);
 
 bool aarch64_atomic_ldop_supported_p (enum rtx_code);
-void aarch64_gen_atomic_ldop (enum rtx_code, rtx, rtx, rtx, rtx);
+void aarch64_gen_atomic_ldop (enum rtx_code, rtx, rtx, rtx, rtx, rtx);
 void aarch64_split_atomic_op (enum rtx_code, rtx, rtx, rtx, rtx, rtx, rtx);
 
 bool aarch64_gen_adjusted_ldpstp (rtx *, bool, enum machine_mode, RTX_CODE);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 3a1b434..b6cdf7c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11211,6 +11211,25 @@ aarch64_split_compare_and_swap (rtx operands[])
 aarch64_emit_post_barrier (model);
 }
 
+/* Emit a BIC instruction.  */
+
+static void
+aarch64_emit_bic (machine_mode mode, rtx dst, rtx s1, rtx s2, int shift)
+{
+  rtx shift_rtx = GEN_INT (shift);
+  rtx (*gen) (rtx, rtx, rtx, rtx);
+
+  switch (mode)
+{
+case SImode: gen = gen_and_one_cmpl_lshrsi3; break;
+case DImode: gen = gen_and_one_cmpl_lshrdi3; break;
+default:
+  gcc_unreachable ();
+}
+
+  emit_insn (gen 

Re: Fwd: [PATCH] Enable libstdc++ numeric conversions on Cygwin

[Jonathan Wakely]

On 19/09/15 15:55 -0400, Jennifer Yao wrote:

Do you already have a copyright assignment for GCC?

If not, would you be willing to complete one?


No, but I would be willing to complete one, yes. Are you willing to
send me the appropriate forms, or should I contact someone else?


Great, I'll send you the forms, thanks.

[SH][committed] FIx PR 67657

[Oleg Endo]

Hi,

This fixes PR 67657 on trunk.  It seems that something after the
peephole2 pass is not happy to see things like:
 mov.l   @r2+,r2

which some of the SH peephole2 patterns create out of e.g.
mov.l   @r2+,r0
mov r0,r2

The post-inc is a bit pointless, so this patch catches such cases and
replaces the address in the mem with a non-post-inc address.

Tested on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

Committed as r227969.
A backport to GCC 5 will follow.

Cheers,
Oleg

gcc/ChangeLog:
PR target/67657
* config/sh/sh.c (sh_remove_overlapping_post_inc,
sh_peephole_emit_move_insn): Add new functions.
* config/sh/sh-protos.h (sh_remove_overlapping_post_inc,
sh_peephole_emit_move_insn): Declere them.
* config/sh/sh.md: Use them in various peephole2 patterns.
Index: gcc/config/sh/sh-protos.h
===
--- gcc/config/sh/sh-protos.h	(revision 227958)
+++ gcc/config/sh/sh-protos.h	(working copy)
@@ -306,6 +306,8 @@
 extern bool sh_reg_dead_or_unused_after_insn (const rtx_insn* i, int regno);
 extern void sh_remove_reg_dead_or_unused_notes (rtx_insn* i, int regno);
 extern rtx_insn* sh_check_add_incdec_notes (rtx_insn* i);
+extern rtx sh_remove_overlapping_post_inc (rtx dst, rtx src);
+extern rtx_insn* sh_peephole_emit_move_insn (rtx dst, rtx src);
 
 extern bool sh_in_recog_treg_set_expr (void);
 extern bool sh_recog_treg_set_expr (rtx op, machine_mode mode);
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 227958)
+++ gcc/config/sh/sh.c	(working copy)
@@ -13810,6 +13810,34 @@
   return i;
 }
 
+/* Given a move insn destiation and a source, make sure that the move source
+   operand is not a post-inc mem load with the same address reg as the
+   destination.  Returns the modified source operand with the post-inc removed
+   if necessary.  */
+rtx
+sh_remove_overlapping_post_inc (rtx dst, rtx src)
+{
+  if (!MEM_P (src))
+return src;
+
+  rtx addr = XEXP (src, 0);
+
+  if (GET_CODE (addr) == POST_INC
+  && reg_overlap_mentioned_p (XEXP (addr, 0), dst))
+return replace_equiv_address (src, XEXP (addr, 0));
+
+  gcc_assert (GET_CODE (addr) != POST_MODIFY);
+  return src;
+}
+
+/* Emit a move insn that is safe to be used in peephole patterns.  */
+rtx_insn*
+sh_peephole_emit_move_insn (rtx dst, rtx src)
+{
+  return sh_check_add_incdec_notes (
+	emit_move_insn (dst, sh_remove_overlapping_post_inc (dst, src)));
+}
+
 /* Given an op rtx and an insn, try to find out whether the result of the
specified op consists only of logical operations on T bit stores.  */
 bool
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 227958)
+++ gcc/config/sh/sh.md	(working copy)
@@ -14681,7 +14681,7 @@
   [(const_int 0)]
 {
   emit_insn (gen_addsi3 (operands[1], operands[1], operands[2]));
-  sh_check_add_incdec_notes (emit_move_insn (operands[3], operands[1]));
+  sh_peephole_emit_move_insn (operands[3], operands[1]);
 })
 
 ;;	mov.l	@(r0,r9),r1
@@ -14694,7 +14694,7 @@
   "TARGET_SH1 && peep2_reg_dead_p (2, operands[0])"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[1]));
+  sh_peephole_emit_move_insn (operands[2], operands[1]);
 })
 
 (define_peephole2
@@ -14705,7 +14705,7 @@
   "TARGET_SH1 && peep2_reg_dead_p (2, operands[0])"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[1]));
+  sh_peephole_emit_move_insn (operands[2], operands[1]);
 })
 
 (define_peephole2
@@ -14717,7 +14717,7 @@
   [(const_int 0)]
 {
   sh_check_add_incdec_notes (emit_insn (gen_extendsi2 (operands[2],
-			 operands[1])));
+		   sh_remove_overlapping_post_inc (operands[2], operands[1];
 })
 
 ;;	mov.w	@(18,r1),r0 (r0 = HImode)
@@ -14747,8 +14747,9 @@
 
   // We don't know what the new set insn will be in detail.  Just make sure
   // that it still can be recognized and the constraints are satisfied.
-  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
-		 
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2],
+		sh_remove_overlapping_post_inc (operands[2], operands[3])));
+
   recog_data_d prev_recog_data = recog_data;
   bool i_invalid = insn_invalid_p (i, false); 
   recog_data = prev_recog_data;
@@ -14786,7 +14787,8 @@
 {
   // We don't know what the new set insn will be in detail.  Just make sure
   // that it still can be recognized and the constraints are satisfied.
-  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2],
+		sh_remove_overlapping_post_inc (operands[2], operands[3])));
 
   recog_data_d prev_recog_data = recog_data;
   bool i_invalid = insn_invalid_p (i, false); 

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67649

--- Comment #6 from Markus Trippelsdorf  ---
I guess valgrind just needs to be silenced in this case.
See valgrind related macros in gcc/system.h.

Re: [AArch64][PATCH 4/5] Use atomic load-operate instructions for fetch-update patterns.

[Matthew Wahab]

On 18/09/15 09:55, James Greenhalgh wrote:

On Thu, Sep 17, 2015 at 05:47:43PM +0100, Matthew Wahab wrote:

Hello,

ARMv8.1 adds atomic swap and atomic load-operate instructions with
optional memory ordering specifiers. This patch uses the ARMv8.1 atomic
load-operate instructions to implement the atomic_fetch_
patterns. This patch also updates the implementation of the atomic_
patterns, which are treated as versions of the atomic_fetch_ which
discard the loaded data.


[..]


Ok for trunk?


Some comments in line below.



diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index eba4c76..76ebd6f 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -378,6 +378,8 @@ rtx aarch64_load_tp (rtx);
  void aarch64_expand_compare_and_swap (rtx op[]);
  void aarch64_split_compare_and_swap (rtx op[]);
  void aarch64_gen_atomic_cas (rtx, rtx, rtx, rtx, rtx);
+
+bool aarch64_atomic_ldop_supported_p (enum rtx_code);
  void aarch64_gen_atomic_ldop (enum rtx_code, rtx, rtx, rtx, rtx);
  void aarch64_split_atomic_op (enum rtx_code, rtx, rtx, rtx, rtx, rtx, rtx);

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index dc05c6e..33f9ef3 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11064,6 +11064,33 @@ aarch64_expand_compare_and_swap (rtx operands[])
emit_insn (gen_rtx_SET (bval, x));
  }

+/* Test whether the target supports using a atomic load-operate instruction.
+   CODE is the operation and AFTER is TRUE if the data in memory after the
+   operation should be returned and FALSE if the data before the operation
+   should be returned.  Returns FALSE if the operation isn't supported by the
+   architecture.
+  */


Stray newline, leave the */ on the line before.


Fixed this.


+
+bool
+aarch64_atomic_ldop_supported_p (enum rtx_code code)
+{
+  if (!TARGET_LSE)
+return false;
+
+  switch (code)
+{
+case SET:
+case AND:
+case IOR:
+case XOR:
+case MINUS:
+case PLUS:
+  return true;
+default:
+  return false;
+}
+}
+
  /* Emit a barrier, that is appropriate for memory model MODEL, at the end of a
 sequence implementing an atomic operation.  */

@@ -11206,26 +11233,169 @@ aarch64_emit_atomic_swap (machine_mode mode, rtx 
dst, rtx value,
emit_insn (gen (dst, mem, value, model));
  }

-/* Emit an atomic operation where the architecture supports it.  */
+/* Operations supported by aarch64_emit_atomic_load_op.  */
+
+enum aarch64_atomic_load_op_code
+{
+  AARCH64_LDOP_PLUS,   /* A + B  */
+  AARCH64_LDOP_XOR,/* A ^ B  */
+  AARCH64_LDOP_OR, /* A | B  */
+  AARCH64_LDOP_BIC /* A & ~B  */
+};


I have a small preference to calling these the same name as the
instructions they will generate, so AARCH64_LDOP_ADD, AARCH64_LDOP_EOR,
AARCH64_LDOP_SET and AARCH64_LDOP_CLR, but I'm happy fo you to leave it
this way if you prefer.



I prefer to keep them related to the operation being implemented rather than how it 
is implemented so I've left them as they are.




-(define_insn_and_split "atomic_"
+(define_expand "atomic_"
+ [(set (match_operand:ALLI 0 "aarch64_sync_memory_operand" "")
+   (unspec_volatile:ALLI
+[(atomic_op:ALLI (match_dup 0)
+  (match_operand:ALLI 1 "" ""))
+ (match_operand:SI 2 "const_int_operand")]
+UNSPECV_ATOMIC_OP))
+  (clobber (reg:CC CC_REGNUM))]


This is not needed for the LSE forms of these instructions and may result
in less optimal code genmeration. On the other hand, that will only be in
a corner case and this is only a define_expand. Because of that, it would
be clearer to a reader if you dropped the detailed description of this
in RTL (which is never used) and rewrote it using just the uses of the
operands, as so:


+(define_expand "atomic_"
+ [(match_operand:ALLI 0 "aarch64_sync_memory_operand" "")
+  (match_operand:ALLI 1 "" "")
+  (match_operand:SI 2 "const_int_operand")]




Switched the new expanders in this and the other patches to the simpler form.




+(define_insn_and_split "aarch64_atomic_"
+ [(set (match_operand:ALLI 0 "aarch64_sync_memory_operand" "+Q")
+   (unspec_volatile:ALLI
+[(atomic_op:ALLI (match_dup 0)
+  (match_operand:ALLI 1 "" "r"))
+ (match_operand:SI 2 "const_int_operand")]
+UNSPECV_ATOMIC_OP))
+  (clobber (reg:CC CC_REGNUM))
+  (clobber (match_scratch:ALLI 3 "="))
+  (clobber (match_scratch:SI 4 "="))]
+  ""


TARGET_LSE ?


It's not needed here because this pattern is always available.


+  "#"
+  "&& reload_completed"
+  [(const_int 0)]
+  {
+aarch64_split_atomic_op (, NULL, operands[3], operands[0],
+operands[1], operands[2], operands[4]);
+DONE;
+  }
+)
+
+(define_insn_and_split "aarch64_atomic__lse"
[(set (match_operand:ALLI 0 "aarch64_sync_memory_operand" "+Q")
  (unspec_volatile:ALLI
[(atomic_op:ALLI (match_dup 0)
(match_operand:ALLI 1 "" "r"))
-   (match_operand:SI 2 

Re: [RFC] Try vector as a new representation for vector masks

[Ilya Enkovich]

2015-09-18 19:50 GMT+03:00 Richard Henderson :
> On 09/18/2015 06:21 AM, Ilya Enkovich wrote:
 +machine_mode
 +default_get_mask_mode (unsigned nunits, unsigned vector_size)
 +{
 +  unsigned elem_size = vector_size / nunits;
 +  machine_mode elem_mode
 += smallest_mode_for_size (elem_size * BITS_PER_UNIT, MODE_INT);
>>>
>>> Why these arguments as opposed to passing elem_size?  It seems that every 
>>> hook
>>> is going to have to do this division...
>>
>> Every target would have nunits = vector_size / elem_size because
>> nunits is used to create a vector mode. Thus no difference.
>
> I meant passing nunits and elem_size, but not vector_size.  Thus no division
> required.  If the target does require the vector size, it could be obtained by
> multiplication, which is cheaper.  But in cases like this we'd not require
> either mult or div.

OK

>
 @@ -1885,7 +1885,9 @@ expand_MASK_LOAD (gcall *stmt)
create_output_operand ([0], target, TYPE_MODE (type));
create_fixed_operand ([1], mem);
create_input_operand ([2], mask, TYPE_MODE (TREE_TYPE (maskt)));
 -  expand_insn (optab_handler (maskload_optab, TYPE_MODE (type)), 3, ops);
 +  expand_insn (convert_optab_handler (maskload_optab, TYPE_MODE (type),
 +   TYPE_MODE (TREE_TYPE (maskt))),
 +3, ops);
>>>
>>> Why do we now need a conversion here?
>>
>> Mask mode was implicit for masked loads and stores. Now it becomes
>> explicit because we may load the same value using different masks.
>> E.g. for i386 we may load 256bit vector using both vector and scalar
>> masks.
>
> Ok, sure, the mask mode is needed, I get that.  But that doesn't answer the
> question regarding conversion.  Why would convert_optab_handler be needed to
> *change* the mode of the mask.  I assume that's not actually possible, with 
> the
> target hook already having chosen the proper mode for the mask.

There is no any conversion here, maskload_optab is a convert_optab
because it uses two modes, one for value and the other one for mask.

Ilya

>
>
> r~

Re: [PATCH c/c++] use explicit locations for some warnings in c-pragma.c

[Manuel López-Ibáñez]

On 21 September 2015 at 06:52, Christophe Lyon
 wrote:
> It looks like I mis-applied your patch.
> I cleaned up and re-applied it, and I can confirm it fixes the problem.

Committed as obvious as r227967.

Thanks,

Manuel.

[Bug c++/67669] Wrong works fwrite or fread or both

[beyzman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67669

--- Comment #1 from Bernard  ---
Created attachment 36366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36366=edit
Source

[Bug middle-end/57625] internal compiler error: seg fault when building gcc 4.7.2

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57625

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Looks resolved then.

[Bug target/64345] [SH] Improve single bit extraction

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345

--- Comment #5 from Oleg Endo  ---
Author: olegendo
Date: Mon Sep 21 13:49:07 2015
New Revision: 227971

URL: https://gcc.gnu.org/viewcvs?rev=227971=gcc=rev
Log:
testsuite/
PR target/64345
* gcc.target/sh/pr64345-1.c: Adjust expected insn counts for SH2A.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr64345-1.c

Re: [Patch/ccmp] Cost instruction sequences to choose better expand order

[Jiong Wang]

Bernd Schmidt writes:

> On 09/18/2015 05:21 PM, Jiong Wang wrote:
>>
>> Current conditional compare (CCMP) support in GCC aim to optimize
>> short circuit for cascade comparision, given a simple conditional
>> compare candidate:
>>
>>if (a == 17 || a == 32)
> [...]
>> The problem is current implementation always expand t0 first, then
>> t1. While the expand order need to consider the rtx costs, because "cmp"
>> and "ccmp" may have different restrictions that the expand order will
>> result in performance differences.
>>
>> For example on AArch64, "ccmp" only accept immediate within -31 ~ 31
>> while "cmp" accept wider range, so if we expand "a == 32" in the second
>> step, then it will use "ccmp", and thus an extra "mov reg, 32"
>> instruction is generated because "32" is out of the range. While if we
>> expand "a == 32" first, then it's fine as "cmp" can encoding it.
>
> I've played with this patch a bit with an aarch64 cross compiler. First 
> of all - it doesn't seem to work, I get identical costs and the swapping 
> doesn't happen. Did you forget to include a rtx_cost patch?

No. Please see NOTE part of the description. AArch64 doesn't cost ccmp
currently. It will be fixed by a seperate patch later. The testcase is
thus marked as XFAIL.

>
> I was a little worried about whether this would be expensive for longer 
> sequences of conditions, but it seems like it looks only at leafs where 
> we have two comparisons, so that cost should be minimal. However, it's 
> possible there's room for improvement in code generation. I was curious 
> and looked at a slightly more complex testcase
>
> int
> foo (int a)
> {
>if (a == 17 || a == 32 || a == 47 || a == 53 || a == 66 || a == 72)
>  return 1;
>else
>  return 2;
> }

Yes, this patch only cost the inner most call of the recursive call of
expand_ccmp_expr_1 which is simple and common situation.
>
> and this doesn't generate a sequence of ccmps as might have been 
> expected; we only get pairs of comparisons merged with a bit_ior:
>
>D.2699 = a == 17;
>D.2700 = a == 32;
>D.2701 = D.2699 | D.2700;
>if (D.2701 != 0) goto ; else goto ;
>:
>D.2703 = a == 47;
>D.2704 = a == 53;
>D.2705 = D.2703 | D.2704;
>if (D.2705 != 0) goto ; else goto ;
>
> and the ccmp expander doesn't see the entire thing. I found that a 
> little surprising TBH.

It's because fold_truth_andor has re-written the tree to avoid the use
short circuit given LOGICAL_OP_NON_SHORT_CIRCUIT returns true.

-- 
Regards,
Jiong

Re: [PATCH, libgfortran] Fix FIND_FILE decls and use.

[Kirill Yukhin]

On 21 Sep 12:53, FX wrote:
> Dear Kirill,
> 
> > When libgfortran is configured w/ HAVE_WORKING_STAT undefined
> > *and* current system is not MinGW - FIND_FILE_[DECL|ARGS} still
> > trying to use Windows's handles (id).
> 
> Well, if HAVE_WORKING_STAT is not defined, then it means some other mechanism 
> has to be used. If your target is not mingw32 and stat() is not reliable, 
> we’ll need to provide an alternate way of handling things. Your patch would 
> default to the unusable stat().
That's right, but maybe at least allow bootstrap to pass?

> What’s your target?
I am trying to pass bootstrap w/ couple of insns siwtched on, which are not 
available on host.
While configureing libgfortran test
  checking whether the target stat is reliable...
returns no, since test program fails to execute (due to illegal insn exception).
So, we have non MinGW system w/o stat.

I am not going to use resulting libgfortran, only extra sanity check for my 
changes to i386 target.

--
Thanks, K

> 
> FX

[PATCH] Fix -Wmisleading-indentation false-positive

[Patrick Palka]

This patch fixes the last remaining false-positive
-Wmisleading-indentation warning that is emitted against the sqlite
sources.

The problem is the following kind of code snippet:

for (i = 0;
 i < 10;
 i++
);
foo (i);

which is an "interesting" coding style but it is not misleading, so the
heurisitic shouldn't trip over it.  I adjusted the heuristic (which only
applies when the body is a semicolon) to be more strict in one sense (we
no longer warn when the guard column lines up with the column of the
"next" statement like in the above snippet) and yet more relaxed in
another sense (we now warn when the guard column is greater than the
column of the "next" statement, see test case changes).

Tested by compiling Linux, sqlite and vim code bases with
-Wmisleading-indentation.  OK if bootstrap + regtest succeeds?

gcc/c-family/ChangeLog:

* c-indentation.c (should_warn_for_misleading_indentation):
Float out and consolidate the calls to get_visual_column that is
passed guard_exploc as an argument.  Compare
next_stmt_vis_column with guard_line_first_nws instead of with
body_line_first_nws.

gcc/testsuite/ChangeLog:

* c-c++-common/Wmisleading-indentation.c: Augment test.
---
 gcc/c-family/c-indentation.c   | 23 +++-
 .../c-c++-common/Wmisleading-indentation.c | 25 ++
 2 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
index dd35223..5316316 100644
--- a/gcc/c-family/c-indentation.c
+++ b/gcc/c-family/c-indentation.c
@@ -341,6 +341,8 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
   unsigned int next_stmt_vis_column;
   unsigned int body_vis_column;
   unsigned int body_line_first_nws;
+  unsigned int guard_vis_column;
+  unsigned int guard_line_first_nws;
   /* If we can't determine it, don't issue a warning.  This is sometimes
 the case for input files containing #line directives, and these
 are often for autogenerated sources (e.g. from .md files), where
@@ -351,6 +353,11 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
  _vis_column,
  _line_first_nws))
return false;
+  if (!get_visual_column (guard_exploc,
+ _vis_column,
+ _line_first_nws))
+   return false;
+
   if ((body_type != CPP_SEMICOLON
   && next_stmt_vis_column == body_vis_column)
  /* As a special case handle the case where the body is a semicolon
@@ -365,7 +372,7 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
  || (body_type == CPP_SEMICOLON
  && body_exploc.line > guard_exploc.line
  && body_line_first_nws != body_vis_column
- && next_stmt_vis_column == body_line_first_nws))
+ && next_stmt_vis_column > guard_line_first_nws))
{
   /* Don't warn if they are aligned on the same column
 as the guard itself (suggesting autogenerated code that doesn't
@@ -395,13 +402,6 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
 indentation is misleading).  Using the column of the first
 non-whitespace character on the guard line makes that
 happen.  */
- unsigned int guard_vis_column;
- unsigned int guard_line_first_nws;
- if (!get_visual_column (guard_exploc,
- _vis_column,
- _line_first_nws))
-   return false;
-
  if (guard_line_first_nws == body_vis_column)
return false;
 
@@ -462,13 +462,6 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
  {
if (body_exploc.line == guard_exploc.line)
  {
-   unsigned int guard_vis_column;
-   unsigned int guard_line_first_nws;
-   if (!get_visual_column (guard_exploc,
-   _vis_column,
-   _line_first_nws))
- return false;
-
if (next_stmt_vis_column > guard_line_first_nws
|| (next_tok_type == CPP_OPEN_BRACE
&& next_stmt_vis_column == guard_vis_column))
diff --git a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c 
b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
index 0d6d8d2..f61c182 100644
--- a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
+++ b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
@@ -732,6 +732,13 @@ fn_37 (void)
   foo (0);
 }
 
+  if (flagB) /* { dg-message "3: ...this 'if' clause" } */
+/* blah */;
+   { /* { dg-warning "statement is indented as if" } */
+ foo (0);
+   }
+
+
   if (flagB)
 

Re: [PATCH] Fix -Wmisleading-indentation false-positive

[Bernd Schmidt]

On 09/21/2015 01:23 PM, Patrick Palka wrote:


* c-indentation.c (should_warn_for_misleading_indentation):
Float out and consolidate the calls to get_visual_column that is
passed guard_exploc as an argument.  Compare
next_stmt_vis_column with guard_line_first_nws instead of with
body_line_first_nws.


Ok.


Bernd

[Bug c/67667] New: erroneous type argument for unary operator one's complement

[ka_bena at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67667

Bug ID: 67667
   Summary: erroneous type argument for unary operator one's
complement
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ka_bena at yahoo dot fr
  Target Milestone: ---

Re: [PATCH, i386, AVX-512] Fix splitter for `not-xor' logic.

[Uros Bizjak]

On Mon, Sep 21, 2015 at 12:50 PM, Kirill Yukhin  wrote:
> Hello Uroš,
>
> This simple patch fixes mode (to iterator) in
> splitter for `not-xor' logic.
>
> Bootstrapped & reg-tested on trunk.
>
> Is it ok for trunk?
>
> Is it ok for gcc-5-branch? (if tested accordingly)

OK everywhere. Looks obvious, though.

> (I have no idea how to reference to define_split in
> ChangeLog entry)

Yes, you need a bit of creativity to describe define_splits, but looks OK to me.

>
> gcc/
> * gcc/config/i386/i386.md (define_split not/xor SWI1248x): Use
> iterator instead of fixed modes..

Thanks,
Uros.

Re: Multiprecision Arithmetic Builtins

[Marc Glisse]

On Mon, 21 Sep 2015, Florian Weimer wrote:


On 09/21/2015 08:09 AM, Oleg Endo wrote:

Hi all,

I was thinking of adding some SH specific builtin functions for the
addc, subc and negc instructions.

Are there any plans to add clang's target independent multiprecision
arithmetic builtins (http://clang.llvm.org/docs/LanguageExtensions.html)
to GCC?


Do you mean these?



Is there something else that is missing?


http://clang.llvm.org/docs/LanguageExtensions.html#multiprecision-arithmetic-builtins

Those that take a carryin argument.

--
Marc Glisse

[Bug tree-optimization/67666] single restrict pointer in struct looses restrict

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67666

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 36360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36360=edit
Tentative patch

[PATCH, libgfortran] Fix FIND_FILE decls and use.

[Kirill Yukhin]

Hello,
When libgfortran is configured w/ HAVE_WORKING_STAT undefined
*and* current system is not MinGW - FIND_FILE_[DECL|ARGS} still
trying to use Windows's handles (id).

Proposed patch discriminates MinGW case under HAVE_WORKING_STAT
switched off.

Bootstrapped (on Linux).

libgfortran/
* io/unix.c (FIND_FILE0_DECL): Don't use `id' when
HAVE_WORKING_STAT is not defined and system is not
MinGW.
(FIND_FILE0_ARGS): Ditto.

Is it ok for trunk?

Is it ok for gcc-5-branch? (if bootstrap passed)

--
Thanks, K

$ git show c1d01f74051f65e75b0de73b1b43c76b9b2e1b02
commit c1d01f74051f65e75b0de73b1b43c76b9b2e1b02
Author: Kirill Yukhin 
Date:   Fri Sep 18 19:00:52 2015 +0300

Fix libgfortran/io/unix.c to allow not stable STAT for non MinGW.

diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index b86bd67..772725a 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -1551,8 +1551,13 @@ compare_file_filename (gfc_unit *u, const char *name, 
int len)
 # define FIND_FILE0_DECL struct stat *st
 # define FIND_FILE0_ARGS st
 #else
-# define FIND_FILE0_DECL uint64_t id, const char *path
-# define FIND_FILE0_ARGS id, path
+# if defined(__MINGW32__)
+#  define FIND_FILE0_DECL uint64_t id, const char *path
+#  define FIND_FILE0_ARGS id, path
+# else
+#  define FIND_FILE0_DECL const char *path
+#  define FIND_FILE0_ARGS path
+# endif
 #endif

 /* find_file0()-- Recursive work function for find_file() */
  

Re: [PATCH tree-inline] do not say "called from here" with UNKNOWN_LOCATION

[Richard Biener]

On Mon, Sep 21, 2015 at 12:46 PM, Manuel López-Ibáñez
 wrote:
> On 21 September 2015 at 12:29, Richard Biener
>  wrote:
 least note the function we are failing to inline to (thus, use
 DECL_SOURCE_LOCATION
 of cfun->decl).  So better add a diag_location and compute that upfront to 
 avoid
 repeating the check.
>>>
>>>error ("inlining failed in call to always_inline %q+F: %s", fn,
>>>   cgraph_inline_failed_string (reason));
>>>
>>> The call is using '+F', thus the location is set to some location
>>> related to F, depending on which *_printer function is active at that
>>> moment. cp_printer uses location_of, and default_tree_printer uses
>>> DECL_SOURCE_LOCATION. Is the default_tree_printer always used at this
>>> point? If yes, I completely agree we should use an explicit
>>> DECL_SOURCE_LOCATION. The meaning of '+' is not only opaque but it
>>> breaks #pragma GCC diagnostic.
>>
>> But it prints the location of the function we failed to inline.  I
>> want to retain
>> at least an approximation to the location of the call, which is the location
>> of the function we inline _to_.
>
> I think I misunderstood you. Do you mean something like?
>
> if (gimple_location (stmt) != UNKNOWN_LOCATION)
> inform (gimple_location (stmt), "called from here");
> else
> inform (DECL_SOURCE_LOCATION (cfun->decl), "called from this 
> function");

Yes.  (now that location may also be UNKNOWN in which case I don't
have a good fallback idea and we can drop the note)

Richard.

>
> Cheers,
>
> Manuel.

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[miyuki at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67649

--- Comment #7 from Mikhail Maltsev  ---
Probably. Will look at this today (valgrind has some sort of memory pool API, I
think it can be used here).
I need to configure GCC with --enable-checking=yes,valgrind to reproduce this,
right?

Re: [AArch64][PATCH 3/5] Add atomic load-operate instructions.

[Matthew Wahab]

On 18/09/15 09:39, James Greenhalgh wrote:

On Thu, Sep 17, 2015 at 05:42:35PM +0100, Matthew Wahab wrote:

---
  gcc/config/aarch64/atomics.md | 41 +
  1 file changed, 41 insertions(+)

diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index 0e71002..b7b6fb5 100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -29,8 +29,25 @@
  UNSPECV_ATOMIC_CAS; Represent an atomic CAS.
  UNSPECV_ATOMIC_SWP; Represent an atomic SWP.
  UNSPECV_ATOMIC_OP ; Represent an atomic operation.
+UNSPECV_ATOMIC_LDOP; Represent an atomic 
load-operation
+UNSPECV_ATOMIC_LDOP_OR ; Represent an atomic load-or
+UNSPECV_ATOMIC_LDOP_BIC; Represent an atomic load-bic
+UNSPECV_ATOMIC_LDOP_XOR; Represent an atomic load-xor
+UNSPECV_ATOMIC_LDOP_PLUS   ; Represent an atomic load-add
  ])

+;; Iterators for load-operate instructions.
+
+(define_int_iterator ATOMIC_LDOP
+ [UNSPECV_ATOMIC_LDOP_OR UNSPECV_ATOMIC_LDOP_BIC
+  UNSPECV_ATOMIC_LDOP_XOR UNSPECV_ATOMIC_LDOP_PLUS])
+
+(define_int_attr atomic_ldop
+ [(UNSPECV_ATOMIC_LDOP_OR "set") (UNSPECV_ATOMIC_LDOP_BIC "clr")
+  (UNSPECV_ATOMIC_LDOP_XOR "eor") (UNSPECV_ATOMIC_LDOP_PLUS "add")])


There is precedent (atomic_optab, atomic_op_operand, const_atomic, etc.) for
these living in config/aarch64/iterators.md so they should be moved there.
Presumably the difficulty with that is to do with the position of the
"unspecv" define_c_enum? I'd argue that is in the wrong place too...

If you want to leave this to a cleanup patch in stage 3 that is fine.

This patch is OK for trunk.



I'd prefer to keep the clean-up separate from this series. I'll commit the patch as 
it is and the deal with the iterator move later.


Thanks,
Matthew

[PATCH] Add new hooks ASM_OUTPUT_START_FUNCTION_HEADER ...

[Dominik Vogt]

This patch adds to new backend hooks
ASM_OUTPUT_START_FUNCTION_HEADER and
ASM_OUTPUT_END_FUNCTION_FOOTER that may be defined to emit
assembly code at the very start or end of a function.  This
functionality is needed by the patch that ports the "target"
attribute and pragma to S/390.  (I'll post that patch shortly, and
in a different thread.)

Note that a function may need to switch to a different section in
the .s file (hot/cold section or whatever).  The additional code
is (arguably) emitted *before* switching the section.  That seems
to be more correct to me that emitting it after the switch, but
it's not a big deal to change that.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog

* defaults.h (ASM_OUTPUT_START_FUNCTION_HEADER): New hook function.
(ASM_OUTPUT_START_FUNCTION_FOOTER): Ditto.
* varasm.c (assemble_start_function): Call new hook at start of
function.
(assemble_end_function): Call new hook at end of function.
* doc/tm.texi.in: Document new hook functions.
>From 61c2546ba0aa0e9b2743f8d64427143aac5af2b0 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Wed, 29 Jul 2015 16:14:23 +0100
Subject: [PATCH] Add new hooks ASM_OUTPUT_START_FUNCTION_HEADER ...

and ASM_OUTPUT_END_FUNCTION_FOOTER.  These are used by the implementation of
__attribute__ ((target(...))) on S390.
---
 gcc/defaults.h | 10 ++
 gcc/doc/tm.texi| 14 ++
 gcc/doc/tm.texi.in | 14 ++
 gcc/varasm.c   |  2 ++
 4 files changed, 40 insertions(+)

diff --git a/gcc/defaults.h b/gcc/defaults.h
index d4d3a56..aa9c849 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -135,6 +135,16 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define TARGET_DEFERRED_OUTPUT_DEFS(DECL,TARGET) false
 #endif
 
+/* Output additional assemler code at the very start of the function.  */
+#ifndef ASM_OUTPUT_START_FUNCTION_HEADER
+#define ASM_OUTPUT_START_FUNCTION_HEADER(FILE,DECL) do { } while (0)
+#endif
+
+/* Output additional assemler code at the very end of the function.  */
+#ifndef ASM_OUTPUT_END_FUNCTION_FOOTER
+#define ASM_OUTPUT_START_FUNCTION_FOOTER(FILE,DECL) do { } while (0)
+#endif
+
 /* This is how to output the definition of a user-level label named
NAME, such as the label on variable NAME.  */
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index d548d96..7ba00c3 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -7917,6 +7917,20 @@ If you define @code{TYPE_ASM_OP} and @code{TYPE_OPERAND_FMT}, a default
 definition of this macro is provided.
 @end defmac
 
+@defmac ASM_OUTPUT_START_FUNCTION_HEADER (@var{stream}, @var{decl})
+A C statement (sans semicolon) to output to the stdio stream
+@var{stream} additional assembly language code to be placed at the
+very start of the current function.  The default definition of this
+macro does nothing.
+@end defmac
+
+@defmac ASM_OUTPUT_END_FUNCTION_FOOTER (@var{stream}, @var{decl})
+A C statement (sans semicolon) to output to the stdio stream
+@var{stream} additional assembly language code at the very end of
+the current function.  The default definition of this macro does
+nothing.
+@end defmac
+
 @defmac ASM_DECLARE_FUNCTION_NAME (@var{stream}, @var{name}, @var{decl})
 A C statement (sans semicolon) to output to the stdio stream
 @var{stream} any text necessary for declaring the name @var{name} of a
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 9bef4a5..2b2b7e4 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -5546,6 +5546,20 @@ If you define @code{TYPE_ASM_OP} and @code{TYPE_OPERAND_FMT}, a default
 definition of this macro is provided.
 @end defmac
 
+@defmac ASM_OUTPUT_START_FUNCTION_HEADER (@var{stream}, @var{decl})
+A C statement (sans semicolon) to output to the stdio stream
+@var{stream} additional assembly language code to be placed at the
+very start of the current function.  The default definition of this
+macro does nothing.
+@end defmac
+
+@defmac ASM_OUTPUT_END_FUNCTION_FOOTER (@var{stream}, @var{decl})
+A C statement (sans semicolon) to output to the stdio stream
+@var{stream} additional assembly language code at the very end of
+the current function.  The default definition of this macro does
+nothing.
+@end defmac
+
 @defmac ASM_DECLARE_FUNCTION_NAME (@var{stream}, @var{name}, @var{decl})
 A C statement (sans semicolon) to output to the stdio stream
 @var{stream} any text necessary for declaring the name @var{name} of a
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 706e652..dcee8f0 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1701,6 +1701,7 @@ assemble_start_function (tree decl, const char *fnname)
   char tmp_label[100];
   bool hot_label_written = false;
 
+  ASM_OUTPUT_START_FUNCTION_HEADER (asm_out_file, current_function_decl);
   if (flag_reorder_blocks_and_partition)
 {
   ASM_GENERATE_INTERNAL_LABEL (tmp_label, "LHOTB", const_labelno);
@@ -1864,6 +1865,7 @@ assemble_end_function 

[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
The reghunt revealed (not completely unexpected) the following patch as
the culprit:

The first bad revision is:
changeset:   25098:fa3edfa6a9a7
user:davem@138bc75d-0d04-0410-961f-82ee72b054a4
date:Sat Sep 12 00:13:23 2015 +
summary: Convert SPARC backend over to LRA.

Rainer

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #113 from Oleg Endo  ---
Created attachment 36363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36363=edit
CSiBE I08 const cost = 0 vs. cost = 1, no LRA

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #114 from Oleg Endo  ---
Created attachment 36364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36364=edit
CSiBE I08 const cost = 0 vs. cost = 1, LRA

[Bug middle-end/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67651

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug middle-end/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67651

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 21 12:33:23 2015
New Revision: 227968

URL: https://gcc.gnu.org/viewcvs?rev=227968=gcc=rev
Log:
2015-09-21  Richard Biener  

PR middle-end/67651
* rtlanal.c (nonzero_address_p): SYMBOL_REFs may have zero
address with -fno-delete-null-pointer-checks.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c

[Bug c/67668] erroneous type argument for unary operator one's complement

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67668

--- Comment #2 from Marc Glisse  ---
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Complex.html
-Wpedantic

What is your question exactly?

[Bug other/67300] -foffload* undocumented

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67300

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-21
 CC||bernds at gcc dot gnu.org,
   ||iverbin at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
(As you have found already), -foffload=[...] currently is only documented on
, and in the patch submission email,
.
 This documentation should be moved into the GCC users manual.

Re: [C++ PATCH] Complete the implementation of N4230, Nested namespace definition.

[Jason Merrill]

OK, thanks!

Jason

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

[Hal Finkel]

- Original Message -
> From: "H.J. Lu" 
> To: "Hal Finkel" 
> Cc: "GCC Development" , cfe-...@lists.llvm.org
> Sent: Monday, September 21, 2015 5:57:36 PM
> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
> 
> On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel  wrote:
> > - Original Message -
> >> From: "H.J. Lu via cfe-dev" 
> >> To: "GCC Development" , cfe-...@lists.llvm.org
> >> Sent: Monday, September 21, 2015 11:27:18 AM
> >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception
> >> handlers
> >>
> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu 
> >> wrote:
> >> > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu 
> >> > wrote:
> >> >>> To implement interrupt and exception handlers for x86
> >> >>> processors,
> >> >>> a
> >> >>> compiler should support:
> >> >>>
> >> >>> 1. void * __builtin_ia32_interrupt_data (void)
> >> >>
> >> >> I got a feedback on the name of this builtin function.  Since
> >> >> it also works for 64-bit,  we should avoid ia32 in its name.
> >> >> We'd like to change it to
> >> >>
> >> >> void * __builtin_interrupt_data (void)
> >> >>
> >> >
> >> > Here is the updated spec.
> >> >
> >>
> >> This updated spec adds
> >>
> >>unsigned int __builtin_exception_error (void)
> >>unsigned long long int __builtin_exception_error (void)
> >>
> >> This function returns the exception error code pushed onto the
> >> stack
> >> by
> >> processor.  Its return value is 64 bits in 64-bit mode and 32 bits
> >> in
> >> 32-bit mode.  This function can only be used in exception handler.
> >>
> >> It also changes the definition of
> >>
> >> void * __builtin_interrupt_data (void)
> >>
> >> so that it returns a pointer to the data layout pushed onto stack
> >> by processor for both interrupt and exception handlers.
> >>
> >>
> >> --
> >> H.J.
> >> ---
> >> The interrupt and exception handlers are called by x86 processors.
> >>  X86
> >> hardware pushes information onto stack and calls the handler.  The
> >> requirements are
> >>
> >> 1. Both interrupt and exception handlers must use the 'IRET'
> >> instruction,
> >> instead of the 'RET' instruction, to return from the handlers.
> >> 2. All registers are callee-saved in interrupt and exception
> >> handlers.
> >> 3. The difference between interrupt and exception handlers is the
> >> exception handler must pop 'ERROR_CODE' off the stack before the
> >> 'IRET'
> >> instruction.
> >>
> >> The design goals of interrupt and exception handlers for x86
> >> processors
> >> are:
> >>
> >> 1. No new calling convention in compiler.
> >> 2. Support both 32-bit and 64-bit modes.
> >> 3. Flexible for compilers to optimize.
> >> 4. Easy to use by programmers.
> >>
> >> To implement interrupt and exception handlers for x86 processors,
> >> a
> >> compiler should support:
> >>
> >> 1. void * __builtin_interrupt_data (void)
> >>
> >> This function returns a pointer to the return address pushed onto
> >> the
> >> stack by processor.
> >>
> >> The __builtin_frame_address builtin isn't suitable for interrupt
> >> and
> >> exception handlers since it returns the stack frame address on the
> >> callee side and compiler may generate a new stack frame for stack
> >> alignment.
> >>
> >> 2. unsigned int __builtin_exception_error (void)
> >>unsigned long long int __builtin_exception_error (void)
> >>
> >> This function returns the exception error code pushed onto the
> >> stack
> >> by
> >> processor.  Its return value is 64 bits in 64-bit mode and 32 bits
> >> in
> >> 32-bit mode.  This function can only be used in exception handler.
> >
> > Instead of adding more builtins for these, why not simply model
> > this by giving the handler function a non-trivial signature? So,
> > for example, the interrupt handler would be:
> >
> >  void handler(void *);
> >
> > and the exception handler would be:
> >
> >   void handler(size_t);
> >
> 
> Since x86 interrupt/exception handlers don't conform to any x86
> psABI,
> you need to modify compiler to generate proper codes for
> 
> void handler(void *);
> 
> Please take a look at interrupt/exception handlers section in Intel
> SDM
> vol 3.

Yes, I understand that. But we already would need to customize the 
call-frame-lowering code for these functions, and since this already requires 
customization, what's the advantage of the builtins over adding special logic 
to make these parameters correspond to the appropriate stack locations and/or 
registers?

 -Hal

> 
> --
> H.J.
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

[H.J. Lu]

On Mon, Sep 21, 2015 at 4:03 PM, Hal Finkel  wrote:
> - Original Message -
>> From: "H.J. Lu" 
>> To: "Hal Finkel" 
>> Cc: "GCC Development" , cfe-...@lists.llvm.org
>> Sent: Monday, September 21, 2015 5:57:36 PM
>> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers
>>
>> On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel  wrote:
>> > - Original Message -
>> >> From: "H.J. Lu via cfe-dev" 
>> >> To: "GCC Development" , cfe-...@lists.llvm.org
>> >> Sent: Monday, September 21, 2015 11:27:18 AM
>> >> Subject: Re: [cfe-dev] RFC: Support x86 interrupt and exception
>> >> handlers
>> >>
>> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu 
>> >> wrote:
>> >> > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu 
>> >> > wrote:
>> >> >>> To implement interrupt and exception handlers for x86
>> >> >>> processors,
>> >> >>> a
>> >> >>> compiler should support:
>> >> >>>
>> >> >>> 1. void * __builtin_ia32_interrupt_data (void)
>> >> >>
>> >> >> I got a feedback on the name of this builtin function.  Since
>> >> >> it also works for 64-bit,  we should avoid ia32 in its name.
>> >> >> We'd like to change it to
>> >> >>
>> >> >> void * __builtin_interrupt_data (void)
>> >> >>
>> >> >
>> >> > Here is the updated spec.
>> >> >
>> >>
>> >> This updated spec adds
>> >>
>> >>unsigned int __builtin_exception_error (void)
>> >>unsigned long long int __builtin_exception_error (void)
>> >>
>> >> This function returns the exception error code pushed onto the
>> >> stack
>> >> by
>> >> processor.  Its return value is 64 bits in 64-bit mode and 32 bits
>> >> in
>> >> 32-bit mode.  This function can only be used in exception handler.
>> >>
>> >> It also changes the definition of
>> >>
>> >> void * __builtin_interrupt_data (void)
>> >>
>> >> so that it returns a pointer to the data layout pushed onto stack
>> >> by processor for both interrupt and exception handlers.
>> >>
>> >>
>> >> --
>> >> H.J.
>> >> ---
>> >> The interrupt and exception handlers are called by x86 processors.
>> >>  X86
>> >> hardware pushes information onto stack and calls the handler.  The
>> >> requirements are
>> >>
>> >> 1. Both interrupt and exception handlers must use the 'IRET'
>> >> instruction,
>> >> instead of the 'RET' instruction, to return from the handlers.
>> >> 2. All registers are callee-saved in interrupt and exception
>> >> handlers.
>> >> 3. The difference between interrupt and exception handlers is the
>> >> exception handler must pop 'ERROR_CODE' off the stack before the
>> >> 'IRET'
>> >> instruction.
>> >>
>> >> The design goals of interrupt and exception handlers for x86
>> >> processors
>> >> are:
>> >>
>> >> 1. No new calling convention in compiler.
>> >> 2. Support both 32-bit and 64-bit modes.
>> >> 3. Flexible for compilers to optimize.
>> >> 4. Easy to use by programmers.
>> >>
>> >> To implement interrupt and exception handlers for x86 processors,
>> >> a
>> >> compiler should support:
>> >>
>> >> 1. void * __builtin_interrupt_data (void)
>> >>
>> >> This function returns a pointer to the return address pushed onto
>> >> the
>> >> stack by processor.
>> >>
>> >> The __builtin_frame_address builtin isn't suitable for interrupt
>> >> and
>> >> exception handlers since it returns the stack frame address on the
>> >> callee side and compiler may generate a new stack frame for stack
>> >> alignment.
>> >>
>> >> 2. unsigned int __builtin_exception_error (void)
>> >>unsigned long long int __builtin_exception_error (void)
>> >>
>> >> This function returns the exception error code pushed onto the
>> >> stack
>> >> by
>> >> processor.  Its return value is 64 bits in 64-bit mode and 32 bits
>> >> in
>> >> 32-bit mode.  This function can only be used in exception handler.
>> >
>> > Instead of adding more builtins for these, why not simply model
>> > this by giving the handler function a non-trivial signature? So,
>> > for example, the interrupt handler would be:
>> >
>> >  void handler(void *);
>> >
>> > and the exception handler would be:
>> >
>> >   void handler(size_t);
>> >
>>
>> Since x86 interrupt/exception handlers don't conform to any x86
>> psABI,
>> you need to modify compiler to generate proper codes for
>>
>> void handler(void *);
>>
>> Please take a look at interrupt/exception handlers section in Intel
>> SDM
>> vol 3.
>
> Yes, I understand that. But we already would need to customize the 
> call-frame-lowering code for these functions, and since this already requires 
> customization, what's the advantage of the builtins over adding special logic 
> to make these parameters correspond to the appropriate stack locations and/or 
> registers?
>

Interrupt data and exception error code are always passed
on stack in both 32-bit and 64-bit modes.  For exception
data and error code, they locations are different from any
calling 

[Bug target/67675] [SH] Improve __builtin_strcmp alignment test

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-22
 Ever confirmed|0   |1

--- Comment #1 from Oleg Endo  ---
This fixes it:

Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc (revision 227970)
+++ gcc/config/sh/sh-mem.cc (working copy)
@@ -224,11 +224,10 @@
   rtx_code_label *L_loop_long = gen_label_rtx ();
   rtx_code_label *L_end_loop_long = gen_label_rtx ();

-  int align = INTVAL (operands[3]);
+  const unsigned int addr1_alignment = MEM_ALIGN (operands[1]) /
BITS_PER_UNIT;
+  const unsigned int addr2_alignment = MEM_ALIGN (operands[2]) /
BITS_PER_UNIT;

-  emit_move_insn (tmp0, const0_rtx);
-
-  if (align < 4)
+  if (addr1_alignment < 4 && addr2_alignment < 4)
 {
   emit_insn (gen_iorsi3 (tmp1, s1_addr, s2_addr));
   emit_insn (gen_tstsi_t (tmp1, GEN_INT (3)));
@@ -235,6 +234,18 @@
   jump = emit_jump_insn (gen_branch_false (L_loop_byte));
   add_int_reg_note (jump, REG_BR_PROB, prob_likely);
 }
+  else if (addr1_alignment < 4 && addr2_alignment >= 4)
+{
+  emit_insn (gen_tstsi_t (s1_addr, GEN_INT (3)));
+  jump = emit_jump_insn (gen_branch_false (L_loop_byte));
+  add_int_reg_note (jump, REG_BR_PROB, prob_likely);
+}
+  else if (addr1_alignment >= 4 && addr2_alignment < 4)
+{
+  emit_insn (gen_tstsi_t (s2_addr, GEN_INT (3)));
+  jump = emit_jump_insn (gen_branch_false (L_loop_byte));
+  add_int_reg_note (jump, REG_BR_PROB, prob_likely);
+}

   addr1 = adjust_automodify_address (addr1, SImode, s1_addr, 0);
   addr2 = adjust_automodify_address (addr2, SImode, s2_addr, 0);