[Bug boehm-gc/52217] [boehm-gc] revision 184100 causes segmentation fault in mingw32

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52217

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
No feedback in almost 3 years so not expecting any time soon so closing.

[Bug target/58446] Support for musl libc

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #18 from Andrew Pinski  ---
Fixed.

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

2016-08-04 Thread vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847

--- Comment #23 from Vladimir Makarov  ---
(In reply to mwahab from comment #22)
> I believe that this patch is the cause of compilation failures for a number
> of tests on arm-none-linux-gnueabihf and arm-none-eabi.
> 
> E.g. arm-none-linux-gnueabihf-gcc -S testsuite/gcc.dg/torture/vshuf-v64qi.c
> -O1
> results in an ICE with
> 
> testsuite/gcc.dg/torture/vshuf-main.inc: In function ‘test_2’:
> testsuite/gcc.dg/torture/vshuf-main.inc:28:1: error: insn does not satisfy
> its constraints:
>  TESTS
>  ^
> (insn 606 607 589 2 (set (reg:QI 3 r3 [326])
> (reg:QI 31 s15)) testsuite/gcc.dg/torture/vshuf-main.inc:28 182
> {*arm_movqi_insn}
>  (expr_list:REG_EQUAL (const_int 13 [0xd])
> (nil)))
> testsuite/gcc.dg/torture/vshuf-main.inc:28:1: internal compiler error: in
> extract_constrain_insn, at recog.c:2211
> 0xaea3e8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
>   /work/src/gnutools/armdsg/src/gcc/gcc/rtl-error.c:108
> 0xaea40f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>   /work/src/gnutools/armdsg/src/gcc/gcc/rtl-error.c:119
> 0xabcf1d extract_constrain_insn(rtx_insn*)
>   /work/src/gnutools/armdsg/src/gcc/gcc/recog.c:2211
> 0x9d76af check_rtl
>   /work/src/gnutools/armdsg/src/gcc/gcc/lra.c:2108
> 0x9dbfa9 lra(_IO_FILE*)
>   /work/src/gnutools/armdsg/src/gcc/gcc/lra.c:2516
> 0x99106f do_reload
>   /work/src/gnutools/armdsg/src/gcc/gcc/ira.c:5384
> 0x99106f execute
>   /work/src/gnutools/armdsg/src/gcc/gcc/ira.c:5568
> 
> 
> The test compiles with trunk before the change.
> 
> Let me know if there's anything else I should check.

I tried to reproduce it on my arm board (armv7l-unknown-linux-gnueabihf) and
using cross-compiler arm-non-eabi without any success.

Could you provide a preprocessed source file with all *cc1* options for
arm-non-eabi.

Thank you.

[Bug middle-end/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69008

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end

--- Comment #4 from Andrew Pinski  ---
I know there are other bug reports about this exact same thing.  One for
PowerPC but I can't seem to find it.  I thought I had filed it but it looks
like someone else did.
>From what I remember Trivial is given BLKmode so it always go to the stack even
though the it is passed via two registers.

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68894

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization, TREE

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> I think this is fixed on the trunk now.

Or rather improved enough so PHI_OPT could do something about if needed:

  if (_6 < _7)
goto ;
  else
goto ;

  :
  _22 = MIN_EXPR <_6, pretmp_25>;
  goto ;

  :
  _28 = MIN_EXPR <_7, pretmp_25>;

  :
  # d_2 = PHI <_22(6), _28(7)>


Though we get:
.L12:
ldr w4, [x2, x8]
ldr w0, [x2, x6]
ldr w3, [x2, x7]
cmp w0, w4
cselw0, w0, w4, le
cmp w0, w3
cselw0, w0, w3, le
str w0, [x1, x2]
add x2, x2, 4
cmp x5, x2
bne .L12

From the assembly code which looks correct:


For aarch64 at -O3 we get:
.L18:
ldr q0, [x2, x7]
add w3, w3, 1
ldr q2, [x2, x5]
ldr q1, [x2, x6]
sminv0.4s, v0.4s, v2.4s
sminv0.4s, v0.4s, v1.4s
str q0, [x1, x2]
add x2, x2, 16
cmp w4, w3
bhi .L18



-O3 tree level:
  :
  # ivtmp.35_79 = PHI <0(13), ivtmp.35_78(14)>
  _42 = MEM[symbol: a1, index: ivtmp.35_79, offset: 0B];
  _43 = MEM[symbol: a2, index: ivtmp.35_79, offset: 0B];
  pretmp_44 = MEM[symbol: a3, index: ivtmp.35_79, offset: 0B];
  _45 = MIN_EXPR <_42, pretmp_44>;
  _46 = MIN_EXPR <_43, pretmp_44>;
  d_47 = _42 < _43 ? _45 : _46;
  MEM[base: c_12(D), index: ivtmp.35_79, offset: 0B] = d_47;
  ivtmp.35_78 = ivtmp.35_79 + 4;
  if (ivtmp.35_78 == _111)
goto ;
  else
goto ;

As you can see it does the right thing for the vectorized code.
Though in both cases it is not done at the tree level only at the RTL level.

[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault

2016-08-04 Thread kristian.spangsege at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191

Kristian Spangsege  changed:

   What|Removed |Added

 CC||kristian.spangsege at gmail 
dot co
   ||m

--- Comment #13 from Kristian Spangsege  
---
I've now run into this problem too, and it seems to be general, not just
limited to Ubuntu.

There is the code that I compile:

#include 
#include 
#include 

int main()
{
std::error_code ec(EDOM, std::system_category());
bool b = (ec == std::errc::argument_out_of_domain);
std::cout << b << "\n";
}

I expect it to write `1`, not `0`.

I get the expected result with Clang on OS X. I get the wrong result with

 - GCC 6.1.1 on Fedora 24, which links against libstdc++.so.6.0.22
 - GCC 5.4.0 on Linux Mint 18 (Ubuntu 14.04), which links against
libstdc++.so.6.0.21
 - GCC 4.9.3 on Linux Mint 17.1 (Ubuntu 16.04), which links against
libstdc++.so.6.0.22

It therefore seems to me that this is really a bug in libstdc++.

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68894

--- Comment #5 from Andrew Pinski  ---
I think this is fixed on the trunk now.

[Bug c++/68703] __attribute__((vector_size(N))) template member confusion

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-05
 Ever confirmed|0   |1
  Known to fail||6.1.0

--- Comment #2 from Andrew Pinski  ---
Confirmed.  The type of v should have been declared a dependent type but is
not.

[Bug middle-end/68762] link error for inline function decorated with OpenMP declare simd

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68762

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #3 from Andrew Pinski  ---
_ZGVbN2v__Z3food should have been in its own comdat section.

Note on aarch64-linux-gnu I don't hit this bug but that is because aarch64 does
not have a simd version of exp, cos or sin (we should be that a different
story).

[Bug c++/68103] Unnecessary copying due to order of evaluation with operator new

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68103

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||6.1.0

--- Comment #2 from Andrew Pinski  ---
This might have fixed on the trunk as there was a change recently dealing with
order of evaluation.

[Bug c++/68180] [ICE] at cp/constexpr.c:2768 in initializing __vector in a loop

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68180

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||easyhack, ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
t88.cc: In function ‘float32x4_t foo(float32x4_t)’:
t88.cc:10:33:   in constexpr expansion of ‘fill(1.0e+0f)’
t88.cc:10:37: internal compiler error: tree check: expected constructor, have
vector_cst in cxx_eval_store_expression, at cp/constexpr.c:3051
   constexpr float32x4_t v = fill(1.f);
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This should not be hard to fix.  Basically after:
ctx->values->get (object)

You convert VECTOR_CST back into a CONSTRUCTOR.  Then the rest will work.

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

2016-08-04 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802

--- Comment #4 from Segher Boessenkool  ---
When -mno-powerpc64, I see.  Thanks.  Yeah this needs some untangling.

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

2016-08-04 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802

--- Comment #3 from Alan Modra  ---
wY is using mem_operand_gpr which is designed for gpr loads/stores.  When -m32,
mem_operand_gpr does not enforce multiple-of-4 offsets.

[Bug target/71869] __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

2016-08-04 Thread meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Changes committed to both trunk and gcc-6-branch.

[Bug c++/72808] [6/7 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72808

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |6.2

[Bug c++/72808] New: [6/7 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72808

Bug ID: 72808
   Summary: [6/7 Regression] ICE on valid c++ code in verify_type
(gcc/tree.c:14047)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I've just isolated following snippet from Firefox master:

typedef int uint32_t;
class A
{
  virtual void m_fn1 ();
};
class B : A
{
  void m_fn1 ();
  enum TrackCommands : uint32_t;
};
enum B::TrackCommands : uint32_t
{
  TRACK_EVENT_UNUSED
};
void
B::m_fn1 ()
{
}

$ g++ reduced.ii -g
reduced.ii:18:1: error: type variant has different TYPE_FIELDS
 }
 ^
  constant 64>
unit size  constant 8>
align 64 symtab 1196241216 alias set -1 canonical type 0x7f274761b000
fields 
asm_written type_5 SI
size 
unit size 
align 32 symtab 1196241296 alias set -1 canonical type
0x7f274761b3f0 precision 32 min  max

values 
local bindings <(nil)>> value > context 
chain >
readonly constant private VOID file reduced.ii line 13 col 3
align 1 context  initial

chain 
ignored decl_6 BLK file reduced.ii line 6 col 7 size  unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain >> context

full-name "class B"
needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=0
pointer_to_this  chain >
reduced.ii:18:1: error: first mismatch is field
 
unit size 
align 64 symtab 1196241536 alias set -1 canonical type 0x7f2747612e70
fields 
unsigned virtual DI file reduced.ii line 2 col 7 size  unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain > context

full-name "class A"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  chain >
ignored decl_6 BLK file reduced.ii line 6 col 7 size  unit size 
align 64 offset_align 128 offset  bit offset
 context  chain
>
reduced.ii:18:1: error: and field
 
unit size 
align 32 symtab 1196240976 alias set -1 canonical type
0x7f27474ae7e0 precision 32 min  max
>
asm_written type_5 SI size  unit size

align 32 symtab 1196241296 alias set -1 canonical type 0x7f274761b3f0
precision 32 min  max 
values 
local bindings <(nil)>> value > context 
chain >
readonly constant private VOID file reduced.ii line 13 col 3
align 1 context  initial
 chain >
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7f274761b000
fields  unit
size 
align 64 symtab 1196241536 alias set -1 canonical type
0x7f2747612e70 fields  context

full-name "class A"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=0 interface-unknown
pointer_to_this  chain >
ignored decl_6 BLK file reduced.ii line 6 col 7 size  unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
nonlocal decl_4 VOID file reduced.ii line 7 col 1
align 1 context  result 
chain >> context

full-name "class B"
needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=0
chain >
reduced.ii:18:1: internal compiler error: verify_type failed
0x10543d2 verify_type(tree_node const*)
../../gcc/tree.c:14047
0xa3c4fc gen_type_die_with_usage
../../gcc/dwarf2out.c:22712
0xa3d8b6 gen_type_die
../../gcc/dwarf2out.c:22910
0xa355b9 gen_decl_die
../../gcc/dwarf2out.c:23502
0xa44048 gen_member_die
../../gcc/dwarf2out.c:22381
0xa44048 gen_struct_or_union_type_die
../../gcc/dwarf2out.c:22487
0xa45566 gen_tagged_type_die
../../gcc/dwarf2out.c:22690
0xa3cb8c gen_type_die_with_usage
../../gcc/dwarf2out.c:22855
0xa3d8b6 gen_type_die
../../gcc/dwarf2out.c:22910
0xa355b9 gen_decl_die
../../gcc/dwarf2out.c:23502
0xa35fbe dwarf2out_decl
../../gcc/dwarf2out.c:23962
0xa4da1b dwarf2out_type_decl
../../gcc/dwarf2out.c:23672
0xcd019f rest_of_type_compilation(tree_node*, int)
../../gcc/passes.c:333
0x8052a5 note_debug_info_needed(tree_node*)
../../gcc/cp/search.c:2365
0x762d3e maybe_emit_vtables
../../gcc/cp/decl2.c:2135
0x763a88 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4611

[Bug c++/66426] ICE: unexpected expression ‘int(Constructible())...’ of kind expr_pack_expansion

2016-08-04 Thread jamrial at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66426

James Almer  changed:

   What|Removed |Added

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

--- Comment #2 from James Almer  ---
Closing this as 4.9.4 was released and support for 4.9 has ended.

I did not check to see if the issue can still be reproduced with 4.9.4

[Bug c++/72806] Extra note/missing not location for __builtin_va_list

2016-08-04 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72806

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-04
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
The code here:

 if (alias_template_specialization_p (type))
error ("using alias template specialization %qT after %qs",
   type, tag_name (tag_code));
  else
error ("using typedef-name %qD after %qs", decl, tag_name (tag_code));
  inform (DECL_SOURCE_LOCATION (decl),
  "%qD has a previous declaration here", decl);

needs to check for DECL_IS_BUILTIN(decl) or something similar. Also, for
consistency, it would be better to say: "%q#D previously declared here".

Perhaps:

 inform (DECL_SOURCE_LOCATION (decl),
 DECL_IS_BUILTIN(decl) ? _G("%q#D is a built-in type")
   : _G("%q#D previously declared here"),
decl);

In theory, the diagnostics machinery should print

: note: message

if DECL_SOURCE_LOCATION (decl) == BUILTINS_LOCATION. I wonder if the location
is wrong (perhaps UNKNOWN_LOCATION?) or the C++ FE (unintentionally?) overrides
the default location prefix for built-in.

[Bug target/72805] AVX512: invalid code generation involving masks

2016-08-04 Thread wen...@mitsuba-renderer.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

--- Comment #6 from Wenzel Jakob  ---
awesome, thanks!

[Bug target/72805] AVX512: invalid code generation involving masks

2016-08-04 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
For the attached testcase patched gcc now generates:

vmovdqa64   %zmm0, %zmm1
vmovdqa64   -112(%rbp), %zmm0
movl$-1, %eax
kmovw   %eax, %k3
vpcmpd  $1, %zmm1, %zmm0, %k2{%k3}
kmovw   %k2, %eax
movzwl  %ax, %eax  < changed insn
addq$112, %rsp
popq%r10

Fixed for all active branches.

[Bug c++/70361] Obviously false code in if not detected

2016-08-04 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70361

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-04
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug target/72805] AVX512: invalid code generation involving masks

2016-08-04 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug  4 21:25:33 2016
New Revision: 239155

URL: https://gcc.gnu.org/viewcvs?rev=239155=gcc=rev
Log:
PR target/72805
* config/i386/avx512fintrin.h (_mm512_cmp_epi32_mask) [!__OPTIMIZE__]:
Cast builtin function result to __mmask16 instead of __mmask8.
(_mm512_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto.
(_mm512_mask_cmp_epi32_mask) [!__OPTIMIZE__]: Ditto.
(_mm512_mask_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/avx512fintrin.h

[Bug target/71869] __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

2016-08-04 Thread meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Thu Aug  4 21:25:05 2016
New Revision: 239154

URL: https://gcc.gnu.org/viewcvs?rev=239154=gcc=rev
Log:
[gcc]
2016-08-04  Michael Meissner  

Backport from trunk
2016-07-26  Michael Meissner  

PR target/71869
* config/rs6000/rs6000.c (rs6000_generate_compare): Rework
__float128 support when we don't have hardware support, so that
the IEEE built-in functions like isgreater, first call __unordkf3
to make sure neither operand is a NaN, and if both operands are
ordered, do the normal comparison.

[gcc/testsuite]
2016-08-04  Michael Meissner  

Backport from trunk
2016-07-26  Michael Meissner  

PR target/71869
* gcc.target/powerpc/float128-cmp.c: New test to make sure that
IEEE built-in functions handle quiet and signalling NaNs
correctly.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/float128-cmp.c
  - copied unchanged from r239143,
trunk/gcc/testsuite/gcc.target/powerpc/float128-cmp.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/72805] AVX512: invalid code generation involving masks

2016-08-04 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug  4 21:22:06 2016
New Revision: 239153

URL: https://gcc.gnu.org/viewcvs?rev=239153=gcc=rev
Log:
PR target/72805
* config/i386/avx512fintrin.h (_mm512_cmp_epi32_mask) [!__OPTIMIZE__]:
Cast builtin function result to __mmask16 instead of __mmask8.
(_mm512_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto.
(_mm512_mask_cmp_epi32_mask) [!__OPTIMIZE__]: Ditto.
(_mm512_mask_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/avx512fintrin.h

[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type

2016-08-04 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
What about committing a test case (if this isn't already covered)?

[Bug target/72807] [7 Regression] bootstrap broken on armhf-linux-gnuabihf

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

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 ---
I suspect it's fallout from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847

[Bug target/72805] AVX512: invalid code generation involving masks

2016-08-04 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug  4 21:14:39 2016
New Revision: 239152

URL: https://gcc.gnu.org/viewcvs?rev=239152=gcc=rev
Log:
PR target/72805
* config/i386/avx512fintrin.h (_mm512_cmp_epi32_mask) [!__OPTIMIZE__]:
Cast builtin function result to __mmask16 instead of __mmask8.
(_mm512_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto.
(_mm512_mask_cmp_epi32_mask) [!__OPTIMIZE__]: Ditto.
(_mm512_mask_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512fintrin.h

[Bug target/72807] New: [7 Regression] bootstrap broken on armhf-linux-gnuabihf

2016-08-04 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72807

Bug ID: 72807
   Summary: [7 Regression] bootstrap broken on
armhf-linux-gnuabihf
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

gnat r239146 fails to build on armhf-linux-gnuabihf, configured with

 --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --with-sysroot=/
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --enable-plugin
 --with-system-zlib
 --enable-objc-gc
 --enable-multiarch
 --enable-multilib
 --disable-sjlj-exceptions
 --with-arch=armv7-a
 --with-fpu=vfpv3-d16
 --with-float=hard
 --with-mode=thumb
 --disable-werror
 --enable-multilib
 --enable-checking=yes
 --build=arm-linux-gnueabihf
 --host=arm-linux-gnueabihf
 --target=arm-linux-gnueabihf

../../src/gcc/ada/debug_a.adb -o ada/debug_a.o
../../src/gcc/ada/csets.adb: In function 'Csets':
../../src/gcc/ada/csets.adb:1187:5: error: insn does not satisfy its
constraints:
(insn 8362 9127 7259 2 (set (reg:QI 2 r2 [5594])
(reg:QI 31 s15)) ../../src/gcc/ada/csets.adb:171 182 {*arm_movqi_insn}
 (expr_list:REG_EQUAL (const_int -59 [0xffc5])
(nil)))
+===GNAT BUG DETECTED==+
| 7.0.0 20160804 (experimental) [trunk revision 239146] (arm-linux-gnueabihf)
GCC error:|
| in extract_constrain_insn, at recog.c:2211   |
| Error detected around ../../src/gcc/ada/csets.adb:1187:5 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

../../src/gcc/ada/system.ads
../../src/gcc/ada/csets.adb
../../src/gcc/ada/csets.ads
../../src/gcc/ada/opt.ads
../../src/gcc/ada/hostparm.ads
../../src/gcc/ada/types.ads
../../src/gcc/ada/unchconv.ads
../../src/gcc/ada/unchdeal.ads
../../src/gcc/ada/s-string.ads
../../src/gcc/ada/ada.ads
../../src/gcc/ada/a-uncdea.ads
../../src/gcc/ada/s-wchcon.ads
../../src/gcc/ada/s-exctab.ads
../../src/gcc/ada/s-stalib.ads
../../src/gcc/ada/a-unccon.ads
../../src/gcc/ada/s-unstyp.ads
../../src/gcc/ada/s-conca2.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:406
../../src/gcc/ada/gcc-interface/Make-lang.in:119: recipe for target
'ada/csets.o' failed
make[5]: *** [ada/csets.o] Error 1

[Bug target/72805] AVX512: invalid code generation involving masks

2016-08-04 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-04
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Indeed, there are a couple of intrinsics in avx512fintrin.h defined under

#ifndef __OPTIMIZE__

with a wrong cast to (__mmask8) instead of (__mmask16), e.g.:

 #define _mm512_cmp_epi32_mask(X, Y, P) \
-  ((__mmask8) __builtin_ia32_cmpd512_mask ((__v16si)(__m512i)(X),  \
-  (__v16si)(__m512i)(Y), (int)(P),\
-  (__mmask16)-1))
+  ((__mmask16) __builtin_ia32_cmpd512_mask ((__v16si)(__m512i)(X), \
+   (__v16si)(__m512i)(Y), (int)(P), \
+   (__mmask16)-1))

I have an obvious patch.

[Bug middle-end/71078] x/abs(x) -> sign(1.0,x)

2016-08-04 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078

--- Comment #9 from prathamesh3492 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #8)
> On Thu, 4 Aug 2016, prathamesh3492 at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> > 
> > --- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
> > (In reply to prathamesh3492 from comment #6)
> > > (In reply to rguent...@suse.de from comment #5)
> > > > On Thu, 4 Aug 2016, mwahab at gcc dot gnu.org wrote:
> > > > 
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> > > > > 
> > > > > mwahab at gcc dot gnu.org changed:
> > > > > 
> > > > >What|Removed |Added
> > > > > 
> > > > >  CC||mwahab at gcc dot 
> > > > > gnu.org
> > > > > 
> > > > > --- Comment #4 from mwahab at gcc dot gnu.org ---
> > > > > (In reply to prathamesh3492 from comment #3)
> > > > > > Fixed.
> > > > > 
> > > > > The new test pr71078-1.c fails for arm and aarch64 because copysignl 
> > > > > isn't 
> > > > > generated for fabsl making the expected output fail to match.
> > > > 
> > > > Is that a non-C99 target?  If so add require-effective-target 
> > > > c99_runtime
> > > dg-require-effective-target c99_runtime didn't work.
> > > Apparently for long double, it is simplified to __builtin_copysign
> > > instead of __builtin_copysignl
> > > 
> > > Applying pattern match.pd:208, gimple-match.c:1347
> > > gimple_simplified to t2_3 = __builtin_copysign (1.0e+0, x_1(D));
> > > f3 (long double x)
> > > {
> > >   long double t2;
> > >   long double t1;
> > > 
> > >   :
> > >   t1_2 = ABS_EXPR ;
> > >   t2_3 = __builtin_copysign (1.0e+0, x_1(D));
> > >   return t2_3;
> > > 
> > > }
> > > 
> > > Looks like for arm, long double and double are same
> > > (sizeof (double) == sizeof (long double)).
> > > Since we first match for the double case,
> > > we end up simplifying to __builtin_copysign.
> > 
> > I wonder if this is a bug in the pattern or in test-case ?
> 
> I think this is what is expected and correct for long double == double 
> targets.
> 
> > If double and long double are same, then I suppose it shouldn't
> > matter if copysign would get called for long double ?
> > In that case, should I add following target-effective-checks
> > to the test-case ?
> > dg-require-effective-target large_long_double
> > dg-require-effective-target large_double
> > 
> > Adding
> > /* { dg-require-effective-target large_long_double } */
> > to the test-case makes it unsupported on arm-linux-gnueabihf.
> 
> If you go down that route (and not simply scan for three times
> copysign) please split the testacse into three.
Committed r239149 which splits the test-case into three.

Thanks,
Prathamesh
> 
> Richard.

[Bug web/69601] current/ redirect is off by at least a day

2016-08-04 Thread egall at gwmail dot gwu.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #5 from Eric Gallager  ---
(In reply to Joost VandeVondele from comment #4)
> and also in July...

...and in August...

[Bug c++/72806] New: Extra note/missing not location for __builtin_va_list

2016-08-04 Thread denis.campredon at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72806

Bug ID: 72806
   Summary: Extra note/missing not location for __builtin_va_list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Compiling the following code

void f(struct __builtin_va_list* ap);


Will result in an unfinished message

./Messages.h:1:15: error: using typedef-name ‘__builtin_va_list’ after ‘struct’
 void f(struct __builtin_va_list* ap);
   ^
cc1plus: note: ‘__builtin_va_list’ has a previous declaration here

I would expect no note or the compiler saying that __builtin_va_list is a
builtin_type.

[Bug target/72805] New: AVX512: invalid code generation involving masks

2016-08-04 Thread wen...@mitsuba-renderer.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805

Bug ID: 72805
   Summary: AVX512: invalid code generation involving masks
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wen...@mitsuba-renderer.org
  Target Milestone: ---

Consider the following minimal program, which initializes an 16 int AVX512
vector with -1 entries, does a componen-twise "< 0" comparison, and prints the
resulting mask.

Since there are 16 entries, the expected output is "65535". GCC trunk prints
"255" (compilation flags: g++-7 -S -mavx512f  test.c -o test.s
-fomit-frame-pointer -fno-asynchronous-unwind-tables -fno-exceptions). The
issue goes away when compiling at higher optimization levels, though that is
clearly not a good solution.

#include 
#include 

__attribute__((noinline))
int test() { 
__m512i value = _mm512_set1_epi32(-1);
return (int) _mm512_cmp_epi32_mask(value, _mm512_setzero_si512(), 1 /*
_MM_CMPINT_LT */);
}

int main(int argc, char *argv[]) {
printf("%i\n", test());
return 0;
}

Looking at the assembly reveals the problem:

__Z4testv:
leaq8(%rsp), %r10
andq$-64, %rsp
pushq   -8(%r10)
pushq   %rbp
movq%rsp, %rbp
pushq   %r10
subq$112, %rsp
movl$-1, -52(%rbp)
vmovdqa64   -176(%rbp), %zmm0
movl$-1, %eax
kmovw   %eax, %k2
vpbroadcastd-52(%rbp), %zmm0{%k2}
vmovdqa64   %zmm0, -240(%rbp)
vpxord  %zmm0, %zmm0, %zmm0
vmovdqa64   %zmm0, %zmm1
vmovdqa64   -240(%rbp), %zmm0
movl$-1, %eax
kmovw   %eax, %k3
vpcmpd  $1, %zmm1, %zmm0, %k1{%k3}
kmovw   %k1, %eax
movzbl  %al, %eax<- UH OH
addq$112, %rsp
popq%r10
popq%rbp
leaq-8(%r10), %rsp
ret

For some reason, GCC things that the mask is only eight byte wide and uses a
"movzbl" instruction.

At higher optimization levels, many of the moves are elided, and the mask is
directly copied to %eax. Very mysterious.

__Z4testv:
vpternlogd  $0xFF, %zmm0, %zmm0, %zmm0
vpxord  %zmm1, %zmm1, %zmm1
vpcmpd  $1, %zmm1, %zmm0, %k1
kmovw   %k1, %eax
movzwl  %ax, %eax
ret

[Bug c++/72800] [5/6 Regression] ICE on invalid C++14 code with initialized lambda capture: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in add_capture, at cp/lambda.c:505

2016-08-04 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72800

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |invalid C++14 code with |invalid C++14 code with
   |initialized lambda capture: |initialized lambda capture:
   |tree check: expected class  |tree check: expected class
   |‘type’, have ‘exceptional’  |‘type’, have ‘exceptional’
   |(error_mark) in |(error_mark) in
   |add_capture, at |add_capture, at
   |cp/lambda.c:505 |cp/lambda.c:505

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/72800] [5/6/7 Regression] ICE on invalid C++14 code with initialized lambda capture: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in add_capture, at cp/lambda.c:505

2016-08-04 Thread paolo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72800

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Aug  4 19:22:58 2016
New Revision: 239148

URL: https://gcc.gnu.org/viewcvs?rev=239148=gcc=rev
Log:
/cp
2016-08-04  Paolo Carlini  

PR c++/72800
* lambda.c (add_capture): Check lambda_capture_field_type return
value for error_mark_node.

/testsuite
2016-08-04  Paolo Carlini  

PR c++/72800
* g++.dg/cpp1y/lambda-ice1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-ice1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/72759] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, tree_class_check, ocp_convert)

2016-08-04 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72759

--- Comment #3 from Patrick Palka  ---
Author: ppalka
Date: Thu Aug  4 19:14:32 2016
New Revision: 239147

URL: https://gcc.gnu.org/viewcvs?rev=239147=gcc=rev
Log:
Fix ICE on invalid variable template instantiation (PR c++/72759)

gcc/cp/ChangeLog:

PR c++/72759
* pt.c (tsubst_qualified_id): Return error_mark_node if
template_args is error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/72759
* g++.dg/cpp1y/pr72759.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr72759.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/72804] New: Poor code gen with -mvsx-timode

2016-08-04 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804

Bug ID: 72804
   Summary: Poor code gen with -mvsx-timode
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

The option -mvsx-timode generates very poor code in some circumstances.  The
following two test cases show the problem:

bergner@genoa:~/gcc/BUGS/$ cat t.i 
__int128_t
foo (__int128_t *p)
{
  return p[1];
}

With -O2 -mcpu=power7 -mno-vsx-timode, we get:
foo:
ld 4,24(3)
ld 3,16(3)
blr

With -O2 -mcpu=power7 -mvsx-timode, we get:
foo:
li 9,16
add 3,3,9
ld 4,8(3)
ld 3,0(3)
blr

For bool3-p7.c:ptr4() from the test suite, we see even worse code gen:

bergner@genoa:~/gcc/BUGS/$ cat ptr4.i 
void ptr4 (__int128_t *p)
{
  __int128_t a = p[1];
  __int128_t b;

  __asm__ ("# gpr reg %0" : "+r" (a));
  b = ~a;
  __asm__ ("# gpr reg %0" : "+r" (b));
  p[0] = b;
}

bergner@genoa:~/gcc/BUGS/$
/home/bergner/gcc/build/gcc-fsf-mainline-vsx-timode-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-vsx-timode-debug/gcc/ -O2
-mcpu=power7 -mno-vsx-timode -S ptr4.i 
ptr4:
ld 8,16(3)
ld 9,24(3)
# gpr reg 8
not 10,8
not 11,9
# gpr reg 10
std 10,0(3)
std 11,8(3)
blr

bergner@genoa:~/gcc/BUGS/$
/home/bergner/gcc/build/gcc-fsf-mainline-vsx-timode-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-vsx-timode-debug/gcc/ -O2
-mcpu=power7 -mvsx-timode -S ptr4.i 
bergner@genoa:~/gcc/BUGS/$ cat ptr4.s 
ptr4:
li 9,16
std 23,-72(1)
lxvd2x 0,3,9
std 24,-64(1)
std 25,-56(1)
std 26,-48(1)
std 27,-40(1)
std 28,-32(1)
std 29,-24(1)
std 30,-16(1)
xxpermdi 0,0,0,2
std 31,-8(1)
stdu 1,-368(1)
xxpermdi 0,0,0,2
addi 9,1,144
addi 23,1,272
stxvd2x 0,0,9
addi 9,1,272
addi 8,1,48
xxpermdi 0,0,0,2
addi 7,1,64
addi 6,1,80
addi 5,1,96
addi 4,1,112
addi 12,1,128
addi 31,1,144
xxpermdi 0,0,0,2
addi 30,1,160
addi 29,1,176
addi 28,1,192
addi 27,1,208
addi 26,1,224
addi 25,1,240
stxvd2x 0,0,9
addi 24,1,256
ori 2,2,0
ld 10,0(9)
ld 11,8(9)
addi 9,1,32
# gpr reg 10
std 10,0(23)
std 11,8(23)
ori 2,2,0
lxvd2x 0,0,23
xxpermdi 0,0,0,2
xxlnor 0,0,0
xxpermdi 0,0,0,2
stxvd2x 0,0,23
ori 2,2,0
ld 10,0(23)
ld 11,8(23)
# gpr reg 10
std 10,0(23)
std 11,8(23)
ori 2,2,0
lxvd2x 0,0,23
stxvd2x 0,0,24
stxvd2x 0,0,25
stxvd2x 0,0,26
stxvd2x 0,0,27
stxvd2x 0,0,28
stxvd2x 0,0,29
stxvd2x 0,0,30
stxvd2x 0,0,31
stxvd2x 0,0,12
stxvd2x 0,0,4
stxvd2x 0,0,5
stxvd2x 0,0,6
stxvd2x 0,0,7
stxvd2x 0,0,8
stxvd2x 0,0,9
addi 1,1,368
ld 23,-72(1)
ld 24,-64(1)
ld 25,-56(1)
ld 26,-48(1)
ld 27,-40(1)
ld 28,-32(1)
ld 29,-24(1)
ld 30,-16(1)
ld 31,-8(1)
stxvd2x 0,0,3
blr

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72803

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||dmalcolm at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug c++/72803] New: [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72803

Bug ID: 72803
   Summary: [7 Regression] ICE on invalid code in
linemap_position_for_loc_and_offset, at
libcpp/line-map.c:891
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r238008, we ICE:

$ g++ tc.cc

tc.cc:1:64: error: expected nested-name-specifier before
‘__gnu_cxx__alloc_traitstemplate’
   template class basic_string {   typedef typename
__gnu_cxx__alloc_traitstemplate  rebindother _Char_alloc_typepublic
   
 static const int npos = static_cast private  
template class num_get  public localefacettemplate  localeid
num_putid;;;;;;   
;;;;;;; }
   
^~~
tc.cc:1:64: error: expected ‘;’ at end of member declaration
tc.cc:1:97: error: ‘rebindother’ does not name a type; did you mean ‘register’?
   template class basic_string {   typedef typename
__gnu_cxx__alloc_traitstemplate  rebindother _Char_alloc_typepublic
   
 static const int npos = static_cast private  
template class num_get  public localefacettemplate  localeid
num_putid;;;;;;   
;;;;;;; }
   
 ^~~
   
 register
tc.cc:4:127: internal compiler error: in linemap_position_for_loc_and_offset,
at libcpp/line-map.c:891
0x1543639 linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
../../libcpp/line-map.c:891
0x789893 cp_parser_class_specifier_1
../../gcc/cp/parser.c:21506
0x789893 cp_parser_class_specifier
../../gcc/cp/parser.c:21657
0x789893 cp_parser_type_specifier
../../gcc/cp/parser.c:15883
0x79e441 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:12802
0x7a4637 cp_parser_explicit_instantiation
../../gcc/cp/parser.c:15647
0x7b4fe1 cp_parser_declaration
../../gcc/cp/parser.c:12132
0x7b38f6 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12059
0x7b3c28 cp_parser_translation_unit
../../gcc/cp/parser.c:4350
0x7b3c28 c_parse_file()
../../gcc/cp/parser.c:37549
0x916922 c_common_parse_file()
../../gcc/c-family/c-opts.c:1070

$ cat tc.cc

  template class basic_string {   typedef typename
__gnu_cxx__alloc_traitstemplate  rebindother _Char_alloc_typepublic
   
 static const int npos = static_cast private  
template class num_get  public localefacettemplate  localeid
num_putid;;;;;;   
;;;;;;; }
# 1 "" 1

[Bug c++/71696] Libiberty Demangler segfaults (6)

2016-08-04 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71696

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Should be fixed on trunk now.

[Bug c++/71696] Libiberty Demangler segfaults (6)

2016-08-04 Thread law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71696

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Thu Aug  4 16:53:18 2016
New Revision: 239143

URL: https://gcc.gnu.org/viewcvs?rev=239143=gcc=rev
Log:
2016-08-04  Marcel Böhme  

PR c++/71696
* cplus-dem.c: Prevent infinite recursion when there is a cycle
in the referencing of remembered mangled types.
(work_stuff): New stack to keep track of the remembered mangled
types that are currently being processed.
(push_processed_type): New method to push currently processed
remembered type onto the stack.
(pop_processed_type): New method to pop currently processed
remembered type from the stack.
(work_stuff_copy_to_from): Copy values of new variables.
(delete_non_B_K_work_stuff): Free stack memory.
(demangle_args): Push/Pop currently processed remembered type.
(do_type): Do not demangle a cyclic reference and push/pop
referenced remembered type.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cplus-dem.c
trunk/libiberty/testsuite/demangle-expected

[Bug gcov-profile/53915] gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99%

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
Can you please test the PR with a more recent compiler and attach a reproducer
if it's still valid?

[Bug c++/70254] Compiler crash

2016-08-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70254

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
The first revision that crashes is r208040 (gcc 4.9.0).  It was fixed in
r227098 (gcc 6.0.0) to resolve bug 63693.  It seems this bug can be closed as a
duplicate then, or what's the process here?

[Bug gcov-profile/55121] ICE in if-conversion with PGO (ARM)

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55121

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #16 from Martin Liška  ---
Is the issue still valid with a recent version of the GCC?

[Bug gcov-profile/57015] Link error while building GCC 4.8.0 with 4.7.2 and Binutils 2.22: hidden symbol `__deregister_frame_info' in /.../4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o) is referenced by DSO

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57015

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Hello, looks the problem is quite old, I'm closing the PR.
Please re-open if it's still valid with recent binutils and GCC.

[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945

2016-08-04 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542

Gerhard Steinmetz  changed:

   What|Removed |Added

Summary|ICE on initializing type|ICE in
   |variable with a longer  |gfc_emit_parameter_debug_in
   |array   |fo, at
   ||fortran/trans-decl.c:4947
   ||and :4945

--- Comment #7 from Gerhard Steinmetz  
---

The problems are gone for examples z1, z2, z3 (and others),
but still there for examples z4, z5, z6. Volatile and transient,
for different runs and different options. Summary line adjusted.


One example -- but not limited to -std=f2008 nor depending on it :


$ for n in `seq 1 100`
$ do
$gfortran-7-20160731 -std=f2008 -c z6.f90
$ done


$ gfortran-7-20160731 -std=f2008 -c z6.f90
z6.f90:10:0:

 end

internal compiler error: Segmentation fault
0xc1436f crash_signal
../../gcc/toplev.c:335
0x73cb13 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:4947
0x706ddb do_traverse_symtree
../../gcc/fortran/symbol.c:3930
0x74bfc5 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6381
0x6d7610 translate_all_program_units
../../gcc/fortran/parse.c:5916
0x6d7610 gfc_parse_file()
../../gcc/fortran/parse.c:6122
0x719b32 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198


---


$ gfortran-7-20160731 -std=f2008 -c z4.f90
z4.f90:9:0:

 end

internal compiler error: Segmentation fault
0xc1436f crash_signal
../../gcc/toplev.c:335
0x73ad38 gfc_conv_const_charlen(gfc_charlen*)
../../gcc/fortran/trans-const.c:182
0x73cb01 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:4945
0x706ddb do_traverse_symtree
../../gcc/fortran/symbol.c:3930
0x74bfc5 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6381
0x6d7610 translate_all_program_units
../../gcc/fortran/parse.c:5916
0x6d7610 gfc_parse_file()
../../gcc/fortran/parse.c:6122
0x719b32 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug c++/72800] [5/6/7 Regression] ICE on invalid C++14 code with initialized lambda capture: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in add_capture, at cp/lambda.c:505

2016-08-04 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72800

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Seems easy.

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

2016-08-04 Thread mwahab at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #22 from mwahab at gcc dot gnu.org ---
I believe that this patch is the cause of compilation failures for a number of
tests on arm-none-linux-gnueabihf and arm-none-eabi.

E.g. arm-none-linux-gnueabihf-gcc -S testsuite/gcc.dg/torture/vshuf-v64qi.c -O1
results in an ICE with

testsuite/gcc.dg/torture/vshuf-main.inc: In function ‘test_2’:
testsuite/gcc.dg/torture/vshuf-main.inc:28:1: error: insn does not satisfy its
constraints:
 TESTS
 ^
(insn 606 607 589 2 (set (reg:QI 3 r3 [326])
(reg:QI 31 s15)) testsuite/gcc.dg/torture/vshuf-main.inc:28 182
{*arm_movqi_insn}
 (expr_list:REG_EQUAL (const_int 13 [0xd])
(nil)))
testsuite/gcc.dg/torture/vshuf-main.inc:28:1: internal compiler error: in
extract_constrain_insn, at recog.c:2211
0xaea3e8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/work/src/gnutools/armdsg/src/gcc/gcc/rtl-error.c:108
0xaea40f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/work/src/gnutools/armdsg/src/gcc/gcc/rtl-error.c:119
0xabcf1d extract_constrain_insn(rtx_insn*)
/work/src/gnutools/armdsg/src/gcc/gcc/recog.c:2211
0x9d76af check_rtl
/work/src/gnutools/armdsg/src/gcc/gcc/lra.c:2108
0x9dbfa9 lra(_IO_FILE*)
/work/src/gnutools/armdsg/src/gcc/gcc/lra.c:2516
0x99106f do_reload
/work/src/gnutools/armdsg/src/gcc/gcc/ira.c:5384
0x99106f execute
/work/src/gnutools/armdsg/src/gcc/gcc/ira.c:5568


The test compiles with trunk before the change.

Let me know if there's anything else I should check.
Matthew

[Bug c++/72415] [6/7 regression][concepts] ICE in satisfy_predicate_constraint

2016-08-04 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c++/72796] [7 Regression] Firefox build error: use of deleted function

2016-08-04 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72796

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/71451] [5/6/7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: in dependent_type_p, at cp/pt.c:22599

2016-08-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71451

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2016-06-08 00:00:00 |2016-8-4
 CC||msebor at gcc dot gnu.org
  Known to fail||4.3.0, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.1.0, 7.0

--- Comment #3 from Martin Sebor  ---
The first revision that I have access to that shows the ICE is r125126 but I
suspect the root cause is actually r125062.  Prior to that, GCC rejected the
code with the error below:

t.C:8: error: parameter packs not expanded with `...':
t.C:8: note: ‘T’
t.C: In function ‘int main()’:
t.C:14: error: no matching function for call to ‘B::foo()’

[Bug c++/72415] [6/7 regression][concepts] ICE in satisfy_predicate_constraint

2016-08-04 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Aug  4 16:06:59 2016
New Revision: 239139

URL: https://gcc.gnu.org/viewcvs?rev=239139=gcc=rev
Log:
PR c++/72415 - member template with fold-expression constraint

* pt.c (tsubst_pack_expansion): Pull a single pack expansion out
of the TREE_VEC.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/concepts/memfun2.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/72415] [6/7 regression][concepts] ICE in satisfy_predicate_constraint

2016-08-04 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Aug  4 16:06:22 2016
New Revision: 239138

URL: https://gcc.gnu.org/viewcvs?rev=239138=gcc=rev
Log:
PR c++/72415 - member template with fold-expression constraint

* pt.c (tsubst_pack_expansion): Pull a single pack expansion out
of the TREE_VEC.

Added:
trunk/gcc/testsuite/g++.dg/concepts/memfun2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/72796] [7 Regression] Firefox build error: use of deleted function

2016-08-04 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72796

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Aug  4 16:06:09 2016
New Revision: 239136

URL: https://gcc.gnu.org/viewcvs?rev=239136=gcc=rev
Log:
PR c++/72796 - wrong resolution of scoped method call.

* typeck.c (finish_class_member_access_expr): Avoid stripping
SCOPE_REF to dependent base.

Added:
trunk/gcc/testsuite/g++.dg/template/dependent-base2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug c++/72763] [5/6/7 Regression] incorrectly accepts invalid C++11 code that instantiates a non-template class

2016-08-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72763

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Depends on||72764
  Known to fail||4.8.5, 4.9.3, 5.3.0, 6.1.0,
   ||7.0

--- Comment #3 from Martin Sebor  ---
The test case was rejected prior to r191412 (see also bug 72764 for an ICE
caused by this commit):

r191412 | jason | 2012-09-17 23:47:35 -0400 (Mon, 17 Sep 2012) | 4 lines

PR c++/54575
* pt.c (instantiate_alias_template): New.
(tsubst): Use it.
(push_access_scope): Allow TYPE_DECL.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72764
[Bug 72764] [5/6/7 Regression] ICE on invalid C++11 code instantiating an alias
template: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in
typedef_variant_p, at tree.c:12660

[Bug c++/72764] [5/6/7 Regression] ICE on invalid C++11 code instantiating an alias template: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in typedef_variant_p, at tree.c:12660

2016-08-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72764

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||4.8.2, 4.9.3, 5.3.0, 6.1.0,
   ||7.0

--- Comment #3 from Martin Sebor  ---
r191412 is the first commit that triggers the ICE:

r191412 | jason | 2012-09-17 23:47:35 -0400 (Mon, 17 Sep 2012) | 4 lines

PR c++/54575
* pt.c (instantiate_alias_template): New.
(tsubst): Use it.
(push_access_scope): Allow TYPE_DECL.

[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677

2016-08-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
(In reply to Marek Polacek from comment #1)
> But before r233183 this code compiled fine.

It didn't do what one would expect at runtime, though, and neither did a
program that used the aggregate initialization (i.e., struct S { bool b; char
a[]; } s = { 1, "foo" };) because it treated the flexible array member as a
zero-length array.  With the flexible array member improvements committed in
6.0, GCC accepts the latter, so it seems that the original test case should be
accepted as well, as an extension.  I.e., I suggest to treat this as
ice-on-valid code.

$ cat y.C && ~/bin/gcc-5.1.0/bin/g++ -fpermissive -std=c++11 y.C && ./a.out
struct S {
  bool b;
  char a[] = "foo";
  S () {}
} s;

int main ()
{
  if (__builtin_strcmp (s.a, "foo"))
__builtin_abort ();
}
y.C:3:14: warning: initializer-string for array of chars is too long
[-fpermissive]
   char a[] = "foo";
  ^
y.C: In constructor ‘S::S()’:
y.C:4:8: warning: initializer-string for array of chars is too long
[-fpermissive]
   S () {}
^
Aborted (core dumped)

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

2016-08-04 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #12 from Manuel López-Ibáñez  ---
(In reply to Steve Kargl from comment #9)
> +  if (!gfc_option.warn_tabs && c == '\t')
> +   gfc_warning ("Nonconforming tab character in FORMAT at %C");
>  }

Nowadays, this would be:

if (c == '\t')
 gfc_warning (OPT_Wtabs, Nonconforming tab character in FORMAT at %C");

Cheers,

Manuel.

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

2016-08-04 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802

--- Comment #2 from Segher Boessenkool  ---
Why is "wY" wrong for 32-bit?  I don't see it?

[Bug c++/72800] [5/6/7 Regression] ICE on invalid C++14 code with initialized lambda capture: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in add_capture, at cp/lambda.c:505

2016-08-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72800

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
  Known to fail||5.3.0, 6.1.0, 7.0

--- Comment #2 from Martin Sebor  ---
The ICE first appears in r210829:

r210829 | paolo | 2014-05-22 18:28:24 -0400 (Thu, 22 May 2014) | 16 lines

/cp
2014-05-22  Paolo Carlini  

PR c++/61088
* lambda.c (add_capture): Enforce that capture by value requires
complete type.
* typeck2.c (cxx_incomplete_type_inform): Early return if
TYPE_MAIN_DECL is null.

/testsuite
2014-05-22  Paolo Carlini  

PR c++/61088
* g++.dg/cpp0x/lambda/lambda-ice13.C: New.
* g++.dg/cpp0x/lambda/lambda-ice7.C: Adjust.

[Bug gcov-profile/57165] ICE when using -fprofile-use in cgraph.c

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57165

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
No response, I'm closing the PR. Please re-open if it's still a valid issue.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Martin Liška  ---
I've just verified that GCC 5.3.1 and GCC 6.1.1 and latest trunk work fine
(x86_64-linux-gnu). I built the binary and unrar a rar archive.

Can you please re-try that?

[Bug fortran/67542] ICE on initializing type variable with a longer array

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542

--- Comment #6 from Dominique d'Humieres  ---
Is not this PR fixed?

[Bug fortran/58667] Add -Wfloat-conversion

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58667

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Dominique d'Humieres  ---
> Without feedback I'll close this PR as WONTFIX.

No feed-back, closing.

[Bug libfortran/25830] [libgfortran] Optionally support multi-process locking

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Dominique d'Humieres  ---
> This PR did not get any attention for almost five years. Any point to keep it 
> open?

No feed-back. Closing as WONTFIX.

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #11 from Dominique d'Humieres  ---
> What happened with patch in comment 9?

PING!

[Bug fortran/47879] wrong-debug issue with multiple USE-assoc of variables of other translation units

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47879

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Dominique d'Humieres  ---
> Is is still an issue. If yes, would it be possible to have a better test case?

No feed-back, closing as invalid.

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

2016-08-04 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779

--- Comment #21 from Bernd Edlinger  ---
Author: edlinger
Date: Thu Aug  4 13:23:36 2016
New Revision: 239123

URL: https://gcc.gnu.org/viewcvs?rev=239123=gcc=rev
Log:
016-08-04  Bernd Edlinger  

PR rtl-optimization/71779
* emit-rtl.c (set_reg_attrs_from_value): Only propagate REG_POINTER,
if the value was sign-extended according to POINTERS_EXTEND_UNSIGNED
or if it was truncated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
Bug 18918 depends on bug 25830, which changed state.

Bug 25830 Summary: [libgfortran] Optionally support multi-process locking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug target/70903] [4.9/5/6/7 Regression] wrong code with bfi @ aarch64 with -Os

2016-08-04 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70903

--- Comment #6 from Bernd Edlinger  ---
Author: edlinger
Date: Thu Aug  4 13:20:57 2016
New Revision: 239122

URL: https://gcc.gnu.org/viewcvs?rev=239122=gcc=rev
Log:
2016-08-04  Bernd Edlinger  

PR rtl-optimization/70903
* cse.c (cse_insn): If DEST is a paradoxical SUBREG, don't record DEST.

testsuite:
2016-08-04  Bernd Edlinger  

PR rtl-optimization/70903
* gcc.c-torture/execute/pr70903.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70903.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type

2016-08-04 Thread Joost.VandeVondele at mat dot ethz.ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
 Resolution|--- |FIXED

--- Comment #7 from Joost VandeVondele  
---
confirmed fixed.

[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259

--- Comment #6 from Dominique d'Humieres  ---
AFAICT this PR is now fixed on trunk (7.0) and the gcc-5 and 6 branches. Likely
r238822.

I'll close the PR as FIXED in the coming days unless someone object.

[Bug fortran/71807] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71807

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Dominique d'Humieres  ---
> Waiting one week for regressions before closing.

So closing.

[Bug fortran/70842] [5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Dominique d'Humieres  ---
> Waiting one week for regressions before closing as fixed.

So closing.

[Bug fortran/68241] [meta-bug] Deferred-length character

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 70842, which changed state.

Bug 70842 Summary: [5/6/7 Regression] internal compiler error with character 
members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #14 from Dominique d'Humieres  ---
> With one thing and another, I completely forgot about the backport.
> Yes, please do. I am not able to do commits fo the next week.

Upon further investigation revision r233797 caused the pr70040 regression. IMO
it would be better to fix the regression before doing the back port to the
gcc-5 branch.

[Bug gcov-profile/58544] Segfault with profile guided optimisation

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58544

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Running that with latest GCC 7.0.0 works fine (one has to disable version
check):
error: ‘/tmp/memory_map_backing_store.cc.gcda’ is version ‘408*’, expected
version ‘A70e’ [-Werror]

Thus closing as invalid.

[Bug gcov-profile/59735] code coverage options generate corrupted gcno file

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59735

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please provide a source file which I can test?

[Bug fortran/72791] Internal compiler error for reshape intrinsic

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72791

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dominique d'Humieres  ---
Fixed by revision r238911. Marked as duplicate of pr68566.

> I'll do the backport (if it's doable in reasonable way).

IMO it should. Let me know if you need some help.

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

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68566

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||patrick.seewald at gmail dot 
com

--- Comment #19 from Dominique d'Humieres  ---
*** Bug 72791 has been marked as a duplicate of this bug. ***

[Bug middle-end/71078] x/abs(x) -> sign(1.0,x)

2016-08-04 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 4 Aug 2016, prathamesh3492 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> 
> --- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
> (In reply to prathamesh3492 from comment #6)
> > (In reply to rguent...@suse.de from comment #5)
> > > On Thu, 4 Aug 2016, mwahab at gcc dot gnu.org wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> > > > 
> > > > mwahab at gcc dot gnu.org changed:
> > > > 
> > > >What|Removed |Added
> > > > 
> > > >  CC||mwahab at gcc dot 
> > > > gnu.org
> > > > 
> > > > --- Comment #4 from mwahab at gcc dot gnu.org ---
> > > > (In reply to prathamesh3492 from comment #3)
> > > > > Fixed.
> > > > 
> > > > The new test pr71078-1.c fails for arm and aarch64 because copysignl 
> > > > isn't 
> > > > generated for fabsl making the expected output fail to match.
> > > 
> > > Is that a non-C99 target?  If so add require-effective-target c99_runtime
> > dg-require-effective-target c99_runtime didn't work.
> > Apparently for long double, it is simplified to __builtin_copysign
> > instead of __builtin_copysignl
> > 
> > Applying pattern match.pd:208, gimple-match.c:1347
> > gimple_simplified to t2_3 = __builtin_copysign (1.0e+0, x_1(D));
> > f3 (long double x)
> > {
> >   long double t2;
> >   long double t1;
> > 
> >   :
> >   t1_2 = ABS_EXPR ;
> >   t2_3 = __builtin_copysign (1.0e+0, x_1(D));
> >   return t2_3;
> > 
> > }
> > 
> > Looks like for arm, long double and double are same
> > (sizeof (double) == sizeof (long double)).
> > Since we first match for the double case,
> > we end up simplifying to __builtin_copysign.
> 
> I wonder if this is a bug in the pattern or in test-case ?

I think this is what is expected and correct for long double == double 
targets.

> If double and long double are same, then I suppose it shouldn't
> matter if copysign would get called for long double ?
> In that case, should I add following target-effective-checks
> to the test-case ?
> dg-require-effective-target large_long_double
> dg-require-effective-target large_double
> 
> Adding
> /* { dg-require-effective-target large_long_double } */
> to the test-case makes it unsupported on arm-linux-gnueabihf.

If you go down that route (and not simply scan for three times
copysign) please split the testacse into three.

Richard.

[Bug gcov-profile/60171] SEGFAULT when compiling with --coverage on travis-ci

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60171

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Well, without a reproducer, it's hard to guess what's wrong.
Thus, I'm closing the PR, let re-open when having a test-case.

[Bug gcov-profile/60321] compiler error: in gcov_open, at gcov-io.c:82

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60321

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Well, I've tried to build the project with the latest release (6.1.0) and it
produces many errors. Can you please re-try it? If the error still exists,
please paste complete error message.

[Bug c/72794] [7 regression] CF on spec2000/176.gcc after r238862.

2016-08-04 Thread ysrumyan at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794

--- Comment #6 from Yuri Rumyantsev  ---
Thanks for clarification.
This bug can be closed as user misunderstanding.

2016-08-04 14:08 GMT+03:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794
>
> --- Comment #5 from Richard Biener  ---
> No, it's not a bug in the LTO phase - C99 inline simply does _not_ emit a
> out-of-line copy.  You have to add a extern declaration to force that.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

2016-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72772

--- Comment #9 from Richard Biener  ---
FAIL: gcc.dg/tree-ssa/20030714-2.c scan-tree-dump-times dom2 "if " 3

is because jump-threading doesn't want to thread to a loop header and w/o the
patch we have a pre-header with the degenerate PHI which causes it to stop
there.  With the patch we have an empty pre-header which is threaded as well
and thus threading fails.  We hit

  /* One case occurs when there was loop header buried in a jump
 threading path that crosses loop boundaries.  We do not try
 and thread this elsewhere, so just cancel the jump threading
 request by clearing the AUX field now.  */
  if ((bb->loop_father != e2->src->loop_father
   && !loop_exit_edge_p (e2->src->loop_father, e2))
  || (e2->src->loop_father != e2->dest->loop_father
  && !loop_exit_edge_p (e2->src->loop_father, e2)))
{
  /* Since this case is not handled by our special code
 to thread through a loop header, we must explicitly
 cancel the threading request here.  */
  delete_jump_thread_path (path);
  e->aux = NULL;
  continue;
}

as e2 is the loop entry edge.

  Registering jump thread: (3, 5) incoming edge;  (5, 8) normal; (8, 6) nocopy;

and 8->6 is this edge while 8 is the loop preheader.  Not sure why we
have the above 2nd condition.  Not sure why, if we have this condition,
we do not simply drop the tail of this path.  It looks like
mark_threaded_blocks
would fix this up if the crossed_header check would be >= 1 and not just > 1.

Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 239117)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -1531,10 +1531,8 @@ thread_block_1 (basic_block bb, bool nol
 threading path that crosses loop boundaries.  We do not try
 and thread this elsewhere, so just cancel the jump threading
 request by clearing the AUX field now.  */
- if ((bb->loop_father != e2->src->loop_father
-  && !loop_exit_edge_p (e2->src->loop_father, e2))
- || (e2->src->loop_father != e2->dest->loop_father
- && !loop_exit_edge_p (e2->src->loop_father, e2)))
+ if (bb->loop_father != e2->src->loop_father
+ && !loop_exit_edge_p (e2->src->loop_father, e2))
{
  /* Since this case is not handled by our special code
 to thread through a loop header, we must explicitly

fixes this testcase.

[Bug gcov-profile/65831] gcov does not output 0% coverage files

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65831

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-04
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/71078] x/abs(x) -> sign(1.0,x)

2016-08-04 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078

--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #6)
> (In reply to rguent...@suse.de from comment #5)
> > On Thu, 4 Aug 2016, mwahab at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> > > 
> > > mwahab at gcc dot gnu.org changed:
> > > 
> > >What|Removed |Added
> > > 
> > >  CC||mwahab at gcc dot gnu.org
> > > 
> > > --- Comment #4 from mwahab at gcc dot gnu.org ---
> > > (In reply to prathamesh3492 from comment #3)
> > > > Fixed.
> > > 
> > > The new test pr71078-1.c fails for arm and aarch64 because copysignl 
> > > isn't 
> > > generated for fabsl making the expected output fail to match.
> > 
> > Is that a non-C99 target?  If so add require-effective-target c99_runtime
> dg-require-effective-target c99_runtime didn't work.
> Apparently for long double, it is simplified to __builtin_copysign
> instead of __builtin_copysignl
> 
> Applying pattern match.pd:208, gimple-match.c:1347
> gimple_simplified to t2_3 = __builtin_copysign (1.0e+0, x_1(D));
> f3 (long double x)
> {
>   long double t2;
>   long double t1;
> 
>   :
>   t1_2 = ABS_EXPR ;
>   t2_3 = __builtin_copysign (1.0e+0, x_1(D));
>   return t2_3;
> 
> }
> 
> Looks like for arm, long double and double are same
> (sizeof (double) == sizeof (long double)).
> Since we first match for the double case,
> we end up simplifying to __builtin_copysign.

I wonder if this is a bug in the pattern or in test-case ?
If double and long double are same, then I suppose it shouldn't
matter if copysign would get called for long double ?
In that case, should I add following target-effective-checks
to the test-case ?
dg-require-effective-target large_long_double
dg-require-effective-target large_double

Adding
/* { dg-require-effective-target large_long_double } */
to the test-case makes it unsupported on arm-linux-gnueabihf.

Thanks,
Prathamesh
> 
> Thanks,
> Prathamesh
> > 
> > Richard.

[Bug middle-end/71078] x/abs(x) -> sign(1.0,x)

2016-08-04 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #5)
> On Thu, 4 Aug 2016, mwahab at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> > 
> > mwahab at gcc dot gnu.org changed:
> > 
> >What|Removed |Added
> > 
> >  CC||mwahab at gcc dot gnu.org
> > 
> > --- Comment #4 from mwahab at gcc dot gnu.org ---
> > (In reply to prathamesh3492 from comment #3)
> > > Fixed.
> > 
> > The new test pr71078-1.c fails for arm and aarch64 because copysignl isn't 
> > generated for fabsl making the expected output fail to match.
> 
> Is that a non-C99 target?  If so add require-effective-target c99_runtime
dg-require-effective-target c99_runtime didn't work.
Apparently for long double, it is simplified to __builtin_copysign
instead of __builtin_copysignl

Applying pattern match.pd:208, gimple-match.c:1347
gimple_simplified to t2_3 = __builtin_copysign (1.0e+0, x_1(D));
f3 (long double x)
{
  long double t2;
  long double t1;

  :
  t1_2 = ABS_EXPR ;
  t2_3 = __builtin_copysign (1.0e+0, x_1(D));
  return t2_3;

}

Looks like for arm, long double and double are same
(sizeof (double) == sizeof (long double)).
Since we first match for the double case,
we end up simplifying to __builtin_copysign.

Thanks,
Prathamesh
> 
> Richard.

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

2016-08-04 Thread tulipawn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004

--- Comment #25 from PeteVine  ---
In that case, it might be relevant to note the x86 build succeeded on a 32-bit
**single-core** Athlon XP.

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

2016-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72772

--- Comment #8 from Richard Biener  ---
A more light-weight fix for the specific issue would be

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 239117)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -344,7 +344,7 @@ tree_forwarder_block_p (basic_block bb,
 {
   basic_block dest;
   /* Protect loop headers.  */
-  if (bb->loop_father->header == bb)
+  if (bb_loop_header_p (bb))
return false;

   dest = EDGE_SUCC (bb, 0)->dest;

where bb_loop_header_p only relies on DOM info.  Of course other checks
are still bogus in the presence of new, undiscovered loops (and overly
cautionous in the case of removed loops not marked for removal).  This
applies to all loop related stuff done in CFG hooks as well (though if
LOOPS_NEED_FIXUP is set all the updates they do bogously or fail to do
are fixed by the required loop-fixup).  So in the end only CFG cleanup
routines guarding transforms require up-to-date loop info.  The above
is nearly the only one (with the following preheader/latch checks
falling into the same category as the CFG hook cases).  So the above
might be a complete fix at this point.  Testing that now.

[Bug c/72794] [7 regression] CF on spec2000/176.gcc after r238862.

2016-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794

--- Comment #5 from Richard Biener  ---
No, it's not a bug in the LTO phase - C99 inline simply does _not_ emit a
out-of-line copy.  You have to add a extern declaration to force that.

[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers

2016-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72795

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
"memory" only includes memory that can be indirectly accessed (thus may be
address-taken in this or another CU).  You have to add other vars explicitely.

Note that we asume that asm volatile might read 'x' through such a pointer.

[Bug gcov-profile/67097] gcov-tool merge (can) crash when dir2 contains files not in dir1

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67097

--- Comment #4 from Martin Liška  ---
(In reply to Gilles Gouaillardet from comment #3)
> Shall I try again with the latest snapshot instead ?
> I am not very familiar with building from svn...

What was the original version you tested?
Maybe just trying GCC 6.1.0 would be recent enough.

[Bug gcov-profile/67097] gcov-tool merge (can) crash when dir2 contains files not in dir1

2016-08-04 Thread gilles.gouaillardet at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67097

--- Comment #3 from Gilles Gouaillardet  
---
Shall I try again with the latest snapshot instead ?
I am not very familiar with building from svn...

[Bug middle-end/71078] x/abs(x) -> sign(1.0,x)

2016-08-04 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 4 Aug 2016, mwahab at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
> 
> mwahab at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||mwahab at gcc dot gnu.org
> 
> --- Comment #4 from mwahab at gcc dot gnu.org ---
> (In reply to prathamesh3492 from comment #3)
> > Fixed.
> 
> The new test pr71078-1.c fails for arm and aarch64 because copysignl isn't 
> generated for fabsl making the expected output fail to match.

Is that a non-C99 target?  If so add require-effective-target c99_runtime

Richard.

[Bug middle-end/71078] x/abs(x) -> sign(1.0,x)

2016-08-04 Thread mwahab at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #4 from mwahab at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #3)
> Fixed.

The new test pr71078-1.c fails for arm and aarch64 because copysignl isn't 
generated for fabsl making the expected output fail to match.

Matthew

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

2016-08-04 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847

--- Comment #21 from Andreas Krebbel  ---
I did a S/390 Spec measurement. All the testcases got smaller with the patch
what definitely is a good sign.

However, there appear to be performance regressions at least with cactusADM.

[Bug gcov-profile/67097] gcov-tool merge (can) crash when dir2 contains files not in dir1

2016-08-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67097

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
Ok, closing the issue, please re-open if it's a still existing
issue.https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67097#

[Bug c++/72801] ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

2016-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72801

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
   Target Milestone|5.5 |---
  Known to fail||4.3.0

--- Comment #5 from Richard Biener  ---
It's there since variadic template support, but we issue an error before
if checking is disabled:

t.ii:17: error: 'template' (as a disambiguator) is only allowed within
templates
t.ii:17: confused by earlier errors, bailing out

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

2016-08-04 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72772

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
Thus the following "fixes" it.  I'm really not sure at which level we should
try to fix this - ideally passes doing this kind of transform would reset
the upper bound (and niter info).  Unfortunately in this case it is really
CFG cleanup ... but the thread pass threading destination is a new header
and not yet identified as such (the thread pass fails to create the new loop
itself, leaving it to loop fixup - in this case CFG cleanup avoids this new
loop by mashing it with the existing one).  In fact tree_forwarder_block_p
guards against the transform (but it doesnt' work because BB is not yet
marked as loop header):

  if (current_loops)
{
  basic_block dest;
  /* Protect loop headers.  */
  if (bb->loop_father->header == bb)
return false;

CFG cleanup runs loop fixup after its job and I'm (not) sure we want to do it
at its start as well to catch this case.

Index: gcc/loop-init.c
===
--- gcc/loop-init.c (revision 239117)
+++ gcc/loop-init.c (working copy)
@@ -306,6 +311,8 @@ fix_loop_structure (bitmap changed_bbs)
flow_loop_free (loop);
any_deleted = true;
   }
+else if (loop)
+  loop->any_upper_bound = false;

   /* If we deleted loops then the cached scalar evolutions refering to
  those loops become invalid.  */

The alternative is to make sure loops are fixed up before CFG cleanup as
it guards transforms using loop info:

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 239117)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -731,59 +731,19 @@ cleanup_tree_cfg_1 (void)
 }


-/* Remove unreachable blocks and other miscellaneous clean up work.
-   Return true if the flowgraph was modified, false otherwise.  */
-
-static bool
-cleanup_tree_cfg_noloop (void)
-{
-  bool changed;
-
-  timevar_push (TV_TREE_CLEANUP_CFG);
-
-  /* Iterate until there are no more cleanups left to do.  If any
- iteration changed the flowgraph, set CHANGED to true.
-
- If dominance information is available, there cannot be any unreachable
- blocks.  */
-  if (!dom_info_available_p (CDI_DOMINATORS))
-{
-  changed = delete_unreachable_blocks ();
-  calculate_dominance_info (CDI_DOMINATORS);
-}
-  else
-{
-  checking_verify_dominators (CDI_DOMINATORS);
-  changed = false;
-}
-
-  changed |= cleanup_tree_cfg_1 ();
-
-  gcc_assert (dom_info_available_p (CDI_DOMINATORS));
-  compact_blocks ();
-
-  checking_verify_flow_info ();
-
-  timevar_pop (TV_TREE_CLEANUP_CFG);
-
-  if (changed && current_loops)
-loops_state_set (LOOPS_NEED_FIXUP);
-
-  return changed;
-}
-
 /* Repairs loop structures.  */

@@ -803,17 +764,57 @@ repair_loop_structures (void)
   timevar_pop (TV_REPAIR_LOOPS);
 }

-/* Cleanup cfg and repair loop structures.  */
+/* Cleanup the CFG by removing unreachable blocks and doing other
miscellaneous
+   clean up work.  Also repair loop structures if necessary.
+
+   Return true if the flowgraph was modified, false otherwise.  */

 bool
 cleanup_tree_cfg (void)
 {
-  bool changed = cleanup_tree_cfg_noloop ();
+  bool changed;
+
+  timevar_push (TV_TREE_CLEANUP_CFG);
+
+  /* Iterate until there are no more cleanups left to do.  If any
+ iteration changed the flowgraph, set CHANGED to true.
+
+ If dominance information is available, there cannot be any unreachable
+ blocks.  */
+  if (!dom_info_available_p (CDI_DOMINATORS))
+{
+  changed = delete_unreachable_blocks ();
+  calculate_dominance_info (CDI_DOMINATORS);
+}
+  else
+{
+  checking_verify_dominators (CDI_DOMINATORS);
+  changed = false;
+}

+  /* Repair loop structures as we rely on loops being correct with
+ guarding several of the transforms.  */
   if (current_loops != NULL
   && loops_state_satisfies_p (LOOPS_NEED_FIXUP))
 repair_loop_structures ();

+  changed |= cleanup_tree_cfg_1 ();
+
+  gcc_assert (dom_info_available_p (CDI_DOMINATORS));
+  compact_blocks ();
+
+  checking_verify_flow_info ();
+
+  timevar_pop (TV_TREE_CLEANUP_CFG);
+
+  if (changed && current_loops != NULL)
+{
+  /* We are not marking loops for fixup in all cases, thus force it
+ here.  */
+  loops_state_set (LOOPS_NEED_FIXUP);
+  repair_loop_structures ();
+}
+
   return changed;
 }


I'm leaning towards this one even though it is more expensive :/  (and we
should fix that last comment issue and re-visit the loop-closed SSA update
stuff we do in repair_loop_structures).

  1   2   >