[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758

2020-04-07 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-04-07
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. Looks like a missing backport of:
http://gcc.gnu.org/g:3a30d2558b3a199fe346479e6140cddae7fba5ed

[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758

2020-04-07 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Should be fixed now on the branch

[Bug target/94530] [9/10 Regression] ICE: SIGSEGV in rhs_regno (rtl.h:1924) with -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large

2020-04-08 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-04-08
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
In the code
538   if (!aarch64_classify_address (&addr, XEXP (x, 0), mode, true))
539 return false;
540
541   unsigned regno = REGNO (addr.base);
542   if (global_regs[regno] || fixed_regs[regno])
543 return false;

addr.base is not guaranteed to be a register. In this instance it's:
(mem/u/c:DI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0  S8 A64])

[Bug target/93053] [10 Regression] libgcc build failure with old binutils on aarch64

2020-04-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #9 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> I've tried manually:
> --- cas_16_1.s~   2020-04-14 12:19:03.0 +0200
> +++ cas_16_1.s2020-04-14 12:20:10.083098672 +0200
> @@ -5,7 +5,7 @@
>  # 1 "" 2
>  # 1 "/usr/src/gcc/libgcc/config/aarch64/lse.S"
>  # 53 "/usr/src/gcc/libgcc/config/aarch64/lse.S"
> - .arch armv8-a+lse
> + .arch armv8-a
>  
>  
>   .hidden __aarch64_have_lse_atomics
> @@ -37,7 +37,8 @@
>  STARTFN __aarch64_cas16_relax
>   JUMP_IF_NOT_LSE 8f
>  # 166 "/usr/src/gcc/libgcc/config/aarch64/lse.S"
> - casp x0, x1, x2, x3, [x4]
> +// casp x0, x1, x2, x3, [x4]
> + .word 0x48207c82
>   ret
>  
>  8: mov x16, x0
> which assembles (the constant taken from aarch64-linux-objdump -dr before
> the changes), but for some reason when disassembled aarch64-linux-objdump
> -dr knows that it was .word and not casp instruction.
> Any way to emit insns not supported by the assembler?

There is the .inst directive

[Bug target/94591] [8/9/10 Regression] Assembler messages: Error: operand mismatch -- `rev64 v0.2d,v0.2d'

2020-04-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94591

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-14
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug libfortran/93871] COTAN is slow for complex types

2020-04-20 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #48 from ktkachov at gcc dot gnu.org ---
(In reply to CVS Commits from comment #45)
> The master branch has been updated by Fritz Reese :
> 
> https://gcc.gnu.org/g:57391ddaf39f7cb85825c32e83feb1435889da51
> 
> commit r10-7603-g57391ddaf39f7cb85825c32e83feb1435889da51
> Author: Fritz Reese 
> Date:   Tue Apr 7 11:59:36 2020 -0400
> 
> Fix PR fortran/93871 and re-implement degree-valued trigonometric
> intrinsics.
> 
> 2020-04-01  Fritz Reese  
> Steven G. Kargl  
> 
> gcc/fortran/ChangeLog
> 
> PR fortran/93871
> * gfortran.h (GFC_ISYM_ACOSD, GFC_ISYM_ASIND, GFC_ISYM_ATAN2D,
> GFC_ISYM_ATAND, GFC_ISYM_COSD, GFC_ISYM_COTAND, GFC_ISYM_SIND,
> GFC_ISYM_TAND): New.
> * intrinsic.c (add_functions): Remove check for flag_dec_math.
> Give degree trig functions simplification and name resolution
> functions (e.g, gfc_simplify_atrigd () and gfc_resolve_atrigd
> ()).
> (do_simplify): Remove special casing of degree trig functions.
> * intrinsic.h (gfc_simplify_acosd, gfc_simplify_asind,
> gfc_simplify_atand, gfc_simplify_cosd, gfc_simplify_cotand,
> gfc_simplify_sind, gfc_simplify_tand, gfc_resolve_trigd2): Add
> new
> prototypes.
> (gfc_simplify_atrigd, gfc_simplify_trigd, gfc_resolve_cotan,
> resolve_atrigd): Remove prototypes of deleted functions.
> * iresolve.c (is_trig_resolved, copy_replace_function_shallow,
> gfc_resolve_cotan, get_radians, get_degrees, resolve_trig_call,
> gfc_resolve_atrigd, gfc_resolve_atan2d): Delete functions.
> (gfc_resolve_trigd, gfc_resolve_trigd2): Resolve to library
> functions.
> * simplify.c (rad2deg, deg2rad, gfc_simplify_acosd,
> gfc_simplify_asind,
> gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd,
> gfc_simplify_sind, gfc_simplify_tand, gfc_simplify_cotand): New
> functions.
> (gfc_simplify_atan2): Fix error message.
> (simplify_trig_call, gfc_simplify_trigd, gfc_simplify_atrigd,
> radians_f): Delete functions.
> * trans-intrinsic.c: Add LIB_FUNCTION decls for sind, cosd, tand.
> (rad2deg, gfc_conv_intrinsic_atrigd, gfc_conv_intrinsic_cotan,
> gfc_conv_intrinsic_cotand, gfc_conv_intrinsic_atan2d): New
> functions.
> (gfc_conv_intrinsic_function): Handle ACOSD, ASIND, ATAND, COTAN,
> COTAND, ATAN2D.
> * trigd_fe.inc: New file. Included by simplify.c to implement
> simplify_sind, simplify_cosd, simplify_tand with code common to
> the
> libgfortran implementation.
> 
> gcc/testsuite/ChangeLog
> 
> PR fortran/93871
> * gfortran.dg/dec_math.f90: Extend coverage to real(10) and
> real(16).
> * gfortran.dg/dec_math_2.f90: New test.
> * gfortran.dg/dec_math_3.f90: Likewise.
> * gfortran.dg/dec_math_4.f90: Likewise.
> * gfortran.dg/dec_math_5.f90: Likewise.
> 
> libgfortran/ChangeLog
> 
> PR fortran/93871
> * Makefile.am, Makefile.in: New make rule for intrinsics/trigd.c.
> * gfortran.map: New routines for {sind, cosd, tand}X{r4, r8,
> r10, r16}.
> * intrinsics/trigd.c, intrinsics/trigd_lib.inc,
> intrinsics/trigd.inc:
> New files. Defines native degree-valued trig functions.

I think this broke the build for bare-metal (newlib) targets like
aarch64-none-elf:

libgfortran/intrinsics/trigd_lib.inc:55:56: error: implicit declaration of
function 'copysignl' [-Werror=implicit-function-declaration]
   55 | #define mpfr_copysign(rop, op1, op2, rnd) rop = SUFFIX(copysign)((op1),
(op2))
  |^~~~

I think newlib doesn't support long double functions well so likely doesn't
have copysignl. Is there some way this use can be conditionalised on library
support?

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

2020-04-21 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Ever confirmed|0   |1
   Severity|blocker |normal
 Target||aarch64
  Known to fail||10.0
Summary|[libgfortran] libgfortran   |[10
   |does not compile on |Regression][libgfortran]
   |bare-metal aarch64-none-elf |libgfortran does not
   |(newlib)|compile on bare-metal
   ||aarch64-none-elf (newlib)
   Last reconfirmed||2020-04-21
 Status|UNCONFIRMED |NEW
   Keywords||build
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed, I see it too.

[Bug target/95128] aarch64: configure option for outline-atomics

2020-05-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95128

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-14

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Agreed. I'd be happy to review such a patch

[Bug target/95129] aarch64: make outline-atomics work on non-gnu targets

2020-05-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95129

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2020-05-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/95341] Poor vector_size decomposition when SVE is enabled

2020-05-26 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-26

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug target/95341] Poor vector_size decomposition when SVE is enabled

2020-05-26 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Interestingly, -msve-vector-bits gives good codegen for 128, 256, 512 but bad
for 1024, 2048 and VLA code

[Bug target/95399] [ARM, AArch64] 32/64-bit vcvtnq_* functions are missing

2020-05-29 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Hmm... I see them present for aarch64 and even in the gotbolt setup you
provided (use ARM64 gcc 8.2)
They do seem to be missing from arm though indeed

[Bug target/95399] [ARM] 32/64-bit vcvtnq_* functions are missing

2020-05-29 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-29

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Thanks for this. Having this bug listing all of the missing intrinsics is fine.
If you are willing to do the same for the aarch64 functions (keep in mind there
are other include files like arm_fp16.h and arm_bf16.h involved) that would be
a  good separate report

[Bug target/95471] vrndvq_f32 not supported on armv8

2020-06-02 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95471

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
-mfpu=neon doesn't support the Neon features from Armv8-A.
The recommended way is to use -mfpu=auto and use an appropriate -mcpu or -march
option.
In this case, using -march=armv8-a+simd -mfpu=auto generates the instruction.

[Bug middle-end/95899] -funroll-loops does not duplicate accumulators when calculating reductions, failing to break up dependency chains

2020-06-25 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95899

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Is this -fvariable-expansion-in-unroller ? (off by default for everything but
powerpc)

[Bug c++/96196] infinite loop removed by optimizer

2020-07-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96196

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
This is -ffinite-loops which is on by default and was added in GCC 10.1
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#Optimize-Options

[Bug target/96305] Unnecessary signed x unsigned multiplication with squares of signed variables

2020-07-24 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96305

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
This did get a bit better in GCC 10.1, which generates:
compute:
smull   r0, r3, r0, r0
asrsr0, r1, #31
mulsr0, r3, r0
asrsr2, r3, #31
mla r0, r1, r2, r0
umull   r3, r1, r3, r1
add r0, r0, r1
bx  lr

[Bug target/96357] New: [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE

2020-07-28 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96357

Bug ID: 96357
   Summary: [10/11 Regression] could not split insn
UNSPEC_COND_FSUB with AArch64 SVE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The reduced testcase:
typedef int a;
int d;
void e(char f, char *g, char *h, char *l, char * n) {
  double i = d, j = 1.0 - f, k = j ? d : j;
  if (k == 1.0)
i = 0.0;
  *g = *h = i * 0.5;
  *l = *n = 0;
}

void o() {
  int  a, m, c = o;
  for (; c; c--) {
char b = a++;
e(b, m, m + 1, m + 2, m + 3);
m += 4;
  }
}

ICEs with -w -O3 -march=arvm8.2-a+sve
reduced.c: In function ‘o’:
reduced.c:18:1: error: could not split insn
   18 | }
  | ^
(insn 145 401 149 (set (reg:VNx2DF 39 v7 [orig:145 _127 ] [145])
(unspec:VNx2DF [
(reg:VNx2BI 69 p1 [318])
(unspec:VNx2DF [
(reg:VNx2BI 78 p10 [318])
(const_int 1 [0x1])
(const_vector:VNx2DF [
(const_double:DF 1.0e+0 [0x0.8p+1])
])
(reg:VNx2DF 37 v5 [orig:152 vect__27.15 ] [152])
] UNSPEC_COND_FSUB)
(reg:VNx2DF 48 v16 [orig:140 vect_i_26.13 ] [140])
] UNSPEC_SEL)) 5775 {*cond_subvnx2df_any_const}
 (expr_list:REG_DEAD (reg:VNx2BI 78 p10 [318])
(expr_list:REG_DEAD (reg:VNx2BI 69 p1 [318])
(expr_list:REG_DEAD (reg:VNx2DF 37 v5 [orig:152 vect__27.15 ]
[152])
(nil)
during RTL pass: final

[Bug target/96357] [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE

2020-07-28 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96357

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.2.1, 11.0
 Target||aarch64
   Target Milestone|--- |10.3
  Known to work||9.3.1

[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics

2020-07-31 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Thanks, can you share the hardware you ran it on? Depending on whether LSE is
present different code paths are taken at runtime...

[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics

2020-07-31 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Thanks, that's a CPU without the LSE instructions so it should be using the
load-exclusive-store-exclusive loop fallback

[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics

2020-08-03 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48985 [details]
> gcc11-pr96402.patch
> 
> So, something like this then?  Then the SIZE 16 compare and swap matches
> what the 1/2/4/8 SIZE ones do.

Looks like it, yes. Ok if it passes bootstrap testing

[Bug tree-optimization/96483] New: ICE in code hoisting with AArch64 SVE2 intrinsics

2020-08-05 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96483

Bug ID: 96483
   Summary: ICE in code hoisting with AArch64 SVE2 intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

The following (reduced) testcase ICEs on aarch64 with
-O2 -w -march=armv8.2-a+sve2

GCC 10 and trunk ICE. Since the SVE2 intrinsics were introduced in GCC 10 it's
not a regression.

during GIMPLE pass: pre
red.c: In function 'u':
red.c:25:1: internal compiler error: in create_component_ref_by_pieces_1, at
tree-ssa-pre.c:2659
   25 | u () {
  | ^
0xfc03c8 create_component_ref_by_pieces_1
$SRC/gcc/tree-ssa-pre.c:2659
0xfbe4fc create_expression_by_pieces
$SRC/gcc/tree-ssa-pre.c:2795
0xfc215b do_hoist_insertion
$SRC/gcc/tree-ssa-pre.c:3587
0xfc215b insert
$SRC/gcc/tree-ssa-pre.c:3674
0xfc215b execute
$SRC/gcc/tree-ssa-pre.c:4224
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

include "arm_sve.h"

typedef unsigned long a;

void
b (svuint8_t *c, int d, char e, int f, char g, int h) {
  svbool_t i = svwhilegt_b8(svcntb(), (a)d);
  *c = svld1_u8(i, d);
}

void
j (struct k *ci, long l, svuint8_t *m, svuint8_t *n, int o, char p, int w) {
  int q = 0, r, s;
  if (l)
b(m, q, ci, r, ci, s);
  x(m);
}

void
t (svuint8_t *c, int d, char p, struct k *ci, long offset) {
  j(ci, offset, c, 0, d, p, 6);
}

void
u () {
  for (;;) {
int ci, d;
long offset;
svuint8_t v;
t(&v, d, 1, ci, offset);
  }
}

[Bug tree-optimization/96483] ICE in code hoisting with AArch64 SVE2 intrinsics

2020-08-05 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96483

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.3
  Known to fail||10.1.1, 11.0

[Bug rtl-optimization/96796] [9 Regression] aarch64: ICE during RTL pass: reload

2020-08-26 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||10.1.1, 11.0, 8.4.1
 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2020-08-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||9.3.1
Summary|aarch64: ICE during RTL |[9 Regression] aarch64: ICE
   |pass: reload|during RTL pass: reload

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on GCC 9 branches. Other branches don't ICE for me

[Bug rtl-optimization/96796] [9/10/11 Regression] aarch64: ICE during RTL pass: reload

2020-08-26 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||10.1.1, 11.0
Summary|[9 Regression] aarch64: ICE |[9/10/11 Regression]
   |during RTL pass: reload |aarch64: ICE during RTL
   ||pass: reload
  Known to work|10.1.1, 11.0|

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Updating regression markers then

[Bug tree-optimization/96915] New: ICE in tree-switch-conversion

2020-09-03 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96915

Bug ID: 96915
   Summary: ICE in tree-switch-conversion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

The following SVE intrinsics code ICEs with -O3 -march=armv8.2-a+sve

#include 

void b (void);

void
a ()
{
  switch (svcntd())
  case 2:
  case 4:
b();
}

during GIMPLE pass: switchconv
foo.c: In function 'a':
foo.c:12:1: internal compiler error: in expand, at tree-switch-conversion.c:988
   12 | }
  | ^
0xe475f1 tree_switch_conversion::switch_conversion::expand(gswitch*)
$SRC/gcc/tree-switch-conversion.c:988
0xe478ae execute
$SRC/gcc/tree-switch-conversion.c:2401
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/96915] ICE in tree-switch-conversion

2020-09-03 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96915

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.1.1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Reproduced on the GCC 10 branch as well. Since SVE ACLE intrinsics were only
added in GCC 10 it's technically not a regression

[Bug tree-optimization/96974] New: [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE

2020-09-08 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974

Bug ID: 96974
   Summary: [10/11 Regression] ICE in
vect_get_vector_types_for_stmt compiling for SVE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

The reduced testcase:

float a;

int
b ()
{ return __builtin_lrintf(a); }

struct c {
  float d;
  c() {
for (int e = 0; e < 9; e++)
  coeffs[e] = d ? b() : 0;
  }
  int coeffs[10];
} f;

ICEs with g++ -Ofast -march=armv8.2-a+sve

during GIMPLE pass: slp
foo.cc: In function '(static initializers for foo.cc)':
foo.cc:14:4: internal compiler error: in vect_get_vector_types_for_stmt, at
tree-vect-stmts.c:12055
   14 | } f;
  |^
0x126e44d vect_get_vector_types_for_stmt(vec_info*, _stmt_vec_info*,
tree_node**, tree_node**, unsigned int)
$SRC/gcc/tree-vect-stmts.c:12054
0x12a7b9a vect_build_slp_tree_1
$SRC/gcc/tree-vect-slp.c:801
0x12a7b9a vect_build_slp_tree_2
$SRC/gcc/tree-vect-slp.c:1284
0x12a642b vect_build_slp_tree
$SRC/gcc/tree-vect-slp.c:1195
0x12a8a30 vect_build_slp_tree_2
$SRC/gcc/tree-vect-slp.c:1413
0x12a642b vect_build_slp_tree
$SRC/gcc/tree-vect-slp.c:1195
0x12a8a30 vect_build_slp_tree_2
$SRC/gcc/tree-vect-slp.c:1413
0x12a642b vect_build_slp_tree
$SRC/gcc/tree-vect-slp.c:1195
0x12ab23e vect_analyze_slp_instance
$SRC/gcc/tree-vect-slp.c:2210
0x12aea06 vect_analyze_slp(vec_info*, unsigned int)
$SRC/gcc/tree-vect-slp.c:2418
0x12b0fc3 vect_slp_analyze_bb_1
$SRC/gcc/tree-vect-slp.c:3388
0x12b0fc3 vect_slp_region
$SRC/gcc/tree-vect-slp.c:3498
0x12b0fc3 vect_slp_bb(basic_block_def*)
$SRC/gcc/tree-vect-slp.c:3628
0x12b4a70 execute
$SRC/gcc/tree-vectorizer.c:1429
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE

2020-09-08 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.1.1, 11.0
  Known to work||9.3.1
   Target Milestone|--- |10.4

[Bug target/96357] [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE

2020-09-09 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96357

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed everywhere then, thanks.

[Bug target/92388] [10 Regression] ICE in insert_regs, at cse.c:1129

2019-11-07 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92388

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-11-06 00:00:00 |2019-11-07
   Target Milestone|--- |10.0
Summary|ICE in insert_regs, at  |[10 Regression] ICE in
   |cse.c:1129  |insert_regs, at cse.c:1129
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on trunk.

[Bug target/92424] New: [aarch64] Broken code with -fpatchable-function-entry and BTI

2019-11-08 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424

Bug ID: 92424
   Summary: [aarch64] Broken code with -fpatchable-function-entry
and BTI
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

-fpatchable-function-entry seems to interact badly with
-mbranch-protection=standard (used to insert BTI markers)

void g(void);

void f(void)
{ g(); g(); }

aarch64-linux-gnu-gcc  -mbranch-protection=standard
-fpatchable-function-entry=2,1 -O3 -c foo.c -save-temps


Produces:
.arch armv8-a
.file   "foo.c"
.text
.align  2
.p2align 3,,7
.global f
.section__patchable_function_entries,"aw",@progbits
.8byte  .LPFE1
.text
.LPFE1:
nop
.type   f, %function
f:
nop  // <--- Function entry has NOP rather than PACIASP landing pad
.LFB0:
.cfi_startproc
hint25 // paciasp
.cfi_window_save
stp x29, x30, [sp, -16]!
.cfi_def_cfa_offset 16
.cfi_offset 29, -16
.cfi_offset 30, -8
mov x29, sp
bl  g
ldp x29, x30, [sp], 16
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
hint29 // autiasp
.cfi_window_save
b   g
.cfi_endproc
.LFE0:
.size   f, .-f


Could a possible solution be to emit ofr -mbranch-protection={standard or bti}
-fpatchable-function-entry=N,M:

f-4*M:
.rept M
nop
.endr
f:
bti c
.rept N-M
nop
.endr
// paciasp may be used from here on in

Unless we fix the codegen we should perhaps error out when the two options are
combined rather than producing silently wrong code?

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

2020-01-07 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93184

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Shift by a negative amount or larger than the type width is undefined behaviour
in C (I think C++ as well). There are no guarantees on the results of that
program.

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

2020-01-07 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93184

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Wojciech Migda from comment #2)
> Should there be at least a warning in case when the shift amount is a
> compile-time known constant?

In an ideal world yes. Howevever, most such warnings are done before any
optimisations are done. To detect this case the compiler would need to inline
mask into pub and do the constant propagation to figure out the bogus shift
count.

The compiler does warn about a more direct use of a negative shift count e.g.:
static
unsigned long long mask(const unsigned long long sz)
{
auto const rv = (unsigned long long)-1 >> (8 - 9) * 8;
return rv;
}

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

2020-01-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Marking as confirmed

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

2020-01-15 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692

--- Comment #11 from ktkachov at gcc dot gnu.org ---
It will need a target with LSE atomics. -march=armv8.1-a or equivalent. Or add
+lse to an -march or -mcpu line.

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

2020-01-15 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #11)
> It will need a target with LSE atomics. -march=armv8.1-a or equivalent. Or
> add +lse to an -march or -mcpu line.

Wait, no sorry, this shouldn't be related to LSE. Perhaps -mno-outline-atomics
?

[Bug target/93341] [10 Regression] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:221

2020-01-21 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93341

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The assert triggering is:
  enum rtx_code inv_cond_code
= reversed_comparison_code (cond, insn);
  /* We should be able to reverse all conditions.  */
  gcc_assert (inv_cond_code != UNKNOWN);

865257c447cc50f5819e9b53da83145f3c36c305 had recent changes in that area

[Bug tree-optimization/56321] New: ICE:segfault in midend for -funsafe-math-optimizations -O3

2013-02-14 Thread ktkachov at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321

 Bug #: 56321
   Summary: ICE:segfault in midend for -funsafe-math-optimizations
-O3
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ktkac...@gcc.gnu.org
CC: jgreenha...@gcc.gnu.org, wschm...@linux.vnet.ibm.com
Target: arm-none-eabi, x86_64-unknown-linux-gnu


Created attachment 29449
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29449
ICE triggers for -O3 -funsafe-math-optimizations

Attached test case triggers a segfault in the midend.

Observed on both arm-none-eabi and x86_64-unknown-linux-gnu

gcc -O3 -funsafe-math-optimizations test.c -S
test.c: In function ‘foo’:
test.c:1:7: internal compiler error: Segmentation fault
 float foo(int n)
   ^
0x8f4e45 crash_signal
../../gcc-fsf/gcc/toplev.c:332
0x84b7bc execute_function_todo
../../gcc-fsf/gcc/passes.c:1967
0x84da0d execute_todo
../../gcc-fsf/gcc/passes.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Bisection showed r186567 introduced the problem.
It seems that the reassoc code tries to do something wrong with __builtin_pow*


[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

2013-02-15 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56321



--- Comment #9 from ktkachov at gcc dot gnu.org 2013-02-15 11:08:38 UTC ---

Created attachment 29463

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29463

Slightly modified testcase



This testcase is similar, but gives the error, I think it has the same cause,

might be helpful:

testcase.c: In function 'foo':

testcase.c:2:6: error: virtual use of statement not up-to-date

 void foo(int n, int nreps, float tdgefa, float tdgesl)

  ^

# .MEM_25 = VDEF <_7>

printf ("%f\n", _24);

testcase.c:2:6: internal compiler error: verify_ssa failed

0x844aec execute_function_todo

/work/kyrtka01/local-checkouts/aarch32-trunk-testing/gcc/gcc/passes.c:1967

0x846d3d execute_todo

/work/kyrtka01/local-checkouts/aarch32-trunk-testing/gcc/gcc/passes.c:1999


[Bug tree-optimization/56662] New: ICE in gcc.dg/vect/vect-outer-5.c

2013-03-20 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56662



 Bug #: 56662

   Summary: ICE in gcc.dg/vect/vect-outer-5.c

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: rguent...@suse.de

ReportedBy: ktkac...@gcc.gnu.org

Target: arm-none-eabi





$SOURCE/gcc/gcc/testsuite/gcc.dg/vect/vect-outer-5.c:13:5: internal compiler

error: in vect_do_peeling_for_loop_bound, at tree-vect-loop-manip.c:1798

0xaa4439 vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node**, unsigned

int, bool)

$SOURCE/gcc/gcc/tree-vect-loop-manip.c:1798

0xaadea1 vectorize_loops()

$SOURCE/gcc/gcc/tree-vectorizer.c:123

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



FAIL: gcc.dg/vect/vect-outer-5.c (internal compiler error)



Compiler configured with:



Configured with: $SOURCE/gcc/configure --target=arm-none-eabi

--prefix=$SOURCE/build/install --with-gmp=$SOURCE/build/host-tools

--with-mpfr=$SOURCE/build/host-tools --with-mpc=$SOURCE/build/host-tools

--with-pkgversion=unknown --disable-shared --disable-nls --disable-threads

--disable-tls --enable-checking=yes --enable-languages=c,c++,fortran

--with-newlib --with-fpu=neon-fp16 --with-float=hard --with-arch=armv7-a



ICE triggered for me with the command:

arm-none-eabi-gcc -fno-diagnostics-show-caret -ffast-math -ftree-vectorize

-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S vect-outer-5.i



caused by r196770.



I believe Richard already has a patch queued to fix this


[Bug target/56720] New: ICE when expanding vcond with floating point unordered comparisons

2013-03-25 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56720



 Bug #: 56720

   Summary: ICE when expanding vcond with floating point unordered

comparisons

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: ktkac...@gcc.gnu.org

ReportedBy: ktkac...@gcc.gnu.org

Target: arm-none-eabi





Created attachment 29720

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29720

ICEing testcase



Compiling the attached testcase with:

-O1 -funsafe-math-optimizations -ftree-vectorize -mfpu=neon -mfloat-abi=hard

causes an ICE on arm-none-eabi



vcond.c: In function 'foo':

vcond.c:7:10: internal compiler error: in expand_insn, at optabs.c:8274

 w[i] = MAX (0.0f, w2[i]);

  ^

0x82f9c5 expand_insn(insn_code, unsigned int, expand_operand*)

$SOURCE/gcc/gcc/optabs.c:8274

0x83430f expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,

rtx_def*)

$SOURCE/gcc/gcc/optabs.c:6777

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Looking at the vcond pattern in neon.md, the predicate for the

comparison operator (arm_comparison_operator) uses maybe_get_arm_condition_code

 which is not needed for vcond since we don't care about the ARM condition code

(we can handle all the comparison cases ourselves in the expander).



Changing the predicate to comparison_operator allows the expander to proceed

but it ICEs again because the pattern doesn't handle the floating point

unordered cases! (i.e. UNGT, UNORDERED, UNLE etc).



Adding support for the unordered cases is very similar to the aarch64 port

added here:

http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00957.html





The given testcase works for 4.6 and 4.7 but can be easily made to ICE by

changing

#define MAX(a, b) (a > b ? a : b)

to

#define UNORD(a, b) (__builtin_isunordered (a, b) ? a : b)

causing an ICE again because the code doesn't handle the unordered cases

properly.



I've got a patch to fix it for current trunk.


[Bug target/56720] ICE when expanding vcond with floating point unordered comparisons

2013-03-25 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56720



--- Comment #1 from ktkachov at gcc dot gnu.org 2013-03-25 12:23:25 UTC ---

Created attachment 29721

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29721

Patch to fix ICE on trunk



Patch fixing bug on trunk.



Will test to ensure it fixes the issue on 4.6, 4.7, 4.8



gcc/ChangeLog

2013-03-25  Kyrylo Tkachov  



* config/arm/iterators.md (v_cmp_result): New mode attribute.

* config/arm/neon.md (vcond): Handle unordered cases.





gcc/testsuite/ChangeLog

2013-03-25  Kyrylo Tkachov  



* gcc.target/arm/neon-vcond-gt.c: New test.

* gcc.target/arm/neon-vcond-ltgt.c: Likewise.

* gcc.target/arm/neon-vcond-unordered.c: Likewise.


[Bug regression/56738] New: ICE in c-c++-common/torture/vshuf-v4di.c

2013-03-26 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738



 Bug #: 56738

   Summary: ICE in c-c++-common/torture/vshuf-v4di.c

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: regression

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ktkac...@gcc.gnu.org

CC: stevenb@gmail.com

Target: arm-none-eabi





Created attachment 29729

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29729

Preprocessed file



Testcase ICEs on arm-none-eabi when compiled with -O1 (ICEs also with -O2 and

-O3)



In file included from vshuf-v4di.c:19:0:

vshuf-main.inc: In function 'main':

vshuf-main.inc:26:1: internal compiler error: in df_insn_delete, at

df-scan.c:1162

 }

 ^

0x634b9c df_insn_delete(rtx_def*)

$SOURCE/gcc/gcc/df-scan.c:1162

0x68b98a remove_insn(rtx_def*)

$SOURCE/gcc/gcc/emit-rtl.c:4036

0x5f83be delete_insn(rtx_def*)

$SOURCE/gcc/gcc/cfgrtl.c:167

0xd335b6 resolve_simple_move

$SOURCE/gcc/gcc/lower-subreg.c:1072

0xd338b3 resolve_simple_move

$SOURCE/gcc/gcc/lower-subreg.c:923

0xd34a13 decompose_multiword_subregs

$SOURCE/gcc/gcc/lower-subreg.c:1563

0xd3528d rest_of_handle_lower_subreg2

$SOURCE/gcc/gcc/lower-subreg.c:1682

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.





Bisection shows it started with r196977



Cross compiler configured with:

Target: arm-none-eabi

Configured with: $SOURCE/gcc/configure --target=arm-none-eabi

--prefix=$SOURCE/build/install --with-gmp=$SOURCE/build/host-tools

--with-mpfr=$SOURCE/build/host-tools --with-mpc=$SOURCE/build/host-tools

--with-pkgversion=unknown --disable-shared --disable-nls --disable-threads

--disable-tls --enable-checking=yes --enable-languages=c --with-newlib

--with-fpu=neon --with-float=hard --with-arch=armv7-a

Thread model: single

gcc version 4.9.0 20130322 (experimental) (unknown)


[Bug regression/56738] ICE in c-c++-common/torture/vshuf-v4di.c

2013-03-26 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0


[Bug regression/56738] ICE in c-c++-common/torture/vshuf-v4di.c

2013-03-26 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-03-26 12:07:07 UTC ---

(In reply to comment #1)

> I see a similar error on powerpc-*-* (see

> http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02572.html ) for

> c-c++-common/torture/vshuf-v2di.c and g++.dg/torture/vshuf-v2di.C.

> 

> Should I fill a new PR or extend this one to vshuf-v2di.c?



Are you seeing the ICE at the same location? (df-scan.c).

Also, from the testresults page you linked I don't see an ICE for -O2 or -O3.

Do those run successfully?



If you believe they are the same error I think you can add powerpc

to the targets in this PR.



Regards,

Kyrill


[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete

2013-03-26 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 CC||ktkachov at gcc dot gnu.org



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-03-26 14:58:07 UTC ---

PR 56738 possible related? Similar ICE on arm-none-eabi



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738


[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-02 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-02 09:43:57 UTC ---

Similar problem on aarch64-none-elf. The testcase produces this ICE with

aarch64-none-elf-gcc ice.c -S





ice.c:28:1: internal compiler error: in aarch64_output_casesi, at

config/aarch64/aarch64.c:4098

 }

 ^

0xb171fe aarch64_output_casesi(rtx_def**)

$SOURCE/gcc/gcc/config/aarch64/aarch64.c:4098

0x6b9579 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)

$SOURCE/gcc/gcc/final.c:2854

0x6b9faf final(rtx_def*, _IO_FILE*, int)

$SOURCE/gcc/gcc/final.c:1958

0x6ba1d9 rest_of_handle_final

$SOURCE/gcc/gcc/final.c:4333

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See <http://gcc.gnu.org/bugs.html> for instructions.


[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-02 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Target|arm-none-eabi,  |arm-none-eabi,

   |aarch64-none-elf|aarch64-none-elf,

   ||arm-none-linux-gnueabihf,

   ||arm-none-linux-gnueabi



--- Comment #3 from ktkachov at gcc dot gnu.org 2013-04-02 11:05:00 UTC ---

Also, r197266 causes arm-none-linux-gnueabi targets to fail building glibc

with:



/tmp/ccJoCcvx.s: Assembler messages:

/tmp/ccJoCcvx.s:79: Error: bad immediate value for offset (4228)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfwscanf.o] Error 1

make[2]: *** Waiting for unfinished jobs

/tmp/ccRTqSyv.s: Assembler messages:

/tmp/ccRTqSyv.s:47: Error: bad immediate value for offset (4556)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfscanf.o] Error 1

/tmp/ccxxOo62.s: Assembler messages:

/tmp/ccxxOo62.s:72: Error: bad immediate value for offset (4244)

/tmp/ccxxOo62.s:88: Error: bad immediate value for offset (4208)

/tmp/ccxxOo62.s:95: Error: bad immediate value for offset (4196)

/tmp/ccxxOo62.s:127: Error: bad immediate value for offset (4228)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfwscanf.os] Error 1

/tmp/ccuTrEWO.s: Assembler messages:

/tmp/ccuTrEWO.s:57: Error: bad immediate value for offset (4136)

/tmp/ccuTrEWO.s:79: Error: bad immediate value for offset (4104)

make[2]: *** [$SOURCE/build-linux/obj/glibc/stdio-common/vfscanf.os] Error 1

make[2]: Leaving directory `$SOURCE/glibc/libc/stdio-common'

make[1]: *** [stdio-common/subdir_lib] Error 2

make[1]: Leaving directory `$SOURCE/glibc/libc'

make: *** [all] Error 2

make: Leaving directory `$SOURCE/build-linux/obj/glibc


[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-03 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|WAITING |UNCONFIRMED

   Last reconfirmed|2013-04-03 00:00:00 |2013-04-02 0:00

 Ever Confirmed|1   |0



--- Comment #5 from ktkachov at gcc dot gnu.org 2013-04-03 11:25:41 UTC ---

(In reply to comment #4)

> Does this still happen with r197307 or later?



Yes, it still happens as of r197390.


[Bug middle-end/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-03 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |UNCONFIRMED

   Last reconfirmed|2013-04-03 00:00:00 |2013-04-02 0:00

  Component|target  |middle-end

 Ever Confirmed|1   |0



--- Comment #7 from ktkachov at gcc dot gnu.org 2013-04-03 12:51:10 UTC ---

Thanks, that seems to fix the problem.



Now testing a patch...


[Bug target/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-03 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed|2013-04-02 00:00:00 |2013-04-03

  Component|middle-end  |target

 Ever Confirmed|0   |1


[Bug target/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-03 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



--- Comment #9 from ktkachov at gcc dot gnu.org 2013-04-03 16:42:18 UTC ---

r197425 for arm



2013-04-03  Kyrylo Tkachov  



PR target/56809

* config/arm/arm.c (is_jump_table): Use next_active_insn instead of

next_real_insn.

(thumb1_output_casesi): Likewise.

(thumb2_output_casesi): Likewise.



* gcc.dg/pr56809.c: New testcase.



and



r197434 for aarch64



2013-04-03  Kyrylo Tkachov  



PR target/56809

* config/aarch64/aarch64.c (is_jump_table): Use next_active_insn

instead of next_real_insn.



should fix it.


[Bug target/56809] [4.9 Regression] Revision 197266 causes trunk ICE for arm-none-eabi targets

2013-04-03 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from ktkachov at gcc dot gnu.org 2013-04-03 16:42:44 UTC ---

Fixed on trunk.


[Bug target/56720] ICE when expanding vcond with floating point unordered comparisons

2013-04-09 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56720



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-09 13:43:50 UTC ---

Fixed on trunk and 4.8



Doesn't seem to significantly affect users of earlier release branches

to justify the risk of backporting the fix.


[Bug middle-end/56916] New: ICE when building libgfortran for arm-none-eabi

2013-04-11 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56916



 Bug #: 56916

   Summary: ICE when building libgfortran for arm-none-eabi

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ktkac...@gcc.gnu.org

CC: rguent...@suse.de

Target: arm-none-eabi





With r197671 gcc ICEs while building libgfortran



$SOURCE/gcc/libgfortran/generated/matmul_i8.c: In function 'matmul_i8':

$SOURCE/gcc/libgfortran/generated/matmul_i8.c:374:1: internal compiler error:

Segmentation fault

 }

 ^

0x8f1a85 crash_signal

0x8a1c88 rtx_cost(rtx_def*, rtx_code, int, bool)

$SOURCE/gcc/gcc/rtlanal.c:3805

0xd4220d set_src_cost

$SOURCE/gcc/gcc/rtl.h:1368

0xd4220d doloop_optimize

$SOURCE/gcc/gcc/loop-doloop.c:662

0xd4220d doloop_optimize_loops()

$SOURCE/gcc/gcc/loop-doloop.c:764

0x7e3b37 rtl_doloop

$SOURCE/gcc/gcc/loop-init.c:543

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Weirdly, when I execute the ICEing command on itself it ICEs, but when I add

-save-temps it doesn't and the resulting .i file compiles without error



$SOURCE/build/obj/gcc2/./gcc/xgcc -B$SOURCE/build/obj/gcc2/./gcc/

-B$SOURCE/build/install/arm-none-eabi/bin/

-B$SOURCE/build/install/arm-none-eabi/lib/ -isystem

$SOURCE/build/install/arm-none-eabi/include -isystem

$SOURCE/build/install/arm-none-eabi/sys-include -DHAVE_CONFIG_H -I.

-I$SOURCE/gcc/libgfortran -iquote$SOURCE/gcc/libgfortran/io

-I$SOURCE/gcc/libgfortran/../gcc -I$SOURCE/gcc/libgfortran/../gcc/config

-I../.././gcc -I$SOURCE/gcc/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall

-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra

-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections

-ftree-vectorize -funroll-loops -O2 -g -MT matmul_i8.lo -MD -MP -MF

.deps/matmul_i8.Tpo -c $SOURCE/gcc/libgfortran/generated/matmul_i8.c -o

matmul_i8.o





Cross compiler configuration:

--with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a

--with-language=c,c++,fortran


[Bug middle-end/56916] ICE when building libgfortran for arm-none-eabi

2013-04-11 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56916



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

  Known to fail||4.9.0


[Bug middle-end/56916] ICE when building libgfortran for arm-none-eabi

2013-04-11 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56916



--- Comment #1 from ktkachov at gcc dot gnu.org 2013-04-11 11:34:56 UTC ---

Created attachment 29856

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29856

Reduced testcase



ICEs with:

-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes

-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules

-ffunction-sections -fdata-sections -ftree-vectorize -funroll-loops -O2 -g



This is as much as I could reduce the testcase


[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC

2013-04-15 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921



--- Comment #12 from ktkachov at gcc dot gnu.org 2013-04-15 15:26:10 UTC ---

(In reply to comment #11)

> Created attachment 29877 [details]

> patch papering over the issue with TODO_do_not_ggc_collect

> 

> Patch papering over (restoring non-GC collect) attached.  Not exactly the

> best solution as garbage is then again not collected during the in some

> cases memory expensive passes.



Fixes ICE while building libgfortran for arm-*-*.

Also, no regressions on arm-none-eabi tested with qemu.


[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

2013-04-16 Thread ktkachov at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979



ktkachov at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-16

 CC||ktkachov at gcc dot gnu.org

  Known to work||4.6.4

 Ever Confirmed|0   |1

  Known to fail||4.7.3, 4.8.0, 4.9.0



--- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-16 13:13:42 UTC ---

Reproduced on arm-none-eabi with trunk, 4.8, 4.7.

4.6 does not ICE.


[Bug debug/57351] New: ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

Bug ID: 57351
   Summary: ICE: internal compiler error: in dbx_reg_number, at
dwarf2out.c:10507 on arm-none-eabi
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: christian.bruel at st dot com
Target: arm-none-eabi

Created attachment 30152
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30152&action=edit
Preprocessed testcase

Building newlib for arm-none-eabi fails after r199132

2013-05-21  Christian Bruel  

* dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for
spanning registers. LEAF_REG_REMAP is supported only for contiguous
registers. Set register size out of the PARALLEL loop.


with an ICE:
$SRC/binutils/newlib/libc/stdlib/dtoa.c:862:1: internal compiler error: in
dbx_reg_number, at dwarf2out.c:10507
 }
 ^
0x659a6e dbx_reg_number
$SRC/gcc/gcc/dwarf2out.c:10507
0x6dc41c rest_of_handle_final
$SRC/gcc/gcc/final.c:4393
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

I encounter the same ICE when trying to build libgfortran on arm-none-eabi. The
attached testcase is reduced from there.

I reproduced the ICE with flags -std=c99 -O2 -g on the testcase
My cross compiler is configured with --with-fpu=neon-vfpv4 --with-float=hard
--with-arch=armv7-a

Thanks,
Kyrill


[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

--- Comment #4 from ktkachov at gcc dot gnu.org ---
hmmm...
now I'm getting a different ICE:
internal compiler error: in arm_dbx_register_number, at config/arm/arm.c:25834

a gcc_unreachable () is reached.

If I print out the regno argument to arm_dbx_register_number, it's 272 which
seem to me like it could be reg number in DWARF numbering?


[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to chrbr from comment #5)
> > If I print out the regno argument to arm_dbx_register_number, it's 272 which
> > seem to me like it could be reg number in DWARF numbering?
> 
> yes it is. strange, I can't see this new failure, with a full newlib build
> for 
> 
>   --enable-languages=c,c++ \
>   --with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a 
> 
> could you please attach the preprocessed file ? thanks,

My apologies, the attachment I added in the bug report is reduced from newlib
(I initially said it was from libgfortran).

I'm getting the ICE in arm_dbx_register_number on the initial file I attached.

On a side note, in your patch you say:
-  t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)),
+  reg = REGNO (XVECEXP (regs, 0, i));
+  t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg),

but reg is undeclared in this scope (changing it to "unsigned reg = ..." fixes
it)
which suggests to me there's some other changes?
In your original patch you also moved the #ifdef LEAF_REG_MAP and associated
definitions inside the "if (regs == NULL_RTX)" block...

[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to chrbr from comment #7)

> thanks for catching it.

No problem, thanks for fixing :)


[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to chrbr from comment #9)
> no, in fact, you confused me. The patch was committed correctly :-)
>  
> > On a side note, in your patch you say:
> > -  t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)),
> > +  reg = REGNO (XVECEXP (regs, 0, i));
> > +  t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg),
> > 
> > but reg is undeclared in this scope (changing it to "unsigned reg = ..."
> > fixes it)
> > which suggests to me there's some other changes?
> > In your original patch you also moved the #ifdef LEAF_REG_MAP and associated
> > definitions inside the "if (regs == NULL_RTX)" block...
> 
> are you sure you have the good version of this file ? you should have
> 
> t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)),
> 
> so reg is not needed and doesn't need to be initialized. reg is set/used
> only in the "/* Simple, contiguous registers.  */ part.
> 
> The original failing attachment now passes with the "ARM" patch. Will post
> after checking with the testsuite

In that post (comment 6) I was citing the patch you attached to this report,
which says:

-  t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)),
+  reg = REGNO (XVECEXP (regs, 0, i));
+  t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg),

which doesn't apply to trunk cleanly because the trunk version was:
  t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)),

like you said. Presumably that attached part should have been applied instead
of your original patch?

In any case, from what I understand you reproduced the arm.c ICE and confirmed
that it's fixed with your (under test) ARM patch?

Thanks,
Kyrill


In any case, if you have


[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

--- Comment #11 from ktkachov at gcc dot gnu.org ---
> In any case, if you have

Err... stray line. Ignor that.


[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi

2013-05-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351

--- Comment #15 from ktkachov at gcc dot gnu.org ---
(In reply to chrbr from comment #14)
> > In that post (comment 6) I was citing the patch you attached to this report,
> > which says:
> > 
> 
> OK that's clear. Wrong attachment 
> 
> > like you said. Presumably that attached part should have been applied
> > instead of your original patch?
> 
> no, applied patch was OK as approved.
> 
> > 
> > In any case, from what I understand you reproduced the arm.c ICE and
> > confirmed that it's fixed with your (under test) ARM patch?
>  
> yes, correct. Reproduced and fixed with the ARM patch posted in comment #13

Cool, that patch fixes it for me as well. A build with newlib and fortran
enabled succeeded. Running tests as well.

Thanks,
Kyrill


[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness

2013-05-29 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to jules from comment #9)
> This appears to have regressed on mainline. I now get the following assembly
> output for the test case added by Maxim:
> 
> longfunc:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> stmfd   sp!, {r4, r5}
> umull   r4, r5, r0, r2
> mul r3, r0, r3
> mla r1, r2, r1, r3
> mov r0, r4
> add r1, r1, r5
> ldmfd   sp!, {r4, r5}
> bx  lr

Current trunk (r199375) gives, I think this can be closed.

longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mul r3, r0, r3
mla r3, r2, r1, r3
umull   r0, r1, r0, r2
add r1, r3, r1
bx  lr


[Bug regression/57473] New: FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)

2013-05-30 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473

Bug ID: 57473
   Summary: FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: jh at suse dot cz
Target: arm-none-eabi

With r199422 gcc.dg/tls/emutls-2.c started ICEing with:

$SOURCE/gcc/testsuite/gcc.dg/tls/emutls-2.c: In function
'_GLOBAL__sub_I_65535_0_emutls_2.c':
$SOURCE/gcc/testsuite/gcc.dg/tls/emutls-2.c:8:1: internal compiler error:
Segmentation fault
0x916255 crash_signal
   $SOURCE/gcc/toplev.c:333
0x6575b6 dom_info_available_p(cdi_direction)
$SOURCE/gcc/dominance.c:1482
0x657fd3 free_dominance_info(cdi_direction)
$SOURCE/gcc/dominance.c:685
0x86d429 do_per_function
$SOURCE/gcc/passes.c:1719
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1

on arm-none-eabi.

Cross compiler configured with:
--with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a


[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)

2013-06-03 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Hans-Peter Nilsson from comment #4)
> Seems to have been fixed with the "Symtab cleanups 2/17 - merge alias code"
> fix (r199577) or possibly with the same fix as for PR57467 (r199582).

Fixed on arm-none-eabi it seems.
Dominique, can you confirm that x86_64-apple-darwin10 is fixed as well?


[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)

2013-06-04 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.0   |---

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.


[Bug target/57637] New: Miscompare on 178.galgel in SPEC2000 on arm

2013-06-17 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

Bug ID: 57637
   Summary: Miscompare on 178.galgel in SPEC2000 on arm
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: bernds at codesourcery dot com, zhenqiang.chen at linaro 
dot org
Target: armv7l-unknown-linux-gnueabihf

We're getting a miscompare on the 178.galgel benchmark in SPEC2000 on
armv7l-unknown-linux-gnueabihf, on a Cortex-A15.
The .mis file just says 'galgel.out' short.

Bisection shows it started with r199439.

2013-05-30 Bernd Schmidt 
Zhenqiang Chen 

config/arm/arm-protos.h: Add and update function protos.
config/arm/arm.c (use_simple_return_p): New added.
(thumb2_expand_return): Check simple_return flag.
config/arm/arm.md: Add simple_return and conditional simple_return.
config/arm/iterators.md: Add iterator for return and simple_return.


The compiler was configured: "--with-cpu=cortex-a15 --with-fpu=neon-vfpv4
--with-mode=thumb --with-float=hard --enable-languages=c,c++,fortran"

The flags for the benchmark are -ffixed-form -mthumb -mcpu=cortex-a15
-mfpu=neon-vfpv4 -mfloat-abi=hard -O3.
It works with -O1, fails at -O2 and -O3


[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm

2013-06-18 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Thanks, Zhenqiang.

For me, it's a segfault in function DGETF2. gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0001d964 in dgetf2_ ()
(gdb) bt
#0  0x0001d964 in dgetf2_ ()
#1  0x000255a4 in dgetrf_ ()
#2  0x00015856 in sysnsl_ ()
#3  0x0001194e in MAIN__ () at galgel.f90:9


Looking further into it, the segfault seems to be from the function idamax that
is inlined in dgetf2.

Hope this helps,
Kyrill


[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm

2013-06-21 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

--- Comment #5 from ktkachov at gcc dot gnu.org ---

> Please try the attached patch. If it works, I will send it for community
> review.

Hi Zhenqiang,

This seems to fix the miscompare on my setup, thanks!
I haven't ran a full regression test on it though, but it seems reasonable at
first glance.

Kyrill


[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm

2013-06-26 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to zhenqiang.chen from comment #7)
> Created attachment 30364 [details]
> update patch
> 
> 
> Please try the updated patch. Local tests: x86-64 and pandaboard bootstrap

This fixes the segfault in SPEC on arm for me.

Is there a way to produce a testsuite testcase for this regression? The
benchmark where this occurs is a large chunk of Fortran, not sure how easy it
is to reduce it.


[Bug c/57727] RaspberryPi gcc internal compiler error unrecognisable insn

2013-06-26 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Reproduced with GCC 4.6.4.
However, this is fixed on all currently maintained versions of GCC, it worked
for me with 4.7.4, 4.8.1 and current trunk (4.9).

GCC 4.6 is not maintained anymore, please use a more recent release if you can.


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-06-27 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed with 4.8.1
Works with 4.7 and current trunk 4.9 though.

Fails for -mcpu=xscale , iwmmxt and iwmmxt2

Trying to reduce...


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-06-28 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 30406
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30406&action=edit
Reduced testcase

Reduced testcase, compile with -march=armv5te -marm  -mtune=xscale
-mfloat-abi=soft  -O1


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-06-28 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-28
 Ever confirmed|0   |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Thus confirmed.


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-07-01 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Mikael Pettersson from comment #4)
> The ICE on the reduced test case started with r186147 and stopped with
> r199188.
> They both touch the same code so I believe r199188 is a proper fix and not
> just coincidental.  Backporting r199188 to current 4.8 branch fixes the ICE
> there too,
> but I haven't done a full bootstrap and regression test run on anything
> except x86_64 yet.
> 
> r199188 did cause a regression (ICE on s390x), but the fix for that has
> already been backported to 4.8 branch (at r199813).

Thanks for investigating. I'll run a bootstrap on arm with the backported
patch.


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-07-01 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Mikael Pettersson from comment #4)
> The ICE on the reduced test case started with r186147 and stopped with
> r199188.
> They both touch the same code so I believe r199188 is a proper fix and not
> just coincidental.  Backporting r199188 to current 4.8 branch fixes the ICE
> there too,
> but I haven't done a full bootstrap and regression test run on anything
> except x86_64 yet.
> 
> r199188 did cause a regression (ICE on s390x), but the fix for that has
> already been backported to 4.8 branch (at r199813).

After looking at it more closely: Mikael, are you sure the revisions are right?
It seems to me that r199813 is just the backport of r199188.

Can you please double-check the revision that fixes this current ICE?

Thanks,
Kyrill


[Bug rtl-optimization/57637] [4.9 regression] Miscompare on 178.galgel in SPEC2000 on arm

2013-07-30 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0


[Bug rtl-optimization/57637] [4.9 regression] Miscompare on 178.galgel in SPEC2000 on arm

2013-07-30 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
I can confirm as of r201326:

2013-07-30  Zhenqiang Chen  

PR rtl-optimization/57637
* function.c (move_insn_for_shrink_wrap): Also check the
GEN set of the LIVE problem for the liveness analysis
if it exists, otherwise give up.

the segfault is gone.

Thanks,
Kyrill


[Bug regression/58084] New: FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

2013-08-05 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084

Bug ID: 58084
   Summary: FAIL: gcc.dg/torture/pr8081.c  -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (internal
compiler error)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

New ICE in the testsuite when targeting arm-none-eabi:

FAIL: gcc.dg/torture/pr8081.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: gcc.dg/torture/pr8081.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/pr8081.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
FAIL: gcc.dg/torture/pr8081.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
WARNING: gcc.dg/torture/pr8081.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  compilation failed to produce executable

example output:

Executing on host: $ROOT/build/obj/gcc2/gcc/xgcc -B$ROOT/build/obj/gcc2/gcc/
$ROOT/gcc/gcc/testsuite/gcc.dg/torture/pr8081.c gcc_tg.o 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -flto
-fno-use-linker-plugin -flto-partition=none   -specs=rdimon.specs -Wa,-m
no-warn-deprecated  -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main
-Wl,-wrap,abort -lm   -o ./pr8081.exe(timeout = 300)
$ROOT/gcc/gcc/testsuite/gcc.dg/torture/pr8081.c: In function 'retframe_block':
$ROOT/gcc/gcc/testsuite/gcc.dg/torture/pr8081.c:15:3: error: invalid conversion
in return statement
struct block

struct block

# VUSE <.MEM_6>
return ;
$ROOT/gcc/gcc/testsuite/gcc.dg/torture/pr8081.c:15:3: internal compiler error:
verify_gimple failed
0x89d91d verify_gimple_in_cfg(function*)
$ROOT/gcc/gcc/tree-cfg.c:4807
0x7c1bf2 execute_function_todo
$ROOT/gcc/gcc/passes.c:1627
0x7c4d6d execute_todo
$ROOT/gcc/gcc/passes.c:1660
0x7c6e89 execute_one_ipa_transform_pass
$ROOT/gcc/gcc/passes.c:1843
0x7c6e89 execute_all_ipa_transforms()
$ROOT/gcc/gcc/passes.c:1873
0x574348 expand_function
$ROOT/gcc/gcc/cgraphunit.c:1601
0x575150 expand_all_functions
$ROOT/gcc/gcc/cgraphunit.c:1712
0x575150 compile()
$ROOT/gcc/gcc/cgraphunit.c:2049
0x4f9126 lto_main()
$ROOT/gcc/gcc/lto/lto.c:3872
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: $ROOT/build/obj/gcc2/gcc/xgcc returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status
compiler exited with status 1


Bisection shows it started with r201468:

2013-08-02  Jan Hubicka  

* lto-cgraph.c (compute_ltrans_boundary): Add abstract origins into
boundaries.
* lto-streamer-out.c (tree_is_indexable): Results decls and
parm decls are not indexable.
(DFS_write_tree_body): Do not follow args and results.
(hash_tree): Likewise.
(output_functions): Rearrange so struct function is needed
only when real body is output; be able to also ouptut abstract
functions; output DECL_ARGUMENTS and DECL_RESULT.
(lto_output): When not in WPA, ale store abstract functions.
(write_symbol): Do not care about RESULT_DECL.
(output_symbol_p): Handle correctly sbtract decls.
* lto-streamer-in.c (input_function): Rearrange so struct
function can be NULL at entry; allow streaming of
functions w/o body; store DECL_ARGUMENTS and DECL_RESULT.
* ipa.c (symtab_remove_unreachable_nodes): Silence confused
sanity check during LTO.
* tree-streamer-out.c (write_ts_decl_non_common_tree_pointers): Skip
RESULT_DECl and DECL_ARGUMENTS.
* tree-streamer-in.c (lto_input_ts_decl_non_common_tree_pointers):
Likewise.


[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

2013-08-05 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||lto
 CC||jh at suse dot cz
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0


[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

2013-08-05 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm-none-eabi

--- Comment #1 from ktkachov at gcc dot gnu.org ---
In case it's needed, compiler configured for arm-none-eabi:

--with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-08-05 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||i686-pc-linux-gnu,
   ||arm-none-eabi
 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
FWIW, also segfaults on arm-none-eabi.

gdb says:

fold_binary_loc (loc=787, code=BIT_AND_EXPR, type=0x76eba5e8,
op0=0x77052488, op1=0x76de6280)


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-08-06 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
> Another testcases:
> 
> int
> bar (int i)
> {
>   return 1 | ((i * 2) & 254);
> }
> 
> int
> foo (int i)
> {
>   return 1 | ((i * 2) & 255);
> }

This happens for any value of the RHS of the AND that is >= 128.
A stack overflow occurs because fold_binary_loc keeps getting called, but op1,
which is supposed to be the result of maksing the RHS with the NOT of the 2 in
(i * 2) is set to something else.
Now investigating...


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-08-06 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Mine.


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-08-07 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Proposed patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00361.html


[Bug middle-end/58106] New: ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

2013-08-08 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58106

Bug ID: 58106
   Summary: ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

Created attachment 30625
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30625&action=edit
Reduced testcase

Given the attached testcase, gcc ICEs with:

besttry.c:45:1: internal compiler error: in ipa_edge_duplication_hook, at
ipa-prop.c:2839
 }
 ^
0x61b31b cgraph_call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
$TOP/gcc/gcc/cgraph.c:438
0xd7f357 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
$TOP/gcc/gcc/ipa-inline-transform.c:178
0xd7e9b8 recursive_inlining
$TOP/gcc/gcc/ipa-inline.c:1320
0xd7e9b8 inline_small_functions
$TOP/gcc/gcc/ipa-inline.c:1571
0xd7ed3d ipa_inline
$TOP/gcc/gcc/ipa-inline.c:1796
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


Bisection shows it started with r200368:

2013-06-24  Martin Jambor  

PR tree-optimization/57539
* cgraphclones.c (cgraph_clone_node): Add parameter new_inlined_to, set
global.inlined_to of the new node to it.  All callers changed.
* ipa-inline-transform.c (clone_inlined_nodes): New variable
inlining_into, pass it to cgraph_clone_node.
* ipa-prop.c (ipa_propagate_indirect_call_infos): Do not call
ipa_free_edge_args_substructures.
(ipa_edge_duplication_hook): Only add edges from inlined nodes to
rdesc linked list.  Do not assert rdesc edges have inlined caller.
Assert we have found an rdesc in the rdesc list.

compiled with gcc -O3.

Thanks to James Greenhalgh for spotting this.
Seems like fallout or an incomplete fix for PR57539


[Bug middle-end/58106] ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

2013-08-08 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58106

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-09-09 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Sep  9 13:11:45 2013
New Revision: 202397

URL: http://gcc.gnu.org/viewcvs?rev=202397&root=gcc&view=rev
Log:
[gcc/]
2013-09-09  Kyrylo Tkachov  

PR target/57735
Backport from mainline
2013-04-30  Richard Sandiford  

* explow.c (plus_constant): Pass "mode" to immed_double_int_const.
Use gen_int_mode rather than GEN_INT.

[gcc/testsuite]
2013-09-09  Kyrylo Tkachov  

PR target/57735
* g++.dg/ext/pr57735.C: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/pr57735.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/explow.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-09-09 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Sep  9 13:16:44 2013
New Revision: 202398

URL: http://gcc.gnu.org/viewcvs?rev=202398&root=gcc&view=rev
Log:
2013-09-09  Kyrylo Tkachov  

PR target/57735
* g++.dg/ext/pr57735.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr57735.C
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit

2013-09-09 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Fixed in 4.8 branch. Testcase added in trunk.


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-09-17 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Sep 17 13:29:41 2013
New Revision: 202652

URL: http://gcc.gnu.org/viewcvs?rev=202652&root=gcc&view=rev
Log:
[gcc/]
2013-09-17  Kyrylo Tkachov  

PR tree-optimization/58088
* fold-const.c (mask_with_trailing_zeros): New function.
(fold_binary_loc): Make sure we don't recurse infinitely
when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2.
Use mask_with_trailing_zeros where appropriate.

[gcc/testsuite]
2013-09-17  Kyrylo Tkachov  

PR tree-optimization/58088
* gcc.c-torture/compile/pr58088.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr58088.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-09-17 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Fixed on trunk and 4.8 branch.


[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

2013-09-17 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Sep 17 13:59:42 2013
New Revision: 202653

URL: http://gcc.gnu.org/viewcvs?rev=202653&root=gcc&view=rev
Log:
[gcc/]
2013-09-17  Kyrylo Tkachov  

PR tree-optimization/58088
* fold-const.c (mask_with_trailing_zeros): New function.
(fold_binary_loc): Make sure we don't recurse infinitely
when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2.
Use mask_with_trailing_zeros where appropriate.

[gcc/testsuite/]
2013-09-17  Kyrylo Tkachov  

PR tree-optimization/58088
* gcc.c-torture/compile/pr58088.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr58088.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug tree-optimization/58556] [4.9 Regression] gen-vect-26.c / gen-vect-28.c regression merging from r202839 to r202981

2013-09-30 Thread ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58556

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arc-elf32   |arc-elf32, arm-none-eabi
 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Also appears on arm.


  1   2   3   4   5   6   7   8   9   10   >