[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #6 from Vittorio Zecca  ---
After applying the proposed patch the asan memory checker did not report
any memory fault, in particular the heap-use-after-free in interface.c

Fritz, do you have a -fsanitize=address version of gfortran, in
particular of f951?

[Bug tree-optimization/67886] Incomplete optimization for virtual function call into freshly constructed object

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---

Dropping polymorphic call info; it can not be used by ipa-prop
t99.cc:15:25: note: speculatively devirtualizing call in void test()/7 to
virtual void Derived::func()/0
Indirect call -> speculative call void test()/7 => virtual void
Derived::func()/0
1 polymorphic calls, 0 devirtualized, 1 speculatively devirtualized, 0 cold
0 have multiple targets, 0 overwritable, 0 already speculated (0 agree, 0
disagree), 0 external, 0 not defined, 0 artificial, 1 infos dropped


Confirmed.  GCC is also to speculatively devirtualizing.  The first time
through the loop it is Derived::func but then that is a pure/const function
which means it is does not change memory so rest through the loop, it should
detect that it can  devirtualizing the function call.

[Bug tree-optimization/67886] Incomplete optimization for virtual function call into freshly constructed object

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|minor   |enhancement

[Bug c++/77376] GCC segfaults/returns bogus error (depending on version) when calling a member function from a generic lambda with a captured this without using "this->" explicitly.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
dup

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

[Bug c++/61636] generic lambda "cannot call member function without object"

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||tinab at hush dot ai

--- Comment #19 from Markus Trippelsdorf  ---
*** Bug 77376 has been marked as a duplicate of this bug. ***

[Bug c++/77376] GCC segfaults/returns bogus error (depending on version) when calling a member function from a generic lambda with a captured this without using "this->" explicitly.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. May be a dup of PR61636.

[Bug ipa/69033] [6 regression] many internal compiler errors starting with r231928

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |ipa
   Target Milestone|--- |6.0

[Bug tree-optimization/69047] memcpy is not as optimized as union is

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|arm, aarch64|
  Component|rtl-optimization|tree-optimization
Summary|memcpy of 64-bit integer to |memcpy is not as optimized
   |32-bit integer causes   |as union is
   |pointless stack operations  |
   |on ARM  |
   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
Take:
union li
{
  int a[2];
  long long b;
};
int f(long long b) {
int a;
__builtin_memcpy(, , sizeof a);
return a;
}
int f1(long long b) {
union li a;
a.b = b;
return a.a[0];
}

These two functions should produce the same code but f produces worse.

Also f1 is optimized at the tree level while f is optimized at the RTL level
leaving behind the stack location that is used to store b.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
The test case you propose, dec_structure_13.f90, does not trigger the asan
memory checker.

As I wrote before, the test case gfortran.dg/import4.f90 does trigger
the asan memory checker.

In your test case I do not understand the final statement "call
sub2(u2)" because
sub2 is not defined.

[Bug c++/66096] Unexpected __gnu_cxx::__concurrence_lock_error with _GLIBCXX_DEBUG

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No feedback in over a year so closing.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
The reproducer I proposed comes from testcase gfortran.dg/import4.f90

[Bug c++/77376] New: GCC segfaults/returns bogus error (depending on version) when calling a member function from a generic lambda with a captured this without using "this->" explicitly.

[tinab at hush dot ai]

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

Bug ID: 77376
   Summary: GCC segfaults/returns bogus error (depending on
version) when calling a member function from a generic
lambda with a captured this without using "this->"
explicitly.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tinab at hush dot ai
  Target Milestone: ---

GCC segfaults/returns bogus error (depending on version) when calling a member
function from a generic lambda with a captured this without using "this->"
explicitly.

Seems to affect all versions of GCC with different results.

On 5.4.0 a bogus error is returned: 
error: cannot call member function ‘...’ without object

On other versions of GCC a segmentation fault occurs (up to and including GCC
7.0.0). This bug only occurs when a member function is called without "this->"
being specified from the generic lambda, using "this->" explicitly resolves the
problem.

Example (from http://coliru.stacked-crooked.com/a/2a41c21343437d9c)
===
g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp: In lambda function:
main.cpp:13:10: internal compiler error: Segmentation fault
 thing(asdf, foo);

Test case
=

#include 
#include 
#include 

struct Foo {
  void test();
  void thing(void* a1, std::string a2);
};

void Foo::test() {
auto foo = "gfdgfd";
auto l = [&](auto asdf) {
 thing(asdf, foo);
};
l(nullptr);
}

void Foo::thing(void* a1, std::string a2) {
}

int main()
{
}

[Bug driver/50250] Driver documentation on -l does not mention shared libraries

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Tom Payerle from comment #4)
> In the interest of actually getting this fixed, may I suggest the following
> revised wording:

Create a diff patch against ^/trunk:

See point 8 here:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

Send to gcc-patches with "[doc]" somewhere in the subject (see examples of
subjects in the archives: https://gcc.gnu.org/ml/gcc-patches/

CC docs co-maintainers (you can find their emails in the MAINTAINERS file).

[Bug target/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Peter Bergner  ---
Adding Vlad since there are IRA and LRA questions.


(In reply to Segher Boessenkool from comment #2)
> It already goes wrong at IRA:
> 
[snip]
> 
> (define_insn "*movsf_update1"
>   [(set (match_operand:SF 3 "gpc_reg_operand" "=f,f")
> (mem:SF (plus:SI (match_operand:SI 1 "gpc_reg_operand" "0,0")
>  (match_operand:SI 2 "reg_or_short_operand" "r,I"
>(set (match_operand:SI 0 "gpc_reg_operand" "=b,b")
> (plus:SI (match_dup 1) (match_dup 2)))]
> 
> so operand 1 is not the same as operand 0.

I'm not sure if IRA is supposed to always assign operand 1 the same register as
operand 0 here, or whether that is reload/LRA's job.  Vlad?

I will say that with -mno-lra, reload handles the above just fine, by noticing
that the two operands do not have the same register and forces a reload that
fixes things up.

The same does not happen in LRA, even though it does check.  What happens is
that lra-constraints.c:process_alt_operands() (line #1991) which does the
checking, uses operands_match_p()/get_hard_regno() to check if the two operands
are the same.  Before get_hard_regno() returns its hardreg #, it passes it to
get_final_hard_regno(), which in turn passes it to
lra_get_elimination_hard_regno().  In the case above, reg 208 has been assigned
r31, but lra_get_elimination_hard_regno(31) returns r1 since r31 can be
eliminated to r1 normally.  Since r1 was returned for operand 0 instead of r31,
it looks like our insn satisfies its constraints by having operand 0 and
operand 1 being assigned to the same register, so we don't modify it.  However,
later when LRA calls check_rtl/extract_constrain_insn, they doesn't recognize
r31 and r1 as being the same, so it throws an ICE.

In the case above, I'm not sure we can eliminate r31 in favor of r1, since this
is a load with update insn and I don't think we can use r1 as the address reg,
since the update would clobber the stack pointer.  If I add the following hack:

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 239609)
+++ lra-constraints.c   (working copy)
@@ -2010,8 +2010,10 @@ process_alt_operands (int only_alternati
   this alternative may be rejected when it is
   actually desirable.)  */
match_p = false;
-   if (operands_match_p (*curr_id->operand_loc[nop],
- *curr_id->operand_loc[m], m_hregno))
+   if (m_hregno != STACK_POINTER_REGNUM
+   && operands_match_p (*curr_id->operand_loc[nop],
+*curr_id->operand_loc[m],
+m_hregno))
  {
/* We should reject matching of an early
   clobber operand if the matching operand is

...then it passes and generates the same code reload does.

Vlad, should we be disallowing matching of eliminable registers here or just
special ones like stack pointers and maybe others?  If so, I guess we could add
a strict param to get_hard_regno() and get_final_hard_regno() that doesn't
allow eliminable registers by not calling lra_get_elimination_hard_regno() when
strict.  Thoughts?

[Bug c++/77375] New: constant object with mutable subobject allocated in read-only memory

[Casey at Carter dot net]

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

Bug ID: 77375
   Summary: constant object with mutable subobject allocated in
read-only memory
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

When run, this program results in a segmentation fault:

struct Base {
mutable int i;
};

struct Derived : Base {};

const Derived foo{};

int main() { foo.i = 42; }

Despite its mutable subobject, the compiler allocates foo in read-only memory.

[Bug driver/50250] Driver documentation on -l does not mention shared libraries

[payerle at umd dot edu]

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

--- Comment #4 from Tom Payerle  ---
In the interest of actually getting this fixed, may I suggest the following
revised wording:

Search the library named @var{library} when linking.  (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)

This is actually just passed directly to the linker, so the exact behavior is
dependent on your linker.  The description below is provided as a courtesy to
users; your linker documentation should be considered definitive and should be
referred to for more details.

Typically, the linker will search a list of directories for a library with a
name matching @var{library}.  On Unix-like systems, this is usually a file
named @file{lib@var{library}.@var{ext}} where @var{ext} is @samp{.a} for static
libraries or @samp{.so} for dynamic libraries.  The list of directories
searched
typically consists of several standard directories (system dependent) as well
as
directories added with the @option{-L} option.

Note that in general it makes a difference where in the command you write this
option: the linker typically processes libraries and object files in the order
they are specified.  Symbols in object files (or even other libraries specified
with the @samp{-l} option) that follow the @samp{-l@var{library}} option on the
command line might not get resolved.  


I think the above provides the same basic information as the original to the
casual reader while making it clear that one needs to read the linker
documentation for details.

[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #10)
> > t.c:4:13: warning: logical not is only applied to the left hand side of
> > comparison [-Wlogical-not-parentheses]
> >return !a == (a < b);
> >  ^~
> 
> Why is this not a valid warning?

Ah, this is on purpose to avoid too many false positives. Sorry for the noise.

[Bug tree-optimization/71026] Missing division optimizations

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Wed, 24 Aug 2016, ktkachov at gcc dot gnu.org wrote:

> int f4(float x) { return (1.0f / x) < 0.0f; } // -> x < 0.0f

Requires -fno-trapping-math, as this could lose an overflow or underflow 
from the division (but provided subnormals are supported, it can't 
underflow to zero for IEEE types).

> int f5(float x) { return (x / 2.0f) <= 0.0f; }// -> x <= 0.0f

Requires -funsafe-math-optimizations or similar; this is not a correct 
transformation for the least positive subnormal.  (In principle, given 
-fno-rounding-math -fno-trapping-math, you could convert this to x <= 
FLT_TRUE_MIN and be correct.)

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com  ---
On Wed, 24 Aug 2016, bernd.edlinger at hotmail dot de wrote:

> glibc's malloc returns 128-bit aligned on x86-64-linux-gnu.
> but what does it return on windows?

glibc does not support Windows.  I've no idea what Windows malloc returns 
(and it could always depend on which C library version is used; there are 
several that MinGW can be made to use).

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com  ---
On Wed, 24 Aug 2016, bernd.edlinger at hotmail dot de wrote:

> It is only necessary if __float128 is declared a base type.
> But __m512 is no base type, right?

It's clear that __m512 should not be considered a basic type - such types 
are a large part of the point of having aligned_alloc and other such 
aligned allocation interfaces.

__float128 is now (GCC 7) an alias for _Float128, which is defined by TS 
18661-3 to be a basic type (and _Decimal128 met the relevant requirements 
long before that).

> Then MALLOC_ABI_ALIGNMENT should be changed to 128 at least for the i386.

I think that would risk breaking applications that do not use any 
16-byte-aligned types, without obvious benefits (only those programs that 
do use those types are affected by the present issue with malloc providing 
insufficient alignment).

MALLOC_ABI_ALIGNMENT is indeed unnecessarily conservative.  For glibc 
targets it could reflect the actual glibc logic, depending on the glibc 
version determined at GCC configure time - except that this might break 
things for applications that replace malloc with a version that yields 
lower alignment (possibly only for small allocations - if there is a 
16-byte-aligned basic type, ISO C requires malloc (1) to return a 
16-byte-aligned address, but some replacements may be for contexts where 
that is unnecessary), knowing the higher alignment is irrelevant to their 
application, so there would need to be some way to address that breakage.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[fritzoreese at gmail dot com]

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

--- Comment #3 from Fritz Reese  ---
> interface.c:403 is 
> if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
> 
> and I believe d->attr.flavor is the item used after freed.

This is correct, and the reason is clear when you look up a few lines and
realize I did not check the type of cmp1 or cmp2 before jumping straight to
checking properties about their derived type declarations (in
cmp->ts.u.derived). Unless cmp->ts.type == BT_DERIVED or cmp->ts.type ==
BT_UNION, the cmp->ts.u.derived pointer is garbage.

I have a patch which implements that part of code in a different way - also
correctly and more reliably. It fixes this PR and I hope to commit it over the
weekend:
https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html

However I am not sure how one would observe that no invalid memory references
occur for your code via a DejaGNU testcase. I would appreciate ideas for a
testcase I can commit with the aforementioned patch to ensure this PR isn't
regressed.

[Bug libfortran/74755] libgfortran: build breaks if localtime_r prototype is present, but definition is not

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
The target is nvptx-none, specifically when it is built as an offloaded target
for OpenACC. Thomas thinks the problem is in newlib rather than gcc though.

[Bug libfortran/74755] libgfortran: build breaks if localtime_r prototype is present, but definition is not

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Target?

[Bug fortran/77371] [6/7 Regression] ICE in force_constant_size, at gimplify.c:671 (... and others)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-24
  Known to work||5.4.0
Summary|ICE in force_constant_size, |[6/7 Regression] ICE in
   |at gimplify.c:671 (... and  |force_constant_size, at
   |others) |gimplify.c:671 (... and
   ||others)
 Ever confirmed|0   |1
  Known to fail||6.2.0, 7.0

--- Comment #3 from Dominique d'Humieres  ---
Compiling the test in comment 0 has started to give an ICE between revisions
r232023 (2016-01-01, compiles) and r232451 (2016-01-15, ICE), r232151?

The tests in comments 1 and 2 require a compiler configured with
--enable-checking=yes. Compiling the test in comment 1 gives an ICE with 6.0.0
r235027, but not with 5.0 r220825, while the test in comment 2 gives an ICE for
both.

[Bug fortran/77358] [F08] deferred-length character function returns zero-length string

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Fixed on trunk and 6-branch.

Thanks for the report.

Paul

[Bug fortran/77358] [F08] deferred-length character function returns zero-length string

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Wed Aug 24 19:45:56 2016
New Revision: 239741

URL: https://gcc.gnu.org/viewcvs?rev=239741=gcc=rev
Log:
2016-08-24  Paul Thomas  

PR fortran/77358
* resolve.c (resolve_fl_procedure): Use the correct gfc_charlen
for deferred character length module procedures.

2016-08-24  Paul Thomas  

PR fortran/77358
* gfortran.dg/submodule_17.f08: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_17.f08
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/77372] ICE in simplify_ieee_selected_real_kind, at fortran/simplify.c:7049

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Thous shalt dereference NULL pointers.

Index: simplify.c
===
--- simplify.c  (revision 239737)
+++ simplify.c  (working copy)
@@ -7044,9 +7044,19 @@ gfc_simplify_compiler_version (void)
 gfc_expr *
 simplify_ieee_selected_real_kind (gfc_expr *expr)
 {
-  gfc_actual_arglist *arg = expr->value.function.actual;
-  gfc_expr *p = arg->expr, *q = arg->next->expr,
-  *rdx = arg->next->next->expr;
+  gfc_actual_arglist *arg;
+  gfc_expr *p = NULL, *q = NULL, *rdx = NULL;
+
+  arg = expr->value.function.actual;
+  if (arg->expr)
+p = arg->expr;
+  if (arg->next)
+{
+  if (arg->next->expr)
+   q = arg->next->expr;
+  if (arg->next->next && arg->next->next->expr)
+   rdx = arg->next->next->expr;
+}

   /* Currently, if IEEE is supported and this module is built, it means
  all our floating-point types conform to IEEE. Hence, we simply handle

[Bug fortran/77358] [F08] deferred-length character function returns zero-length string

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Wed Aug 24 19:33:14 2016
New Revision: 239740

URL: https://gcc.gnu.org/viewcvs?rev=239740=gcc=rev
Log:
2016-08-24  Paul Thomas  

PR fortran/77358
* resolve.c (resolve_fl_procedure): Use the correct gfc_charlen
for deferred character length module procedures.

2016-08-24  Paul Thomas  

PR fortran/77358
* gfortran.dg/submodule_17.f08: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_17.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77372] ICE in simplify_ieee_selected_real_kind, at fortran/simplify.c:7049

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-24
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||error-recovery,
   ||ice-on-invalid-code
   Last reconfirmed||2016-08-24
 Ever confirmed|0   |1
Summary|ICE in resolve_omp_atomic,  |[6/7 Regression] ICE in
   |at fortran/openmp.c:3949|resolve_omp_atomic, at
   ||fortran/openmp.c:3949
  Known to fail||6.2.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
The ICE appeared between revisions r227754 (2015-09-14, no ICE) and r228407
(2015-10-02, ICE). When the compiler is configured with
--enable-checking=release, the ICE is replaced with

(null):0: confused by earlier errors, bailing out

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #25 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01749.html

[Bug fortran/77374] New: ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77374
   Summary: ICE in resolve_omp_atomic, at fortran/openmp.c:3949
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Invalid code with a displaced OpenMP directive.
Configured with --enable-checking=yes.


$ cat z1.f90
subroutine s1 (a, b)
   integer :: a, b
!$omp atomic
   b = b + a
!$omp atomic
end subroutine

subroutine s2 (x, z)
   integer :: x(2), z(2)
   z(1) = z(1) + x(1)
end subroutine


$ cat z2.f90
program p
   !integer :: x(1)
   !$omp atomic
   x(1) = x(1) + 1
end


$ gfortran-7-20160821 -fopenmp -c z1.f90
z1.f90:6:3:

 end subroutine
   1
Error: Unexpected END statement at (1)
z1.f90:8:0:

 subroutine s2 (x, z)

Error: Unclassifiable statement at (1)
z1.f90:9:24:

integer :: x(2), z(2)
1
Error: Unexpected data declaration statement at (1)
z1.f90:10:3:

z(1) = z(1) + x(1)
   1
Error: The function result on the lhs of the assignment at (1) must have the
pointer attribute.
f951: internal compiler error: in resolve_omp_atomic, at fortran/openmp.c:3949
0x6c69d8 resolve_omp_atomic
../../gcc/fortran/openmp.c:3949
0x6ec7dd gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10844
0x6eed92 resolve_codes
../../gcc/fortran/resolve.c:15560
0x6eee8e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15595
0x6da1aa resolve_all_program_units
../../gcc/fortran/parse.c:5855
0x6da1aa gfc_parse_file()
../../gcc/fortran/parse.c:6107
0x71c622 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug c++/77373] __attribute__((vector_size(N))) fails on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-24
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/77373] New: __attribute__((vector_size(N))) fails on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 77373
   Summary: __attribute__((vector_size(N))) fails on AIX
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
Depends on: 68703
  Target Milestone: ---
Target: powerpc-ibm-aix*

vector32.C and vector32a.C fail on AIX

internal compiler error: in get, at cgraph.h:395


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703
[Bug 68703] __attribute__((vector_size(N))) template member confusion

[Bug fortran/77372] New: ICE in simplify_ieee_selected_real_kind, at fortran/simplify.c:7049

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77372
   Summary: ICE in simplify_ieee_selected_real_kind, at
fortran/simplify.c:7049
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects gfortran 7, 6, 5 (not implemented before 5).


$ cat z1.f90
program p
   use ieee_arithmetic
   real(kind=ieee_selected_real_kind(10_1)) :: z1
   real(kind=ieee_selected_real_kind(10_2)) :: z2
   real(kind=ieee_selected_real_kind(10_8)) :: z8
   real(kind=ieee_selected_real_kind(10_16)) :: z16
end


$ gfortran-7-20160821 z1.f90
f951: internal compiler error: Segmentation fault
0xc1b65f crash_signal
../../gcc/toplev.c:335
0x70767f simplify_ieee_selected_real_kind(gfc_expr*)
../../gcc/fortran/simplify.c:7049
0x68a607 gfc_check_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2485
0x68acd7 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2670
0x68bc69 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2709
0x675c18 gfc_match_kind_spec(gfc_typespec*, bool)
../../gcc/fortran/decl.c:2539
0x67af2e gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3330
0x67c3a6 gfc_match_data_decl()
../../gcc/fortran/decl.c:4744
0x6d0269 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6d3a7e match_word
../../gcc/fortran/parse.c:373
0x6d3a7e decode_statement
../../gcc/fortran/parse.c:373
0x6d5784 next_free
../../gcc/fortran/parse.c:1148
0x6d5784 next_statement
../../gcc/fortran/parse.c:1382
0x6d66dc parse_spec
../../gcc/fortran/parse.c:3708
0x6d8bb3 parse_progunit
../../gcc/fortran/parse.c:5493
0x6da154 gfc_parse_file()
../../gcc/fortran/parse.c:6002
0x71c622 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77371] ICE in force_constant_size, at gimplify.c:671 (... and others)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---

Related :

$ cat z6.f90
program p
   integer, allocatable :: n
!$acc parallel reduction (+:n) private(n)
!$acc end parallel
end


$ gfortran-7-20160821 -fopenacc z6.f90
z6.f90:3:0:

 !$acc parallel reduction (+:n) private(n)

Error: invalid private reduction on 'n'
z6.f90:3:0: internal compiler error: in scan_sharing_clauses, at omp-low.c:2374
0xb05762 scan_sharing_clauses
../../gcc/omp-low.c:2373
0xb127d8 scan_omp_target
../../gcc/omp-low.c:3191
0xb127d8 scan_omp_1_stmt
../../gcc/omp-low.c:3982
0x9a308a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9a32a8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9a31e2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:632
0x9a32a8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9a3162 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9a32a8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xae78e9 scan_omp
../../gcc/omp-low.c:4025
0xb1c88a execute_lower_omp
../../gcc/omp-low.c:17902
0xb1c88a execute
../../gcc/omp-low.c:17949

[Bug fortran/77371] ICE in force_constant_size, at gimplify.c:671 (... and others)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

$ cat z2.f90
program p
   integer, allocatable :: z
   !$acc parallel
   z = 1
   !$acc end parallel
   print *, z
end


$ gfortran-7-20160821 -fopenacc z2.f90
z2.f90:2:0:

integer, allocatable :: z

Error: non-trivial conversion at assignment
integer(kind=4)
integer(kind=4) *
z.3 = *D.3442;
z2.f90:2:0: internal compiler error: verify_gimple failed
0xc54e6d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:4879
0xb4a3d0 execute_function_todo
../../gcc/passes.c:1966
0xb4ac95 execute_todo
../../gcc/passes.c:2014

[Bug fortran/77371] New: ICE in force_constant_size, at gimplify.c:671 (... and others)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77371
   Summary: ICE in force_constant_size, at gimplify.c:671 (... and
others)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Some snippets with allocatable scalars (valid code) combined with
OpenACC. Similar issue for "pointer" instead of "allocatable".


$ cat z1.f90
program p
   character(:), allocatable :: z
   !$acc parallel
   z = 'abc'
   !$acc end parallel
   print *, z
end


$ gfortran-7-20160821 -fopenacc z1.f90
z1.f90:3:0:

!$acc parallel

internal compiler error: in force_constant_size, at gimplify.c:671
0x9a4ad6 force_constant_size
../../gcc/gimplify.c:671
0x9ab547 gimple_add_tmp_var(tree_node*)
../../gcc/gimplify.c:709
0x9860ea create_tmp_var(tree_node*, char const*)
../../gcc/gimple-expr.c:476
0xb1ac2d lower_omp_target
../../gcc/omp-low.c:15920
0xb1ac2d lower_omp_1
../../gcc/omp-low.c:17084
0xb1ac2d lower_omp
../../gcc/omp-low.c:17177
0xb1564c lower_omp_1
../../gcc/omp-low.c:17016
0xb1564c lower_omp
../../gcc/omp-low.c:17177
0xb15fec lower_omp_1
../../gcc/omp-low.c:17025
0xb15fec lower_omp
../../gcc/omp-low.c:17177
0xb1d1cf execute_lower_omp
../../gcc/omp-low.c:17912
0xb1d1cf execute
../../gcc/omp-low.c:17949

[Bug c++/77370] New: missing -Wignored-qualiifiers on a bogus const reference

[msebor at gcc dot gnu.org]

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

Bug ID: 77370
   Summary: missing -Wignored-qualiifiers on a bogus const
reference
   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: ---

GCC rejects the program below because it tries to initialize the non-const
reference object cr with a temporary, but it doesn't diagnose the declaration
of the reference type CR where it disregards the const qualifier.  In contrast,
Clang diagnoses both.  GCC could be improved by doing the same.

$ (set -x && cat z.C && /build/gcc-trunk-svn/gcc/xgcc -B
/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic z.C;
/build/llvm-trunk/bin/clang -S -Wall z.C)
+ cat z.C
typedef char& R;
typedef const R CR;

char c;
R r = c;
CR cr = 'b';
+ /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall -Wextra
-Wpedantic z.C
z.C:6:9: error: cannot bind non-const lvalue reference of type ‘CR {aka char&}’
to an rvalue of type ‘char’
 CR cr = 'b';
 ^~~
+ /build/llvm-trunk/bin/clang -S -Wall z.C
z.C:2:9: warning: 'const' qualifier on reference type 'R' (aka 'char &') has no
  effect [-Wignored-qualifiers]
typedef const R CR;
^~
z.C:6:4: error: non-const lvalue reference to type 'char' cannot bind to a
  temporary of type 'char'
CR cr = 'b';
   ^~~~
1 warning and 1 error generated.

[Bug fortran/77360] Self-assignment of allocatable character array yields erroneous result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
This has been caused by revision r233797 and fixed on trunk and the gcc-6
branch by revisions r236525 and r236526 respectively. It is fixed on the 6.2.0
release.

[Bug target/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
And this 208 vs. sfp is created by combine:

Trying 76 -> 77:
Successfully matched this instruction:
(parallel [
(set (reg:SF 33 1)
(mem:SF (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [1 MEM[base: _17, offset: 0B]+0 S4
A32]))
(set (reg:SI 208 [ ivtmp.6 ])
(plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])))
])

[Bug target/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
It already goes wrong at IRA:

(insn 77 79 71 3 (parallel [
(set (reg:SF 33 1)
(mem:SF (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [1 MEM[base: _17, offset: 0B]+0 S4
A32]))
(set (reg:SI 208 [ ivtmp.6 ])
(plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])))
]) 77289.c:9 617 {*movsf_update1}
 (nil))

where 208 is assigned r31:

   19:r206 l0291:r208 l0312:r209 l030   18:r247 l075

but the pattern is

(define_insn "*movsf_update1"
  [(set (match_operand:SF 3 "gpc_reg_operand" "=f,f")
(mem:SF (plus:SI (match_operand:SI 1 "gpc_reg_operand" "0,0")
 (match_operand:SI 2 "reg_or_short_operand" "r,I"
   (set (match_operand:SI 0 "gpc_reg_operand" "=b,b")
(plus:SI (match_dup 1) (match_dup 2)))]

so operand 1 is not the same as operand 0.

[Bug testsuite/77317] x86_64 --target_board=''unix/ unix/-m32'' parallel testrun gives inconsistent results in gcc.dg/vect

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |robert.suchanek at 
imgtec dot com

--- Comment #3 from Tom de Vries  ---
Marking resolved-fixed

[Bug c++/77368] Private static member visible to templated subclass

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
It's PR 58993

PR 59002 tracks the others.

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

[Bug c++/58993] incorrectly accept access of protected member method from derived class template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||albin.olsson at volvocars dot 
com

--- Comment #4 from Jonathan Wakely  ---
*** Bug 77368 has been marked as a duplicate of this bug. ***

[Bug c++/77368] Private static member visible to templated subclass

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
There are several bugs related to access checking in templates, this is a dup
of one of them.

[Bug c++/77369] incorrect noexcept specification deduction

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/77369] New: incorrect noexcept specification deduction

[aaron.ballman+gcc at gmail dot com]

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

Bug ID: 77369
   Summary: incorrect noexcept specification deduction
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron.ballman+gcc at gmail dot com
  Target Milestone: ---

The following code produces "false, false" with Clang 3.8.0 and MSVC 2015, but
"true, true" with GCC 6.1.0 (and EDG).

#include 

template 
int some_function(int param, Func fn) noexcept(noexcept(fn(param))) {
  return fn(param);
}

int noexcept_fn(int) noexcept(true) { return 0; }
int not_noexcept_fn(int) noexcept(false) { return 0; }

int main() {
  std::cout << std::boolalpha <<
noexcept(some_function(0, noexcept_fn)) << ", " <<
noexcept(some_function(0, not_noexcept_fn)) << std::endl;
}

This is dangerous because it means that if not_noexcept_fn() throws (as it is
allowed to do per its exception specification) when called from
some_function(), it results in std::terminate() being called due to
some_function() having the wrong exception specification.

This happens with -std=c++14, where exception specifications are not considered
part of the type system.

[Bug rtl-optimization/70134] combine misses jump optimization on powerpc64le

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
The reason why it is missed on the tree level is due to the code being
undefined.  In that it uses uninitialized variables like:
  if (iter_5(D) >= itmx_6(D))
goto ;
  else
goto ;

[Bug target/77270] Flag -mprftchw is shared with 3dnow for -march=k8

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Aug 24 14:59:43 2016
New Revision: 239737

URL: https://gcc.gnu.org/viewcvs?rev=239737=gcc=rev
Log:
PR target/77270
* gcc.dg/tree-ssa/loop-28.c: Also compile on 32bit x86 targets.
(dg-options): Use -march=amdfam10 instead of -march=athlon.
* gcc.dg/tree-ssa/update-unroll-1.c: Ditto.
* gcc.dg/tree-ssa/prefetch-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-4.c: Ditto.
* gcc.dg/tree-ssa/prefetch-5.c: Ditto.
* gcc.dg/tree-ssa/prefetch-6.c: Ditto.  Do not require sse2
effective target.  Remove scan-assembler-times directives.
* gcc.dg/tree-ssa/prefetch-7.c: Ditto.
* gcc.dg/tree-ssa/prefetch-8.c: Ditto.
* gcc.dg/tree-ssa/prefetch-9.c: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-9.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/update-unroll-1.c

[Bug c++/77368] New: Private static member visible to templated subclass

[albin.olsson at volvocars dot com]

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

Bug ID: 77368
   Summary: Private static member visible to templated subclass
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albin.olsson at volvocars dot com
  Target Milestone: ---

The following code is accepted by g++, but only if B is a templated class:

struct A
{
private:
static const int private_of_A = 5;
};

template 
struct B : public A
{
int get()
{
return private_of_A;
}
};

int main()
{
B b;
return b.get();
}


This problem exists for all version of gcc I tested, which are:
x86-64 gcc 4.8.4
x86-64 gcc 6.2 (g++ ('Compiler) 6.2.0)
ARM64 gcc 4.8 (aarch64-linux-gnu-g++ (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.1)
5.4.0 20160609)
The two latter ones via https://gcc.godbolt.org/#

[Bug tree-optimization/71026] Missing division optimizations

[wdijkstr at arm dot com]

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

--- Comment #3 from Wilco  ---
(In reply to ktkachov from comment #2)
> The transforms
> 
> int f4(float x) { return (1.0f / x) < 0.0f; } // -> x < 0.0f
> int f5(float x) { return (x / 2.0f) <= 0.0f; }// -> x <= 0.0f
> 
> can be done as match.pd patterns, no?

Note f5 is already transformed to (x * 0.5f) <= 0.0f even with -O2. The more
general form for that one is (X * C0) <= C1 -> X <= C1/C0.

[Bug c++/77367] Duck-typing error not detected when using CRTP

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #2 from Andrew Pinski  ---
.

[Bug c++/77364] -fnon-call-exceptions does not work

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Invalid, as raise is nothrow.
It just works by accident for the non non-call-exceptions case

[Bug middle-end/77357] strlen of constant strings not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Martin Sebor  ---
Sorry, wrong test case.  Here's the right one:

const char a[] = "abc";
const char* const s = "abc";

void global_array (void)
{
  if (__builtin_strlen (a) != 3)
__builtin_abort ();
}

void local_array (void)
{
  static const char a[] = "abc";
  if (__builtin_strlen (a) != 3)
__builtin_abort ();
}

void global_pointer (void)
{
  if (__builtin_strlen (s) != 3)
__builtin_abort ();
}

void local_pointer (void)
{
  static const char* const s = "abc";
  if (__builtin_strlen (s) != 3)
__builtin_abort ();
}


struct X { char a [4]; };
const struct X x = { "abc" };

void global_struct (void)
{
  if (__builtin_strlen (x.a) != 3)
__builtin_abort ();
}

void local_struct (void)
{
  static const struct X x =  { "abc" };
  if (__builtin_strlen (x.a) != 3)
__builtin_abort ();
}

[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64*-*-*, s390x-*-*

--- Comment #10 from Richard Biener  ---
Testcase from PR77366 for s390x.

void
foo(unsigned int size, unsigned int *state)
{
   unsigned int i;

   for(i = 0; i < size; i++)
{
   if(*state & 1)
 {
   *state ^= 1;
 }
}
}

[Bug c++/77367] Duck-typing error not detected when using CRTP

[yuhang_tang at brown dot edu]

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

Yu-Hang Tang  changed:

   What|Removed |Added

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

--- Comment #1 from Yu-Hang Tang  ---
I just realized that this resulted in Base::B() calling itself indefinitely and
hence is not a compiler bug. However maybe it would nice for GCC to throw out a
warning in this case?

[Bug middle-end/77366] Rev. 2ac4967 prevents loop unrolling for s390

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Richard Biener  ---
Is this the same as PR77283?  (please use svn revisions ...)

I guess so.

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

[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rdapp at linux dot vnet.ibm.com

--- Comment #9 from Richard Biener  ---
*** Bug 77366 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/71026] Missing division optimizations

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The transforms

int f4(float x) { return (1.0f / x) < 0.0f; } // -> x < 0.0f
int f5(float x) { return (x / 2.0f) <= 0.0f; }// -> x <= 0.0f

can be done as match.pd patterns, no?

[Bug c++/77367] New: Duck-typing error not detected when using CRTP

[yuhang_tang at brown dot edu]

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

Bug ID: 77367
   Summary: Duck-typing error not detected when using CRTP
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuhang_tang at brown dot edu
  Target Milestone: ---

The following code was able to pass compilation & linking, yet the Derived::B()
function is not defined. Since the cast is static I would expect that the
compiler could find that there is not a definition of
static_cast(*this).B() and raise an error.

template
struct Base {
void A() { static_cast(*this).A(); }
void B() { static_cast(*this).B(); }
};

struct Derived : Base {
void A() {}
//void B() {}
};

int main() {
Derived d;
Base  = d;
b.A();
b.B();
}

This resulted in the compiled binary hanging forever in Fedora 24 Kernel 4.6.5.

[Bug middle-end/77366] New: Rev. 2ac4967 prevents loop unrolling for s390

[rdapp at linux dot vnet.ibm.com]

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

Bug ID: 77366
   Summary: Rev. 2ac4967 prevents loop unrolling for s390
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdapp at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: s390
Target: s390

Since 2ac4967f49a70e1bd0bb28a142324f527dac3743 the following loop is not being
unrolled anymore (-O3 -funroll-loops):

void
foo(unsigned int size, unsigned int *state)
{
   unsigned int i;

   for(i = 0; i < size; i++)
{
   if(*state & 1)
 {
   *state ^= 1;
 }
}
}

The revision adds an additional check that allows the split-paths pass to
duplicate a basic block (returned NULL before the patch) which in turn causes
check_simple_exit() in loop-iv.c to not find a proper niter_desc. This seems
due to

if (!dominated_by_p (CDI_DOMINATORS, loop->latch, exit_bb))

failing, i.e. check_simple_exit() doesn't see that the exit condition is
checked every iteration.

[Bug c/77365] Wrong result with -fcaller-saves on i386

[olebole at debian dot org]

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

--- Comment #4 from Ole Streicher  ---
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-i386/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i686
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 6.2.0 20160822 (Debian 6.2.0-1) 
COLLECT_GCC_OPTIONS='-v' '-O2' '-o' 'm' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/6/cc1 -quiet -v -imultiarch i386-linux-gnu m.c
-quiet -dumpbase m.c -mtune=generic -march=i686 -auxbase m -O2 -version -o
/tmp/ccUvhfOb.s
GNU C11 (Debian 6.2.0-1) version 6.2.0 20160822 (i686-linux-gnu)
compiled by GNU C version 6.2.0 20160822, GMP version 6.1.1, MPFR
version 3.1.4-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i686-linux-gnu/6/../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/6/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
GNU C11 (Debian 6.2.0-1) version 6.2.0 20160822 (i686-linux-gnu)
compiled by GNU C version 6.2.0 20160822, GMP version 6.1.1, MPFR
version 3.1.4-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1e4bebb54de70f35ce8dd91f33b3d708
COLLECT_GCC_OPTIONS='-v' '-O2' '-o' 'm' '-mtune=generic' '-march=i686'
 as -v --32 -o /tmp/ccZBW7WX.o /tmp/ccUvhfOb.s
GNU assembler version 2.27 (i686-linux-gnu) using BFD version (GNU Binutils for
Debian) 2.27
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/6/:/usr/lib/gcc/i686-linux-gnu/6/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/6/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/6/:/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O2' '-o' 'm' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/6/collect2 -plugin
/usr/lib/gcc/i686-linux-gnu/6/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/i686-linux-gnu/6/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccIH7x7J.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker
/lib/ld-linux.so.2 -o m
/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/crt1.o
/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/crti.o
/usr/lib/gcc/i686-linux-gnu/6/crtbegin.o -L/usr/lib/gcc/i686-linux-gnu/6
-L/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu
-L/usr/lib/gcc/i686-linux-gnu/6/../../../../lib -L/lib/i386-linux-gnu
-L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/i686-linux-gnu/6/../../.. /tmp/ccZBW7WX.o -lm -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-linux-gnu/6/crtend.o
/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/crtn.o
COLLECT_GCC_OPTIONS='-v' '-O2' '-o' 'm' '-mtune=generic' '-march=i686'

[Bug c/77365] Wrong result with -fcaller-saves on i386

[olebole at debian dot org]

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

--- Comment #3 from Ole Streicher  ---
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-i386/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i686
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 6.2.0 20160822 (Debian 6.2.0-1)

[Bug c/77365] Wrong result with -fcaller-saves on i386

[olebole at debian dot org]

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

--- Comment #2 from Ole Streicher  ---
Created attachment 39497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39497=edit
Preprocessed source file

[Bug c/77365] Wrong result with -fcaller-saves on i386

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-24
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please specify what is printed if you add -v to the compiler command.  Also
please attach preprocessed source.

Can't reproduce this on x86_64-linux with -m32 -march=i586

[Bug c/77365] New: Wrong result with -fcaller-saves on i386

[olebole at debian dot org]

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

Bug ID: 77365
   Summary: Wrong result with -fcaller-saves on i386
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olebole at debian dot org
  Target Milestone: ---

With gcc-6.2.0 on Debian, I get a wrong result with the following code:

#include 
#include 
#include 

double f(double x) {
  return sqrt(1.0 - x) - 1.0;
}

double g(double x) {
  double res = f(x);
  printf("res=%.20g\n", res);
  return res;
}

int main(void) {
  double x = 3.1740879016271733482e-09;
  double r1 = f(x);
  double r2 = g(x);
  printf("r1=%.20g r2=%.20g diff=%20g\n", r1, r2, r2-r1);
  exit(0);
}  

Compile this with `gcc -O -o m m.c -lm` gives

r =-1.5870439520936432953e-09
r1=-1.5870439407095204842e-09 r2=-1.5870439520936432953e-09 diff=   
-1.13841e-17

Adding `-fno-caller-saves` gives the expected result.

[Bug c++/77364] New: -fnon-call-exceptions does not work

[theubik at mail dot ru]

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

Bug ID: 77364
   Summary: -fnon-call-exceptions does not work
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theubik at mail dot ru
  Target Milestone: ---

Created attachment 39496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39496=edit
example1.cpp and example2.cpp

> g++ -std=c++11 -fnon-call-exceptions example1.cpp && ./a.out
> terminate called after throwing an instance of 'std::runtime_error'
what():  Segmentation fault
  Aborted (core dumped)

> g++ -std=c++11 example1.cpp && ./a.out
> Exception: Segmentation fault

> g++ -std=c++11 -fnon-call-exceptions example2.cpp && ./a.out
> Exception: Segmentation fault

> g++ -std=c++11 example2.cpp && ./a.out
> terminate called after throwing an instance of 'std::runtime_error'
what():  Segmentation fault
  Aborted (core dumped)

g++ (4.7.3, 4.8.1, 4.9.2)
Linux ubik 3.2.0-101-generic #141-Ubuntu SMP Thu Mar 10 21:43:24 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

[Bug fortran/77358] [F08] deferred-length character function returns zero-length string

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Paul Thomas  ---
Created attachment 39495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39495=edit
Patch for the problem

This does the job and regtests fine.

Cheers

Paul

[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-24
  Known to work||5.4.1
   Target Milestone|--- |6.3
Summary|[7 Regression] [graphite]   |[6/7 Regression] [graphite]
   |ICE in  |ICE in
   |sese_build_liveouts_use w/  |sese_build_liveouts_use w/
   |-O2 -floop-nest-optimize|-O2 -floop-nest-optimize
 Ever confirmed|0   |1
  Known to fail||6.1.0

--- Comment #1 from Richard Biener  ---
Confirmed.  Also crashes on the GCC 6 branch, works with GCC 5 it seems.

[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4
   Keywords||wrong-debug
   Last reconfirmed||2016-08-24
 Ever confirmed|0   |1
Summary|Missing debug information   |[5/6/7 Regression] Missing
   |in DWARF|debug information in DWARF
   Target Milestone|--- |5.5
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #1 from Richard Biener  ---
Confirmed with GCC 6.  The root cause seems to be that we lack a DIE for the
uint8 typedef as well (the uint16 one is IMHO correctly pruned as unused by
both FEs).  It works fine with GCC 4.8 and 4.9 where we also lack the uint8
typedef DIE but at least get

 <1><24>: Abbrev Number: 2 (DW_TAG_base_type)
<25>   DW_AT_byte_size   : 1
<26>   DW_AT_encoding: 8(unsigned char)
<27>   DW_AT_name: (indirect string, offset: 0x72): unsigned char
 <1><2b>: Abbrev Number: 3 (DW_TAG_typedef)
<2c>   DW_AT_name: (indirect string, offset: 0x23): tHash1
<30>   DW_AT_decl_file   : 1
<31>   DW_AT_decl_line   : 4
<32>   DW_AT_type: <0x36>
 <1><36>: Abbrev Number: 4 (DW_TAG_array_type)
<37>   DW_AT_type: <0x24>
<3b>   DW_AT_sibling : <0x46>
 <2><3f>: Abbrev Number: 5 (DW_TAG_subrange_type)
<40>   DW_AT_type: <0x46>
<44>   DW_AT_upper_bound : 15

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[bseifert at gmx dot at]

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

--- Comment #8 from Berni  ---

With GCC 5.4.0 comparison is done between two 8-bit registers r24 and r25, as
expected.

With GCC 6.2.0 additionally registers r19 and r25 are loaded with 0 and 16-bit
comparison between register pairs (r18, r19) and (r24, r25) is performed!

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[bseifert at gmx dot at]

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

--- Comment #6 from Berni  ---
Created attachment 39493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39493=edit
GCC 6.2.0 build output

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[bseifert at gmx dot at]

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

--- Comment #7 from Berni  ---
Created attachment 39494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39494=edit
GCC 6.2.0 listing

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[bseifert at gmx dot at]

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

--- Comment #5 from Berni  ---
Created attachment 39492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39492=edit
GCC 5.4.0 listing

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[bseifert at gmx dot at]

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

--- Comment #4 from Berni  ---
Created attachment 39491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39491=edit
GCC 5.4.0 build output

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[bseifert at gmx dot at]

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

--- Comment #3 from Berni  ---
Created attachment 39490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39490=edit
main.cpp

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

[vogt at linux dot vnet.ibm.com]

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

--- Comment #2 from Dominik Vogt  ---
It's a bit awkward because I don't have access to an AIX machine right now. 
What's the "configure" line fron config.log, please?

[Bug middle-end/64971] [5 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[ramana at gcc dot gnu.org]

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

--- Comment #18 from Ramana Radhakrishnan  ---
(In reply to Richard Biener from comment #16)
> GCC 5.4 is being released, adjusting target milestone.

This is still open on GCC-5 - Do we want to take Renlin's fix into GCC-5 or do
we want to push the band-aid back into GCC-5 ? I would suggest the band-aid but
leave it to Kyrill / Renlin and the Release managers.


Ramana

[Bug tree-optimization/65068] Improve rewriting for address type induction variables in IVOPT

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
And by default we see this

.L4:
add x3, x5, x1
add x1, x1, 1
ldr w2, [x4, x3, lsl 2]
cmp w0, w1
add w2, w2, 1
str w2, [x4, x3, lsl 2]
bgt .L4


- Costs ?

[Bug c++/77363] New: Missing debug information in DWARF

[EngyCZ at gmail dot com]

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

Bug ID: 77363
   Summary: Missing debug information in DWARF
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: EngyCZ at gmail dot com
  Target Milestone: ---

Created attachment 39489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39489=edit
example.c

I have found a missing debug information in dwarf for file compiled with g++.
Same file compiled with gcc has correct debug information.

I have compiled the file as g++ -c -g example.c
Export debug information as readelf -wi example.o >deb

There is a missing information for type tHash1
 <1><2b>: Abbrev Number: 3 (DW_TAG_typedef)
<2c>   DW_AT_name: (indirect string, offset: 0x23): tHash1
<30>   DW_AT_decl_file   : 1
<31>   DW_AT_decl_line   : 4

but for the type tHash2 the information is correct
 <1><39>: Abbrev Number: 4 (DW_TAG_typedef)
<3a>   DW_AT_name: (indirect string, offset: 0x2a): tHash2
<3e>   DW_AT_decl_file   : 1
<3f>   DW_AT_decl_line   : 5
<40>   DW_AT_type: <0x44><--- OK

I ask someone to confirm the bug.
example.c attached

[Bug libfortran/77261] gfortran.dg/random_3.f90 FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Janne Blomqvist  ---
> Patch here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01630.html
>
> Could you Rainer verify that it works on Solaris/SPARC? It *should* do the
> trick, but I have only tested on x86_64-linux-gnu.

Hi Janne,

just did on sparc-sun-solaris2.12 (both 32 and 64-bit) and it worked
fine.

Thanks.
Rainer

[Bug tree-optimization/77362] New: [7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[asolokha at gmx dot com]

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

Bug ID: 77362
   Summary: [7 Regression] [graphite] ICE in
sese_build_liveouts_use w/ -O2 -floop-nest-optimize
   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: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160821 and some earlier snapshots (at least back to
7.0.0-alpha20160731) ICE when compiling the following snippet w/ -O2 (-O3,
-Ofast) -floop-nest-optimize:

int mc[2];
int f2, sk;
short int hm;

void
zm (void)
{
  int k1;

  for (k1 = 0; k1 < 2; ++k1)
{
  for (sk = 0; sk < 2; ++sk)
mc[sk] = hm = ++f2;
  if (hm >= 0)
++hm;
}
}

% gcc-7.0.0-alpha20160821 -O2 -floop-nest-optimize -c rzmadogh.c   
rzmadogh.c: In function 'zm':
rzmadogh.c:6:1: internal compiler error: Segmentation fault

Backtrace is seemingly different for different targets, nevertheless
sese_build_liveouts_use is always on top. For x86_64 I have:

#0  0x012ff0b1 in sese_build_liveouts_use(sese_info_t*, bitmap_head*,
basic_block_def*, tree_node*) ()
#1  0x012ff87c in sese_insert_phis_for_liveouts(sese_info_t*,
basic_block_def*, edge_def*, edge_def*) ()
#2  0x0126859a in graphite_regenerate_ast_isl(scop*) ()
#3  0x0125edac in graphite_transform_loops() ()
#4  0x0125f2c1 in (anonymous
namespace)::pass_graphite_transforms::execute(function*) ()
#5  0x00a8e236 in execute_one_pass(opt_pass*) ()
#6  0x00a8e848 in execute_pass_list_1(opt_pass*) ()
#7  0x00a8e85a in execute_pass_list_1(opt_pass*) ()
#8  0x00a8e85a in execute_pass_list_1(opt_pass*) ()
#9  0x00a8e85a in execute_pass_list_1(opt_pass*) ()
#10 0x00a8e8a5 in execute_pass_list(function*, opt_pass*) ()
#11 0x0076e004 in cgraph_node::expand() ()
#12 0x0076f9a7 in symbol_table::compile() [clone .part.47] ()
#13 0x00771c78 in symbol_table::finalize_compilation_unit() ()
#14 0x00b5fd9d in compile_file() ()
#15 0x005ced77 in toplev::main(int, char**) ()
#16 0x005d10a7 in main ()

[Bug libgcc/77361] sparc - unrecognizable insn in __fixsfdi

[wigyori at uid0 dot hu]

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

--- Comment #1 from Zoltan HERPAI  ---
(In reply to Zoltan HERPAI from comment #0)
> Hi,
> 
> I'm trying to build a cross-compiler for sparc, however libgcc build fails
> with the following error:
> 
> -
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0-
> minimal/./gcc/xgcc
> -B/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0-
> minimal/./gcc/
> -B/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-
> openwrt-linux-musl/bin/
> -B/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-
> openwrt-linux-musl/lib/ -isystem
> /openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-
> openwrt-linux-musl/include -isystem
> /openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-
> openwrt-linux-musl/sys-include-Os -pipe -mcpu=v8 -fno-caller-saves
> -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable
> -Wno-error=unused-result -O2  -Os -pipe -mcpu=v8 -fno-caller-saves
> -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable
> -Wno-error=unused-result -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -g
> -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC
> -I. -I. -I../.././gcc
> -I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc
> -I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/.
> -I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/../gcc
> -I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/../include  -DHAVE_CC_TLS  -o _fixsfdi.o -MT _fixsfdi.o -MD -MP -MF
> _fixsfdi.dep -DL_fixsfdi -c
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
> cc1: note: someone does not honour COPTS correctly, passed 2 times
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/libgcc2.c: In function '__fixsfdi':
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/libgcc2.c:1502:1: error: unrecognizable insn:
>  }
>  ^
> (call_insn/j 34 33 35 7 (parallel [
> (set (reg:DI 24 %i0)
> (call (mem:SI (reg/f:SI 123) [0 __fixunssfdi S4 A32])
> (const_int 0 [0])))
> (return)
> ])
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/libgcc2.c:1501 -1
>  (expr_list:REG_CALL_DECL (symbol_ref:SI ("__fixunssfdi") [flags 0x41]
> )
> (nil))
> (expr_list:SF (use (reg:SF 24 %i0))
> (nil)))
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/
> libgcc/libgcc2.c:1502:1: internal compiler error: in extract_insn, at
> recog.c:2343
> 0x8999b5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
>
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/
> rtl-error.c:110
> 0x8999e9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/
> rtl-error.c:118
> 0x86749e extract_insn(rtx_insn*)
>
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/
> recog.c:2343
> 0x6d9126 instantiate_virtual_regs_in_insn
>
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/
> function.c:1646
> 0x6d9126 instantiate_virtual_regs
>
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/
> function.c:1966
> 0x6d9126 execute
>
> /openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/
> function.c:2015
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[5]: *** [_fixsfdi.o] Error 1
> make[5]: Leaving directory
> `/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0-
> minimal/sparc-openwrt-linux-musl/libgcc'
> make[4]: *** [all-target-libgcc] Error 2
> -
> 
> GCC is configured with:
> 
> /openwrt/sparc/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/
> gcc-5.4.0/configure \
> --with-bugurl=https://dev.openwrt.org/ \
> --with-pkgversion="OpenWrt GCC 5.4.0 49903" \
> --prefix=/openwrt/sparc/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.
> 0_musl-1.1.14 \
> --build=x86_64-linux-gnu \
> --host=x86_64-linux-gnu--target=sparc-openwrt-linux-musl \
> --with-gnu-ld \
> --enable-target-optspace \
> --disable-libgomp \
> --disable-libmudflap \
> --disable-multilib \
> --disable-nls \
> --without-isl \
> 

[Bug libgcc/77361] New: sparc - unrecognizable insn in __fixsfdi

[wigyori at uid0 dot hu]

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

Bug ID: 77361
   Summary: sparc - unrecognizable insn in __fixsfdi
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wigyori at uid0 dot hu
  Target Milestone: ---

Hi,

I'm trying to build a cross-compiler for sparc, however libgcc build fails with
the following error:

-
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0-minimal/./gcc/xgcc
-B/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0-minimal/./gcc/
-B/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-openwrt-linux-musl/bin/
-B/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-openwrt-linux-musl/lib/
-isystem
/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-openwrt-linux-musl/include
-isystem
/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/sparc-openwrt-linux-musl/sys-include
   -Os -pipe -mcpu=v8 -fno-caller-saves -fno-caller-saves -fno-plt
-fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -O2 
-Os -pipe -mcpu=v8 -fno-caller-saves -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -fPIC -I. -I. -I../.././gcc
-I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc
-I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/.
-I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/../gcc
-I/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/../include
 -DHAVE_CC_TLS  -o _fixsfdi.o -MT _fixsfdi.o -MD -MP -MF _fixsfdi.dep
-DL_fixsfdi -c
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
cc1: note: someone does not honour COPTS correctly, passed 2 times
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/libgcc2.c:
In function '__fixsfdi':
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/libgcc2.c:1502:1:
error: unrecognizable insn:
 }
 ^
(call_insn/j 34 33 35 7 (parallel [
(set (reg:DI 24 %i0)
(call (mem:SI (reg/f:SI 123) [0 __fixunssfdi S4 A32])
(const_int 0 [0])))
(return)
])
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/libgcc2.c:1501
-1
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("__fixunssfdi") [flags 0x41]
)
(nil))
(expr_list:SF (use (reg:SF 24 %i0))
(nil)))
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/libgcc/libgcc2.c:1502:1:
internal compiler error: in extract_insn, at recog.c:2343
0x8999b5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/rtl-error.c:110
0x8999e9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/rtl-error.c:118
0x86749e extract_insn(rtx_insn*)
   
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/recog.c:2343
0x6d9126 instantiate_virtual_regs_in_insn
   
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/function.c:1646
0x6d9126 instantiate_virtual_regs
   
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/function.c:1966
0x6d9126 execute
   
/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[5]: *** [_fixsfdi.o] Error 1
make[5]: Leaving directory
`/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0-minimal/sparc-openwrt-linux-musl/libgcc'
make[4]: *** [all-target-libgcc] Error 2
-

GCC is configured with:

/openwrt/sparc/openwrt/build_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14/gcc-5.4.0/configure
\
--with-bugurl=https://dev.openwrt.org/ \
--with-pkgversion="OpenWrt GCC 5.4.0 49903" \
--prefix=/openwrt/sparc/openwrt/staging_dir/toolchain-sparc_sparc_gcc-5.4.0_musl-1.1.14
\
--build=x86_64-linux-gnu \
--host=x86_64-linux-gnu--target=sparc-openwrt-linux-musl \
--with-gnu-ld \
--enable-target-optspace \
--disable-libgomp \
--disable-libmudflap \
--disable-multilib \
--disable-nls \

[Bug libstdc++/77356] regex error for a ECMAScript syntax string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-24
   Assignee|unassigned at gcc dot gnu.org  |timshen at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Tim has a fix for this.

[Bug tree-optimization/72817] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from amker at gcc dot gnu.org ---
Fixed.

[Bug testsuite/77317] x86_64 --target_board=''unix/ unix/-m32'' parallel testrun gives inconsistent results in gcc.dg/vect

[rts at gcc dot gnu.org]

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

--- Comment #2 from rts at gcc dot gnu.org ---
Author: rts
Date: Wed Aug 24 07:53:07 2016
New Revision: 239730

URL: https://gcc.gnu.org/viewcvs?rev=239730=gcc=rev
Log:
Fix PR testsuite/77317

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_vect_aligned_arrays): Don't cache the result.
(check_effective_target_vect_natural_alignment): Ditto.
(check_effective_target_vector_alignment_reachable): Ditto.
(check_effective_target_vector_alignment_reachable_for_64bit): Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[amker at gcc dot gnu.org]

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

Bug 69848 Summary: poor vectorization of a loop from SPEC2006 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848

   What|Removed |Added

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

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from amker at gcc dot gnu.org ---
Fixed, I think.

[Bug target/77353] [AVR] uint16_t instead uint8_t comparison

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Please always provide complete testcases that can be compiled.

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||amker at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from amker at gcc dot gnu.org ---
Fixed now.

[Bug middle-end/77357] strlen of constant strings not folded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Contents of strlen.c?

[Bug c/77332] ICE when building gcc 6.2 (with gcc 6.1.0)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Ok, it sounds like it may be a fluke due to bad memory / disk then.

[Bug tree-optimization/76490] [5 Regression] when use -O2 -fcheck-founds compiler appears to hang and consumes all memory

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 24 07:39:42 2016
New Revision: 239729

URL: https://gcc.gnu.org/viewcvs?rev=239729=gcc=rev
Log:
2016-08-24  Richard Biener  

Backport from mainline
2016-08-17  Richard Biener  

PR tree-optimization/76490
* tree-vrp.c (update_value_range): Preserve overflow infinities
when intersecting with ranges from get_range_info.
(operand_less_p): Handle overflow infinities correctly.
(value_range_constant_singleton): Use vrp_operand_equal_p
to handle overflow max/min correctly.
(vrp_valueize): Likewise.
(union_ranges): Likewise.
(intersect_ranges): Likewise.
(vrp_visit_phi_node): Improve iteration limitation to only
apply when we'll possibly re-visit the PHI via a changed argument
on the backedge.

* gfortran.fortran-torture/compile/pr76490.f90: New testcase.
* gcc.dg/pr52904.c: XFAIL.

Added:
   
branches/gcc-6-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr76490.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr52904.c
branches/gcc-6-branch/gcc/tree-vrp.c

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Tue, 23 Aug 2016, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
> 
> --- Comment #23 from Tom de Vries  ---
> (In reply to Richard Biener from comment #22)
> > (In reply to vries from comment #18)
> > > Created attachment 39484 [details]
> > > Tentative patch using attributes ms_abi/sysv_abi
> > > 
> > > not build or regression tested yet, but at least makes test-case pass.
> > 
> > LGTM.
> 
> Just realized, there's a potential problem with the patch and
> sysv_va_list_type_node. sysv_va_list_type_node is an array type (array with
> length 1 and a struct as element type).
> 
> grokdeclarator (in c-decl.c, see comment 'A parameter declared as an array of 
> T
> is really a pointer to T') converts that type into a pointer to array element
> type (as explained in more detail in build_va_arg) and drops the attributes.
> 
> Perhaps we should mark the underlying element type with the attribute (as
> well/instead? I'm not sure yet).

Hmm, yeah.  You'd have to do some experiments in which process we might
get a few more testcases ;)

[Bug tree-optimization/33244] Missed opportunities for vectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
The only loop I see in this file now is one which contains a call to sqrt and
logf.

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
glibc's malloc returns 128-bit aligned on x86-64-linux-gnu.
but what does it return on windows?

[Bug bootstrap/66022] 4.8.4 build fails with stage 2 and 3 comparison error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-24
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Does this work in 5.4.0 (the latest supported GCC)?

[Bug libfortran/77261] gfortran.dg/random_3.f90 FAILs

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-08/msg01630.ht
   ||ml

--- Comment #4 from Janne Blomqvist  ---
Patch here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01630.html

Could you Rainer verify that it works on Solaris/SPARC? It *should* do the
trick, but I have only tested on x86_64-linux-gnu.