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

2014-10-12 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #60 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #59)
> Yet another lra-assigns.c:1335 ICE when compiling nrrd/kernel.c of CSiBE/
> teem-1.6.0 test.  It looks that RA fails for FPUL_REGS class.

It seems that the scenario starts at insn 58 in .reload.

   58: {r199:DF=float_extend(r190:SF);use :PSI;}

LRA inserts a reload insn 138 before it.

  138: {r261:SF=r190:SF;use :PSI;clobber scratch;0;}
   58: {r199:DF=float_extend(r261:SF);use :PSI;}

During inheritance/split process, LRA inserts a move insn 151
after 138 to save r190.

Add save<-reg after:
  151: r280:SI=r190:SF#0

where LRA assigns the hard reg fr8 to r190 and #0 means subreg:SI
here.  We need fpul to save the SFmode value on fr8 to SImode
object and insn 58 is actually fcnvds instruction of which destination
is fpul.  This causes the ICE.
LRA chooses SImode at insn 151 because fr8 is a caller save register
and HARD_REGNO_CALLER_SAVE_MODE returns SImode for fr8 even with
SFmode.  SH doesn't define its specific HARD_REGNO_CALLER_SAVE_MODE
and uses the default choose_hard_reg_mode (regno, nregs, false)
implementation.  choose_hard_reg_mode chooses mode based on
HARD_REGNO_MODE_OK and returns ?Imode for float registers when
sh_hard_regno_mode_ok permits integer modes on them. 
I guess that HARD_REGNO_CALLER_SAVE_MODE should return SFmode in
this case.

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

2014-10-12 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #61 from Kazumoto Kojima  ---
Created attachment 33692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33692&action=edit
a possible patch

I'm testing a patch to define a SH specific HARD_REGNO_CALLER_SAVE_MODE macro.

[Bug c++/62115] [5 Regression] ICE with invalid default argument

2014-10-12 Thread paolo.carlini at oracle dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed then.

[Bug c/16351] NULL dereference warnings

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #18 from Manuel López-Ibáñez  ---
(In reply to Jeffrey A. Law from comment #16)
> Created attachment 31928 [details]
> Work-In-Progress patch

Jeff, what happened with this?

[Bug other/63513] New: Error to build gcc loaded from svn

2014-10-12 Thread karo13de at googlemail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63513

Bug ID: 63513
   Summary: Error to build gcc loaded from svn
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karo13de at googlemail dot com

Build error of gcc svn on MacOSX 10.9:

No options given for configure and make

...
/Users/xxx/sw/gccdir/./gcc/xgcc -B/Users/karo/sw/gccdir/./gcc/
-B/usr/local/x86_64-apple-darwin13.4.0/bin/
-B/usr/local/x86_64-apple-darwin13.4.0/lib/ -isystem
/usr/local/x86_64-apple-darwin13.4.0/include -isystem
/usr/local/x86_64-apple-darwin13.4.0/sys-include-g -O2 -m32 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -pipe -fno-common -I. -I. -I../../.././gcc
-I../../.././../gcc/libgcc -I../../.././../gcc/libgcc/.
-I../../.././../gcc/libgcc/../gcc -I../../.././../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _mulxc3.o -MT _mulxc3.o -MD -MP -MF _mulxc3.dep
-DL_mulxc3 -c ../../.././../gcc/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../.././../gcc/libgcc/libgcc2.c: In Funktion »__mulxc3«:
../../.././../gcc/libgcc/libgcc2.c:1955:6: interner Compiler-Fehler: Illegal
instruction: 4
a = COPYSIGN (isinf (a) ? 1 : 0, a);
  ^
libbacktrace could not find executable to open
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Siehe  für nähere Anweisungen.
make[5]: *** [_mulxc3.o] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
gccdir $

[Bug c++/25689] missed diagnostic about assignment used as truth value.

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25689

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Last reconfirmed|2006-01-06 12:32:23 |2014-10-12

--- Comment #2 from Manuel López-Ibáñez  ---
A simpler testcase:

struct Var {
  operator int() const;
  Var& operator = (int);
};

void foo(Var var)
{
  if (var = 0) {}  // we should warn
  if (var.operator=(0)) {} // we should NOT warn
}

Clang prints:

pr25689.C:8:11: warning: using the result of an assignment as a condition
without parentheses [-Wparentheses]
  if (var = 0) {}  // if (var.operator=(0))
  ^~~
pr25689.C:8:11: note: place parentheses around the assignment to silence this
warning
  if (var = 0) {}  // if (var.operator=(0))
  ^
  (  )
pr25689.C:8:11: note: use '==' to turn this assignment into an equality
comparison
  if (var = 0) {}  // if (var.operator=(0))
  ^
  ==

[Bug c/37866] "passing argument from incompatible pointer type" warning cannot be passed to -Werror=

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37866

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #9 from Manuel López-Ibáñez  ---
https://gcc.gnu.org/gcc-5/changes.html

It is possible to disable warnings about conversions between pointers that have
incompatible types via a new warning option -Wno-incompatible-pointer-types;
warnings about implicit incompatible integer to pointer and pointer to integer
conversions via a new warning option -Wno-int-conversion; and warnings about
qualifiers on pointers being discarded via a new warning option
-Wno-discarded-qualifiers.

[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260

--- Comment #1 from Oleg Endo  ---
The following functions should not show any mode changes:

float test_0 (float x)
{
  return -x;
}

double test_1 (double x)
{
  return -x;
}

float test_2 (float x)
{
  return __builtin_fabs (x);
}

double test_3 (double x)
{
  return __builtin_abs (x);
}

[Bug c++/43487] method locations are incorrect

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Manuel López-Ibáñez  ---
I cannot reproduce this and no testcase is forthcoming (and Mozilla already
replaced their GCC plugins for Clang, so probably they don't care anymore about
this).

[Bug fortran/63514] New: functions containing volatile are considered pure

2014-10-12 Thread Joost.VandeVondele at mat dot ethz.ch 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514

Bug ID: 63514
   Summary: functions containing volatile are considered pure
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch

The following testcase is miscompiled at -O1:

> cat test.f90
MODULE M1
CONTAINS
  INTEGER FUNCTION F1()
INTEGER, VOLATILE :: i
F1=i
  END FUNCTION
  INTEGER FUNCTION F2()
F2=F1()+F1()
  END FUNCTION
END MODULE

> gfortran -O1 -fdump-tree-optimized -fno-inline -c test.f90

;; Function f2 (__m1_MOD_f2, funcdef_no=0, decl_uid=2355, cgraph_uid=0,
symbol_order=0)

f2 ()
{
  integer(kind=4) __var_1;
  integer(kind=4) __result_f2.0_3;

  :
  __var_1_2 = f1 ();
  __result_f2.0_3 = __var_1_2 + __var_1_2;
  return __result_f2.0_3;

}

f1 should be called twice in this case, as it returns the value of a volatile.
I believe f1 is being considered as pure here, which seems not correct.
Actually, it doesn't generate an error if I add 'PURE' to the function
definition, which I assume is not correct either.

[Bug fortran/63514] functions containing volatile are considered pure

2014-10-12 Thread Joost.VandeVondele at mat dot ethz.ch 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
Actually there is wording about this in F2008 (but not F2003):

C1282 A designator of a variable with the VOLATILE attribute shall not appear
in a pure subprogram.

[Bug target/53513] SH Target: Add support for fschg and fpchg insns

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513

--- Comment #17 from Oleg Endo  ---
(In reply to Oleg Endo from comment #14)
> 
> The switch is done by 3 (+2 artificial) individual instructions (load -
> modify - store).  In this case the RA / optimizers figure out that there's
> no need to store fpscr twice and reorder the operations.  This is because
> all the fp insn patterns in the machine description only "use" the fpscr,
> but actually they also modify it.  This means that the fenv is reset after
> the 'fadd', i.e. it potentially clears exception flags etc.
> 
> I think this is wrong.  It also seems impossible to get the fpscr value
> immediately after the fp insn, as it always gets reordered in some way.  As
> far as I understand, all the fp insns that update bits in fpscr should
> actually do so (clobber it or set it in someway) and a builtin "get_fpscr"
> is required so that optimizers see the dependencies on fpscr.

In the 'addsf3_i' pattern, I've tried replacing the

(use (match_operand:PSI 3 "fpscr_operand" "c"))

with

(set (match_operand:PSI 3 "fpscr_operand" "=&c")
 (unspec:PSI [(match_dup 3)] UNSPEC_FPSCR_SET))]

and after that the asm output looks OK:
sts fpscr,r1
mov.l   .L2,r2
xor r2,r1
lds r1,fpscr
fmovfr5,fr0
faddfr4,fr0
sts fpscr,r1
xor r2,r1
rts
lds r1,fpscr

I haven't checked all the other side effects it could have, but at least the
FMA combine patterns still seem work after that change.

[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind

2014-10-12 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504

--- Comment #6 from Markus Trippelsdorf  ---
Created attachment 33693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33693&action=edit
testcase for issue 2)

2)
 % valgrind --track-origins=yes --trace-children=yes ./gcc/xgcc -Bgcc -c -S
-std=gnu11 -fcx-fortran-rules -O2 ../read.i

[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429

--- Comment #6 from Oleg Endo  ---
A test case for this problem is gcc/testsuite/g++.dg/tls/thread_local-order1.C,
which is compiled without optimizations and contains the following sequence:

stc gbr,r1
mov.l   .L20,r2
add r2,r1
lds r1,fpul
fstsfpul,fr1
fldsfr1,fpul
sts fpul,r0
mov r14,r15
lds.l   @r15+,pr
mov.l   @r15+,r14
rts
nop

what the code is actually doing:
stc gbr,r1
mov.l   .L20,r2
add r2,r1
mov r1,r0
mov r14,r15
lds.l   @r15+,pr
mov.l   @r15+,r14
rts
nop

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

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #62 from Oleg Endo  ---
Just a note... I've briefly checked whether PR 54429 gets any better with LRA. 
It doesn't seem to be the case.

[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind

2014-10-12 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504

--- Comment #7 from Markus Trippelsdorf  ---
4)
markus@x4 gcc % valgrind -q --track-origins=yes --trace-children=yes g++
-Igcc/testsuite/g++.dg/cpp1y -Igcc/testsuite//g++.dg/cpp1y/testinc
gcc/testsuite/g++.dg/cpp1y/feat-cxx14.C -std=gnu++1y -S
==16557== Conditional jump or move depends on uninitialised value(s)
==16557==at 0x1215932: parse_has_include(cpp_reader*, include_type)
(expr.c:2143)
==16557==by 0x1218E63: eval_token (expr.c:1056)
==16557==by 0x1218E63: _cpp_parse_expr (expr.c:1224)
==16557==by 0x1211BE3: do_if(cpp_reader*) (directives.c:1980)
==16557==by 0x1213417: _cpp_handle_directive (directives.c:509)
==16557==by 0x12202CC: _cpp_lex_token (lex.c:2172)
==16557==by 0x122513F: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2408)
==16557==by 0x7CB2BC: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:303)
==16557==by 0x673A0F: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:763)
==16557==by 0x6AA905: cp_parser_initial_pragma (parser.c:31771)
==16557==by 0x6AA905: cp_lexer_new_main (parser.c:633)
==16557==by 0x6AA905: cp_parser_new (parser.c:3434)
==16557==by 0x6AA905: c_parse_file() (parser.c:32090)
==16557==by 0x7D3482: c_common_parse_file() (c-opts.c:1043)
==16557==by 0xBD4631: compile_file() (toplev.c:551)
==16557==by 0xBD6A01: do_compile (toplev.c:1946)
==16557==by 0xBD6A01: toplev_main(int, char**) (toplev.c:2022)
==16557==  Uninitialised value was created by a heap allocation
==16557==at 0x4028AEF: malloc (vg_replace_malloc.c:296)
==16557==by 0x124B867: xmalloc (xmalloc.c:147)
==16557==by 0x121D6CA: _cpp_init_tokenrun (lex.c:2006)
==16557==by 0x121BD1A: cpp_create_reader(c_lang, ht*, line_maps*)
(init.c:242)
==16557==by 0x7D115C: c_common_init_options(unsigned int,
cl_decoded_option*) (c-opts.c:237)
==16557==by 0xBD6131: toplev_main(int, char**) (toplev.c:2000)
==16557==by 0x4ED6FCF: (below main) (in /lib64/libc-2.19.90.so)
==16557== 
==16557== Conditional jump or move depends on uninitialised value(s)
==16557==at 0x1218424: _cpp_parse_expr (expr.c:1325)
==16557==by 0x1211BE3: do_if(cpp_reader*) (directives.c:1980)
==16557==by 0x1213417: _cpp_handle_directive (directives.c:509)
==16557==by 0x12202CC: _cpp_lex_token (lex.c:2172)
==16557==by 0x122513F: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2408)
==16557==by 0x7CB2BC: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:303)
==16557==by 0x673A0F: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:763)
==16557==by 0x6AA905: cp_parser_initial_pragma (parser.c:31771)
==16557==by 0x6AA905: cp_lexer_new_main (parser.c:633)
==16557==by 0x6AA905: cp_parser_new (parser.c:3434)
==16557==by 0x6AA905: c_parse_file() (parser.c:32090)
==16557==by 0x7D3482: c_common_parse_file() (c-opts.c:1043)
==16557==by 0xBD4631: compile_file() (toplev.c:551)
==16557==by 0xBD6A01: do_compile (toplev.c:1946)
==16557==by 0xBD6A01: toplev_main(int, char**) (toplev.c:2022)
==16557==by 0x4ED6FCF: (below main) (in /lib64/libc-2.19.90.so)
==16557==  Uninitialised value was created by a heap allocation
==16557==at 0x4028AEF: malloc (vg_replace_malloc.c:296)
==16557==by 0x124B867: xmalloc (xmalloc.c:147)
==16557==by 0x121D6CA: _cpp_init_tokenrun (lex.c:2006)
==16557==by 0x121BD1A: cpp_create_reader(c_lang, ht*, line_maps*)
(init.c:242)
==16557==by 0x7D115C: c_common_init_options(unsigned int,
cl_decoded_option*) (c-opts.c:237)
==16557==by 0xBD6131: toplev_main(int, char**) (toplev.c:2000)
==16557==by 0x4ED6FCF: (below main) (in /lib64/libc-2.19.90.so)
==16557==

[Bug c++/63515] New: unused templated member can be instatiated

2014-10-12 Thread luka.rahne at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63515

Bug ID: 63515
   Summary: unused templated member can be instatiated
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luka.rahne at gmail dot com

Created attachment 33694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33694&action=edit
source that fails

I was working on curried functions and came across some unusual behaviour.
(compilation fails with error)

I have trimmed some code and put relevant comments in source.

compiler: g++ 5.0 -> commit 9bf79212ecec2245e66156c2b18d8a76a0187b04
flags:  -O3  -Wall -Wextra -std=c++11

[Bug bootstrap/63516] New: error when trying to build without a c++ compiler could be better

2014-10-12 Thread tbsaunde at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63516

Bug ID: 63516
   Summary: error when trying to build without a c++ compiler
could be better
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tbsaunde at gcc dot gnu.org
CC: segher at gcc dot gnu.org

If for whatever reason you miss the requirement that you need a c++ compiler to
build the first error you hit is
checking for uintmax_t... yes
checking for uintptr_t... yes
checking for int64_t underlying type... long long
configure: error: error verifying int64_t uses long long
Makefile:4042: recipe for target 'configure-stage1-gcc' failed
make[2]: *** [configure-stage1-gcc] Error 1
make[2]: Leaving directory '/src/gcc-opt'
Makefile:21799: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2

Which happens because that configure check happens to use C++.  It seems to me
explicitly checking for a C++ compiler would be better.  This is reproducably
by putting a dummy g++ in your path that just exits 1.
make[1]: Leaving directory '/src/gcc-opt'

[Bug bootstrap/63516] error when trying to build without a c++ compiler could be better

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63516

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
Dup.

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

[Bug other/63509] Misleading error message when building gcc without C++ compiler installed

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||tbsaunde at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
*** Bug 63516 has been marked as a duplicate of this bug. ***

[Bug target/54760] [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760

--- Comment #15 from Oleg Endo  ---
Author: olegendo
Date: Sun Oct 12 23:14:07 2014
New Revision: 216128

URL: https://gcc.gnu.org/viewcvs?rev=216128&root=gcc&view=rev
Log:
gcc/
PR target/59401
* config/sh/sh-protos (sh_find_equiv_gbr_addr): Use rtx_insn* instead
of rtx.
* config/sh/sh.c (sh_find_equiv_gbr_addr): Use def chains instead of
insn walking.
(sh_find_equiv_gbr_addr): Do nothing if input mem is already a GBR
address.  Use def chains to handle GBR clobbering call insns.

gcc/testsuite/
PR target/59401
PR target/54760
* gcc.target/pr54760-5.c: New.
* gcc.target/pr54760-6.c: New.
* gcc.target/sh/pr59401-1.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr54760-5.c
trunk/gcc/testsuite/gcc.target/sh/pr54760-6.c
trunk/gcc/testsuite/gcc.target/sh/pr59401-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-protos.h
trunk/gcc/config/sh/sh.c
trunk/gcc/testsuite/ChangeLog

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #2 from Oleg Endo  ---
Author: olegendo
Date: Sun Oct 12 23:14:07 2014
New Revision: 216128

URL: https://gcc.gnu.org/viewcvs?rev=216128&root=gcc&view=rev
Log:
gcc/
PR target/59401
* config/sh/sh-protos (sh_find_equiv_gbr_addr): Use rtx_insn* instead
of rtx.
* config/sh/sh.c (sh_find_equiv_gbr_addr): Use def chains instead of
insn walking.
(sh_find_equiv_gbr_addr): Do nothing if input mem is already a GBR
address.  Use def chains to handle GBR clobbering call insns.

gcc/testsuite/
PR target/59401
PR target/54760
* gcc.target/pr54760-5.c: New.
* gcc.target/pr54760-6.c: New.
* gcc.target/sh/pr59401-1.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr54760-5.c
trunk/gcc/testsuite/gcc.target/sh/pr54760-6.c
trunk/gcc/testsuite/gcc.target/sh/pr59401-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-protos.h
trunk/gcc/config/sh/sh.c
trunk/gcc/testsuite/ChangeLog

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

Oleg Endo  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #3 from Oleg Endo  ---
Kaz, I'd like to backport this to 4.8 and 4.9, but I can't decide in which
form.

The patch from r216128 could be applied to the branches.  Another option is to
prevent the sh_find_equiv_gbr_addr function from crossing labels.  This is just
a few lines, but of course it produces not so good results in some cases.

Do you have an opinion on that?

[Bug c/60440] Bogus -Wreturn-type warning after error

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-13
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Confirmed.

[Bug c++/63517] New: bogus Wreturn-type warning after error

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63517

Bug ID: 63517
   Summary: bogus Wreturn-type warning after error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org

struct X{};
int foo (int x, const X& y)
{
  return x + y;
}


test.cc:4:12: error: no match for ‘operator+’ (operand types are ‘int’ and
‘const X’)
   return x + y;
^
test.cc: In function ‘int foo(int, const X&)’:
test.cc:5:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

The Wreturn-type warning is bogus.

A similar issue in the  C FE is PR60440.

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-13
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Confirmed. It does warn for "aaa" + x, when x is char/int.

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181

--- Comment #2 from Manuel López-Ibáñez  ---
In both FEs there is a function build_binary_op. Put a break-point inside,
examine the operands with debug_tree and figure out how to detect this case and
when to warn. Add the new warning option to c-family/c.opt and document it in
gcc/doc/invoke.texi.

I think the note is useful but we cannot give the fix-it hints yet. Add a FIXME
in the code on top of the inform call.

[Bug middle-end/63518] New: missing Wuninitialized warning independent of order of arguments

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63518

Bug ID: 63518
   Summary: missing Wuninitialized warning independent of order of
arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org

typedef int Timeout;

void wait(Timeout, bool);

void wait2(Timeout, bool);

bool setTimeout(Timeout &t)
{
  t = 5;
  return true;
}

void foo(void)
{
  Timeout t;
   wait(t, setTimeout(t));
}


void bar(void)
{
  Timeout t;
   wait2(setTimeout(t),t);
}

At least one of the both variants should give a warning. Ideally, both should.

Clang warns for the first variant.

[Bug c++/63519] New: missing Wparenthesis warning for x binary_op bool ?:

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63519

Bug ID: 63519
   Summary: missing Wparenthesis warning for x binary_op bool ?:
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org

int foo(bool a, int x, int y, int z)
{
  return x * a ? y : z;
}

Clang:

test.cc:3:16: warning: operator '?:' has lower precedence than '*'; '*' will be
evaluated first [-Wparentheses]
  return x * a ? y : z;
 ~ ^
test.cc:3:16: note: place parentheses around the '*' expression to silence this
warning
  return x * a ? y : z;
   ^
 ()
test.cc:3:16: note: place parentheses around the '?:' expression to evaluate it
first
  return x * a ? y : z;
   ^
 ()

[Bug c++/60664] bool / out of range int comparison warning failure

2014-10-12 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Put a break-point in build_binary_op then figure out where to warn (probably in
EQ_EXPR and NE_EXPR and other logical operators). Use debug_tree() to examine
the operands and figure out how to detect the correct cases.

[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host

2014-10-12 Thread zhenqiang.chen at arm dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302

--- Comment #19 from Zhenqiang Chen  ---
(In reply to John David Anglin from comment #18)
> Hi Zhenqiang,
> 
> Do you plan to submit patch to gcc-patches soon?

Yes. It is in internal review process. I hope to send out it this week.

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

2014-10-12 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #4 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #3)
> Do you have an opinion on that?

Looks the latter is enough for the released branches.  I'm OK with eather way,
though.

[Bug sanitizer/63520] New: ICE: in get_biv_step, at loop-iv.c:824 with -fsanitize=undefined on ppc64

2014-10-12 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63520

Bug ID: 63520
   Summary: ICE: in get_biv_step, at loop-iv.c:824 with
-fsanitize=undefined on ppc64
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.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: powerpc64-unknown-linux-gnu

trippels@gcc1-power7 libdecnumber % cat decNumber.i
int a;
void
fn1 (void)
{
  for (;;)
{
  if (a == 1)
break;
  a -= 1;
}
}

trippels@gcc1-power7 libdecnumber % gcc -c -fsanitize=undefined -O2 decNumber.i
decNumber.i: In function ‘fn1’:
decNumber.i:11:1: internal compiler error: in get_biv_step, at loop-iv.c:824
 }
 ^
0x105a9b13 get_biv_step
../../gcc/gcc/loop-iv.c:824
0x105a9b13 iv_analyze_biv
../../gcc/gcc/loop-iv.c:913
0x105a9f8b iv_analyze_op
../../gcc/gcc/loop-iv.c:1189
0x105a9e6f iv_analyze_op
../../gcc/gcc/loop-iv.c:1159
0x105aa2cb iv_analyze_expr(rtx_insn*, rtx_def*, machine_mode, rtx_iv*)
../../gcc/gcc/loop-iv.c:969
0x105aa3d3 iv_analyze_expr(rtx_insn*, rtx_def*, machine_mode, rtx_iv*)
../../gcc/gcc/loop-iv.c:1025
0x105aabeb iv_analyze_def
../../gcc/gcc/loop-iv.c:1120
0x105a9df3 iv_analyze_op
../../gcc/gcc/loop-iv.c:1191
0x105ab30b iv_number_of_iterations
../../gcc/gcc/loop-iv.c:2387
0x105ab30b check_simple_exit
../../gcc/gcc/loop-iv.c:2950
0x105ab30b find_simple_exit(loop*, niter_desc*)
../../gcc/gcc/loop-iv.c:2975
0x105ac97f get_simple_loop_desc(loop*)
../../gcc/gcc/loop-iv.c:3056
0x10d8e99f doloop_optimize
../../gcc/gcc/loop-doloop.c:617
0x10d8e99f doloop_optimize_loops()
../../gcc/gcc/loop-doloop.c:745
0x1059f253 execute
../../gcc/gcc/loop-init.c:643
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513

--- Comment #18 from Oleg Endo  ---
(In reply to Oleg Endo from comment #15)
> Created attachment 33691 [details]
> a possible patch
> 
> The previous patch was buggy, it always generated a PR toggle sequence, even
> if a mode should be set directly.

I've tested the patch, there are some new failures:

-m4 -mb:
FAIL: g++.dg/torture/type-generic-1.C   -O0  execution test
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/complex-6.c   -O0  execution test
FAIL: gcc.c-torture/execute/gofast.c   -O0  execution test
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/copysign1.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/mzero3.c execution,  -O0 
FAIL: gcc.dg/torture/type-generic-1.c   -O0  execution test

-m4 -ml:
FAIL: g++.dg/torture/type-generic-1.C   -O0  execution test
FAIL: g++.dg/torture/type-generic-1.C   -O1  execution test
FAIL: g++.dg/torture/type-generic-1.C   -O2  execution test
FAIL: g++.dg/torture/type-generic-1.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/torture/type-generic-1.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/torture/type-generic-1.C   -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/type-generic-1.C   -O3 -g  execution test
FAIL: g++.dg/torture/type-generic-1.C   -Os  execution test
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/complex-6.c   -O0  execution test
FAIL: gcc.c-torture/execute/conversion.c   -O0  execution test
FAIL: gcc.c-torture/execute/gofast.c   -O0  execution test
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution,  -Og -g 
FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/copysign1.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/mzero3.c execution,  -O0 
FAIL: gcc.dg/pr28796-2.c execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O0  execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O1  execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O2  execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O3 -fomit-frame-pointer 
execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -O3 -g  execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c   -Os  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O0  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O1  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O2  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O3 -fomit-frame-pointer  execution
test
FAIL: gcc.dg/torture/type-generic-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -Os  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O0  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O1  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O2  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/vec-cvt-1.c   -Os  execution test

[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support

2014-10-12 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513

--- Comment #19 from Oleg Endo  ---
(In reply to Oleg Endo from comment #18)
> (In reply to Oleg Endo from comment #15)
> > Created attachment 33691 [details]
> > a possible patch
> > 
> > The previous patch was buggy, it always generated a PR toggle sequence, even
> > if a mode should be set directly.
> 
> I've tested the patch, there are some new failures:
> ...

No I didn't.  That was a patch for PR 63260.  Sorry for the noise.