[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
>
> I am thinking that maybe we should just remove the Ltb check from the test
> case.

Feel free to do it ;)

[Bug target/79391] sh ICE in in eligible_for_delay, at config/sh/sh.md:564

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Closing as fixed.

[Bug tree-optimization/81790] New: [8 Regression] ICE in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1738

[marxin at gcc dot gnu.org]

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

Bug ID: 81790
   Summary: [8 Regression] ICE in vn_nary_build_or_lookup_1, at
tree-ssa-sccvn.c:1738
   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: ---

Following ICEs starting from r247092:

$ cat /tmp/ice.i
typedef int a __attribute__ ((__vector_size__ (16)));
typedef struct
{
  a b;
} c;

int d, e;

void foo (c *ptr);

void bar ()
{
  double b = 1842.9028;
  c g, h;
  if (d)
b = 77.7998;
  for (; e;)
{
  g.b = g.b = g.b + g.b;
  h.b = (a){b};
  h.b = h.b + h.b;
}
  foo (&g);
  foo (&h);
}

$ gcc -O1  --param sccvn-max-scc-size=10 /tmp/ice.i
during GIMPLE pass: fre
/tmp/ice.i: In function ‘bar’:
/tmp/ice.i:25:1: internal compiler error: in vn_nary_build_or_lookup_1, at
tree-ssa-sccvn.c:1738
 }
 ^
0xd6d693 vn_nary_build_or_lookup_1
../../gcc/tree-ssa-sccvn.c:1738
0xd6fbe7 vn_nary_build_or_lookup
../../gcc/tree-ssa-sccvn.c:1774
0xd6fbe7 vn_reference_lookup_3
../../gcc/tree-ssa-sccvn.c:2053
0xcb5b9a walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*,
tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool*),
tree_node* (*)(tree_node*), void*)
../../gcc/tree-ssa-alias.c:2827
0xd6e2a9 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../gcc/tree-ssa-sccvn.c:2466
0xd42cf0 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-pre.c:4544
0x12d53aa dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:291
0xd41a4b eliminate
../../gcc/tree-ssa-pre.c:4832
0xd41b1e execute
../../gcc/tree-ssa-pre.c:5277

[Bug tree-optimization/81790] [8 Regression] ICE in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1738

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug rtl-optimization/81791] New: [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422

[marxin at gcc dot gnu.org]

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

Bug ID: 81791
   Summary: [8 Regression] ICE in
cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r250360, we probably exposed a latent bug:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr47355.C -O2 
-fmodulo-sched
during RTL pass: sms
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr47355.C: In function
‘void foo()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr47355.C:39:1: internal
compiler error: in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422
 }
 ^
0x95cb2e cfg_layout_redirect_edge_and_branch
../../gcc/cfgrtl.c:4422
0x95cb58 cfg_layout_redirect_edge_and_branch_force
../../gcc/cfgrtl.c:4432
0x9475c3 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
../../gcc/cfghooks.c:474
0x9481c9 make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void
(*)(basic_block_def*))
../../gcc/cfghooks.c:892
0x9558f3 create_preheader(loop*, int)
../../gcc/cfgloopmanip.c:1534
0x955b3e create_preheaders(int)
../../gcc/cfgloopmanip.c:1585
0xbf55de apply_loop_flags
../../gcc/loop-init.c:64
0xbf60bc loop_optimizer_init(unsigned int)
../../gcc/loop-init.c:123
0x1589322 sms_schedule
../../gcc/modulo-sched.c:1351
0x1589322 execute
../../gcc/modulo-sched.c:3342

[Bug rtl-optimization/81791] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/81791] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||hubicka at ucw dot cz
 Ever confirmed|0   |1

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Aug 10 07:43:49 2017
New Revision: 251020

URL: https://gcc.gnu.org/viewcvs?rev=251020&root=gcc&view=rev
Log:
Fix target attribute handling (PR c++/81355).

2017-08-10  Martin Liska  

PR c++/81355
* c-attribs.c (handle_target_attribute):
Report warning for an empty string argument of target attribute.
2017-08-10  Martin Liska  

PR c++/81355
* g++.dg/other/pr81355.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr81355.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Unassigning ..

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||5.4.0, 6.3.0, 7.1.0
  Known to fail||8.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #3)
> It apparently started failing last week of January 2017.  Only 64-bit
> fails, -m32 is fine.
> 
> I don't know where that missing function name is coming from.

Yep, it must start in r244854 where we enable TSAN on power. So we don't have
much detailed information should I disable it for power?

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #38 from Martin Liška  ---
Ok, I believe consumers of profiling infrastructure must follow paradigm of
gcov_exit and thus I'm closing the PR as invalid.

[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 10 08:54:04 2017
New Revision: 251021

URL: https://gcc.gnu.org/viewcvs?rev=251021&root=gcc&view=rev
Log:
PR testsuite/81784
* gcc.dg/compare2.c: Update dg-bogus and dg-warning.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compare2.c

[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Ok, so GIMPLE IL is different in between x86_64-linux-gnu:

__attribute__((noinline))
bar (const struct S f, int x)
{
  int _5;

   [100.00%] [count: INV]:
  hs = &f;
  _5 = foo (f, x_3(D));
  return _5;

}

and hppa-unknown-linux-gnu:

__attribute__((noinline))
bar (const struct S f, int x)
{
  const struct S f.0;
  int _6;

   [100.00%] [count: INV]:
  f.0 = f;
  hs = &f.0;
  _6 = foo (f.0, x_4(D));
  return _6;

}

We decide about creation of f.0 variable in:

   │2472  /* See if this arg was passed by invisible reference.  */   
   │2473  if (pass_by_reference (&all->args_so_far_v, passed_mode,
   │2474 passed_type, data->named_arg))   
   │2475{ 
   │2476  passed_type = nominal_type = build_pointer_type
(passed_type);
   │2477  data->passed_pointer = true;
  >│2478  passed_mode = nominal_mode = TYPE_MODE (nominal_type);
   |2479}

So hppa uses invisible reference to pass the struct argument.
Thus I guess we should not run the test-case on hppa target? Martin can you
please take a look?

[Bug c++/81337] g++.dg/gcov/pr16855.C etc. FAIL

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks Rainer for the report, I've composed email to GCC and glibc folks who
should hopefully help us.

[Bug middle-end/40298] possible failure in cgraph_clone_inlined_nodes with -O3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Can't reproduce, even 4.5.0 works fine for me.

[Bug middle-end/69026] dwarf2out.c:4295 warning: ‘finder[...]addr_table_entry_struct_union::label’ may be used uninitialized

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||marxin at gcc dot gnu.org
  Known to work||7.1.0
 Ever confirmed|0   |1
  Known to fail||6.4.0

--- Comment #2 from Martin Liška  ---
Confirmed, disappeared in r239181.

[Bug middle-end/69025] df-scan.c:2536 warning: array subscript is above array bounds

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Can't reproduce with any GCC release. Also revision from the date you reported
the PR is not triggering the warning.

[Bug target/81389] _mm_cmpestri segfault on -O0

[rockeet at gmail dot com]

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

rockeet  changed:

   What|Removed |Added

 CC||rockeet at gmail dot com

--- Comment #9 from rockeet  ---
Created attachment 41962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41962&action=edit
test intrinsic _mm_cmpestri

test case source file is attached.

$ g++ -march=native _mm_cmpestri_test.cpp # default -O0
$ ./a.out # segfault
Segmentation fault (core dumped)

$ g++ -O2 -march=native _mm_cmpestri_test.cpp
$ ./a.out # OK
10

[Bug libstdc++/81482] by-value lambda capture in remove_if

[fabian-gcc at kloetzl dot info]

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

--- Comment #4 from kloetzl  ---
> And changing the algorithm to make no copies would not make it opaque, because
> the lack of copies would be observable. As the standard says, whether copies
> are made or not is unspecified. So if you want to treat them as opaque, don't
> do something that depends on the internal details, use them as suggested by 
> the
> note in the standard.

I see that changing the behaviour might be a bigger issue than the quirks
itself. Fixing this on the client side by changing the capture to by-reference
is trivial. I just fear that developers might waste quite some working hours
trying to figure it out for themselves.

Feel free to close this as wontfix/notabug. ☺

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[dominiq at lps dot ens.fr]

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

--- Comment #64 from Dominique d'Humieres  ---
Created attachment 41963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41963&action=edit
Log file with the patch in comment 63

[Bug c/81779] bool define from stdbool.h suppresses -Wdeclaration-after-statement

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  This patch fixes it

--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -4828,6 +4828,7 @@ c_parser_compound_statement_nostart (c_parser *parser)
   while (c_parser_next_token_is_not (parser, CPP_CLOSE_BRACE))
 {
   location_t loc = c_parser_peek_token (parser)->location;
+  loc = expansion_point_location_if_in_system_header (loc);
   if (c_parser_next_token_is_keyword (parser, RID_CASE)
  || c_parser_next_token_is_keyword (parser, RID_DEFAULT)
  || (c_parser_next_token_is (parser, CPP_NAME)

but we'll need more general way to approach this, something like I outlined in
.

[Bug testsuite/81792] New: New fails in compare2.c

[segher at gcc dot gnu.org]

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

Bug ID: 81792
   Summary: New fails in compare2.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

gcc.dg/compare2.c fails (at least on powerpc64-linux) since at most a few
days with:

FAIL: gcc.dg/compare2.c (test for excess errors)
FAIL: gcc.dg/compare2.c case 20 (test for warnings, line 49)
FAIL: gcc.dg/compare2.c case 24 (test for warnings, line 57)

/home/segher/src/gcc/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of
?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other
operand [-Wsign-compare]
/home/segher/src/gcc/gcc/testsuite/gcc.dg/compare2.c:57:12: warning: operand of
?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other
operand [-Wsign-compare]

[Bug testsuite/81792] New fails in compare2.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Should be already fixed.

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

[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
*** Bug 81792 has been marked as a duplicate of this bug. ***

[Bug other/81793] New: static pie fails on powerpc-linux

[segher at gcc dot gnu.org]

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

Bug ID: 81793
   Summary: static pie fails on powerpc-linux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

The new testcases gcc.dg/pie-static-[12].c fail on powerpc-linux:

spawn -ignore SIGHUP /home/segher/build/tot/gcc/xgcc
-B/home/segher/build/tot/gcc/
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pie-static-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -static -fpie -pie -lm
-m32 -o ./pie-static-1.exe
/home/segher/tot/powerpc64-unknown-linux-gnu/bin/ld: cannot find -lm
/home/segher/tot/powerpc64-unknown-linux-gnu/bin/ld: cannot find -lc

[Bug preprocessor/81794] New: "would be stringified in traditional C" warning should be controlled by -Wtraditional

[egallager at gcc dot gnu.org]

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

Bug ID: 81794
   Summary: "would be stringified in traditional C" warning should
be controlled by -Wtraditional
   Product: gcc
   Version: 8.0
   URL: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01325.ht
ml
Status: UNCONFIRMED
  Keywords: diagnostic, easyhack, patch
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Opening a bug to track the underlying issue that caused me to submit this
patch:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00481.html
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01325.html

When compiling my fork of binutils-gdb, I get a lot of warnings like this one
on one file:

unwind-ia64.c:183:30: warning: macro argument "code" would be stringified in
traditional C
 #define UNW_DEC_BAD_CODE(code)   \
  ^

To reduce it to a testcase, we can modify gcc.dg/pragma-diag-7.c to look like
this:

$ cat pragma-diag-7.c
/* { dg-do compile } */

unsigned long ok = 0UL;
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wtraditional"
unsigned long bad = 1UL; /* { dg-warning "suffix" } */
/* Note the extra space before the pragma on this next line: */
 #pragma GCC diagnostic pop
unsigned long ok_again = 2UL; /* { dg-bogus "suffix" } */

/* Redundant with the previous pop, but just shows that it fails to stop the
 * following warning with an unpatched GCC: */
#pragma GCC diagnostic ignored "-Wtraditional"

/* { dg-bogus "would be stringified" .+1 } */
#define UNW_DEC_PROLOGUE(fmt, body, rlen, arg) \
  do {  \
  unw_rlen = rlen;  \
  *(int *)arg = body;   \
  printf("%s:%s(rlen=%lu)\n",   \
 fmt, (body ? "body" : "prologue"), (unsigned long)rlen);   \
  } while (0)
$ /usr/local/bin/gcc -c pragma-diag-7.c
pragma-diag-7.c:6:21: warning: traditional C rejects the "UL" suffix
[-Wtraditional]
 unsigned long bad = 1UL; /* { dg-warning "suffix" } */
 ^~~
pragma-diag-7.c:16:46: warning: macro argument "rlen" would be stringified in
traditional C
 #define UNW_DEC_PROLOGUE(fmt, body, rlen, arg) \
  ^
pragma-diag-7.c:16:46: warning: macro argument "body" would be stringified in
traditional C
$ 

To get rid of the unwanted warnings, all that is necessary is a 1-line patch to
libcpp/macro.c to change a call to cpp_error with CPP_DL_WARNING into a call to
cpp_warning with CPP_W_TRADITIONAL instead. The patch is already linked above.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Why disable it?  Can the feature not work, can the test not work?

Disabling the test is papering over the problem as far as I see.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #5)
> Why disable it?  Can the feature not work, can the test not work?
> 
> Disabling the test is papering over the problem as far as I see.

The test does not work :) So should we generalize more the scanned back-trace
in order to survive '#1  ' ?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Why can't the unwinder find the function name here?

[Bug c/81783] -Wtautological-compare could do better

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/81389] _mm_cmpestri segfault on -O0

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
(In reply to rockeet from comment #9)
> Created attachment 41962 [details]
> test intrinsic _mm_cmpestri
> 
> test case source file is attached.
> 
> $ g++ -march=native _mm_cmpestri_test.cpp # default -O0
> $ ./a.out # segfault
> Segmentation fault (core dumped)

*(const __m128i*)(ptr+3),
^^  You can't lie to compiler.  This isn't aligned.

*(const __m128i_u *)(ptr+3),
^^  Please use __m128i_u instead.

[Bug c/81795] New: Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[egallager at gcc dot gnu.org]

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

Bug ID: 81795
   Summary: Stray "originally defined here" when using
-Wc++-compat with #pragma GCC diagnostic push/pop
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Let's say I have source like this:

$ cat originally_defined_here0.c

struct debug_type { int foo; };

typedef struct debug_type *debug_type;
debug_type dt0;

debug_type dt1;
$ /usr/local/bin/gcc -c -Wc++-compat originally_defined_here0.c
originally_defined_here0.c:4:28: warning: using ‘debug_type’ as both a typedef
and a tag is invalid in C++ [-Wc++-compat]
 typedef struct debug_type *debug_type;
^~
originally_defined_here0.c:2:8: note: originally defined here
 struct debug_type { int foo; };
^~
$

I want to avoid this warning but keep using the flag in general when compiling,
so I use #pragma GCC diagnostic push/pop to avoid it:

$ cat originally_defined_here1.c

struct debug_type { int foo; };

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++-compat"

typedef struct debug_type *debug_type;
debug_type dt0;

#pragma GCC diagnostic pop

debug_type dt1;
$

This silences the warning, but there's still a stray note left behind:
$ /usr/local/bin/gcc -c -Wc++-compat originally_defined_here1.c
originally_defined_here1.c:2:8: note: originally defined here
 struct debug_type { int foo; };
^~
$

The stray note remains even when moving the first pragma above where the struct
is originally defined. Grepping the gcc sources for "originally defined here"
shows that there's 4 inform calls where the message comes from in
gcc/c/c-decl.c, 2 of which follow warning_at calls with OPT_Wc___compat. The
inform calls are guarded by:

if (b->locus != UNKNOWN_LOCATION)

and that's it. warning_at returns true if the warning was printed, and false if
it was inhibited, so shouldn't the calls to inform have a check against the
return value of warning_at added to their guarding conditions, too? i.e.
something like this:

bool warned = warning_at (loc, OPT_Wc___compat,
  ("using %qD as both a typedef and a tag is "
   "invalid in C++"),
  b->decl);
if ((b->locus != UNKNOWN_LOCATION) && warned)
  inform (b->locus, "originally defined here");

[Bug c/81795] Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
You're right, do you want to send a patch or should I handle it?

[Bug c++/81796] New: error: no matching function for call to ‘S2::operator delete(void*)’

[sbergman at redhat dot com]

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

Bug ID: 81796
   Summary: error: no matching function for call to ‘S2::operator
delete(void*)’
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

> $ g++ --version
> g++ (GCC) 8.0.0 20170810 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ cat test.cc
> #include 
> struct S1 { virtual ~S1(); };
> struct S2: S1 {
> static void * operator new(std::size_t);
> static void operator delete(void *, std::size_t);
> };
> 
> $ g++ -fsyntax-only test.cc
> test.cc:3:8: error: no matching function for call to ‘S2::operator 
> delete(void*)’
>  struct S2: S1 {
> ^~
> test.cc:5:17: note: candidate: ‘static void S2::operator delete(void*, 
> std::size_t)’
>  static void operator delete(void *, std::size_t);
>  ^~~~
> test.cc:5:17: note:   candidate expects 2 arguments, 1 provided

[Bug libstdc++/81797] New: gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 81797
   Summary: gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

It fails while building libstdc++ in stage1, with the following error:

/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc
-B/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc -nostdinc++
-L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src
-L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs
-L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include-x
c++-header -nostdinc++ -g -O2 
-I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0
-I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include
-I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/libsupc++  -O2
-g -std=gnu++0x
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h
\
-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc
-B/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc -nostdinc++
-L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src
-L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs
-L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include-x
c++-header -nostdinc++ -g -O2 
-I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0
-I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include
-I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/libsupc++  -O2
-g
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch
In file included from
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ios:39:0,
 from
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/istream:38,
 from
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/sstream:38,
 from
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/complex:45,
 from
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ccomplex:39,
 from
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h:52:
/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/libsupc++/exception:143:10:
fatal error: bits/nested_exception.h: No such file or directory
 #include 
  ^
compilation terminated.
make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1



This is configured with ../configure --build=x86_64-apple-darwin17.0.0
--prefix=/usr/local/Cellar/gcc/7.1.0
--libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran,jit --program-suffix=-7
--with-system-zlib --enable-checking=release --with-nls --enable-host-shared

Full output of compilation is there:
https://gist.githubusercontent.com/shatteringlass/21fb3c03bf39931fa7be9d698413282f/raw/d19a4945946afdcf42370abd93018fa80c949a2f/02.make

[Bug target/81357] Extra mov for zero extend of add

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libgomp/81691] libgomp.fortran/target2.f90 fails for nvptx at -O0 and -O1

[igor.venevtsev at intel dot com]

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

Igor Venevtsev  changed:

   What|Removed |Added

 CC||igor.venevtsev at intel dot com

--- Comment #3 from Igor Venevtsev  ---
Confirm, also fail for intelmic accelerator target

[Bug c/81783] -Wtautological-compare could do better

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I have a patch, but as usually, there's a problem with constants coming from
macros...

[Bug target/67638] [SH] ICE with nosave_low_regs ISR and -mfmovd

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
(In reply to Martin Liška from comment #1)
> Can't reproduce with cross compiler on trunk and gcc-5 branch. Is it
> reproducible with cross compiler? Which options do you use?

You have to use -m4 or -m4a (SH4 or SH4A with double precision FPU). -mfmovd is
only effective on those CPUs.

I just checked on some old dev version ( 7.0.0 20160503 (experimental) (GCC) ),
and it is reproducible.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I don't see how this can happen, that header is present in the libstdc++ source
tree and there's nothing target-specific about it.

[Bug c/81798] New: Please introduce new attribute to tell that function zeroes returned memory

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

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

Bug ID: 81798
   Summary: Please introduce new attribute to tell that function
zeroes returned memory
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

gcc is able to detect case when memory is allocated using calloc and then
zeroed out again using memset - in such case it removes this extra memset.
However it cannot do the same with custom calloc-like functions. Please
introduce new function attribute for this, or allow to pass argument to
existing malloc attribute.

Note: this attribute probably could be useful with other functions too, so it
should have more general name.

Code:

#include 
#include 

void* test()
{
void* p = calloc(10240, 1);
memset(p, 0, 10240);
return p;
}

__attribute__((malloc, alloc_size(1)))
void* mycalloc(size_t size);

void* test2()
{
void* p = mycalloc(10240);
memset(p, 0, 10240);
return p;
}

Result:

test():
  mov esi, 1
  mov edi, 10240
  jmp calloc
test2():
  sub rsp, 8
  mov edi, 10240
  call mycalloc(unsigned long)
  mov edx, 10240
  xor esi, esi
  mov rdi, rax
  call memset
  add rsp, 8
  ret

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Do you have the file $target/libstdc++-v3/include/stamp-bits-sup ?

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-08 00:00:00 |2017-8-10

--- Comment #2 from Oleg Endo  ---
(In reply to Martin Liška from comment #1)
> Is it reproducible with x86_64-linux-gnu cross-compiler?

Yes, on gcc version 6.2.1 20160925 (GCC), when compiling attachment 41790 with 

"-m4 -ml -O2" or "-m4 -mb -O2".

[Bug c/81799] New: ICE on valid code at -O3: verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 81799
   Summary: ICE on valid code at -O3: verify_gimple failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170810 (experimental) [trunk revision 251019] (GCC)
$
$ gcc-trunk -O2 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:5:6: error: invalid argument to gimple call
 void fn1 (int h)
  ^~~
&e > 3B
_33 = LOOP_DIST_ALIAS (4, &e > 3B);
during GIMPLE pass: ldist
small.c:5:6: internal compiler error: verify_gimple failed
0xcb091b verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5310
0xb75202 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1992
0xb75ba9 execute_todo
../../gcc-source-trunk/gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$





int printf (const char *, ...);

int a, c[1], d, e, **f;

void fn1 (int h)
{ 
  int *i = 0;
  for (d = 0; d < 1; d++)
{ 
  if (d)
continue;
  for (; e; e++)
{ 
  a = c[*i];
  if (h)
printf ("0");
}
  return;
}
  f = &i;
}

[Bug target/81800] New: [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[nsz at gcc dot gnu.org]

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

Bug ID: 81800
   Summary: [8 regression] on aarch64 ilp32 lrint should not be
inlined as two instructions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

recently lrint is inlined as frintx/fcvtzs on aarch64, but this
is not valid on ilp32 where a non-integer double may be out-of-bound
for a long and then the first instruction raises the inexact,
the second one raises invalid exception and only the invalid should
be raised in this case.

so the inlining is only valid with -fno-trapping-math i think.

gcc -O3 -mabi=ilp32 -S -fno-math-errno b.c

compiles to

f:
frintx  d0, d0
fcvtzs  w0, d0
ret

(the patch for the equivalent bug in glibc is
https://sourceware.org/ml/libc-alpha/2017-08/msg00299.html
which saves and restores the fenv around the instructions.)

[Bug target/67638] [SH] ICE with nosave_low_regs ISR and -mfmovd

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to fail||5.4.0, 6.3.0, 7.1.0, 8.0

--- Comment #3 from Martin Liška  ---
Confirmed, it really ICEs on GCC 5.0+, I haven't tried older versions.

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Martin Liška  ---
(In reply to Oleg Endo from comment #2)
> (In reply to Martin Liška from comment #1)
> > Is it reproducible with x86_64-linux-gnu cross-compiler?
> 
> Yes, on gcc version 6.2.1 20160925 (GCC), when compiling attachment 41790
> [details] with 
> 
> "-m4 -ml -O2" or "-m4 -mb -O2".

Good, I can confirm it works for GCC 5. Let's then bisect that..

[Bug target/81800] [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[nsz at gcc dot gnu.org]

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

--- Comment #1 from nsz at gcc dot gnu.org ---
b.c:

long f(double x)
{
  return __builtin_lrint(x);
}

and an example value where the exceptions are wrong is 0x1p32 + 0.5

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Martin Liška from comment #3)
> 
> Good, I can confirm it works for GCC 5. Let's then bisect that..

I'm not sure whether this will reveal anything useful.
It's probably just a bug in the function sh_find_set_of_reg, which runs into an
unexpected RTL construct.

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Ok, just adding a port maintainer.

[Bug c/81801] New: [PATCH] Difference of two pointers generates signed overflow

[oss at malat dot biz]

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

Bug ID: 81801
   Summary: [PATCH] Difference of two pointers generates signed
overflow
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oss at malat dot biz
  Target Milestone: ---

Created attachment 41964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41964&action=edit
Correction + test

SSH compiled with -ftrapv aborts in strlcpy() function, which computes a length
of a string by subtracting pointer to the string from the pointer to '\0'
character terminating the string.

The problem arises only if the string spawns over the positive/negative
boundary, for example assume a string of the length 23 on 32-bit platform
located at 0x7FFFfff8:
   char *str = (char *)0x7FFFfff8;
   char *str_end = (char *)0x800f;
then the following:
   int len = str_end - str;
produces a signed overflow, which leads to abort() if compiled with -ftrapv.

The whole issue can be easily shown by compiling the following code:
  int ptrdiff(char *a, char *b) {
return b - a;
  }
but more illustrative is to use a pointer to a larger object:
  int ptrdiff(int *a, int *b) {
return b - a;
  }
which produces the following test.c.003t.original:
  ;; Function ptrdiff (null)
  ;; enabled by -tree-original
  {
return ((int) b - (int) a) /[ex] 4;
  }
I have tracked this problem down to pointer_diff() function, which explicitly
uses signed type - either ptrdiff_t or larger signed type matching the pointer
size if needed. I assume this is not correct and the pointer difference should
always use unsigned type matching the size of the pointer to make the operation
well behaving even if it overflows. After changing the function to use unsigned
(the patch is attached), I get the following test.c.003t.original:
  ;; Function ptrdiff (null)
  ;; enabled by -tree-original
  {
return (int) ((unsigned int) b - (unsigned int) a) /[ex] 4;
  }
which looks better to me.

The problem with this change is that it leads to
FAIL: gcc.dg/tree-ssa/cmpexactdiv-2.c scan-tree-dump-not optimized "minus_expr"
where it doesn't optimize
  __PTRDIFF_TYPE__ l1 = b - a;
  __PTRDIFF_TYPE__ l2 = c - a;
  return l1 < l2;
to
  return b < c;
Which it could still do, but not because it knows the overflow can't occur but
because if the difference of two pointers doesn't fit to __PTRDIFF_TYPE__ the
behavior is undefined - so it's not possible the difference of two pointers
would wrap around to a wrong sign in the correct program.

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
And in fact, there has been a change to the function sh_find_set_of_reg.  I'd
have to dig through the archives etc to find out what was going on there. 
Meanwhile, it seems that the small backport patch below fixes the issue,
although I have not done any proper tests.

Index: gcc/config/sh/sh-protos.h
===
--- gcc/config/sh/sh-protos.h   (revision 240471)
+++ gcc/config/sh/sh-protos.h   (working copy)
@@ -228,8 +228,12 @@
}
 }

-  if (result.set_src != NULL)
-gcc_assert (result.insn != NULL && result.set_rtx != NULL);
+  /* If the searched reg is found inside a (mem (post_inc:SI (reg))), set_of
+ will return NULL and set_rtx will be NULL.
+ In this case report a 'not found'.  result.insn will always be non-null
+ at this point, so no need to check it.  */
+  if (result.set_src != NULL && result.set_rtx == NULL)
+result.set_src = NULL;

   return result;
 }

[Bug c/81795] Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Marek Polacek from comment #1)
> You're right, do you want to send a patch or should I handle it?

It'd probably be better if you handled it; my hard drive that has the ssh keys
that let me commit is currently unresponsive and needs to be repaired, so even
if I sent the patch and got it approved, someone else would still need to
commit it for me.

[Bug c/81795] Stray "originally defined here" when using -Wc++-compat with #pragma GCC diagnostic push/pop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/81800] [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
confirmed.

[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Aug 10 15:29:05 2017
New Revision: 251028

URL: https://gcc.gnu.org/viewcvs?rev=251028&root=gcc&view=rev
Log:
i386: Don't use frame pointer without stack access

When there is no stack access, there is no need to use frame pointer
even if -fno-omit-frame-pointer is used and caller's frame pointer is
unchanged.

gcc/

PR target/81736
* config/i386/i386.c (ix86_finalize_stack_realign_flags): Renamed
to ...
(ix86_finalize_stack_frame_flags): This.  Also clear
frame_pointer_needed if -fno-omit-frame-pointer is used without
stack access.
(ix86_expand_prologue): Replace ix86_finalize_stack_realign_flags
with ix86_finalize_stack_frame_flags.
(ix86_expand_epilogue): Likewise.
(ix86_expand_split_stack_prologue): Likewise.
* doc/invoke.texi: Add a note for -fno-omit-frame-pointer.

gcc/testsuite/

PR target/81736
* gcc.target/i386/pr81736-1.c: New test.
* gcc.target/i386/pr81736-2.c: Likewise.
* gcc.target/i386/pr81736-3.c: Likewise.
* gcc.target/i386/pr81736-4.c: Likewise.
* gcc.target/i386/pr81736-5.c: Likewise.
* gcc.target/i386/pr81736-6.c: Likewise.
* gcc.target/i386/pr81736-7.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81736-1.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-2.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-3.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-4.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-5.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-6.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/81802] New: Report cuLaunchKernel launch dimensions in GOMP_OFFLOAD_run

[vries at gcc dot gnu.org]

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

Bug ID: 81802
   Summary: Report cuLaunchKernel launch dimensions in
GOMP_OFFLOAD_run
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

This patch:
...
diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index f5b9502..2cb63b4 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -2457,6 +2457,7 @@ nvptx_stacks_free (void *p, int num)
 void
 GOMP_OFFLOAD_run (int ord, void *tgt_fn, void *tgt_vars, void **args)
 {
+  const struct targ_fn_launch *launch = ((struct targ_fn_descriptor *)
tgt_fn)->launch;
   CUfunction function = ((struct targ_fn_descriptor *) tgt_fn)->fn;
   CUresult r;
   struct ptx_device *ptx_dev = ptx_devices[ord];
@@ -2492,6 +2493,9 @@ GOMP_OFFLOAD_run (int ord, void *tgt_fn, void *tgt_vars,
void **args)
 CU_LAUNCH_PARAM_BUFFER_SIZE, &fn_args_size,
 CU_LAUNCH_PARAM_END
   };
+  GOMP_PLUGIN_debug (0, "  %s: kernel %s: launch"
+" [(teams: %u), 1, 1] [32, (threads: %u), 1]\n",
+__FUNCTION__, launch->fn, teams, threads);
   r = CUDA_CALL_NOCHECK (cuLaunchKernel, function, teams, 1, 1,
 32, threads, 1, 0, ptx_dev->null_stream->stream,
 NULL, config);
...

Prints this information with GOMP_DEBUG=1:
...
  GOMP_OFFLOAD_run: kernel f2_tpf_static32$_omp_fn$0: launch [(teams: 1), 1, 1]
[32, (threads: 8), 1]
...

I'm not happy with the term 'threads', the term is ambiguous in the context.

Perhaps 'warps', or 'omp-threads' would be better.

[Bug libgomp/81802] Report cuLaunchKernel launch dimensions in GOMP_OFFLOAD_run

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug target/81803] New: Miscompilation at -O1 on mips64el

[aurelien at aurel32 dot net]

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

Bug ID: 81803
   Summary: Miscompilation at -O1 on mips64el
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mips64el-unknown-linux-gnu
Target: mips64el-unknown-linux-gnu
 Build: mips64el-unknown-linux-gnu

Created attachment 41965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41965&action=edit
testcase

Since the switch to GCC 7 as the default compiler, Debian sees many
miscompilations on mips64el where variables which are stored on the stack and
smaller than 8 bytes long (e.g. uint16_t, bool) are wrongly reloaded with the
LD instruction.

I unfortunately haven't been able to get a self-contained reduced testcase, but
the attached testcase (from apparmor) should show the issue.

The aa_policy_cache_new function takes a uint16_t as the fourth argument. It
gets passed the max_caches, which also has a uint16_t type. When compiled with
g++  -Wfatal-errors -g -O2 -fstack-protector-strong -c -o testcase.o
testcase.ii the generated code contains:

 164:   dea5ld  a1,0(s5)
164: R_MIPS_GOT_OFST.bss+0x38
164: R_MIPS_NONE*ABS*+0x38
164: R_MIPS_NONE*ABS*+0x38
 168:   dfa8ld  a4,0(sp)
 16c:   2406ff9cli  a2,-100
 170:   0320f809jalrt9
170: R_MIPS_JALRaa_policy_cache_new
170: R_MIPS_NONE*ABS*


As you can see, a4 is loaded with the LD instruction, so the upper bytes are
just garbage and causes the aa_policy_cache_new to not function correctly.

[Bug target/81804] New: m32c ICE during configure at leaf_function_p, at final.c:4317

[joel at gcc dot gnu.org]

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

Bug ID: 81804
   Summary: m32c ICE during configure at leaf_function_p, at
final.c:4317
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

Version: (GCC) 8.0.0 20170809
target: m32c-rtems, likely for m32c-elf

checking for m32c-rtems4.12-gcc...
/home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/sys-include   
checking for suffix of object files... configure: error: in
`/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

config.log contains:

configure:3471: /home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/ -isystem
/home/joel/test-gcc/b-m32c-rtems4.12-gcc/m32c-rtems4.12/newlib/targ-include
-isystem /home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/bin/
-B/home/joel/test-gcc/install-master/m32c-rtems4.12/lib/ -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/include -isystem
/home/joel/test-gcc/install-master/m32c-rtems4.12/sys-include-o conftest -g
-O2   conftest.c  >&5
during RTL pass: pro_and_epilogue
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: in leaf_function_p, at final.c:4317
 }
 ^
0x6e67c5 leaf_function_p()
../../gcc/gcc/final.c:4317
0xd484ac m32c_leaf_function_p
../../gcc/gcc/config/m32c/m32c.c:4016
0xd484ac m32c_emit_prologue()
../../gcc/gcc/config/m32c/m32c.c:4070
0xe8573a gen_prologue()
../../gcc/gcc/config/m32c/prologue.md:26
0xd44c58 target_gen_prologue
../../gcc/gcc/config/m32c/blkmov.md:359
0x734b47 make_prologue_seq
../../gcc/gcc/function.c:5835
0x734d03 thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.c:5952
0x7353c2 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6443
0x7353c2 execute
../../gcc/gcc/function.c:6485
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
configure:3474: $? = 1
configure:3662: checking for suffix of object files

[Bug libgomp/81805] New: Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

Bug ID: 81805
   Summary: Another libgomp.c/for-5.c failure on nvptx -- illegal
memory access
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Minimized from for-5.c, without simd:
...
extern void abort ();

#pragma omp declare target
int a[1500];
#pragma omp end declare target

__attribute__((noinline, noclone)) void
f2_tpf_static32 (void)
{
  unsigned long long i;
#pragma omp target parallel for schedule(static, 32)
  for (i = 0x7fffLL + 4500ULL - 27;
   i > 0x7fffLL - 27ULL; i -= 3)
a[(i + 26LL - 0x7fffLL) / 3] -= 4;
}

__attribute__((noinline, noclone)) int
test_tpf_static32 (void)
{
  int i, j, k;
  for (i = 0; i < 1500; i++)
a[i] = i - 25;

#pragma omp target update to(a)
  f2_tpf_static32 ();
#pragma omp target update from(a)

  for (i = 0; i < 1500; i++)
if (a[i] != i - 29)
  return 1;

  return 0;
}

int
main ()
{
  if (test_tpf_static32 ())
abort ();

  return 0;
}
...

...
$ ./install/bin/gcc -fopenmp -B$(pwd
-P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.0 -B$(pwd
-P)/install/offload-nvptx-none/bin for-5.c -O2
$ ( export LD_LIBRARY_PATH=/usr/lib/nvidia-375:$(pwd -P)/install/lib64/;
./a.out ; echo $? )
libgomp: cuCtxSynchronize error: an illegal memory access was encountered

libgomp: cuMemFreeHost error: an illegal memory access was encountered

libgomp: device finalization failed
1
$ gcc for-5.c && ./a.out ; echo $?
0
...

[Bug target/81803] Miscompilation at -O1 on mips64el

[james410 at cowgill dot org.uk]

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

James Cowgill  changed:

   What|Removed |Added

 CC||james410 at cowgill dot org.uk

--- Comment #1 from James Cowgill  ---
Created attachment 41966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41966&action=edit
testcase-b

Here's another testcase which is reduced a bit further using creduce. It
requires -O2 to trigger the bug (but that may be unrelated).

Compile using:
> mips64el-linux-gnuabi64-g++ -g -O2 -fstack-protector-strong -c -o test.o 
> test.c

mips64el-linux-gnuabi64-objdump -dr test.o:
>  98:   8c42lw  v0,0(v0)
>  9c:   0002102bsltuv0,zero,v0
>  a0:   afa20008sw  v0,8(sp)
>  a4:   df99ld  t9,0(gp)
>a4: R_MIPS_CALL16   _Z19aa_policy_cache_newPs
>a4: R_MIPS_NONE *ABS*
>a4: R_MIPS_NONE *ABS*
>  a8:   dfa80008ld  a4,8(sp)
>  ac:   3825movea3,zero
>  b0:   3025movea2,zero
>  b4:   2825movea1,zero
>  b8:   0320f809jalrt9
>b8: R_MIPS_JALR _Z19aa_policy_cache_newPs
>b8: R_MIPS_NONE *ABS*
>b8: R_MIPS_NONE *ABS*

Here, the value calculated in v0 is stored to the stack in 8(sp) using sw, but
then loaded later using ld.

[Bug target/81803] Miscompilation at -O1 on mips64el

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
(In reply to James Cowgill from comment #1)
> Here's another testcase which is reduced a bit further using creduce. It
> requires -O2 to trigger the bug (but that may be unrelated).

I reported it as a miscompilation with -O1, as at least in the clamav case, the
bug is not reproducible with -O0, but is reproducible with both -O1 and -O2.
But it seems this bug is quite dependent on the surrounding code, so my guess
is that the issue is not triggered by a specific optimization.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[amonakov at gcc dot gnu.org]

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

--- Comment #1 from Alexander Monakov  ---
Can't reproduce this on my end. Are you going to proceed with analyzing the
failure?

[Bug tree-optimization/81798] Please introduce new attribute to tell that function zeroes returned memory

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||msebor at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
This sounds a like a useful feature, not just to improve code generation but
also to help avoid false positives when -Wuninitialized is enhanced to
understand allocated memory.  For the latter, the attribute should also make it
possible to indicate whether the memory is zeroed out or just initialized to
some possibly non-zero values.  Confirmed.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Simplified version, aborts in host code because loop has no effect:
...
#include 

extern void abort ();

#define N 32ULL

#pragma omp declare target
int a[N];
#pragma omp end declare target

const unsigned long long c = 0x7fffULL;

__attribute__((noinline, noclone)) void
f2_tpf_static32 (void)
{
  unsigned long long i;
#pragma omp target parallel for schedule(static, 32)
  for (i = c + N; i > c; i -= 1ULL)
a[i - 1ULL - c] -= 4;
}

__attribute__((noinline, noclone)) int
test_tpf_static32 (void)
{
  int i, j, k;
  for (i = 0; i < N; i++)
a[i] = i - 25;

#pragma omp target update to(a)
  f2_tpf_static32 ();
#pragma omp target update from(a)

  for (i = 0; i < N; i++)
printf ("%d: %d, expected: %d\n", i, a[i], i - 29);

  for (i = 0; i < N; i++)
if (a[i] != i - 29)
  return 1;

  return 0;
}

int
main ()
{
  if (test_tpf_static32 ())
abort ();

  return 0;
}
...

[Bug libgcc/81806] New: Split in pbds works in O(n) instead of O(log n)

[aleksandr.kulkov at phystech dot edu]

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

Bug ID: 81806
   Summary: Split in pbds works in O(n) instead of O(log n)
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aleksandr.kulkov at phystech dot edu
  Target Milestone: ---

In the end of the split in policy based data structures extension function
split finish is called
(https://code.woboq.org/gcc/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/split_join_fn_imps.hpp.html#__gnu_pbds::detail::PB_DS_BIN_TREE_NAME::split_finish)
which works in O(n) due to call of std::distance of two iterators. In the
official documentation it is said to be O(log n) though. This problem can be
resolved by keeping subtree sizes in metadata like it is done in
tree_order_statistics_node_update. Is it possible to fix the bug?

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed in r251029.

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Thu Aug 10 17:40:11 2017
New Revision: 251029

URL: https://gcc.gnu.org/viewcvs?rev=251029&root=gcc&view=rev
Log:
PR c++/81586 - valgrind error in output_buffer_append_r with -Wall

gcc/ChangeLog:

PR c++/81586
* pretty-print.c (pp_format): Correct the handling of %s precision.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/pretty-print.c

[Bug target/81803] Miscompilation at -O1 on mips64el

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Very likely LRA, there is a known weakness on little-endian MIPS.

[Bug target/81803] Miscompilation at -O1 on mips64el

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Investigating.

[Bug c/81141] missing warning using sizeof a/sizeof *a with a zero-length array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81117

--- Comment #3 from Martin Sebor  ---
See also bug 81141 for a related request (limited to strncpy).  The patch
submitted there

[Bug tree-optimization/81799] [8 Regression] ICE on valid code at -O3: verify_gimple failed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |tree-optimization
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE on valid code at -O3:   |[8 Regression] ICE on valid
   |verify_gimple failed|code at -O3: verify_gimple
   ||failed

[Bug testsuite/81807] New: many *.cc asan tests fail on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 81807
   Summary: many *.cc asan tests fail on powerpc64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

After r250991 a whole bunch of the asan *.cc tests (activated in that revision)
fail on powerpc64 (both LE and BE).  It looks like some #defines are missing or
wrong from the errors.

FAIL: g++.dg/asan/asan_globals_test.cc   -O0  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test.cc   -O1  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test.cc   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test.cc   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test.cc   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test.cc   -O3 -g  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test.cc   -Os  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -O0  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -O1  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -O3 -g  (test for excess
errors)
FAIL: g++.dg/asan/asan_globals_test-wrapper.cc   -Os  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O0  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O1  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -O3 -g  (test for excess errors)
FAIL: g++.dg/asan/asan_mem_test.cc   -Os  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O0  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O1  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -O3 -g  (test for excess errors)
FAIL: g++.dg/asan/asan_oob_test.cc   -Os  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O0  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O1  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -O3 -g  (test for excess errors)
FAIL: g++.dg/asan/asan_str_test.cc   -Os  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O0  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O1  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -O3 -g  (test for excess errors)
FAIL: g++.dg/asan/asan_test.cc   -Os  (test for excess errors)

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/asan/asan_test.cc
-fsanitize=address -g
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -

[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
Working on a patch.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
The new testcase fails on any target and not related to offloading. Simplified
further:

#define N 32ULL
int a[N];

const unsigned long long c = 0x7fffULL;

f2_tpf_static32 (void)
{
  unsigned long long i;
#pragma omp for
  for (i = c + N; i > c; i -= 1ULL)
a[i - 1ULL - c] -= 4;
}

in the .original dump we have:

{
  long long unsigned int i;

long long unsigned int i;
  #pragma omp for
  for (i = 9223372036854775839; i < 0; i = i + 18446744073709551615)
{
  a[i + 9223372036854775808] = a[i + 9223372036854775808] + -4
}
}

and soon after we deduce that loop doesn't iterate because i is unsigned. The
comparison should have read '(long long)i < 0', no idea how the cast is lost.

[Bug testsuite/81807] many *.cc asan tests fail on powerpc64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|powerpc64*-*-*  |powerpc64*-*-*,
   ||aarch64*-*-*
   Host|powerpc64*-*-*  |
  Build|powerpc64*-*-*  |

--- Comment #1 from Andrew Pinski  ---
Saw it on aarch64-linux-gnu also.

[Bug libstdc++/81808] New: 27_io /basic_fstream/53984.cc failure on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 81808
   Summary: 27_io /basic_fstream/53984.cc failure on AIX
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

./53984.cc:31: void test01(): Assertion 'in.bad()' failed.

[Bug libstdc++/81808] 27_io /basic_fstream/53984.cc failure on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug libstdc++/81808] 27_io /basic_fstream/53984.cc failure on AIX

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
Created attachment 41967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41967&action=edit
Pre-processed source of testcase

[Bug libstdc++/81808] 27_io /basic_fstream/53984.cc failure on AIX

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
After in >> x, x appears to contain the value 0x02ff22770.

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug testsuite/81807] many *.cc asan tests fail

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|powerpc64*-*-*, |
   |aarch64*-*-*|
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
Summary|many *.cc asan tests fail   |many *.cc asan tests fail
   |on powerpc64|
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> After r250991 a whole bunch of the asan *.cc tests (activated in that 
> revision)
> fail on powerpc64 (both LE and BE).

They fail on most (if not all) targets. See
https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00918.html.

[Bug c++/81337] g++.dg/gcov/pr16855.C etc. FAIL

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Bug 52477 deals with the parallel issue for construction.  As I mentioned
there, I think the right solution is to handle attribute constructor/destructor
using the C++ __static_initialization_and_destruction mechanism rather than
.{init,fini}_array.

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Thu Aug 10 19:07:30 2017
New Revision: 251035

URL: https://gcc.gnu.org/viewcvs?rev=251035&root=gcc&view=rev
Log:
PR c++/80452 - Core 1579, implicit move semantics on return/throw

* cp-tree.h (LOOKUP_PREFER_RVALUE): Now means that we've already
tentatively changed the lvalue to an rvalue.
* call.c (reference_binding): Remove LOOKUP_PREFER_RVALUE handling.
(build_over_call): If LOOKUP_PREFER_RVALUE, check that the first
parameter is an rvalue reference.
* except.c (build_throw): Do maybe-rvalue overload resolution twice.
* typeck.c (check_return_expr): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/move-return1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/except.c
trunk/gcc/cp/typeck.c

[Bug c++/80451] [6/7/8 Regression] return implicit type conversion to std::experimental::optional does not compile

[jason at gcc dot gnu.org]

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

Bug 80452 Summary: [DR 1579] incorrect value category deduced for return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80452

   What|Removed |Added

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

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from Jason Merrill  ---
Fixed for GCC 8.

[Bug libstdc++/81808] 27_io /basic_fstream/53984.cc failure on AIX

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to David Edelsohn from comment #3)
> After in >> x, x appears to contain the value 0x02ff22770.

That's just an indeterminate value because it was never initialized, and
doesn't get written to by the failed read.

It seems that on AIX trying to read from the stream sets in.fail() instead.

[Bug c++/80451] [6/7 Regression] return implicit type conversion to std::experimental::optional does not compile

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|[6/7/8 Regression] return   |[6/7 Regression] return
   |implicit type conversion to |implicit type conversion to
   |std::experimental::optional |std::experimental::optional
   |does not compile|does not compile

--- Comment #12 from Jason Merrill  ---
Fixed for GCC 8 by the patch for bug 80452.

[Bug c++/81337] g++.dg/gcov/pr16855.C etc. FAIL

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Thanks Jason, then marking as duplicate.

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

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
*** Bug 81337 has been marked as a duplicate of this bug. ***

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #10 from Martin Liška  ---
I will try to look at it.

[Bug libstdc++/81808] 27_io /basic_fstream/53984.cc failure on AIX

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
On AIX reading the directory just reads the actual contents of the directory,
i.e. the files contained in the directory. Maybe we should restrict the test to
only run on targets where that read used to fail with an exception.

Alternatively, we could read a char instead of an int, and if the read succeeds
don't test for in.bad(). I'd rather just restrict the targets where it runs
though.

[Bug tree-optimization/81799] [8 Regression] ICE on valid code at -O3: verify_gimple failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-10
 CC||amker at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with -ftree-loop-distribution in r249994.

[Bug tree-optimization/81809] missing -Wuninitialized due to alias analysis limitation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=23384

--- Comment #1 from Martin Sebor  ---
See bug 23384 for a discussion of the flow-insensitive alias analysis.

[Bug tree-optimization/81809] New: missing -Wuninitialized due to alias analysis limitation

[msebor at gcc dot gnu.org]

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

Bug ID: 81809
   Summary: missing -Wuninitialized due to alias analysis
limitation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This almost certainly a side-effect of the limitations of the flow-insensitive
alias analysis pointed out in bug 23384 but I wanted to make a record of the
impact the limitation has beyond optimization.

Both functions below read the uninitialized variable b.  The uninitialized read
is diagnosed in g() but not in h() because the address of the variable is
considered to have escaped even though it doesn't happen until after it has
been read.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic a.c
void f (const void*);

int g (void)
{
  int a, b;
  f (&a);

  int i = b;   // -Wuninitialized (good)

  return i;
}

int h (void)
{
  int a, b;
  f (&a);

  int i = b;   // missing -Wuninitialized (bug)

  f (&b);  // &b escapes here

  return i;
}

a.c: In function ‘g’:
a.c:8:7: warning: ‘b’ is used uninitialized in this function [-Wuninitialized]
   int i = b;   // -Wuninitialized (good)
   ^

[Bug libstdc++/81359] [7 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Aug 10 19:55:48 2017
New Revision: 251036

URL: https://gcc.gnu.org/viewcvs?rev=251036&root=gcc&view=rev
Log:
PR c++/81359 - Unparsed NSDMI error from SFINAE context.

* method.c (synthesized_method_walk): Don't diagnose lack of
operator delete.

Added:
trunk/gcc/testsuite/g++.dg/inherit/vdtor1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

[Bug testsuite/81738] [8 Regression] gcc.dg/vect/vect-alias-check-6.c FAILs

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Aug 10 19:58:16 2017
New Revision: 251037

URL: https://gcc.gnu.org/viewcvs?rev=251037&root=gcc&view=rev
Log:
PR81738: Split vect-alias-check-6.c

The second loop in the testcase only vectorises if we can reverse
a vector and if aligned loads aren't required.

2017-08-10  Richard Sandiford  

gcc/testsuite/
PR testsuite/81738
* gcc.dg/vect/vect-alias-check-6.c: Move second function to...
* gcc.dg/vect/vect-alias-check-7.c: ...this new file.  Require
vect_perm and vect_element_align for vectorization.

Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-7.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-6.c