[Bug ipa/82957] [8 Regression] ICE: in to_cgraph_frequency, at profile-count.c:251

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
 CC||hubicka at ucw dot cz,
   ||trippels at gcc dot gnu.org
Summary|internal compiler error: in |[8 Regression] ICE: in
   |to_cgraph_frequency, at |to_cgraph_frequency, at
   |profile-count.c:251 |profile-count.c:251
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Probably started with r254379.

[Bug c/81117] Improve buffer overflow checking in strncpy

[dimhen at gmail dot com]

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

--- Comment #12 from Dmitry G. Dyachenko  ---
char *strncpy(char *dest, const char *src, size_t n);
void foo(char* p)
{
strncpy(p, "1", 1);
p[1] = 0;
}

with gcc8/r254663 is this expected?

$ gcc -c -Wall x.c
x.c: In function ‘foo’:
x.c:4:5: warning: ‘strncpy’ output truncated before terminating nul copying 1
byte from a string of the same length [-Wstringop-truncation]
 strncpy(p, "1", 1);
 ^~

[Bug tree-optimization/82954] [8 regression] ICE in fold_binary_loc, at fold-const.c:9061

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 13 09:01:24 2017
New Revision: 254671

URL: https://gcc.gnu.org/viewcvs?rev=254671&root=gcc&view=rev
Log:
PR tree-optimization/82954
* gimple-ssa-store-merging.c
(imm_store_chain_info::coalesce_immediate_stores): If
!infof->ops[N].base_addr, split group if info->ops[N].base_addr.

* gcc.c-torture/execute/pr82954.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr82954.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-13
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Hmm, GCC 4.2 as host compiler and using non-standard flags (-Os).  Can you try
with standard flags?  It's probably miscompiling libcpp and/or genmatch.

[Bug c/82940] Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc

--- Comment #1 from Richard Biener  ---
Note GCC 5 is no longer supported, you might want to try GCC 7.

[Bug c++/82959] New: g++ doesn't appreciate C++17 evaluation order rules for overloaded operators

[ixsci at yandex dot ru]

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

Bug ID: 82959
   Summary: g++ doesn't appreciate C++17 evaluation order rules
for overloaded operators
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ixsci at yandex dot ru
  Target Milestone: ---

Having the following code:

#include 

using namespace std;

class Int
{
public:
Int() = default;

Int(int val): 
m_Value{val}
{
}

Int operator++(int)
{
Int tmp{*this};
++m_Value;
return tmp;
}

bool operator&&(const Int& rhs) const
{
return m_Value && rhs.m_Value;
}
private:
int m_Value = 0;
};

template 
bool cleverFun(T& value)
{
return (cout << "first\n", value++) && 
(cout << "second\n", value++);
}

int main()
{
int i = 0;
Int complexI{};
cout << "==SIMPLE INT\n";
cleverFun(i);
cout << "==COMPLEX INT\n";
cleverFun(complexI);
};

The conforming C++17 compiler (to my knowledge) should output "first" then
"second" twice, but GCC outputs "second" then "first" with the overloaded &&
operator.

[Bug bootstrap/82948] [8 Regression] prefix.c:202:15: error: 'char* strncpy(char*, const char*, size_t)' destination unchanged after copying no bytes [-Werror=stringop-truncation]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Martin Sebor from comment #0)
> In the program below, while GCC optimizes the strlen call in f() to a
> constant it doesn't do the same for the equivalent function g().
> 
> I suspect this is caused by the same underlying assumptions as pr80944:
> i.e., that the strcpy (a->d, "123") call could change a->d if a->d pointed
> at or into itself.  While that might be true in other circumstances, it's
> not possible here.  Since the array at a->d is subsequently accessed by the
> call to strlen, the strcpy call cannot change a->d in a valid program
> because "123" (or any other string literal) cannot be a valid representation
> of a pointer.  (The only way for a conforming program to obtain a valid
> pointer is by assigning to it the value of another valid pointer.  Even if
> the bit pattern of the literal "123" happened to match a valid address in a
> program, copying the literal into a pointer and then using that pointer is
> undefined.)
> 
> So a->d can be assumed not to change in either function and the strlen
> optimization below is safe in both.
> 
> $ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
> 
> char* strcpy (char*, const char*);
> __SIZE_TYPE__ strlen (const char*);
> 
> struct A { char *d; };
> 
> unsigned f (struct A *a)
> {
>   char *d = a->d;
>   strcpy (d, "123");
>   return strlen (d);   // folded into 3
> }
> 
> unsigned g (struct A *a)
> {
>   strcpy (a->d, "123");
>   return strlen (a->d);   // not folded but can be
> }
> 
> 
> ;; Function f (f, funcdef_no=0, decl_uid=1898, cgraph_uid=0, symbol_order=0)
> 
> f (struct A * a)
> {
>   char * d;
> 
>[local count: 1]:
>   d_4 = a_3(D)->d;
>   __builtin_memcpy (d_4, "123", 4);
>   return 3;
> 
> }
> 
> 
> 
> ;; Function g (g, funcdef_no=1, decl_uid=1902, cgraph_uid=1, symbol_order=1)
> 
> g (struct A * a)
> {
>   char * _1;
>   char * _2;
>   long unsigned int _3;
>   unsigned int _7;
> 
>[local count: 1]:
>   _1 = a_5(D)->d;
>   __builtin_memcpy (_1, "123", 4);
>   _2 = a_5(D)->d; 

Clearly because GCC has to assume a_5(D)->d points to itself and thus
memcpy clobbering it.

Can't see how you can rule that out for a valid program.  Thus - INVALID?

Richard.

>   _3 = strlen (_2);
>   _7 = (unsigned int) _3;
>   return _7;
> 
> }

[Bug c++/82949] internal compiler error: in cp_parser_late_return_type_opt, at cp/parser.c:16698

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.7.3
 Resolution|--- |FIXED

--- Comment #2 from Richard Biener  ---
GCC 4.7.2 is long out of maintainance, please try GCC 6 or newer.  Note this
was fixed in 4.7.3.

[Bug tree-optimization/82950] possible strlen optimization for memcmp/strcmp of arrays

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug testsuite/82951] gcc.c-torture/execute/20040409-1.c undefined behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Hmm, on RTL signs do not matter.  I'd say strip the bogus cases from the
existing tests and "duplicate" them into new variants using -fwrapv?  Thus only
apply -fwrapv to those cases that need it.

[Bug c++/82959] g++ doesn't appreciate C++17 evaluation order rules for overloaded operators

[ixsci at yandex dot ru]

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

--- Comment #1 from Evgeniy Shcherbina  ---
Not that it matters much, but it should be "int i = -1;" in the code to match
my description fully.

[Bug target/82960] New: spu_machine_dependent_reorg does not handle jump_table_data insn

[vries at gcc dot gnu.org]

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

Bug ID: 82960
   Summary: spu_machine_dependent_reorg does not handle
jump_table_data insn
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When building spu with --enable-checking=yes,rtl, I run into:
...
0xf965db rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
src/gcc/rtl.c:820
0x14b6cca pad_bb
src/gcc/config/spu/spu.c:2032
0x14b9d8b spu_machine_dependent_reorg
src/gcc/config/spu/spu.c:2640
0xf83d92 execute
src/gcc/reorg.c:3947
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

In pad_bb, we loop over the insns using active_insn_p and next_active_insn, but
do not handle the jump_table_data insn.

[Bug c++/82952] Hang compiling with g++ -fsanitize=undefined -Wduplicated-branches

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  I suspect UBSAN creates a large number of branches and
-Wduplicated-branches isn't very effective.  In fact it looks quadratic given
we do

128   if (warn_duplicated_branches)
129 walk_tree_without_duplicates (&DECL_SAVED_TREE (fndecl),
130   do_warn_duplicated_branches_r, NULL);

and do_warn_duplicated_branches_r does itself

  /* Compute the hash of the then branch.  */
  inchash::hash hstate0 (0);
  inchash::add_expr (thenb, hstate0);
  hashval_t h0 = hstate0.end ();
...
  && !walk_tree_without_duplicates (&thenb, expr_from_macro_expansion_r,
NULL)

thus we process each tree (in COND_EXPRs) a quadratic amount of times.
inchash is very likely also not avoiding walking duplicates multiple times,
as SAVE_EXPR is tcc_expression it even walks those multiple times.

As a band-aid I suggest to limit the depth we walk here somehow...

[Bug tree-optimization/82954] [8 regression] ICE in fold_binary_loc, at fold-const.c:9061

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug driver/82955] ICE when using -fdump-passes -fdisable-tree-einline

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
  Component|tree-optimization   |driver
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
-fdump-passes is somewhat of a hack and appearantly doesn't mix well with
-fdisable-*

[Bug ipa/82957] [8 Regression] ICE: in to_cgraph_frequency, at profile-count.c:251

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/78990] [6/7/8 Regression] ICE when assigning polymorphic array function result

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
I have a patch for this that I will post on the fortran list just as soon as it
has finished regtesting.

This turned out to be quite a challenging debugging job as often seems to be
the case where the scalarizer is involved. Ultimately, I found that the
testcase compiled when return_t1 was made a pointer and the resulting code
revealed where the problems lay. This modified testcase now works as well but,
of course, it leaks memory.

Thanks for the report by the way.

Paul

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka  ---
Hello,
here is what happens. There is problematic block BB 36
;; basic block 36, loop depth 0, count 34157, maybe hot
;;  prev block 35, next block 37, flags: (HOT_PARTITION, RTL, MODIFIED)
;;  pred:   33 [66.0% (guessed)]  count:0 (CROSSING)
;;  35 [60.9%]  count:34157 (FALLTHRU)
;; bb 36 artificial_defs: { }
;; bb 36 artificial_uses: { u-1(6){ }u-1(7){ }}
;; lr  in3 [bx] 4 [si] 6 [bp] 7 [sp] 20 [frame]
;; lr  use   4 [si] 6 [bp] 7 [sp]
;; lr  def   0 [ax] 5 [di] 17 [flags]
;; live  in  3 [bx] 4 [si] 6 [bp] 7 [sp] 20 [frame]
;; live  gen 0 [ax] 5 [di] 17 [flags]
;; live  kill17 [flags]
(code_label 302 298 303 36 296 (nil) [1 uses])
(note 303 302 305 36 [bb 36] NOTE_INSN_BASIC_BLOCK)
(insn 305 303 306 36 (set (reg/f:SI 0 ax [orig:870 _71->typed.type ] [870])
(mem/f/j:SI (plus:SI (reg/f:SI 4 si [orig:114 _71 ] [114])
(const_int 8 [0x8])) [0 _71->typed.type+0 S4 A32]))
"../../gcc/tree-ssa-strlen.c":2727 75 {*movsi_internal}
 (nil))
(insn 306 305 8625 36 (set (reg:HI 5 di [orig:872 _7->base.code ] [872])
(mem/j:HI (reg/f:SI 0 ax [orig:870 _71->typed.type ] [870]) [0
_7->base.code+0 S2 A32])) "../../gcc/tree-ssa-strlen.c":2727 76
{*movhi_internal}
 (nil))
(insn 8625 306 308 36 (parallel [
(set (reg:SI 5 di [871])
(plus:SI (reg:SI 5 di [orig:872 _7->base.code ] [872])
(const_int -10 [0xfff6])))
(clobber (reg:CC 17 flags))
]) "../../gcc/tree-ssa-strlen.c":2727 190 {*addsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 308 8625 309 36 (set (reg:CC 17 flags)
(compare:CC (reg:HI 5 di [871])
(const_int 1 [0x1]))) "../../gcc/tree-ssa-strlen.c":2727 6
{*cmphi_1}
 (expr_list:REG_DEAD (reg:HI 0 ax [871])
(nil)))
(jump_insn 309 308 310 36 (set (pc)
(if_then_else (gtu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref:SI 343)
(pc))) "../../gcc/tree-ssa-strlen.c":2727 536 {*jcc}

Now see it has two predecesors - one cold (count 0), BB 33 and one hot (BB 35)A

Now BB 35 gets visited in trace 3 which is 31->32->35
BB 36 gets trace 9 (it is alone there)
BB 33 gets trace 266

So we get
Trace 3 (round 1):  31 [554] 32 [554] 35 [554]
Trace 9 (round 2):  36 [337]
Trace 266 (round 4):  33 [0] 34 [0]

Now while connecting traces we get
Connection: 912 819

   Here it is processing trace 3
Connection: 45 31
Connection: 41 45
Connection: 37 38
Connection: 36 37
   Here trace 9 gets used
Connection: 35 36 
changing bb of uid 8944
  unscanned insn
changing bb of uid 8939
  unscanned insn
scanning new insn with uid = 8939.
changing bb of uid 8940
  unscanned insn
scanning new insn with uid = 8940.
changing bb of uid 8941
  unscanned insn
scanning new insn with uid = 8941.
changing bb of uid 8942
  unscanned insn
scanning new insn with uid = 8942.
changing bb of uid 8943
  unscanned insn
scanning new insn with uid = 8943.
Redirecting fallthru edge 35->36 to 913
Duplicated bb 36 (created bb 913)


So BB 36 gets duplicated to be placed just after Trace 3.
>From this moment BB 36 has only one cold predecestor and that is why fixup
eventually turns it cold.

The duplication happens because BB 36 is already attached to begining of the
same trace so
we are duplicating tail of the loop.

This seems reasonable things to do. Only what BB reorder misses is that it may
do the partitining
fixup after the duplication. I am not sure if that is desirable as that would
affect existing 
trace that may need to be updated, too.

So still it seems reasonable to me to disable the partition fixup post
bb-reorder because
it only may trigger ICE if it suceeds so it is a waste of compile time.  We may
teach bb reorder
to be bit smarter here, but it seems quite rare scenario.

[Bug target/82960] spu_machine_dependent_reorg does not handle jump_table_data insn

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 42592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42592&action=edit
Tentative patch

Using this tentative patch, I manage to finish the build.

[Bug c++/82952] Hang compiling with g++ -fsanitize=undefined -Wduplicated-branches

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, indeed.  I'd say in this case the biggest problem is probably repeated
traversal of SAVE_EXPRs in inchash::add_expr (which BTW doesn't seem to be
something that operand_equal_p with OEP_LEXICOGRAPHICS handles).
But generally you're right, even without SAVE_EXPRs with hundreds of nested
COND_EXPRs the compile time complexity isn't tollerable either.
So, shall we before those
  /* Compute the hash of the then branch.  */
  inchash::hash hstate0 (0);
  inchash::add_expr (thenb, hstate0);
  hashval_t h0 = hstate0.end ();

  /* Compute the hash of the else branch.  */
  inchash::hash hstate1 (0);
  inchash::add_expr (elseb, hstate1);
  hashval_t h1 = hstate1.end ();
walk thenb as well as elseb and count trees we've walked (and punt if seen more
than some constant or PARAM trees)?  That could also punt if both numbers of
trees are below the limit, but different (though inchash::add_expr as well as
opernad_equal_p has some spots with STRIP_NOPS, which we'd no longer then
recognize if different).
And/or add some optional hash table for remembering SAVE_EXPRs?  Though, I'd
prefer not to slow down the normal add_expr...
Shall we handle SAVE_EXPR in operand_equal_p if OEP_LEXICOGRAPHICS?

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 13 10:26:13 2017
New Revision: 254679

URL: https://gcc.gnu.org/viewcvs?rev=254679&root=gcc&view=rev
Log:
PR tree-optimization/78821
* gimple-ssa-store-merging.c (compatible_load_p): Don't require
that bit_not_p is the same.
(imm_store_chain_info::coalesce_immediate_stores): Likewise.
(split_group): Count precisely bit_not_p bits in each statement.
(invert_op): New function.
(imm_store_chain_info::output_merged_store): Use invert_op to
emit BIT_XOR_EXPR with a xor_mask instead of BIT_NOT_EXPR if some
but not all orig_stores have BIT_NOT_EXPR in the corresponding spots.

* gcc.dg/store_merging_15.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/store_merging_15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #16 from Eric Botcazou  ---
> So BB 36 gets duplicated to be placed just after Trace 3.
> From this moment BB 36 has only one cold predecestor and that is why fixup
> eventually turns it cold.

OK, exactly the same sequence of events as:
   https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02006.html

> This seems reasonable things to do. Only what BB reorder misses is that it
> may do the partitining fixup after the duplication. I am not sure if that is 
> desirable as that would affect existing trace that may need to be updated, 
> too.

The result is suboptimal though, since you end up with a (cold) block in the
hot partition whose only predecessors are in the cold partition.  What happens
in this case if copy_bb_p returns false for the problematic block, i.e. if you
move the test I added lines 579-584 into the copy_bb_p predicate itself?  Does
this result in a better reordered sequence of blocks?

[Bug target/82961] New: ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

Bug ID: 82961
   Summary: ICE in dwarf2out.c: deferred_asm_name != NULL
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When building for alpha-dec-vms, I run into this ICEs in libgcc:
...
make[2]: *** [_negdi2.o] Error 1
make[2]: *** [_ashldi3.o] Error 1
make[2]: *** [_lshrdi3.o] Error 1
make[2]: *** [_muldi3.o] Error 1
make[4]: *** [_muldi3.o] Error 1
make[4]: *** [_negdi2.o] Error 1
make[4]: *** [_ashrdi3.o] Error 1
make[4]: *** [_ashldi3.o] Error 1
make[4]: *** [_lshrdi3.o] Error 1
...

In more detail, the _lshrdi3.o one:
...
0xa64e1b dwarf2out_finish
src/gcc/dwarf2out.c:29826
0x1476ede vmsdbgout_finish
src/gcc/vmsdbgout.c:1569
0xa64e1b dwarf2out_finish
src/gcc/dwarf2out.c:29826
0x1476ede vmsdbgout_finish
/home/vries/gcc_versions/devel/src/gcc/vmsdbgout.c:1569
Please submit a full bug report,
...

The assert that triggers is:
...
29826 gcc_assert (deferred_asm_name == NULL);
...

The deferred_asm_name is for __clz_tab:
...
(gdb) call debug_generic_expr (deferred_asm_name.created_for )
__clz_tab
...

[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Target||alpha-dec-vms

--- Comment #1 from Tom de Vries  ---
Configure line:
...
$ configure --enable-checking=yes,rtl --enable-languages=c --disable-tls
--disable-threads --target=alpha-dec-vms
...

[Bug libfortran/82962] New: valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

Bug ID: 82962
   Summary: valgrind reports "Conditional jump or move depends on
uninitialised value" in EXECUTE_COMMAND_LINE
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Test case:

integer :: istat
! istat = 0
call execute_command_line('echo "Hello World!"', exitstat=istat)
end


After compiling this with gfortran, and running the resulting executable
through valgrind, I get:

==16313== Conditional jump or move depends on uninitialised value(s)
==16313==at 0x4F3B7EA: _gfortran_execute_command_line_i4 (in
/usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)



This only occurs if an EXITSTAT argument is passed, which is not initialized
before the call. However, EXITSTAT is supposed to be an output argument AFAIK.
I don't see why its value should be used at all inside of EXECUTE_COMMAND_LINE?

A dump of the program shows:

MAIN__ ()
{
  integer(kind=4) istat;

  _gfortran_execute_command_line_i4 (&"echo \"Hello World!\""[1]{lb: 1 sz: 1},
0B, &istat, 0B, 0B, 19, 0);
}


Looking at libgfortran/intrinsics/execute_command_line.c, I see the following
in execute_command_line_i4:


  if (exitstat)
estat_initial = estat = *exitstat;

  execute_command_line (command, w, &estat, cmdstat ? &cstat : NULL,
cmdmsg, command_len, cmdmsg_len);

  if (exitstat && estat != estat_initial)
*exitstat = estat;


Apparenly the existat after the call is compared to the initial exitstat, which
can be uninitialized. I guess it would be better to set exitstat to some
defined initial value, instead of using the input value from outside.

[Bug c/82963] New: -Waddress too trigger happy

[mhocko at kernel dot org]

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

Bug ID: 82963
   Summary: -Waddress too trigger happy
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mhocko at kernel dot org
  Target Milestone: ---

Hi,
in the kernel we have a uggly^Wmacro to help printing numa mask defined as
follows
#define nodemask_pr_args(maskp) MAX_NUMNODES : (maskp)->bits

I have updated it to allow NULL maskp as follows
#define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ?
(maskp)->bits : NULL

but this has triggered warnings on usage where it is clear that maskp is never
NULL. E.g.
In file included from include/linux/mmzone.h:17:0,  
 from include/linux/mempolicy.h:10, 
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function 'mpol_to_str':  
include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always
evaluate as 'true' [-Waddress]  
 #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ?
(maskp)->bits : NULL
 ^  
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args(&nodes));
   ^
include/linux/nodemask.h:107:69: warning: the address of 'nodes' will always
evaluate as 'true' [-Waddress]
 #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ?
(maskp)->bits : NULL
 ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args(&nodes));

While the warning is correct and the given mask will always resolve to the
success path of the ternary operator I really fail to see why we should warn
about this fact. I really do not see any potential problem which could be
caused by this fact.

Moreover the warning itself is quite inconsistent. E.g. the following warns
about the explicit &m but not for n. So I believe this is more of a suboptimal
warning implementation than real intention.

#include 

#define MAX_NUMNODES 10
struct mask {
void *bits;
};
#define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ?
(maskp)->bits : NULL

int foo(void)
{
struct mask m;
struct mask *n = &m;

printf("%*p\n", nodemask_pr_args(&m));
printf("%*p\n", nodemask_pr_args(n));

return 0;
}

[Bug c/82963] -Waddress too trigger happy

[mhocko at kernel dot org]

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

--- Comment #1 from Michal Hocko  ---
Btw. the compiler doesn't complain if I rewrite the macro to do an explicit
NULL check
(maskp != NULL) ? MAX_NUMNODES : 0, (maskp != NULL) ? (maskp)->bits : NULL

[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
Possible patch:

Index: libgfortran/intrinsics/execute_command_line.c
===
--- libgfortran/intrinsics/execute_command_line.c   (revision 254678)
+++ libgfortran/intrinsics/execute_command_line.c   (working copy)
@@ -145,10 +145,11 @@ execute_command_line_i4 (const char *command, GFC_
 gfc_charlen_type cmdmsg_len)
 {
   bool w = wait ? *wait : true;
-  int estat, estat_initial, cstat;
+  const int estat_initial = -100;
+  int estat, cstat;

   if (exitstat)
-estat_initial = estat = *exitstat;
+estat = estat_initial;

   execute_command_line (command, w, &estat, cmdstat ? &cstat : NULL,
cmdmsg, command_len, cmdmsg_len);


Question is: What's a suitable value for estat_initial?

The same changes need to apply to execute_command_line_i8 as well.

[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Since it seems that execute_command_line always sets a return value for the
exitstat argument, one probably does not need to check against an initial value
at all:



Index: libgfortran/intrinsics/execute_command_line.c
===
--- libgfortran/intrinsics/execute_command_line.c   (revision 254678)
+++ libgfortran/intrinsics/execute_command_line.c   (working copy)
@@ -145,15 +145,12 @@ execute_command_line_i4 (const char *command, GFC_
 gfc_charlen_type cmdmsg_len)
 {
   bool w = wait ? *wait : true;
-  int estat, estat_initial, cstat;
+  int estat, cstat;

-  if (exitstat)
-estat_initial = estat = *exitstat;
-
   execute_command_line (command, w, &estat, cmdstat ? &cstat : NULL,
cmdmsg, command_len, cmdmsg_len);

-  if (exitstat && estat != estat_initial)
+  if (exitstat)
 *exitstat = estat;
   if (cmdstat)
 *cmdstat = cstat;

[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |8.0

[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
I have verified that the patch in comment 2 fixes the problem on trunk.

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

[arvo at me dot com]

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

Arne Vogel  changed:

   What|Removed |Added

 CC||arvo at me dot com

--- Comment #4 from Arne Vogel  ---
@Jakub Jelinek: Returning empty structs (this affects empty tuples as well) can
be useful in templates. E.g.

struct empty_t {};

template
void executeContext()
{
auto savedState = C::prepare();
C::execute();
C::cleanup(std::move(savedState));
}

/*
 * Context which does not require saving state but should be compatible
 * with executeContext().
 */
struct StatelessContext
{
static empty_t prepare();
static void execute();
static void cleanup(empty_t);
};

// Usage: executeContext();

Obviously, void does not work here *precisely* because executeContext saves
(i.e. uses) the return value. I have an example that makes more sense than the
above, but takes longer to explain. Anyway, I hope you get the idea.

A possible workaround is e.g. to use a dummy char instead. The documentation
says (slightly misleadingly, see below) empty structs in G++ are treated as
though they contained a single char. But this in turn may cause unwanted
interference e.g. with empty base optimization.

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
I don't argue that returning empty structures can be sometimes useful.
But I fail to understand why would you want to use warn_unused_result attribute
on such functions, that just makes no sense, because there is no harm if the
empty struct is not copied to a temporary.

[Bug target/82964] New: gfortran.dg/class_array_1.f03 regression since r254388

[clyon at gcc dot gnu.org]

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

Bug ID: 82964
   Summary: gfortran.dg/class_array_1.f03 regression since r254388
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

As already reported in https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00286.html
,
a few fortran tests now ICE since r254388 on aarch64:

gfortran.dg/class_array_1.f03   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
gfortran.dg/type_to_class_3.f03   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
gfortran.dg/type_to_class_3.f03   -O3 -g  (internal compiler error)
gfortran.dg/widechar_intrinsics_5.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
gfortran.dg/widechar_intrinsics_5.f90   -O3 -g  (internal compiler error)

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[hubicka at ucw dot cz]

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

--- Comment #17 from Jan Hubicka  ---
> > This seems reasonable things to do. Only what BB reorder misses is that it
> > may do the partitining fixup after the duplication. I am not sure if that 
> > is 
> > desirable as that would affect existing trace that may need to be updated, 
> > too.
> 
> The result is suboptimal though, since you end up with a (cold) block in the
> hot partition whose only predecessors are in the cold partition.  What happens
> in this case if copy_bb_p returns false for the problematic block, i.e. if you
> move the test I added lines 579-584 into the copy_bb_p predicate itself?  Does
> this result in a better reordered sequence of blocks?

I have only dumps. Martin, would it be easy for you to rebuild it with the
change?

I would say that the duplication here is desriable optimization. Disabling it
would only pesmize code in hot path that we don't want to do. So we would paper
around missed optimization ICE by disabling another optimization.

Right thing to do would be to move that BB into cold partition. In this case
it won't be hard as it is not partitioned yet, so one would only need to check
that partitioning fixes are OK.

Other option may be to make partitining fixes to adjust the BB ordering.  I.e.
move all blocks promoted to be cold into beggining of cold section.  That would
still result in not completely optimal BB placement though.

Honza

[Bug c/81117] Improve buffer overflow checking in strncpy

[dimhen at gmail dot com]

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

--- Comment #13 from Dmitry G. Dyachenko  ---
Sounds like -Wno-stringop-overflow does not propagate into LTO build.

I'll try make a small testcase

[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-13
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from janus at gcc dot gnu.org ---
Also it regtests cleanly.

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|marxin at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

--- Comment #21 from Nathan Sidwell  ---
yeah, I messed up.  I had presumed that once set, DECL_ASSEMBLER_NAME does not
change.  That is untrue.
In this case it's even worse, in that DECL_ASSEMBLER_NAME is set on a new decl
that duplicate_decl then deletes.  This is a latent bug that never triggered on
the old code, but would have left the global namespace pointing at dead
storage.

[Bug other/82965] New: [8 regression][armeb] gcc.dg/vect/pr79347.c starts failing after r254379

[clyon at gcc dot gnu.org]

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

Bug ID: 82965
   Summary: [8 regression][armeb] gcc.dg/vect/pr79347.c starts
failing after r254379
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

After r254379, I've noticed a regression on arm big-endian targets (armeb):
FAIL:gcc.dg/vect/pr79347.c -flto -ffat-lto-objects  scan-tree-dump-not vect
"Invalid sum of "
FAIL:gcc.dg/vect/pr79347.c scan-tree-dump-not vect "Invalid sum of "

This could be a duplicate of bug #82925, but that one targets ppc64 both LE and
BE.

[Bug bootstrap/82948] [8 Regression] prefix.c:202:15: error: 'char* strncpy(char*, const char*, size_t)' destination unchanged after copying no bytes [-Werror=stringop-truncation]

[sudi.das at arm dot com]

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

Sudakshina Das  changed:

   What|Removed |Added

 CC||sudi.das at arm dot com

--- Comment #3 from Sudakshina Das  ---
I think this is breaking glibc build on aarch64-none-linux-gnu and
arm-none-linux-gnueabihf. 

../sysdeps/unix/sysv/linux/if_index.c: In function '__if_nametoindex':
../sysdeps/unix/sysv/linux/if_index.c:46:3: error: 'strncpy' specified bound 16
equals destination size [-Werror=stringop-truncation]
   strncpy (ifr.ifr_name, ifname, sizeof (ifr.ifr_name));

[Bug libstdc++/82966] New: node_handle swap fails to compile

[dnljms at gmail dot com]

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

Bug ID: 82966
   Summary: node_handle swap fails to compile
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dnljms at gmail dot com
  Target Milestone: ---

Created attachment 42593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42593&action=edit
Simple demonstration of error

Swapping a node handle fails because 'propagate_on_container_swap' is a type
but is used as a value in bits/node_handle.h. It should be
'propagate_on_container_swap::value'. I've attached an example that fails to
compile.

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
(In reply to Dmitry G. Dyachenko from comment #12)

I'm afraid the warning in the constant string case is unavoidable.  The call is
folded at a point where the checker doesn't have access to the subsequent
statement.  At the same time, it can be viewed as a feature since the code
would be more clearly written simply as strcpy(p, "1").

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor  ---
(In reply to Dmitry G. Dyachenko from comment #12)

LTO doesn't interact with these warnings very well.  pr71907 and pr79062 track
a couple of the problems I know about.  If you find a different issue please do
open a new bug.

[Bug c/82967] New: "did you mean" suggestions are way too suggestive

[samuel.thiba...@ens-lyon.org]

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

Bug ID: 82967
   Summary: "did you mean" suggestions are way too suggestive
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samuel.thiba...@ens-lyon.org
  Target Milestone: ---

Hello,

The new suggestions brought by recent gcc are nice to catch up mere typoes.
They are however quite often misleading, I could for instance see

'PATH_MAX' undeclared (first use in this function); did you mean 'INT8_MAX'?
implicit declaration of function ‘time’; did you mean ‘nice’?
implicit declaration of function ‘bar’; did you mean ‘carg’?

programming beginners will start writing all kinds of crazy code due to this:
"the compiler told me to do it"...

Changing half of the letters of a word, or 3 or more letters, looks too
suggestive to me, I'd say it should be reduced to at most 2 letters, and less
than a quarter or a third of the word.

Samuel

[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Richard Biener from comment #3)

As I explained in comment #0, a_5(D)->d can safely be assumed not to point to
itself as a result of the subsequent access to what it points to in strlen, and
thanks to the fact that a string literal is never a valid representation of a
pointer.

Joseph's bare metal case of strlen (((struct A*)"123")->d) from comment #2
could be handled either by detecting and warning about it, or accommodated
under -ffreestanding or some new option to disable the optimization.

[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
Created attachment 42594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42594&action=edit
genmatch crash report

(In reply to Richard Biener from comment #3)
> Hmm, GCC 4.2 as host compiler and using non-standard flags (-Os).  Can you
> try
> with standard flags?  It's probably miscompiling libcpp and/or genmatch.

When removing -Os it instead segfaults:

build/genmatch --gimple ../../gcc/match.pd \
> tmp-gimple-match.c
/bin/sh: line 1: 76756 Segmentation fault  build/genmatch --gimple
../../gcc/match.pd > tmp-gimple-match.c
make[3]: *** [s-match] Error 139
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

Attaching the crash reporter log.

[Bug c/81117] Improve buffer overflow checking in strncpy

[dimhen at gmail dot com]

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

--- Comment #16 from Dmitry G. Dyachenko  ---
(In reply to Martin Sebor from comment #15)
Thank you. Nice warnings!

[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> Created attachment 42594 [details]
> genmatch crash report
> 
> (In reply to Richard Biener from comment #3)
> > Hmm, GCC 4.2 as host compiler and using non-standard flags (-Os).  Can you
> > try
> > with standard flags?  It's probably miscompiling libcpp and/or genmatch.
> 
> When removing -Os it instead segfaults:
> 
> build/genmatch --gimple ../../gcc/match.pd \
>   > tmp-gimple-match.c
> /bin/sh: line 1: 76756 Segmentation fault  build/genmatch --gimple
> ../../gcc/match.pd > tmp-gimple-match.c
> make[3]: *** [s-match] Error 139
> make[2]: *** [all-stage1-gcc] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2
> 
> Attaching the crash reporter log.

I should probably also include the compilation warnings from a little above the
crash:

/usr/bin/g++-4.2 -c   -g  -DIN_GCC -fPIC   -fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc -I../../gcc/build
-I../../gcc/../include  -I../../gcc/../libcpp/include -I/opt/local/include \
-o build/genmatch.o ../../gcc/genmatch.c
../../gcc/vec.h: In static member function ‘static size_t vec::embedded_size(unsigned int) [with T = c_expr::id_tab, A = va_heap]’:
../../gcc/vec.h:286:   instantiated from ‘static void va_heap::reserve(vec*&, unsigned int, bool) [with T = c_expr::id_tab]’
../../gcc/vec.h:1473:   instantiated from ‘bool vec::reserve(unsigned int, bool) [with T = c_expr::id_tab]’
../../gcc/vec.h:1582:   instantiated from ‘T* vec::safe_push(const T&) [with T = c_expr::id_tab]’
../../gcc/genmatch.c:1330:   instantiated from here
../../gcc/vec.h:1075: warning: invalid access to non-static data member
‘vec::m_vecdata’ of NULL object
../../gcc/vec.h:1075: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)
../../gcc/vec.h: In static member function ‘static size_t vec::embedded_size(unsigned int) [with T = std::pair,
A = va_heap]’:
../../gcc/vec.h:286:   instantiated from ‘static void va_heap::reserve(vec*&, unsigned int, bool) [with T = std::pair]’
../../gcc/vec.h:1473:   instantiated from ‘bool vec::reserve(unsigned int, bool) [with T = std::pair]’
../../gcc/vec.h:1493:   instantiated from ‘bool vec::reserve_exact(unsigned int) [with T = std::pair]’
../../gcc/vec.h:1556:   instantiated from ‘void vec::safe_splice(const vec&) [with T =
std::pair]’
../../gcc/genmatch.c:1462:   instantiated from here
../../gcc/vec.h:1075: warning: invalid access to non-static data member
‘vec, va_heap, vl_embed>::m_vecdata’ of NULL
object
../../gcc/vec.h:1075: warning: (perhaps the ‘offsetof’ macro was used
incorrectly)

[Bug fortran/82968] New: gfortran.dg/ieee/ieee_6.f90 fails at -O0

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 82968
   Summary: gfortran.dg/ieee/ieee_6.f90 fails at -O0
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc64-linux
Target: sparc64-linux
 Build: sparc64-linux

The test raises SIGBUS at run time:

Starting program: /1/ebotcazou/build/ieee_6 

Program received signal SIGBUS, Bus error.
__GI___fegetenv (envp=0x7fef14c) at ../sysdeps/sparc/fpu/fegetenv.c:25
25  ../sysdeps/sparc/fpu/fegetenv.c: No such file or directory.
(gdb) bt
#0  __GI___fegetenv (envp=0x7fef14c) at ../sysdeps/sparc/fpu/fegetenv.c:25
#1  0x00100c68 in MAIN__ () at ieee_6.f90:23

because envp is not a multiple of 8.  On this platform, fenv_t is defined as:

/* Type representing floating-point environment.  */
typedef unsigned long int fenv_t;

so fegetenv expects an address multiple of 8 (the size of 'long').


The problematic Fortran type is apparently declared in ieee_exceptions.F90:

  type, public :: IEEE_STATUS_TYPE
private
character(len=GFC_FPE_STATE_BUFFER_SIZE) :: hidden
  end type

with the GFC_FPE_STATE_BUFFER_SIZE parameter coming from libgfortran.h:

/* Size of the buffer required to store FPU state for any target.
   In particular, this has to be larger than fenv_t on all glibc targets.
   Currently, the winner is x86_64 with 32 bytes.  */
#define GFC_FPE_STATE_BUFFER_SIZE 32

This obviously overlooks alignment constraints.

[Bug lto/81351] [8 regression] Many LTO testcases FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov 13 17:26:41 2017
New Revision: 254697

URL: https://gcc.gnu.org/viewcvs?rev=254697&root=gcc&view=rev
Log:
PR lto/81351
* debug.h (dwarf2out_do_eh_frame): Declare.
* dwarf2cfi.c (dwarf2out_do_eh_frame): New predicate.
(dwarf2out_do_frame): Use it.
(dwarf2out_do_cfi_asm): Likewise.
* dwarf2out.c (dwarf2out_frame_finish): Likewise.
(dwarf2out_assembly_start): Likewise.
(dwarf2out_begin_prologue): Fix comment.
* toplev.c (compile_file): Always call dwarf2out_frame_finish
if the target needs either debug or unwind DWARF2 info.
* lto-opts.c (lto_write_options): Do not save -fexceptions,
-fnon-call-exceptions, -ffp-contract, -fmath-errno, -fsigned-zeros,
-ftrapping-math, -ftrapv and -fwrapv.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/debug.h
trunk/gcc/dwarf2cfi.c
trunk/gcc/dwarf2out.c
trunk/gcc/lto-opts.c
trunk/gcc/toplev.c

[Bug fortran/82969] New: ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211

[gs...@t-online.de]

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

Bug ID: 82969
   Summary: ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This variant does not compile with snapshot from 20171112 :


$ cat z1.f90
module m
   type t
  real, allocatable :: x(:)
  procedure(f), nopass, pointer :: g
   end type
contains
   function f() result(z)
  class(t), allocatable :: z
   end
end


$ gfortran-8-20171112 -c z1.f90
z1.f90:10:0:

 end

internal compiler error: Segmentation fault
0xb61c7f crash_signal
../../gcc/toplev.c:325
0x75c0de gfc_class_vptr_get(tree_node*)
../../gcc/fortran/trans-expr.c:211
0x75c6c8 class_vtab_field_get
../../gcc/fortran/trans-expr.c:280
0x75c6c8 gfc_class_vtab_size_get(tree_node*)
../../gcc/fortran/trans-expr.c:314
0x741de8 structure_alloc_comps
../../gcc/fortran/trans-array.c:8836
0x75ef9a gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8848
0x76d301 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10143
0x731de5 trans_code
../../gcc/fortran/trans.c:1843
0x75897c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x735841 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2206
0x6ea84d translate_all_program_units
../../gcc/fortran/parse.c:6078
0x6ea84d gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72f13f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


---

While configured with --enable-checking=yes :

$ gfortran-8-20171112-chk -c z1.f90
z1.f90:10:0:

 end

internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have function_type in gfc_class_data_get, at
fortran/trans-expr.c:188
0x610875 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9098
0x79578b tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/tree.h:3128
0x79578b gfc_class_data_get(tree_node*)
../../gcc/fortran/trans-expr.c:188
0x773896 structure_alloc_comps
../../gcc/fortran/trans-array.c:8834
0x799c4a gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8848
0x7ab3a9 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10143
0x75e3f5 trans_code
../../gcc/fortran/trans.c:1843
0x7913e8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x763399 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2206
0x715ced translate_all_program_units
../../gcc/fortran/parse.c:6078
0x715ced gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x75b20f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82969] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

These variants compile :


$ cat z2.f90
module m
   type t
  real, allocatable :: x(:)
  procedure(f), nopass, pointer :: g
   end type
contains
   function f() result(z)
  class(t), pointer :: z
   end
end


$ cat z3.f90
module m
   type t
  procedure(f), nopass, pointer :: g
   end type
contains
   function f() result(z)
  class(t), allocatable :: z
   end
end

[Bug lto/81351] [8 regression] Many LTO testcases FAIL

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Fixed at last.

[Bug lto/81351] [8 regression] Many LTO testcases FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov 13 17:29:37 2017
New Revision: 254700

URL: https://gcc.gnu.org/viewcvs?rev=254700&root=gcc&view=rev
Log:
PR lto/81351
* dwarf2out.c (do_eh_frame): New static variable.
(dwarf2out_begin_prologue): Set it.
(dwarf2out_frame_finish): Test it instead of dwarf2out_do_eh_frame.

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

[Bug fortran/82970] New: ICE in vptr_field_get, at fortran/trans-expr.c:264

[gs...@t-online.de]

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

Bug ID: 82970
   Summary: ICE in vptr_field_get, at fortran/trans-expr.c:264
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Wrapping source "x" :


$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: x(:)[:]
   class(t), allocatable :: z(:)
   allocate (x(2)[*])
   allocate (z, source=(x))
end


$ cat z2.f90
program p
   type t
   end type
   class(t), allocatable :: x(:)[:]
   class(t), allocatable :: z(:)
   allocate (x(2)[*])
   allocate (z, mold=(x))
end


$ gfortran-8-20171112 -c z1.f90 -fcoarray=single
z1.f90:7:0:

allocate (z, source=(x))

internal compiler error: Segmentation fault
0xb61c7f crash_signal
../../gcc/toplev.c:325
0x75b91f vptr_field_get
../../gcc/fortran/trans-expr.c:264
0x75c71d gfc_vptr_size_get(tree_node*)
../../gcc/fortran/trans-expr.c:325
0x79f9fb gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5842
0x731ce7 trans_code
../../gcc/fortran/trans.c:1980
0x75897c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x6ea920 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x6ea920 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72f13f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82970] ICE in vptr_field_get, at fortran/trans-expr.c:264

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

This variant compiles, of course :


$ cat z3.f90
program p
   type t
   end type
   class(t), allocatable :: x(:)[:]
   class(t), allocatable :: z(:)
   allocate (x(2)[*])
   allocate (z, source=x)
end

[Bug fortran/82971] New: ICE in gfc_find_derived_vtab, at fortran/class.c:2214 ...

[gs...@t-online.de]

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

Bug ID: 82971
   Summary: ICE in gfc_find_derived_vtab, at fortran/class.c:2214
...
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Another issue :


$ cat z1.f90
module m
   type t
  integer :: n
   end type
   class(t), target :: z
   type t2
  class(t), pointer :: x => z
   end type
end


$ gfortran-8-20171112 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb61c7f crash_signal
../../gcc/toplev.c:325
0x671d71 gfc_find_derived_vtab(gfc_symbol*)
../../gcc/fortran/class.c:2214
0x6760d3 gfc_find_vtab(gfc_typespec*)
../../gcc/fortran/class.c:2837
0x699092 gfc_check_pointer_assign(gfc_expr*, gfc_expr*)
../../gcc/fortran/expr.c:3738
0x699dca gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*)
../../gcc/fortran/expr.c:3947
0x706aaa resolve_component
../../gcc/fortran/resolve.c:13870
0x7072a2 resolve_fl_derived0
../../gcc/fortran/resolve.c:13982
0x70750b resolve_fl_derived
../../gcc/fortran/resolve.c:14077
0x7020cf resolve_symbol
../../gcc/fortran/resolve.c:14436
0x71cb8b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x70548a resolve_types
../../gcc/fortran/resolve.c:16328
0x700dbc gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16442
0x6eac74 gfc_parse_file()
../../gcc/fortran/parse.c:6232
0x72f13f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82971] ICE in gfc_find_derived_vtab, at fortran/class.c:2214 ...

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

$ cat z2.f90
module m
   type t
   end type
   class(t), target :: z
   type t2
  class(t), pointer :: x => z
   end type
end


$ gfortran-8-20171112 -c z2.f90
f951: internal compiler error: Segmentation fault
0xb61c7f crash_signal
../../gcc/toplev.c:325
0x6760cb gfc_find_vtab(gfc_typespec*)
../../gcc/fortran/class.c:2837
0x699092 gfc_check_pointer_assign(gfc_expr*, gfc_expr*)
../../gcc/fortran/expr.c:3738
0x699dca gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*)
../../gcc/fortran/expr.c:3947
0x706aaa resolve_component
../../gcc/fortran/resolve.c:13870
0x7072a2 resolve_fl_derived0
../../gcc/fortran/resolve.c:13982
0x70750b resolve_fl_derived
../../gcc/fortran/resolve.c:14077
0x7020cf resolve_symbol
../../gcc/fortran/resolve.c:14436
0x71cb8b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x70548a resolve_types
../../gcc/fortran/resolve.c:16328
0x700dbc gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16442
0x6eac74 gfc_parse_file()
../../gcc/fortran/parse.c:6232
0x72f13f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c/81117] Improve buffer overflow checking in strncpy

[bugzi...@poradnik-webmastera.com]

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

--- Comment #17 from Daniel Fruzynski  ---
(In reply to Martin Sebor from comment #14)
> (In reply to Dmitry G. Dyachenko from comment #12)
> 
> I'm afraid the warning in the constant string case is unavoidable.  The call
> is folded at a point where the checker doesn't have access to the subsequent
> statement.  At the same time, it can be viewed as a feature since the code
> would be more clearly written simply as strcpy(p, "1").

This can be resolved in this way. However strcpy is not recommended because it
does not check buffer size and can cause buffer overflow (however in this
particular case it would be safe to use). It would be good to use strlcpy here,
however it is not supported by gcc/glibc now. Maybe these new warnings will
help with adding them to gcc/glibc, I saw that many people in the past
requested this but without luck.

[Bug tree-optimization/82945] add warning for passing non-strings to functions that expect string arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00955.html

[Bug sanitizer/82869] c_associated does not always give false for null pointers

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist  ---
Author: jb
Date: Mon Nov 13 20:01:20 2017
New Revision: 254706

URL: https://gcc.gnu.org/viewcvs?rev=254706&root=gcc&view=rev
Log:
Introduce logical_type_node and use it

Backport from trunk.

Earlier GFortran used to redefine boolean_type_node, which in the rest
of the compiler means the C/C++ _Bool/bool type, to the Fortran
default logical type.  When this redefinition was removed, a few
issues surfaced. Namely,

1) PR 82869, where we created a boolean tmp variable, and passed it to
the runtime library as a Fortran logical variable of a different size.

2) Fortran specifies that logical operations should be done with the
default logical kind, not in any other kind.

3) Using 8-bit variables have some issues, such as
   - on x86, partial register stalls and length prefix changes.
  - s390 has a compare with immediate and jump instruction which
   works with 32-bit but not 8-bit quantities.

This patch addresses these issues by introducing a type
logical_type_node which is a Fortran LOGICAL variable of default
kind. It is then used in places were the Fortran standard mandates, as
well as for compiler generated temporary variables.

For x86-64, using the Polyhedron benchmark suite, no performance or
code size difference worth mentioning was observed.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2017-11-13  Janne Blomqvist  

PR 82869
* convert.c (truthvalue_conversion): Use logical_type_node.
* trans-array.c (gfc_trans_allocate_array_storage): Likewise.
(gfc_trans_create_temp_array): Likewise.
(gfc_trans_array_ctor_element): Likewise.
(gfc_trans_array_constructor_value): Likewise.
(trans_array_constructor): Likewise.
(trans_array_bound_check): Likewise.
(gfc_conv_array_ref): Likewise.
(gfc_trans_scalarized_loop_end): Likewise.
(gfc_conv_array_extent_dim): Likewise.
(gfc_array_init_size): Likewise.
(gfc_array_allocate): Likewise.
(gfc_trans_array_bounds): Likewise.
(gfc_trans_dummy_array_bias): Likewise.
(gfc_conv_array_parameter): Likewise.
(duplicate_allocatable): Likewise.
(duplicate_allocatable_coarray): Likewise.
(structure_alloc_comps): Likewise
(get_std_lbound): Likewise
(gfc_alloc_allocatable_for_assignment): Likewise
* trans-decl.c (add_argument_checking): Likewise
(gfc_generate_function_code): Likewise
* trans-expr.c (gfc_copy_class_to_class): Likewise
(gfc_trans_class_array_init_assign): Likewise
(gfc_trans_class_init_assign): Likewise
(gfc_conv_expr_present): Likewise
(gfc_conv_substring): Likewise
(gfc_conv_cst_int_power): Likewise
(gfc_conv_expr_op): Likewise
(gfc_conv_procedure_call): Likewise
(fill_with_spaces): Likewise
(gfc_trans_string_copy): Likewise
(gfc_trans_alloc_subarray_assign): Likewise
(gfc_trans_pointer_assignment): Likewise
(gfc_trans_scalar_assign): Likewise
(fcncall_realloc_result): Likewise
(alloc_scalar_allocatable_for_assignment): Likewise
(trans_class_assignment): Likewise
(gfc_trans_assignment_1): Likewise
* trans-intrinsic.c (build_fixbound_expr): Likewise
(gfc_conv_intrinsic_aint): Likewise
(gfc_trans_same_strlen_check): Likewise
(conv_caf_send): Likewise
(trans_this_image): Likewise
(conv_intrinsic_image_status): Likewise
(trans_image_index): Likewise
(gfc_conv_intrinsic_bound): Likewise
(conv_intrinsic_cobound): Likewise
(gfc_conv_intrinsic_mod): Likewise
(gfc_conv_intrinsic_dshift): Likewise
(gfc_conv_intrinsic_dim): Likewise
(gfc_conv_intrinsic_sign): Likewise
(gfc_conv_intrinsic_ctime): Likewise
(gfc_conv_intrinsic_fdate): Likewise
(gfc_conv_intrinsic_ttynam): Likewise
(gfc_conv_intrinsic_minmax): Likewise
(gfc_conv_intrinsic_minmax_char): Likewise
(gfc_conv_intrinsic_anyall): Likewise
(gfc_conv_intrinsic_arith): Likewise
(gfc_conv_intrinsic_minmaxloc): Likewise
(gfc_conv_intrinsic_minmaxval): Likewise
(gfc_conv_intrinsic_btest): Likewise
(gfc_conv_intrinsic_bitcomp): Likewise
(gfc_conv_intrinsic_shift): Likewise
(gfc_conv_intrinsic_ishft): Likewise
(gfc_conv_intrinsic_ishftc): Likewise
(gfc_conv_intrinsic_leadz): Likewise
(gfc_conv_intrinsic_trailz): Likewise
(gfc_conv_intrinsic_mask): Likewise
(gfc_conv_intrinsic_spacing): Likewise
(gfc_conv_intrinsic_rrspacing): Likewise
(gfc_conv_intrinsic_size): Likewise
(gfc_conv_intrinsic_sizeof): Likewise
(gfc_conv_intrinsic_transfer): Likewise
(gfc_conv_allocated): Likewise
(gfc_conv_associated): Like

[Bug sanitizer/82869] c_associated does not always give false for null pointers

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #10 from Janne Blomqvist  ---
Fixed now on the gcc-7 branch as well. Thanks James for reporting, and Martin
for bisecting!

[Bug sanitizer/82869] c_associated does not always give false for null pointers

[james.s.spencer at gmail dot com]

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

--- Comment #11 from james.s.spencer at gmail dot com ---
(In reply to Janne Blomqvist from comment #10)
> Fixed now on the gcc-7 branch as well. Thanks James for reporting, and
> Martin for bisecting!

Thanks for the quick fix!

[Bug fortran/82970] ICE in vptr_field_get, at fortran/trans-expr.c:264

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 6.4.0 up to trunk (8.0).

If I replace

   allocate (z, source=(x))

with

allocate (z(2), source=(x))

compiling the test gives an ICE also for 4.8, 4.9, and 5.

[Bug fortran/78619] [6/7/8 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:889

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Mon Nov 13 20:43:26 2017
New Revision: 254708

URL: https://gcc.gnu.org/viewcvs?rev=254708&root=gcc&view=rev
Log:
2017-11-13  Paul Thomas  

Backport from trunk
PR fortran/78619
* check.c (same_type_check): Introduce a new argument 'assoc'
with default value false. If this is true, use the symbol type
spec of BT_PROCEDURE expressions.
(gfc_check_associated): Set 'assoc' true in the call to
'same_type_check'.

2017-11-13  Paul Thomas  

Backport from trunk
PR fortran/78619
* gfortran.dg/pr78619.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr78619.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/check.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Mon Nov 13 20:46:08 2017
New Revision: 254709

URL: https://gcc.gnu.org/viewcvs?rev=254709&root=gcc&view=rev
Log:
2017-11-13  Paul Thomas  

Backport from trunk
PR fortran/82934
* trans-stmt.c (gfc_trans_allocate): Remove the gcc_assert on
null string length for assumed length typespec and set
expr3_esize to NULL_TREE;

2017-11-13  Paul Thomas  

Backport from trunk
PR fortran/82934
* gfortran.dg/allocate_assumed_charlen_1.f90: New test.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_1.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-stmt.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82972] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Files from catalog ./gcc/testsuite/gfortran.dg :
   pdt_10.f03
   pdt_2.f03


$ gfortran-8-20171105 -finit-derived -c pdt_2.f03
$ gfortran-8-20171112 -finit-derived -c pdt_2.f03
pdt_2.f03:25:0:

   end subroutine

internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148
0x77ff69 gfc_conv_string_init(tree_node*, gfc_expr*)
../../gcc/fortran/trans-const.c:148
0x7a827f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:6874
0x7a8921 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7735
0x7a82b1 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:6867
0x78c5fc gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1819
0x790327 generate_local_decl
../../gcc/fortran/trans-decl.c:5492
0x74802b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x7910f2 generate_local_vars
../../gcc/fortran/trans-decl.c:5692
0x7910f2 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6356
0x715dc0 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x715dc0 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x75b20f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82972] New: ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

[gs...@t-online.de]

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

Bug ID: 82972
   Summary: ICE with -finit-derived in gfc_conv_structure, at
fortran/trans-expr.c:7733 (and others)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

There are a few issues with -finit-derived, probably a consequence
of pr82886. Please feel free to open separate PRs if it fits better.
gcc configured with --enable-checking=yes.


Files from catalog ./gcc/testsuite/gfortran.dg :
   c_ptr_tests_14.f90
   c_ptr_tests_15.f90
   pr32627.f03
   pr35983.f90
   lto/bind_c-1_0.f90


$ gfortran-8-20171105 -finit-derived -c c_ptr_tests_14.f90
$ gfortran-8-20171112 -finit-derived -c c_ptr_tests_14.f90
c_ptr_tests_14.f90:25:0:

 program test

internal compiler error: Segmentation fault
0xcaca2f crash_signal
../../gcc/toplev.c:325
0x7a88f6 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3201
0x7a88f6 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7733
0x7a82b1 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:6867
0x7a8921 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7735
0x7a82b1 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:6867
0x78c5fc gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1819
0x790327 generate_local_decl
../../gcc/fortran/trans-decl.c:5492
0x74802b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x7910f2 generate_local_vars
../../gcc/fortran/trans-decl.c:5692
0x7910f2 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6356
0x715dc0 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x715dc0 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x75b20f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82972] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

[gs...@t-online.de]

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

--- Comment #2 from G. Steinmetz  ---

Files from catalog ./gcc/testsuite/gfortran.dg :
   pdt_3.f03
   pdt_7.f03


$ gfortran-8-20171105 -finit-derived -c pdt_7.f03
$ gfortran-8-20171112 -finit-derived -c pdt_7.f03
pdt_7.f03:20:0:

 end

internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6983
0x77b4fb gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:6983
0x7a37b1 gfc_trans_alloc_subarray_assign
../../gcc/fortran/trans-expr.c:7001
0x7a6d99 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7339
0x7a6687 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7622
0x7a8c02 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7689
0x7a1074 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7856
0x7aaba9 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:1
0x785030 gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool)
../../gcc/fortran/trans-decl.c:4010
0x78ee21 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4688
0x791563 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6526
0x715dc0 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x715dc0 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x75b20f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82971] ICE in gfc_find_derived_vtab, at fortran/class.c:2214 ...

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0).

My instrumented compiler gives

../../work/gcc/fortran/class.c:2837:36: runtime error: member access within
null pointer of type 'struct gfc_component'

[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

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

[Bug fortran/82973] New: ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[marxin at gcc dot gnu.org]

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

Bug ID: 82973
   Summary: ICE in output_constant_pool_2, at varasm.c:3896 on
aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

Trunk does with cross compiler:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/intrinsic_modulo_1.f90
-frounding-math -Ofast -c
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/intrinsic_modulo_1.f90:37:0:

 end program main

internal compiler error: in output_constant_pool_2, at varasm.c:3896
0xee97bb output_constant_pool_2
.././../gcc/varasm.c:3896
0xee974d output_constant_pool_2
.././../gcc/varasm.c:3929
0xee9846 output_constant_pool_1
.././../gcc/varasm.c:3997
0xef85d9 output_constant_pool_contents
.././../gcc/varasm.c:4134
0xef9003 output_constant_pool
.././../gcc/varasm.c:4162
0xef9003 assemble_end_function(tree_node*, char const*)
.././../gcc/varasm.c:1912
0x8b0f3f rest_of_handle_final
.././../gcc/final.c:4488
0x8b0f3f execute
.././../gcc/final.c:4551

[Bug target/82974] New: ICE in extract_insn, at recog.c:2305 on aarch64

[marxin at gcc dot gnu.org]

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

Bug ID: 82974
   Summary: ICE in extract_insn, at recog.c:2305 on aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

Following cross-compiler ICEs:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/dfp/inf-1.c -O1 -c
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/dfp/inf-1.c: In
function ‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/dfp/inf-1.c:61:1:
error: unrecognizable insn:
 }
 ^
(insn 103 102 104 13 (set (subreg:TI (reg:TD 113) 0)
(const_wide_int 0x77ffcff3fcff3fcff3fcff3fcff3fcff))
"/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/dfp/inf-1.c":26 -1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/dfp/inf-1.c:61:1:
internal compiler error: in extract_insn, at recog.c:2305
0x57c010 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../gcc/rtl-error.c:108
0x57c02f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.././../gcc/rtl-error.c:116
0xacdd2f extract_insn(rtx_insn*)
.././../gcc/recog.c:2305
0x883ceb instantiate_virtual_regs_in_insn
.././../gcc/function.c:1591
0x883ceb instantiate_virtual_regs
.././../gcc/function.c:1959
0x883ceb execute
.././../gcc/function.c:2008

[Bug fortran/82972] [8 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-13
 CC||foreese at gcc dot gnu.org
Summary|ICE with -finit-derived in  |[8 Regression] ICE with
   |gfc_conv_structure, at  |-finit-derived in
   |fortran/trans-expr.c:7733   |gfc_conv_structure, at
   |(and others)|fortran/trans-expr.c:7733
   ||(and others)
 Ever confirmed|0   |1

[Bug fortran/82972] [8 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

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

--- Comment #3 from Fritz Reese  ---
Yikes! I'll take a look, thanks for the report.

[Bug target/82975] New: ICE in baseness at rtlanal.c:6220

[marxin at gcc dot gnu.org]

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

Bug ID: 82975
   Summary: ICE in baseness at rtlanal.c:6220
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: arm-linux-gnueabi-gcc

Following can be seen with cross-compiler:

$ arm-linux-gnueabi-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78904-6.c
/dev/null -mtune=cortex-a57 -fno-sched-pressure -O3
during RTL pass: sched1
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78904-6.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78904-6.c:20:1:
internal compiler error: Segmentation fault
 }
 ^
0xb692af crash_signal
.././../gcc/toplev.c:325
0xaff79d baseness
.././../gcc/rtlanal.c:6220
0xb075c9 decompose_normal_address
.././../gcc/rtlanal.c:6290
0xb075c9 decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
.././../gcc/rtlanal.c:6336
0x1256745 analyze_set_insn_for_autopref
.././../gcc/haifa-sched.c:5535
0x1256932 analyze_set_insn_for_autopref
.././../gcc/haifa-sched.c:5621
0x1256932 autopref_multipass_init
.././../gcc/haifa-sched.c:5621
0x12601ea autopref_multipass_dfa_lookahead_guard(rtx_insn*, int)
.././../gcc/haifa-sched.c:5734
0x126a8d9 choose_ready
.././../gcc/haifa-sched.c:6121
0x126a8d9 schedule_block(basic_block_def**, void*)
.././../gcc/haifa-sched.c:6763
0xb1034a schedule_region
.././../gcc/sched-rgn.c:3174
0xb1034a schedule_insns()
.././../gcc/sched-rgn.c:3513
0xb10863 schedule_insns()
.././../gcc/sched-rgn.c:3498
0xb10863 rest_of_handle_sched
.././../gcc/sched-rgn.c:3717
0xb10863 execute
.././../gcc/sched-rgn.c:3825

[Bug fortran/82973] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-13
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Has the test compiled on aarch64-linux-gnu-gcc with the options?

Note that the test fails at run time when compiled with -frounding-math and
-Ofast.

[Bug fortran/82976] New: [8 Regression] Error: non-trivial conversion at assignment since r254526

[marxin at gcc dot gnu.org]

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

Bug ID: 82976
   Summary: [8 Regression] Error: non-trivial conversion at
assignment since r254526
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jb at gcc dot gnu.org
  Target Milestone: ---

Starting from the mentioned revision we ICE on:

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_16.f90
-Ofast -fno-tree-forwprop

Error: non-trivial conversion at assignment
logical(kind=4)
logical(kind=1)
_54 = 0;
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_16.f90:28:0:
Error: non-trivial conversion at assignment
logical(kind=4)
logical(kind=1)
_47 = 0;
during GIMPLE pass: dom
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_16.f90:28:0:
internal compiler error: verify_gimple failed
0xc63c6d verify_gimple_in_cfg(function*, bool)
.././../gcc/tree-cfg.c:5392
0xb36fc6 execute_function_todo
.././../gcc/passes.c:1994
0xb38042 execute_todo
.././../gcc/passes.c:2048

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||foreese at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #4 from Fritz Reese  ---
> https://gcc.gnu.org/ml/fortran/2017-11/msg00076.html

Patch pending.

[Bug c++/82360] [8 Regression] tree check fail in get_inner_reference, at expr.c:6996

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Mon Nov 13 21:49:16 2017
New Revision: 254710

URL: https://gcc.gnu.org/viewcvs?rev=254710&root=gcc&view=rev
Log:
PR c++/82360 - ICE with static_cast in template.

* call.c (perform_direct_initialization_if_possible): Check
processing_template_decl.
* typeck.c (build_static_cast_1): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/template/cast5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/typeck.c

[Bug tree-optimization/82977] New: [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971

[marxin at gcc dot gnu.org]

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

Bug ID: 82977
   Summary: [8 Regression] AddressSanitizer: heap-use-after-free
in strlen_optimize_stmt
.././../gcc/tree-ssa-strlen.c:2971
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Probably starting from Martin's r254630 sanitizer compiler produces:

$ gcc -g -O2 cp-demangle.i

==22482==ERROR: AddressSanitizer: heap-use-after-free on address 0x61100448
at pc 0x00779828 bp 0x7fffec942150 sp 0x7fffec942148
READ of size 4 at 0x61100448 thread T0
#0 0x779827 in std::pair::operator=(std::pair const&)
/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-asan/build/builddir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:372
#1 0x779827 in hash_map,
simple_hashmap_traits, std::pair > >::put(tree_node* const&, std::pair const&)
.././../gcc/hash-map.h:142
#2 0x779827 in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971
#3 0x779827 in strlen_dom_walker::before_dom_children(basic_block_def*)
.././../gcc/tree-ssa-strlen.c:3137
#4 0x2fc26b7 in dom_walker::walk(basic_block_def*)
.././../gcc/domwalk.c:308
#5 0x1efb4c9 in execute .././../gcc/tree-ssa-strlen.c:3209
#6 0x174c5eb in execute_one_pass(opt_pass*) .././../gcc/passes.c:2497
#7 0x174ddc2 in execute_pass_list_1 .././../gcc/passes.c:2586
#8 0x174ddec in execute_pass_list_1 .././../gcc/passes.c:2587
#9 0x174de6b in execute_pass_list(function*, opt_pass*)
.././../gcc/passes.c:2597
#10 0xea9e27 in cgraph_node::expand() .././../gcc/cgraphunit.c:2139
#11 0xeacb2a in expand_all_functions .././../gcc/cgraphunit.c:2275
#12 0xeacb2a in symbol_table::compile() .././../gcc/cgraphunit.c:2623
#13 0xeb3470 in symbol_table::compile() .././../gcc/cgraphunit.c:2719
#14 0xeb3470 in symbol_table::finalize_compilation_unit()
.././../gcc/cgraphunit.c:2716
#15 0x1a04bcd in compile_file .././../gcc/toplev.c:480
#16 0x97ecd7 in do_compile .././../gcc/toplev.c:2060
#17 0x97ecd7 in toplev::main(int, char**) .././../gcc/toplev.c:2195
#18 0x9893c4 in main .././../gcc/main.c:39
#19 0x7fe5161e0f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#20 0x98a5c9 in _start
(/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-asan/build/builddir/gcc/cc1+0x98a5c9)

0x61100448 is located 72 bytes inside of 208-byte region
[0x61100400,0x611004d0)
freed by thread T0 here:
#0 0xa51240 in __interceptor_free
../../.././../libsanitizer/asan/asan_malloc_linux.cc:66
#1 0x1f10fcb in xcallocator, simple_hashmap_traits, std::pair > >::hash_entry>::data_free(hash_map, simple_hashmap_traits,
std::pair > >::hash_entry*) .././../gcc/hash-table.h:273
#2 0x1f10fcb in hash_table, simple_hashmap_traits, std::pair > >::hash_entry, xcallocator>::expand()
.././../gcc/hash-table.h:765

previously allocated by thread T0 here:
#0 0xa5175c in __interceptor_calloc
../../.././../libsanitizer/asan/asan_malloc_linux.cc:95
#1 0x33f8e50 in xcalloc .././../libiberty/xmalloc.c:162

SUMMARY: AddressSanitizer: heap-use-after-free
/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-asan/build/builddir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:372
in std::pair::operator=(std::pair const&)
Shadow bytes around the buggy address:
  0x0c227fff8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff8040: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
  0x0c227fff8050: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff8060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff8070: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c227fff8080: fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd
  0x0c227fff8090: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x0c227fff80a0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff80b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff80c0: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff80d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==22482==ABORTING

[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 42595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42595&action=edit
test-case

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
(In reply to Nathan Sidwell from comment #21)
> yeah, I messed up.  I had presumed that once set, DECL_ASSEMBLER_NAME does
> not change.  That is untrue.
> In this case it's even worse, in that DECL_ASSEMBLER_NAME is set on a new
> decl that duplicate_decl then deletes.  This is a latent bug that never
> triggered on the old code, but would have left the global namespace pointing
> at dead storage.

Good, I'm happy you're able to reproduce and to fix that ;)

[Bug fortran/82973] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Martin Liška  ---
(In reply to Dominique d'Humieres from comment #1)
> Has the test compiled on aarch64-linux-gnu-gcc with the options?

No, it also ICEs ;)

[Bug c++/82360] [8 Regression] tree check fail in get_inner_reference, at expr.c:6996

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

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

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[foreese at gcc dot gnu.org]

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

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Tue Nov 14 01:25:26 2017
New Revision: 254718

URL: https://gcc.gnu.org/viewcvs?rev=254718&root=gcc&view=rev
Log:
2017-11-13  Fritz Reese 

PR fortran/78240

gcc/fortran/ChangeLog:

PR fortran/78240
* decl.c (match_clist_expr): Replace gcc_assert with proper
handling of bad result from spec_size().
* resolve.c (check_data_variable): Avoid NULL dereference when passing
locus to gfc_error.

gcc/testsuite/ChangeLog:

PR fortran/78240
* gfortran.dg/dec_structure_23.f90: New.
* gfortran.dg/pr78240.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90
trunk/gcc/testsuite/gfortran.dg/pr78240.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82978] New: [PDT] [F2003] Paramaterized Derived Type LEN parameters take the latest value per-kind

[foreese at gcc dot gnu.org]

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

Bug ID: 82978
   Summary: [PDT] [F2003] Paramaterized Derived Type LEN
parameters take the latest value per-kind
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42596&action=edit
test case exhibiting strange PDT behavior

In the attached file I see what I believe is unusual behavior. I skimmed the
F03/F08 specs and by all accounts I could see, this behavior is unexpected.

To summarize/generalize the test file, with the following declarations:

> type :: pdt_t(k, l)
> integer, kind :: k
> integer, len :: l
> character(len=l) :: ch
> end type
> 
> type(pdt_t(k, l1)) :: t1
> type(pdt_t(k, l2)) :: t2
> ...
> type(pdt_t(k, ln)) :: tn

Then I see that len(t1%ch) == len(t2%ch) == ... == len(tn%ch) == ln. That is to
say, every PDT variable gets ch with the last length defined for the same kind.
If different kinds are passed, then the lengths seem to differ fine.

Here is my output for the attached file:

$ gfortran --version
GNU Fortran (GCC) 8.0.0 20171107 (experimental)
[...]
$ gfortran pdtlens.f03
$ ./a.out
 exp. len   act. len
   1   2
   2   2
   4   5
   5   5
   9   7
   7   7
 100 200
 200 200


Am I just misinterpreting the Fortran spec, or is this a real bug?

[Bug c++/60702] thread_local initialization

[tinrow at gmail dot com]

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

Kan Wang  changed:

   What|Removed |Added

 CC||tinrow at gmail dot com

--- Comment #5 from Kan Wang  ---
+1 for this. If class member has thread-local storage and is first accessed
through member access operator (e.g. a.foo), it is not initialized as expected.

The short code snippet below reproduces the bug on g++ 4.8 - 7.1

#include 
int init() {
std::cout << "init" << std::endl;
return 0;
}

struct A {
static thread_local int foo;
};
thread_local int A::foo { init() };

int main() {
A a;
int i = a.foo;
std::cout << "--- should be initialized above ---" << std::endl;
i = A::foo;
return i;
}

Output:
--- should be initialized above ---
init

[Bug fortran/82979] New: [PDT] [F2003] [ice-on-invalid] ICE (segfault) on invalid type-param-name-list in PDT declaration

[foreese at gcc dot gnu.org]

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

Bug ID: 82979
   Summary: [PDT] [F2003] [ice-on-invalid] ICE (segfault) on
invalid type-param-name-list in PDT declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42597&action=edit
test case which causes the ICE

Currently the compiler ICEs due to a segmentation fault when given an invalid
type-param-name-list, such as in the attached file (and shown here):

$ gfortran --version | head -n1
GNU Fortran (GCC) 8.0.0 20171114 (experimental)
$ cat ./test.f03
type :: pdt_t(k=4)
  integer, kind :: k
end type
end
$ gfortran ./test.f03
./test.f03:1:15:

 type :: pdt_t(k=4)
   1
Error: Expected parameter list in type declaration at (1)
f951: internal compiler error: Segmentation fault
0xca9a9f crash_signal
/data/midas/foreese/src/gcc-dev/gcc/toplev.c:325
0x6d260a delete_root
/data/midas/foreese/src/gcc-dev/gcc/fortran/bbt.c:150
0x6d27be gfc_delete_bbt(void*, void*, int (*)(void*, void*))
/data/midas/foreese/src/gcc-dev/gcc/fortran/bbt.c:197
0x789128 gfc_delete_symtree(gfc_symtree**, char const*)
/data/midas/foreese/src/gcc-dev/gcc/fortran/symbol.c:2925
0x78a8bf gfc_restore_last_undo_checkpoint()
/data/midas/foreese/src/gcc-dev/gcc/fortran/symbol.c:3694
0x74af47 reject_statement
/data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:2546
0x74afa4 match_word
/data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:70
0x74e30f decode_statement
/data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:565
0x74f32c next_free
/data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:1225
0x74f32c next_statement
/data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:1457
0x7545f1 gfc_parse_file()
/data/midas/foreese/src/gcc-dev/gcc/fortran/parse.c:6160
0x7987bf gfc_be_parse_file
/data/midas/foreese/src/gcc-dev/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/82980] New: Regression in determination of current instantiation (invalid requirement of template keyword)

[barry.revzin at gmail dot com]

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

Bug ID: 82980
   Summary: Regression in determination of current instantiation
(invalid requirement of template keyword)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example (reduced from SO:
https://stackoverflow.com/q/47261553/2069064)

template 
struct Outer
{
template 
void f();

void bar(Outer outer) {
[outer](){ outer.f(); }; // error
}
};

int main() { }

outer is an instance of the current instantiation, so outer.f isn't type
dependent, so the template keyword shouldn't be required. However, gcc 7 and
later diagnose:

prog.cc: In lambda function:
prog.cc:8:28: error: expected primary-expression before 'int'
 [outer](){ outer.f(); };
^~~
prog.cc:8:28: error: expected ';' before 'int'

gcc 6.3 and earlier accept, as does clang.

[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2017-11-13 00:00:00 |2017-11-14
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I don't have a sanitizer build but I think it's safe to confirm there's
something wrong based on the Valgrind output below.

$ gcc -O2 -S -Wall pr82977.i  -wrapper valgrind
==10920== Memcheck, a memory error detector
==10920== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10920== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==10920== Command: /ssd/build/gcc-git/gcc/cc1 -fpreprocessed pr82977.i -quiet
-dumpbase pr82977.i -mtune=generic -march=x86-64 -auxbase pr82977 -O2 -Wall -o
pr82977.s
==10920== 
In file included from cp-demangle.c:140:
/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-asan/build/libstdc++-v3/../libiberty/cp-demangle.h:184:1:
warning: ‘cplus_demangle_mangled_name’ declared ‘static’ but never defined
[-Wunused-function]
/home/marxin/BIG/buildbot/slave/gcc-master-bootstrap-asan/build/libstdc++-v3/../libiberty/cp-demangle.h:188:1:
warning: ‘cplus_demangle_type’ declared ‘static’ but never defined
[-Wunused-function]
cp-demangle.c:4323:1: warning: ‘d_print’ defined but not used
[-Wunused-function]
==10920== Invalid read of size 8
==10920==at 0x101C826: hash_map,
simple_hashmap_traits, std::pair > >::put(tree_node* const&, std::pair const&)
(hash-map.h:142)
==10920==by 0x101B8DF: strlen_optimize_stmt(gimple_stmt_iterator*)
(tree-ssa-strlen.c:2972)
==10920==by 0x101BFA8:
strlen_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-strlen.c:3138)
==10920==by 0x17BB4F9: dom_walker::walk(basic_block_def*) (domwalk.c:308)
==10920==by 0x101C1A5: (anonymous
namespace)::pass_strlen::execute(function*) (tree-ssa-strlen.c:3210)
==10920==by 0xCDD02C: execute_one_pass(opt_pass*) (passes.c:2497)
==10920==by 0xCDD37B: execute_pass_list_1(opt_pass*) (passes.c:2586)
==10920==by 0xCDD3AC: execute_pass_list_1(opt_pass*) (passes.c:2587)
==10920==by 0xCDD404: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==10920==by 0x92DF5F: cgraph_node::expand() (cgraphunit.c:2139)
==10920==by 0x92E403: expand_all_functions() (cgraphunit.c:2275)
==10920==by 0x92EE87: symbol_table::compile() (cgraphunit.c:2623)
==10920==  Address 0x63cd178 is 136 bytes inside a block of size 208 free'd
==10920==at 0x4C2ED4A: free (vg_replace_malloc.c:530)
==10920==by 0x101D837: xcallocator, simple_hashmap_traits,
std::pair > >::hash_entry>::data_free(hash_map,
simple_hashmap_traits, std::pair > >::hash_entry*) (hash-table.h:273)
==10920==by 0x101DE6B: hash_table, simple_hashmap_traits,
std::pair > >::hash_entry, xcallocator>::expand()
(hash-table.h:765)
==10920==by 0x101D28B: hash_table, simple_hashmap_traits,
std::pair > >::hash_entry,
xcallocator>::find_slot_with_hash(tree_node* const&, unsigned int,
insert_option) (hash-table.h:879)
==10920==by 0x101C7EE: hash_map,
simple_hashmap_traits, std::pair > >::put(tree_node* const&, std::pair const&)
(hash-map.h:137)
==10920==by 0x101B8DF: strlen_optimize_stmt(gimple_stmt_iterator*)
(tree-ssa-strlen.c:2972)
==10920==by 0x101BFA8:
strlen_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-strlen.c:3138)
==10920==by 0x17BB4F9: dom_walker::walk(basic_block_def*) (domwalk.c:308)
==10920==by 0x101C1A5: (anonymous
namespace)::pass_strlen::execute(function*) (tree-ssa-strlen.c:3210)
==10920==by 0xCDD02C: execute_one_pass(opt_pass*) (passes.c:2497)
==10920==by 0xCDD37B: execute_pass_list_1(opt_pass*) (passes.c:2586)
==10920==by 0xCDD3AC: execute_pass_list_1(opt_pass*) (passes.c:2587)
==10920==  Block was alloc'd at
==10920==at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
==10920==by 0x197B203: xcalloc (xmalloc.c:162)
==10920==by 0x101E156: xcallocator, simple_hashmap_traits,
std::pair > >::hash_entry>::data_alloc(unsigned long)
(hash-table.h:263)
==10920==by 0x101D765: hash_table, simple_hashmap_traits,
std::pair > >::hash_entry,
xcallocator>::alloc_entries(unsigned long) const (hash-table.h:650)
==10920==by 0x101CAD8: hash_table, simple_hashmap_traits,
std::pair > >::hash_entry, xcallocator>::hash_table(unsigned
long, bool, bool, mem_alloc_origin) (hash-table.h:586)
==10920==by 0x101C509: hash_map,
simple_hashmap_traits, std::pair > >::hash_map(unsigned long, bool, bool) (hash-map.h:112)
==10920==by 0x101C3EC: __static_initialization_and_destruction_0(int, int)
(tree-ssa-strlen.c:157)
==10920==by 0x101C416: _GLOBAL__sub_I_laststmt (tree-ssa-strlen.c:3235)
==10920==by 0x198A38C: __libc_csu_init (in /ssd/build/gcc-git/gcc/cc1)
==10920==by 0x601438F: (below main) (in /usr/lib64/libc-2.24.so)
==10920== 
==1

[Bug target/82981] New: unnecessary __multi3 call for mips64r6 linux kernel

[wilson at gcc dot gnu.org]

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

Bug ID: 82981
   Summary: unnecessary __multi3 call for mips64r6 linux kernel
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

Given the testcase
unsigned long func(unsigned long a, unsigned long b)
{
return a > (~0UL) / b;
}
compiled with -march=mips64r6 -mabi=64 -mexplicit-relocs -O2 we end up with a
call to __multi3 which is inefficient and inconvenient.

The testcase gets converted to 
  _1 = MUL_OVERFLOW (a_4(D), b_5(D));
  _2 = IMAGPART_EXPR <_1>;
There are no mulv patterns in the mips port, so it tries mulditi3 which fails,
and then calls __multi3.

Mips64r6 does have a widening DImode multiply which should have been used
instead.  The problem is that the *mulditi3 pattern is missing mips64r6
support.

Alternatively, the expander should try using a muldi3_highpart pattern when the
mulditi3 pattern doesn't work.  Especially when the highpart is the only part
we need as in this example.  The mips64r6 multi3_highpart is present.

Or alternatively, a mulvti3 pattern should be added to the mips port.

See for instance the thread at
https://www.linux-mips.org/archives/linux-mips/2017-08/msg00041.html

[Bug target/82981] unnecessary __multi3 call for mips64r6 linux kernel

[wilson at gcc dot gnu.org]

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

--- Comment #1 from Jim Wilson  ---
This problem is causing link errors for the mips64r6 linux kernel.  They would
like the gcc developers to fix it, instead of adding a definition of the
__multi3 function to the linux kernel.

[Bug rtl-optimization/82982] New: [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[asolokha at gmx dot com]

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

Bug ID: 82982
   Summary: [8 Regression] ICE: qsort checking failed (error:
qsort comparator non-negative on sorted output: 5) in
ready_sort_real in haifa scheduler
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*

gcc-8.0.0-alpha20171112 snapshot (r254666) for 32-bit BE powerpc targets ICEs
on the following snippet w/ -misel -Ofast -fgraphite-identity -funroll-loops
-fsched2-use-superblocks:

int xw, mj;

void
km (void)
{
  int r1 = 0;
  signed char *ny = (signed char *)&xw;

  if (xw != 0)
for (;;)
  {
for (xw = 1; xw < 3; ++xw)
  {
for (*ny = 1; *ny < 2; ++*ny)
  ny = (signed char *)&mj;

++r1;
if (r1 != 0)
  {
 w5:
if (xw != 0)
  {
for (*ny = 0; *ny < 1; ++*ny)
  ny = (signed char *)&r1;
++xw;
  }
goto w5;
  }
  }
  }
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20171112 -misel -Ofast
-fgraphite-identity -funroll-loops -fsched2-use-superblocks -c jyt0oer4.c
jyt0oer4.c: In function 'km':
jyt0oer4.c:31:1: error: qsort comparator non-negative on sorted output: 5
 }
 ^
during RTL pass: sched2
jyt0oer4.c:31:1: internal compiler error: qsort checking failed
0x5c5263 qsort_chk_error
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/vec.c:222
0x150878a qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/vec.c:274
0x1401e7a ready_sort_real
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/haifa-sched.c:3087
0x140809f schedule_block(basic_block_def**, void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/haifa-sched.c:6675
0x14a48f9 schedule_ebb(rtx_insn*, rtx_insn*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-ebb.c:537
0x14a5106 schedule_ebbs()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-ebb.c:657
0xc115f4 rest_of_handle_sched2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-rgn.c:3735
0xc115f4 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-rgn.c:3873

[Bug c++/82882] [8 regression] ICE Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/82983] New: [8 Regression] ICE in extract_insn, at recog.c:2305 w/ GFMI

[marxin at gcc dot gnu.org]

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

Bug ID: 82983
   Summary: [8 Regression] ICE in extract_insn, at recog.c:2305 w/
GFMI
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jkoval at gcc dot gnu.org, kyukhin at gcc dot gnu.org
  Target Milestone: ---

Following ICEs:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-4.c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-4.c: In
function ‘avx512vl_test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-4.c:16:1:
error: unrecognizable insn:
 }
 ^
(insn 9 8 10 2 (set (reg:V16QI 91 [ _5 ])
(unspec:V16QI [
(reg:V16QI 90 [ _4 ])
(reg:V16QI 88 [ _2 ])
(const_int 3 [0x3])
] UNSPEC_GF2P8AFFINEINV))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-4.c":14 -1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-4.c:16:1:
internal compiler error: in extract_insn, at recog.c:2305
0xeb6add _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xeb6b1e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0xe58259 extract_insn(rtx_insn*)
../../gcc/recog.c:2305
0xb57803 instantiate_virtual_regs_in_insn
../../gcc/function.c:1591
0xb58cdd instantiate_virtual_regs
../../gcc/function.c:1959
0xb58dac execute
../../gcc/function.c:2008

It's compiled with -mtune=generic -march=x86-64

[Bug target/82983] [8 Regression] ICE in extract_insn, at recog.c:2305 w/ GFMI

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0