[Bug c++/70816] bogus error __builtin_strcmp is not a constant expression in a constexpr function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-08
 Ever confirmed|0   |1
  Known to fail|6.0 |6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
The same limitation affects other string builtins such as __builtin_strlen or
__builtin_strchr.

$ cat cst.C && /home/msebor/build/gcc-6-branch/gcc/xgcc
-B/home/msebor/build/gcc-6-branch/gcc -S -Wall -Wextra -Wpedantic cst.C
-fdump-tree-optimized=/dev/stdout -o/dev/stdout
constexpr int chr (int c)
{
  const char a[] = "123";
  return __builtin_strchr (a, c) - a;
}

constexpr int i = chr ('3');

constexpr int cmp (const char *a)
{
  const char b[] = "123";
  return __builtin_strcmp (a, b);
}

constexpr int j = cmp ("345");

constexpr unsigned len ()
{
  const char s[] = "123";
  return __builtin_strlen (s);
}

constexpr unsigned n = len ();
.file   "cst.C"
cst.C:7:23:   in constexpr expansion of ‘chr(51)’
cst.C:4:27: error: ‘__builtin_strchr(((const char*)(& a)), 51)’ is not a
constant expression
   return __builtin_strchr (a, c) - a;
  ~^~
cst.C:15:23:   in constexpr expansion of ‘cmp(((const char*)"345"))’
cst.C:12:27: error: ‘__builtin_strcmp(((const char*)"345"), ((const char*)(&
b)))’ is not a constant expression
   return __builtin_strcmp (a, b);
  ~^~
cst.C:23:28:   in constexpr expansion of ‘len()’
cst.C:20:27: error: ‘__builtin_strlen(((const char*)(& s)))’ is not a constant
expression
   return __builtin_strlen (s);
  ~^~~

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

[su at cs dot ucdavis.edu]

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

Bug ID: 71451
   Summary: ICE on invalid C++11 code on x86_64-linux-gnu: in
dependent_type_p, at cp/pt.c:22599
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 4.7.x (as it seems to affect 4.8.x and later). 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.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 7.0.0 20160607 (experimental) [trunk revision 237165] (GCC)
$
$ g++-trunk -std=c++11 small.cpp
small.cpp:6:39: error: parameter packs not expanded with ‘...’:
   template < typename A < T::value >::type > void foo ();
   ^~~~
small.cpp:6:39: note: ‘T’
small.cpp: In substitution of ‘template::type
... > void B::foo() [with typename A::type
... = {}]’:
small.cpp:12:10:   required from here
small.cpp:6:51: internal compiler error: in dependent_type_p, at cp/pt.c:22599
   template < typename A < T::value >::type > void foo ();
   ^~~
0x6c1b53 dependent_type_p(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:22599
0x6c2380 dependent_scope_p(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:22630
0x6de2e4 tsubst_qualified_id
../../gcc-source-trunk/gcc/cp/pt.c:13753
0x6df3d4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:16224
0x6d401f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15820
0x6ea07c tsubst_template_arg
../../gcc-source-trunk/gcc/cp/pt.c:10391
0x6f9482 tsubst_template_args
../../gcc-source-trunk/gcc/cp/pt.c:11234
0x6fe28b tsubst_aggr_type
../../gcc-source-trunk/gcc/cp/pt.c:11431
0x6e7121 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:13432
0x6f95de tsubst_template_args
../../gcc-source-trunk/gcc/cp/pt.c:11226
0x6f96fa tsubst_template_args
../../gcc-source-trunk/gcc/cp/pt.c:11194
0x6eff05 tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:11726
0x6e799e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:12829
0x6ffbcd instantiate_template_1
../../gcc-source-trunk/gcc/cp/pt.c:17421
0x6ffbcd instantiate_template(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/pt.c:17472
0x71161c fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc-source-trunk/gcc/cp/pt.c:17847
0x67243b add_template_candidate_real
../../gcc-source-trunk/gcc/cp/call.c:3110
0x67316c add_template_candidate
../../gcc-source-trunk/gcc/cp/call.c:3188
0x67316c add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5361
0x673a06 build_new_method_call_1
../../gcc-source-trunk/gcc/cp/call.c:8313
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


---


template < int > struct A;

template < typename ... T >
struct B
{ 
  template < typename A < T::value >::type > void foo ();
};

int main ()
{ 
  B < int > t;
  t.foo ();
  return 0;
}

[Bug c++/71450] New: ICE on invalid C++11 code on x86_64-linux-gnu: in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search.c:203

[su at cs dot ucdavis.edu]

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

Bug ID: 71450
   Summary: ICE on invalid C++11 code on x86_64-linux-gnu: in tree
check: expected record_type or union_type or
qual_union_type, have template_type_parm in
lookup_base, at cp/search.c:203
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 6.1.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.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 7.0.0 20160607 (experimental) [trunk revision 237165] (GCC)
$
$ g++-6.1 small.cpp
small.cpp: In instantiation of ‘void g(T) [with T = A]’:
small.cpp:18:10:   required from here
small.cpp:12:14: error: use of ‘x’ before deduction of ‘auto’
   auto x = t + x;
~~^~~
small.cpp:12:14: error: no match for ‘operator+’ (operand types are ‘A’ and
‘auto’)
small.cpp:3:5: note: candidate: A A::operator+(A)
   A operator+ (A a)
 ^~~~
small.cpp:3:5: note:   no known conversion for argument 1 from ‘auto’ to ‘A’
$
$ g++-trunk small.cpp
small.cpp: In instantiation of ‘void g(T) [with T = A]’:
small.cpp:18:10:   required from here
small.cpp:12:14: error: use of ‘x’ before deduction of ‘auto’
   auto x = t + x;
~~^~~
small.cpp:12:14: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:203
0x1050d8c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9752
0x80848c tree_check3
../../gcc-source-trunk/gcc/tree.h:3070
0x80848c lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../gcc-source-trunk/gcc/cp/search.c:203
0x66e4af build_user_type_conversion_1
../../gcc-source-trunk/gcc/cp/call.c:3645
0x66f51a implicit_conversion
../../gcc-source-trunk/gcc/cp/call.c:1863
0x6718d4 add_function_candidate
../../gcc-source-trunk/gcc/cp/call.c:2138
0x6731b7 add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5371
0x67a524 build_new_op_1
../../gcc-source-trunk/gcc/cp/call.c:5508
0x67b1be build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:5844
0x7be652 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc-source-trunk/gcc/cp/typeck.c:3891
0x6e1882 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:16209
0x6d401f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15820
0x5d5c5a tsubst_init
../../gcc-source-trunk/gcc/cp/pt.c:13857
0x6d7e24 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15224
0x6d5550 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15303
0x6d1f55 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22033
0x71eb12 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22152
0x761bf7 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4600
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


--


struct A
{ 
  A operator+ (A a)
  { 
return a;
  }
};

template < class T >
void g (T t)
{ 
  auto x = t + x;
}

int
main ()
{ 
  g (A ());
  return 0;
}

[Bug c/71199] Support overloadable attribute in GNU C front-end

[yuxuanchiadm at 126 dot com]

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

Yu Xuanchi  changed:

   What|Removed |Added

 CC||yuxuanchiadm at 126 dot com

--- Comment #4 from Yu Xuanchi  ---
Trying to implement it.

https://github.com/yuxuanchiadm/gcc/tree/gcc-overloadable-attribute

[Bug c++/57433] Local classes have an associated namespace

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #3 from Richard Smith  ---
(In reply to i.hamsa from comment #2)
> This is an expected behaviour in C++14 due to
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1690. Still a
> problem in C++11.

That issue is in DR status, so it seems appropriate for the resolution to apply
to C++11 (and C++98) as well.

[Bug c++/71448] pointer relational comparison fails inside constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-07
 CC||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #2 from Martin Sebor  ---
Confirmed also with 6.1 and current trunk (7.0).  I'd say the underlying
problem is the same as in bug 67376, but the fix for that bug (r231909) is
incomplete: fold_comparison doesn't know how to handle this case.

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
I can (partially) reproduce on Solaris:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/double-int.o differs
make[2]: *** [compare] Error 1

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-07
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/71449] builtins accepted in default template arguments but rejected when explicitly specified

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Most likely __builtin_parity (0) got folded to 0 for the first case.

[Bug c++/71449] builtins accepted in default template arguments but rejected when explicitly specified

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||4.5.3
  Known to fail||4.8.5, 4.9.3, 5.3.0, 6.1.0,
   ||7.0

--- Comment #1 from Martin Sebor  ---
G++ 4.5.3 rejects both declarations so the absence of one could be considered a
regression between it and 4.8.  I'm not sure how difficult it might be to fix
C++ 98 to accept this kind of code but if not terribly it would seem preferable
to rejecting it.

[Bug c++/71449] New: builtins accepted in default template arguments but rejected when explicitly specified

[msebor at gcc dot gnu.org]

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

Bug ID: 71449
   Summary: builtins accepted in default template arguments but
rejected when explicitly specified
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C++ 98 mode, all versions of G++ reject the instantiation of template B
below with an error but accepts the equivalent instantion of A.  Either they
both should be rejected, or they both should be accepted as they are in C++ 11
mode and later.

Clang accepts the code in all C++ modes.

$ cat cst.C && /home/msebor/build/gcc-6-branch/gcc/xgcc
-B/home/msebor/build/gcc-6-branch/gcc -S -Wall -Wextra -Wpedantic -std=c++98
cst.C
template  struct A { };
A<> a;

template  struct B { };
B<__builtin_parity (0)> b;
cst.C:5:3: error: ‘int __builtin_parity(unsigned int)’ cannot appear in a
constant-expression
 B<__builtin_parity (0)> b;
   ^~~~
cst.C:5:22: error: a function call cannot appear in a constant-expression
 B<__builtin_parity (0)> b;
  ^
cst.C:5:23: error: template argument 1 is invalid
 B<__builtin_parity (0)> b;
   ^

[Bug c++/71448] pointer relational comparison fails inside constant expression

[gcc at adamsimpkins dot net]

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

--- Comment #1 from Adam Simpkins  ---
Created attachment 38657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38657=edit
gcc 5.3 configuration options used during repro

[Bug c++/71448] New: pointer relational comparison fails inside constant expression

[gcc at adamsimpkins dot net]

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

Bug ID: 71448
   Summary: pointer relational comparison fails inside constant
expression
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at adamsimpkins dot net
  Target Milestone: ---

Created attachment 38656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38656=edit
Simple repro code

Comparing two pointers with less than/greater than fails inside a constant
expression when compiling without optimization enabled.  Failing code:

static constexpr const char foo[] = "foo";
static constexpr const char* bar = "bar";

static_assert((foo + 3 - foo) == 3, "check");  // Works
static_assert(foo + 2 != foo, "check");// Works
static_assert(foo + 2 >= foo, "check");// Works
static_assert(foo + 3 >= foo, "check");// Works

static_assert((bar + 3 - bar) == 3, "check");  // Works
static_assert(bar + 2 != bar, "check");// Works
static_assert(bar + 2 >= bar, "check");// Compile error without -O2
static_assert(bar + 3 >= bar, "check");// Compile error without -O2

This seems very similar to bug #67376, but not quite the same.
As best I can tell from reading the standard, this pointer arithmetic is
defined, so this seems like it should be a valid constant expression.

When compiling with -O2 or -O3 the code compiles correctly, and static_assert
checks pass/fail as expected.

I've confirmed this behavior with gcc 4.9 (built from r221427) and gcc 5.3
(built from r233903).

[Bug c/71255] Implement #pragma may_alias

[fw at gcc dot gnu.org]

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

--- Comment #25 from Florian Weimer  ---
(In reply to Manuel López-Ibáñez from comment #23)
> (In reply to Florian Weimer from comment #22)
> > (In reply to Marek Polacek from comment #21)
> > > The testcase in Comment 14 should now compile fine.
> > 
> > What's the best way to detect that a compiler has this fix?  We cannot use a
> > configure check.  Is there anything better than looking at __GNUC__?  Are
> > you going to backport this fix?  Thanks.
> 
> It seems a good motivation to add the __has_feature(pragma_may_alias)

Not really.  The expectation is that after these bug fixes, we won't need the
pragma.

[Bug c/71255] Implement #pragma may_alias

[manu at gcc dot gnu.org]

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

--- Comment #24 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #23)
> (In reply to Florian Weimer from comment #22)
> > (In reply to Marek Polacek from comment #21)
> > > The testcase in Comment 14 should now compile fine.
> > 
> > What's the best way to detect that a compiler has this fix?  We cannot use a
> > configure check.  Is there anything better than looking at __GNUC__?  Are
> > you going to backport this fix?  Thanks.
> 
> It seems a good motivation to add the __has_feature(pragma_may_alias) PR6051.

Sorry, PR60512. Although, why not __gcc_has_pragma(may_alias) ?

[Bug c/71255] Implement #pragma may_alias

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #23 from Manuel López-Ibáñez  ---
(In reply to Florian Weimer from comment #22)
> (In reply to Marek Polacek from comment #21)
> > The testcase in Comment 14 should now compile fine.
> 
> What's the best way to detect that a compiler has this fix?  We cannot use a
> configure check.  Is there anything better than looking at __GNUC__?  Are
> you going to backport this fix?  Thanks.

It seems a good motivation to add the __has_feature(pragma_may_alias) PR6051.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-07
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez  ---
AFAIU, it will be welcome if someone implements it.

[Bug c++/61564] #pragma GCC optimize ("-fno-lto") causes the compiler to crash

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #3)
> It looks like both the pragma and the attribute accept any kind of -f/-O
> options
> regardless of them being marked as 'Optimization' in the .opt file.  They
> get applied via decode_options and thus may have side-effects not reflected
> by
> cl_optimization_save/restore.
> 
> I have a patch to issue
> 
> /tmp/t.c:2:9: warning: bad option -fno-lto to pragma attribute [-Wpragmas]
>  #pragma GCC optimize ("-fno-lto")
>  ^~~

to pragma attribute?

Do you mean "to pragma 'optimize'"?

This would be even prettier:

ret = false;
warning (attr_p ? OPT_Wattributes : OPT_Wpragmas,
 attr_p ? "bad option %qs to attribute %"
 : "bad option %qs to pragma %%",
 decoded_options[i].orig_option_with_args_text);
continue;

[Bug c/71255] Implement #pragma may_alias

[fw at gcc dot gnu.org]

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

--- Comment #22 from Florian Weimer  ---
(In reply to Marek Polacek from comment #21)
> The testcase in Comment 14 should now compile fine.

What's the best way to detect that a compiler has this fix?  We cannot use a
configure check.  Is there anything better than looking at __GNUC__?  Are you
going to backport this fix?  Thanks.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella  changed:

   What|Removed |Added

 CC||adhemerval.zanella at linaro 
dot o
   ||rg

--- Comment #2 from Adhemerval Zanella  
---
This is not really aarch64 also, all 64-bit architectures will require this
fix.  And indeed, the features.h header is only fixed at release, until them
GLIBC sets its version to '2.23.90' (meaning 2.23 development).

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #1 from Maxim Ostapenko  ---
Hm, one I can see, Glibc still has __GLIBC_MINOR__ = 23:

/* Major and minor version number of the GNU C library package.  Use
   these macros to test for features in specific releases.  */
#define __GLIBC__   2
#define __GLIBC_MINOR__ 23

Perhaps we can cherry-pick 
http://llvm.org/viewvc/llvm-project?view=revision=272008 after Glibc
release happens?

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |4.9.4

--- Comment #12 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[uros at gcc dot gnu.org]

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

--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jun  7 16:01:50 2016
New Revision: 237179

URL: https://gcc.gnu.org/viewcvs?rev=237179=gcc=rev
Log:
PR target/71389
* config/i386/i386.c (ix86_avx256_split_vector_move_misalign):
Copy op1 RTX to avoid invalid sharing.
(ix86_expand_vector_move_misalign): Ditto.

testsuite/ChangeLog:

PR target/71389
* g++.dg/pr71389.C: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr71389.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[zadeck at naturalbridge dot com]

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

Kenneth Zadeck  changed:

   What|Removed |Added

 CC||zadeck at naturalbridge dot com

--- Comment #10 from Kenneth Zadeck  ---
I should point out that this bug could/should have been caught by turning on
the rtl sharing detector that honza wrote many years ago.  I do not know if we
ever did routine testing with this enabled, but it seems like running this in a
systematic way over actively changing ports would not be a bad idea.

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jun  7 15:23:42 2016
New Revision: 237178

URL: https://gcc.gnu.org/viewcvs?rev=237178=gcc=rev
Log:
PR target/71389
* config/i386/i386.c (ix86_avx256_split_vector_move_misalign):
Copy op1 RTX to avoid invalid sharing.
(ix86_expand_vector_move_misalign): Ditto.

testsuite/ChangeLog:

PR target/71389
* g++.dg/pr71389.C: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/pr71389.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #17 from rdapp at linux dot vnet.ibm.com ---
(In reply to Marc Glisse from comment #16)
> (In reply to rdapp from comment #15)
> > Is there a simple method to access @inner when
> > capturing
> > (outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
> >^-^
> >  @inner
> > or, even-better both, @inner as well as @0 and @1, at the same time? (Apart
> > from looking through use stmts)
> 
> (outer_op (convert (inner_op@3 SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
> 
> Does @3 do what you want here? (I didn't follow the discussion)

looks good, thanks :)

[Bug c/71447] problem with pointer arythmetic?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c/71255] Implement #pragma may_alias

[mpolacek at gcc dot gnu.org]

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

--- Comment #21 from Marek Polacek  ---
The testcase in Comment 14 should now compile fine.

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jun  7 15:16:44 2016
New Revision: 237177

URL: https://gcc.gnu.org/viewcvs?rev=237177=gcc=rev
Log:
PR target/71389
* config/i386/i386.c (ix86_avx256_split_vector_move_misalign):
Copy op1 RTX to avoid invalid sharing.
(ix86_expand_vector_move_misalign): Ditto.

testsuite/ChangeLog:

PR target/71389
* g++.dg/pr71389.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr71389.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/71447] problem with pointer arythmetic?

[johannesjanssens at telenet dot be]

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

--- Comment #2 from Johannes Janssens  ---
I must apolagize, the bug is mine!!! I just discovered why.

So sorry.

Johannes


Op 7/06/2016 om 17:12 schreef mpolacek at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71447
>
> Marek Polacek  changed:
>
> What|Removed |Added
> 
>   Status|UNCONFIRMED |WAITING
> Last reconfirmed||2016-06-07
>   CC||mpolacek at gcc dot gnu.org
>   Ever confirmed|0   |1
>
> --- Comment #1 from Marek Polacek  ---
> That is not a stand-alone testcase.  Does -fno-strict-aliasing "help"?
>

[Bug c/71447] problem with pointer arythmetic?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
That is not a stand-alone testcase.  Does -fno-strict-aliasing "help"?

[Bug c/71447] New: problem with pointer arythmetic?

[johannesjanssens at telenet dot be]

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

Bug ID: 71447
   Summary: problem with pointer arythmetic?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johannesjanssens at telenet dot be
  Target Milestone: ---

code snippet :
--
typedef struct HstruWA *WA;
typedef struct HstruWA{ //NEWHANDLE(WA)
int qt;
int *ofs;
char*cnttypes;
char*record;
} externWA;

typedef struct internWA{
char**ptArray;
int recsize;

WA wa;
int qt_added;
ADDED *added; //chain
} internWA;
typedef internWA *IWA;

/*
#define  mDATAOFFSET(QT)   
(((QT+1)*sizeof(int))+(QT*sizeof(char)))
#define  mOFFSARRAY(_Record)((int*)(_Record+sizeof(int)))
#define  mCNTSARRAY(_Record,_QT)((char*)(_Record+sizeof(int)*(_QT+1)))
*/

iwa->wa = ram.sf_alloc("wa1",iwa->wa, mDATAOFFSET(qt) + bufsize );
iwa->wa->qt=qt;
int *k = mOFFSARRAY(iwa->wa);
iwa->wa->ofs=mOFFSARRAY(iwa->wa);



The problem :
-
assigning the same value to the variable k gives a different result from
assigning it to iwa->wa->ofs. Both are of type *int


in gdb:
---
Program received signal SIGSEGV, Segmentation fault.
0x779cb01b in new_from_stringarray (s=0x4021c4 "Janssens,Johannes",
splitbalk=44 ',') at
/home/wannes/ontwikkeling/projecten/libwgpeUtil/wgpArr.c:154
154 iwa->wa->ofs[idx]=thislen;
(gdb) p k
$8 = (int *) 0x605260
(gdb) p iwa->wa->ofs
$9 = (int *) 0x614a00605260
(gdb)

[Bug middle-end/69526] ivopts candidate strangeness

[glisse at gcc dot gnu.org]

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

--- Comment #16 from Marc Glisse  ---
(In reply to rdapp from comment #15)
> Is there a simple method to access @inner when
> capturing
> (outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
>^-^
>  @inner
> or, even-better both, @inner as well as @0 and @1, at the same time? (Apart
> from looking through use stmts)

(outer_op (convert (inner_op@3 SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))

Does @3 do what you want here? (I didn't follow the discussion)

[Bug c++/71446] New: Incorrect overload resolution when using designated initializers

[roman.perepelitsa at gmail dot com]

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

Bug ID: 71446
   Summary: Incorrect overload resolution when using designated
initializers
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.perepelitsa at gmail dot com
  Target Milestone: ---

Actual behaviour: the following program compiles.
Expected behaviour: doesn't compile.

  #include 

  struct S {
int value;
  };

  int F(S);
  char* F(std::initializer_list);

  char* p = F({.value = 0});

The compiler should either resolve `F({.value = 0})` as `int F(S)` or generate
a `sorry, not implemented` error. It shouldn't resolve it as `char*
F(std::initializer_list)`.

[Bug sanitizer/71445] New: libsanitizer build failure on aarch64-linux-gnu with recent glibc

[yroux at gcc dot gnu.org]

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

Bug ID: 71445
   Summary: libsanitizer build failure on aarch64-linux-gnu with
recent glibc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yroux at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Recent changes in Glibc to follow POSIX specifications for both msghdr and
cmsghdr (switch from size_t to sockelen_t for msg_iovlen, msg_controllen, and
cmsg_len on 64-bits arch.), libsanitizer fails to build for AArch64 (logs at
the end), and I guess other 64-bits targets.

This issue was fixed in compiler-rt sources at revision 272008:

http://llvm.org/viewvc/llvm-project?view=revision=272008

For information Glibc revision which introduced the issue is:

https://sourceware.org/git/?p=glibc.git;a=commit;h=222c2d7f4357d66073176f3beec67af40f0486c7

Full log of the failure:

.../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:254:72:
error: size of array 'assertion_failed__1007' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
.../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:248:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^~~~
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1410:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
   ^~
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1007:1:
note: in expansion of macro 'CHECK_SIZE_AND_OFFSET'
 CHECK_SIZE_AND_OFFSET(msghdr, msg_iovlen);
 ^
.../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:254:72:
error: size of array 'assertion_failed__1009' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
.../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:248:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^~~~
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1410:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
   ^~
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1009:1:
note: in expansion of macro 'CHECK_SIZE_AND_OFFSET'
 CHECK_SIZE_AND_OFFSET(msghdr, msg_controllen);
 ^
.../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:254:72:
error: size of array 'assertion_failed__1013' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
.../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:248:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^~~~
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1410:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
   ^~
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1013:1:
note: in expansion of macro 'CHECK_SIZE_AND_OFFSET'
 CHECK_SIZE_AND_OFFSET(cmsghdr, cmsg_len);
 ^

[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #15 from rdapp at linux dot vnet.ibm.com ---
Thanks for the suggestions. The omission of the inner op was actually more or
less on purpose as I intended to capture the
(convert @inner)
in order to access @inner's value range as a whole rather than re-calculating
what VRP already figured out.

Is there a simple method to access @inner when
capturing
(outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
   ^-^
 @inner
or, even-better both, @inner as well as @0 and @1, at the same time? (Apart
from looking through use stmts)

In my case VRP determines @0's range as ~[0,0] and @inner's as [0,INT_MAX-1].
VRP probably canonicalized the anti-range to a normal range and performed other
simplifications in order to arrive at [0,INT_MAX-1]. If I cannot get @inner's
VRP info with the capture above, would there be another way to obtain it?

The TREE_OVERFLOW/const_binop code is copied from the (A +- CST) +- CST -> A +
CST pattern and the result of const_binop is used in the final simplification.
The overflow check could of course be done via wi::add/sub but wouldn't I just
replicate what int_const_binop_1 is doing on top of it when I need the result
anyway?

[Bug tree-optimization/71414] 2x slower than clang summing small float array, GCC should consider larger vectorization factor for "unrolling" reductions

[yyc1992 at gmail dot com]

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

--- Comment #7 from Yichao Yu  ---
If I add `-fvariable-expansion-in-unroller` (omg this options is like half the
command line ;-p ...), the performance matches the clang one after the clang
3.8 regression.

```
% gcc -funroll-loops -fvariable-expansion-in-unroller -Ofast -march=core-avx2
benchmark.c -o benchmark2 
% ./benchmark2 
45.588861
% ./benchmark-gcc
80.518152
% ./benchmark-clang38
41.920054
% ./benchmark-clang37
25.093145
```

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[ysrumyan at gmail dot com]

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

--- Comment #21 from Yuri Rumyantsev  ---
Richard!

Are you planning to prepare the second part of the patch (zeroing safelen and
testing it in loop invariant motion phase as you proposed)?

Thanks.

[Bug tree-optimization/71414] 2x slower than clang summing small float array, GCC should consider larger vectorization factor for "unrolling" reductions

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

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

--- Comment #6 from Joost VandeVondele  
---
Isn't this a case where -fvariable-expansion-in-unroller is helpful ?

> gcc -Ofast t.c -lrt ; ./a.out
285.670206

> gcc -Ofast -funroll-loops -fvariable-expansion-in-unroller  t.c -lrt ; ./a.out
151.246083

> gcc -Ofast -funroll-loops  t.c -lrt ; ./a.out
277.047507

There is some relation with PR25621 I think.

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

[john.lindgren at aol dot com]

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

John Lindgren  changed:

   What|Removed |Added

  Known to fail||6.1.1

--- Comment #8 from John Lindgren  ---
Just ran into this bug again with GCC 6.1.1.  Any hope of this ever getting
fixed?

[Bug c++/61564] #pragma GCC optimize ("-fno-lto") causes the compiler to crash

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug libstdc++/71444] New: Error code on MinGW-w64

[frankhb1989 at gmail dot com]

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

Bug ID: 71444
   Summary: Error code on MinGW-w64
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

Several enumerators are commented out in  for
MinGW-w64. 

However, I find several macros are actually usable in  in the
distribution (MSYS2) I am using, as:


/* Defined as WSAETIMEDOUT.  */
#ifndef ETIMEDOUT
#define ETIMEDOUT 138
#endif

#ifndef ELOOP
#define ELOOP 114
#endif

#ifndef EPROTOTYPE
#define EPROTOTYPE 136
#endif

#ifndef EOVERFLOW
#define EOVERFLOW 132
#endif


Can they be configured automatically?

[Bug middle-end/71443] New: [7 regression] test case gcc.dg/plugin/must-tail-call-2.c reports error

[wdijkstr at arm dot com]

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

Bug ID: 71443
   Summary: [7 regression] test case
gcc.dg/plugin/must-tail-call-2.c reports error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

There are 2 new failures in the tail-call-2.c test on recent trunk builds:
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 32)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so
(test for excess errors)

The error reported is:
/home/wdijkstr/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In function
'test_2_caller':^M
/home/wdijkstr/gcc/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:32:10: error:
cannot tail-call: argument must be passed by copying^M

The argument is a large structure which is passed by reference on AArch64. So
it looks like the test needs to allow for this possibility. This appears
related to PR71293 for Power.

[Bug c++/61564] #pragma GCC optimize ("-fno-lto") causes the compiler to crash

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  7 12:41:46 2016
New Revision: 237174

URL: https://gcc.gnu.org/viewcvs?rev=237174=gcc=rev
Log:
2016-06-07  Richard Biener  

PR c/61564
* c-common.c (parse_optimize_options): Only apply CL_OPTIMIZATION
options and warn about others.
* common.opt (ffast-math): Make Optimization.

* gcc.dg/Wpragmas-1.c: New testcase.
* gcc.dg/Wattributes-4.c: Likewise.
* gcc.dg/ipa/pr70646.c: Drop optimize pragma in favor of dg-option
entry.

Added:
trunk/gcc/testsuite/gcc.dg/Wattributes-4.c
trunk/gcc/testsuite/gcc.dg/Wpragmas-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/common.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/pr70646.c

[Bug c++/71442] [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 38655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38655=edit
gcc7-pr71442.patch

Untested fix.

[Bug c++/71442] [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-07
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

[Bug c++/71442] New: [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

Bug ID: 71442
   Summary: [5/6/7 Regression] r232569 breaks -Wunused-*
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

// { dg-do compile { target c++11 } }
// { dg-options "-Wunused-variable" }

struct C
{
  template
  int operator()(Ts &&...)
  {
return sizeof...(Ts);
  }
};

int
main ()
{
  C {} (1, 1L, 1LL, 1.0);
  char a;   // { dg-warning "unused variable" }
  short b;  // { dg-warning "unused variable" }
  int c;// { dg-warning "unused variable" }
  long d;   // { dg-warning "unused variable" }
  long long e;  // { dg-warning "unused variable" }
  float f;  // { dg-warning "unused variable" }
  double g; // { dg-warning "unused variable" }
}

FAILs to diagnose c, d, e and g vars as unused, starting with r323569, because
it marks not just decls as TREE_USED, but also types, and when e.g. int type is
TREE_USED, then all vars/parameters with that type are also considered
TREE_USED.

[Bug debug/71441] [7 regression] gcc.dg/pr44023.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug debug/71441] New: [7 regression] gcc.dg/pr44023.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 71441
   Summary: [7 regression] gcc.dg/pr44023.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Between 20160524 and 20160527, gcc.dg/pr44023.c started to FAIL on
Solaris/SPARC:

FAIL: gcc.dg/pr44023.c (test for excess errors)

Excess errors:
xgcc: error: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr44023.c:
-fcompare-debug failure (length)

32-bit only.  This is a regression from the gcc-6 branch.

  Rainer

[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
(In reply to Bernd Schmidt from comment #4)
> Most likely a dup of bug 71413.

Likely as the suggested patch is effectively the same. This one comes with test
case, consider to include it in the final patch.

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The issue with the optimization opportunity is that IPA reference does not
compute that GetIN does not modify pL because its analysis is restricted
to variables local to the compilation unit.  Using -fwhole-program fixes that.
I didn't check whether PRE performs the desired optimization then - the
code gets quite obfuscated with -fwhole-program.

The r235817 issue is likely spurious - the SSA dumps of GCC 6 and trunk
agree and thus differences are likely due to SSA numbering differences.
The usual suspect is out-of SSA coalescing (without having verified that).

[Bug target/66960] Add interrupt attribute to x86 backend

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Created attachment 38653 [details]
> A patch
>
> Please try this.

The patch fixes the issue, thanks.

[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Most likely a dup of 71413.

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Oops, sorry, wrong bug.

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[bernds at gcc dot gnu.org]

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

--- Comment #1 from Bernd Schmidt  ---
Most likely a dup of 71413.

[Bug tree-optimization/71414] 2x slower than clang summing small float array, GCC should consider larger vectorization factor for "unrolling" reductions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-07
 CC||jamborm at gcc dot gnu.org,
   ||mliska at suse dot cz
  Component|other   |tree-optimization
 Blocks||53947
Summary|2x slower than clang|2x slower than clang
   |summing small float array   |summing small float array,
   ||GCC should consider larger
   ||vectorization factor for
   ||"unrolling" reductions
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
An interesting observation is that we clone sum32 for IPA-CP of n == 1024 but
for some unknown reason figure Alignment of 'a' as unusable:

Lattices:
  Node: main/35:
  Node: sum32/34:
param [0]: VARIABLE
 ctxs: VARIABLE
 Alignment unusable (BOTTOM)
AGGS VARIABLE
param [1]: VARIABLE
   1024 [from: 35(99000)] [loc_time: 65, loc_size: 10, prop_time:
0, prop_size: 0]
 ctxs: VARIABLE
 Alignment unusable (BOTTOM)
AGGS VARIABLE

Evaluating opportunities for sum32/34.
 - considering value 1024 for param #1 n (caller_count: 1)
 good_cloning_opportunity_p (time: 65, size: 10, freq_sum: 99000) ->
evaluation: 643500, threshold: 500
  Creating a specialized node of sum32/34.
replacing param #1 n with const 1024
Accounting size:7.00, time:72.78 on predicate:(true)
Accounting size:3.00, time:2.00 on new predicate:(not inlined)
 the new node is sum32.constprop/43.


iff LLVM disables IPA CP cloning with 'noinline' the testcase should add
'noclone' as well to be a fair comparison.

The vectorizer decides to peel the loop for alignment (as usual...) and thus
creates both prologue and epilogue loop.  That shouldn't matter in practice
but it likely obfuscates code enough to make the Job for IVOPTs harder.
If the desire was to have nothing known about alignment and 'n' in sum32
the above cannot be avoided anyway.  We also peel both prologue and epilogue
loop.

clang 3.6 (the one I have locally) doesn't peel for alignment and thus uses
unaligned loads and unrolls the loop by 2 only.  It doesn't do any IPA CP
with -Ofast.

Note that the difference WRT clangs unrolling and GCCs unrolling is that
clang uses two accumulators while GCC just processes multiple loads on
the same accumulator with its unrolling.  Thus clang can exploit parallelism
in the pipeline of the CPU while GCC restricts the CPU due to the dependences.

This means that it is the vectorizer that needs to consider using a larger
vectorization factor rather than post-vectorization unrolling (that's likely
to pay off only for reductions).  I wonder what LLVMs heuristic is here.

The IPA-CP alignment question remains though.  Martins?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
The code in handle_builtin_memcmp looks as follows:


  FOR_EACH_IMM_USE_FAST (use_p, iter, res)
{
  gimple *ustmt = USE_STMT (use_p);
  if (gimple_code (ustmt) == GIMPLE_ASSIGN)
...
  else if (gimple_code (ustmt) == GIMPLE_COND)
...
  else
return true;
}

Note the "else return true;". I wonder whether it should be removed for good -
or whether it makes indeed sense to abort with "true" after the first loop
iteration.

In any case, with debug symbols, I get a bunch of GIMPLE_DEBUG statements
before the the GIMPLE_COND. Hence, the debug compare issue is fixed by the
following patch:

diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 5e2d7db..bb90339 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -1883,5 +1883,5 @@ handle_builtin_memcmp (gimple_stmt_iterator *gsi)
return true;
}
-  else
+  else if (gimple_code (ustmt) != GIMPLE_DEBUG)
return true;
 }

[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
The difference between the two insns-dumps is the "_eq":

0:   extern int __builtin_memcmp_eq (const void *, const void *, long unsigned
int);

vs.

0:   extern int __builtin_memcmp (const void *, const void *, long unsigned
int);

[Bug target/71419] interrupt attribute silently dropped for Thumb code on armv7-a

[hans.buchmann at fhnw dot ch]

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

--- Comment #2 from Hans Buchmann  ---
The code is produced in arm mode:

.file   "irq.cc"
.text
.align  2
.global _Z5_irq_v
.syntax unified
.arm <--- here
.fpu softvfp
.type   _Z5_irq_v, %function
_Z5_irq_v:
.fnstart
.LFB0:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sub lr, lr, #4
push{r0, r1, r2, r3, ip, lr}
.save {r0, r1, r2, r3, ip, lr}
bl  _Z8externalv
pop {r0, r1, r2, r3, ip, pc}^
.fnend
.size   _Z5_irq_v, .-_Z5_irq_v
.ident  "GCC: (GNU) 6.1.0"

compiling with -mthumb yields the correct error:

../src/irq.cc: In function 'void _irq_()':
../src/irq.cc:11:1: error: interrupt Service Routines cannot be coded in Thumb
mode
 }

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |7.0

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||sparc-linux
 CC||bernds at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug c++/61564] #pragma GCC optimize ("-fno-lto") causes the compiler to crash

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
It looks like both the pragma and the attribute accept any kind of -f/-O
options
regardless of them being marked as 'Optimization' in the .opt file.  They
get applied via decode_options and thus may have side-effects not reflected by
cl_optimization_save/restore.

I have a patch to issue

/tmp/t.c:2:9: warning: bad option -fno-lto to pragma attribute [-Wpragmas]
 #pragma GCC optimize ("-fno-lto")
 ^~~

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization
   Last reconfirmed||2016-06-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|[7 regression' Performance  |[7 regression] Performance
   |regression after r235817|regression after r235817
   Target Milestone|--- |7.0

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/71438] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (by tree vectorizer)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||alan.hayward at arm dot com
   Target Milestone|--- |7.0
Summary|wrong code at -O3 on|[7 Regression] wrong code
   |x86_64-linux-gnu (by tree   |at -O3 on x86_64-linux-gnu
   |vectorizer) |(by tree vectorizer)

[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71423] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code
   |code at -Os and above on|at -Os and above on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  7 07:31:40 2016
New Revision: 237167

URL: https://gcc.gnu.org/viewcvs?rev=237167=gcc=rev
Log:
2016-06-07  Richard Biener  

PR tree-optimization/71428
* tree-ssa-math-opts.c (perform_symbolic_merge): Properly distinguish
BIT_FIELD_REF op vs. load.

* gcc.dg/torture/pr71428.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71428.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug tree-optimization/71423] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  7 07:30:47 2016
New Revision: 237166

URL: https://gcc.gnu.org/viewcvs?rev=237166=gcc=rev
Log:
2016-06-07  Richard Biener  

PR middle-end/71423
* match.pd ((X | ~Y) -> Y <= X): Properly invert the comparison
for signed ops.

* gcc.dg/torture/pr71423.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71423.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/71440] ICE on invalid C++ code on x86_64-linux-gnu: in instantiate_type, at cp/class.c:8247

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/71438] wrong code at -O3 on x86_64-linux-gnu (by tree vectorizer)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Also started with r237064 so maybe a dup of PR71439.

[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-07
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|wrong code at -O3 in 32-bit |[7 Regression] wrong code
   |and 64-bit mode on  |at -O3 in 32-bit and 64-bit
   |x86_64-linux-gnu|mode on x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r237064.

[Bug c++/71440] New: ICE on invalid C++ code on x86_64-linux-gnu: in instantiate_type, at cp/class.c:8247

[su at cs dot ucdavis.edu]

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

Bug ID: 71440
   Summary: ICE on invalid C++ code on x86_64-linux-gnu: in
instantiate_type, at cp/class.c:8247
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

It seems to also affect all earlier versions since at least 4.6.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.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 7.0.0 20160606 (experimental) [trunk revision 237117] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp: In instantiation of ‘void C::bar() [with T = int]’:
small.cpp:19:16:   required from here
small.cpp:15:10: error: cannot call constructor ‘A::A’ directly
 B < ::A > b; // should be: B < ::f > b;
  ^
small.cpp:15:17: internal compiler error: in instantiate_type, at
cp/class.c:8247
 B < ::A > b; // should be: B < ::f > b;
 ^
0x73a7a0 instantiate_type(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/class.c:8244
0x6e526b convert_nontype_argument
../../gcc-source-trunk/gcc/cp/pt.c:6628
0x6ebcc3 convert_template_argument
../../gcc-source-trunk/gcc/cp/pt.c:7269
0x6f72eb coerce_template_parms
../../gcc-source-trunk/gcc/cp/pt.c:7730
0x6fa04a lookup_template_class_1
../../gcc-source-trunk/gcc/cp/pt.c:8313
0x6fa04a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-source-trunk/gcc/cp/pt.c:8654
0x6fd88b tsubst_aggr_type
../../gcc-source-trunk/gcc/cp/pt.c:11437
0x6e6b77 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:12908
0x6ee2e7 tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:12324
0x6e6f7e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:12829
0x6d4227 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15174
0x6d4b30 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15303
0x6d1535 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22033
0x71e0f2 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22152
0x7611d7 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4600
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


struct A 
{
  void f () {}
};

typedef void (A::*Ptr) ();

template < Ptr > struct B {};

template < class T > 
struct C : public A
{
  void bar ()
  {
B < ::A > b; // should be: B < ::f > b;
  } 
};

template class C < int >;