[Bug c++/78425] New: Atrtibute warning message location incorrect

[suckfish at ihug dot co.nz]

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

Bug ID: 78425
   Summary: Atrtibute warning message location incorrect
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suckfish at ihug dot co.nz
  Target Milestone: ---

The following C++ code produces a warning message, but the location given for
the warning message is not right.  (gcc claims it comes from the expansion of
the macro GOOD.  In fact it comes from the expansion of BAD).
---
#define BAD [[notreturn]]
#define GOOD __attribute__((format(printf,1,2)))
void foo BAD (const char * fmt, ...) GOOD;
---
$ gcc -c temp.cc 
temp.cc:2:48: warning: ‘notreturn’ attribute directive ignored [-Wattributes]
 #define GOOD __attribute__((format(printf,1,2)))
^
temp.cc:4:38: note: in expansion of macro ‘GOOD’
 void foo BAD (const char * fmt, ...) GOOD;
  ^~~~
$ gcc --version
gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 18 23:51:30 2016
New Revision: 242610

URL: https://gcc.gnu.org/viewcvs?rev=242610=gcc=rev
Log:
PR c++/68180
* g++.dg/cpp1y/pr68180.C: Add -Wno-psabi as dg-additional-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/pr68180.C

[Bug middle-end/78419] ICE with target_clone on invalid target

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 18 22:21:31 2016
New Revision: 242608

URL: https://gcc.gnu.org/viewcvs?rev=242608=gcc=rev
Log:
PR middle-end/78419
* multiple_target.c (get_attr_len): Start with argnum and increment
argnum on every arg.  Use strchr in a loop instead of counting commas
manually.
(get_attr_str): Increment argnum for every comma in the string.
(separate_attrs): Use for instead of while loop, simplify.
(expand_target_clones): Rename defenition argument to definition.
Free attrs and attr_str even when diagnosing errors.  Temporarily
change input_location around targetm.target_option.valid_attribute_p
calls.  Don't emit warning or errors if that function fails.

* gcc.target/i386/pr78419.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr78419.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/multiple_target.c
trunk/gcc/testsuite/ChangeLog

[Bug other/78424] New: intl reincludes sysroot into searching for ld

[neotheuser at ymail dot com]

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

Bug ID: 78424
   Summary: intl reincludes sysroot into searching for ld
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neotheuser at ymail dot com
  Target Milestone: ---

Created attachment 40085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40085=edit
intl duplicated directory error

Hello! I have switched to GLIBC and the GMP issue is gone, but now when GCC
builds, it searches for sysroot/usr/lib/libc.so.6 inside
sysroot/git-toolchain-bin. It should be an absolute path, which is simply just
sysroot/usr/lib/libc.so.6.

"/home//git-toolchain-bin/usr/x86_64-pc-linux-gnu/bin/ld: cannot find
/home//git-toolchain-bin/usr/lib/libc.so.6 inside
/home//git-toolchain-bin"

~/git-toolchain-bin/usr/lib/libc.so.6 exists, but there is no
/home//git-toolchain-bin/home//git-toolchain-bin/usr/lib/libc.so.6
as that would be silly.

Configure line is as follows:

mkdir build && cd build && ../configure
--prefix=/home//git-toolchain-bin/usr
--with-local-prefix=/home//git-toolchain-bin/usr
--with-sysroot=/home//git-toolchain-bin --disable-nls
--disable-shared --disable-multilib --disable-libatomic --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp --disable-libvtv
--disable-libstdcxx --enable-languages=c,c++ --disable-lto --with-system-zlib
--disable-werror --disable-gold --without-isl --disable-libcilkrts
--disable-libitm --disable-libsanitizer

Removing or keeping --with-local-prefix has no effect.

I initially started with having --with-native-system-header-dir set to
sysroot-dir/include but having --with-sysroot=sysroot-dir set along with it
caused redundancies, so I dropped --with-native-system-header-dir.

--with-build-sysroot caused issues finding stdio.h (which was present in the
directory that --with-native-system-header-dir was set to, not too sure what
happened there, just changed configure options) so changing it to simply
--with-sysroot got me a little further.

Build log attached.

[Bug c++/77285] [5/6/7 Regression] extern thread_local linkage

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 18 21:56:50 2016
New Revision: 242607

URL: https://gcc.gnu.org/viewcvs?rev=242607=gcc=rev
Log:
PR c++/77285
* mangle.c (mangle_tls_init_fn, mangle_tls_wrapper_fn): Call
check_abi_tags.

* g++.dg/tls/pr77285-1.C: New test.
* g++.dg/tls/pr77285-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tls/pr77285-1.C
trunk/gcc/testsuite/g++.dg/tls/pr77285-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/78191] [7 regression] ICE in calc_die_sizes

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 18 21:55:46 2016
New Revision: 242606

URL: https://gcc.gnu.org/viewcvs?rev=242606=gcc=rev
Log:
* dwarf2out.c (size_of_discr_list): Fix typo in function comment.

PR debug/78191
* dwarf2out.c (abbrev_opt_base_type_end): New variable.
(die_abbrev_cmp): Sort dies with die_abbrev smaller than
abbrev_opt_base_type_end only by increasing die_abbrev, before
any other dies.
(optimize_abbrev_table): Don't change abbrev numbers of
base types and CU or optimize implicit consts in them if
calc_base_type_die_sizes has been called during build_abbrev_table.
(calc_base_type_die_sizes): If abbrev_opt_start, set
abbrev_opt_base_type_end to one plus largest base type's
die_abbrev.

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

[Bug target/25112] [m68k] Suboptimal equality comparisons with small integers

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk for gcc-7.

[Bug target/25112] [m68k] Suboptimal equality comparisons with small integers

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Fri Nov 18 21:52:32 2016
New Revision: 242605

URL: https://gcc.gnu.org/viewcvs?rev=242605=gcc=rev
Log:
PR target/25112
* config/m68k/m68k.c (moveq feeding equality comparison): New
peepholes.
* config/m68k/predicates.md (addq_subq_operand): New predicate.
(equality_comparison_operator): Likewise.

PR target/25112
* gcc.target/m68k/pr25112: New test.

Added:
trunk/gcc/testsuite/gcc.target/m68k/pr25112.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k.md
trunk/gcc/config/m68k/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/78420] std::less<T*> is not a total order with -O2 enabled

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #8 from Jason Merrill  ---
(In reply to Tomasz Kamiński from comment #7)
> Notice that I am concerned about !std::less{}(a,b) &&
> !std::less(b,a) being false, when std::less{}(a,b) and
> std::less{}(b,a) are both false, and in contrast to raw operator<,
> std::less is required to provide total order, which is no longer the case.
> 
> And my complain, is about behavior of std::less, that is not standard
> compliant. If it can be changed without changing <, I am fine with it.

Yes, I think the way forward here is to work around this in libstdc++.

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

[tomaszkam at gmail dot com]

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

--- Comment #7 from Tomasz Kamiński  ---
> No, it's very much allowed to do that.  But I'm skeptical that it's allowed 
> to turn !(a(b,a)
being false, when std::less{}(a,b) and std::less{}(b,a) are both false,
and in contrast to raw operator<, std::less is required to provide total order,
which is no longer the case.

And my complain, is about behavior of std::less, that is not standard
compliant. If it can be changed without changing <, I am fine with it.

[Bug tree-optimization/77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  ---
pr78116 contains a couple testcases that showed degradation on x86 caused by
spill inside a vectorized loop due to messed up BB frequencies.

[Bug c++/67631] brace initialization bug

[howard.hinnant at gmail dot com]

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

--- Comment #10 from Howard Hinnant  ---
Thanks much Jason!

[Bug c++/67631] brace initialization bug

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 6.3.

[Bug c++/67631] brace initialization bug

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Fri Nov 18 20:27:41 2016
New Revision: 242604

URL: https://gcc.gnu.org/viewcvs?rev=242604=gcc=rev
Log:
PR c++/67631 - list-init and explicit conversions

* semantics.c (finish_compound_literal): Call digest_init_flags.
* typeck2.c (digest_init_flags): Add complain parm.
(store_init_value): Pass it.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/initlist-explicit1.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/cp-tree.h
branches/gcc-6-branch/gcc/cp/semantics.c
branches/gcc-6-branch/gcc/cp/typeck2.c

[Bug c++/67631] brace initialization bug

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Fri Nov 18 20:27:26 2016
New Revision: 242603

URL: https://gcc.gnu.org/viewcvs?rev=242603=gcc=rev
Log:
PR c++/67631 - list-init and explicit conversions

* semantics.c (finish_compound_literal): Call digest_init_flags.
* typeck2.c (digest_init_flags): Add complain parm.
(store_init_value): Pass it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-explicit1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck2.c

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 Depends on||77536

--- Comment #8 from Pat Haugen  ---
Marking this as depends on pr77536. Before vectorization the loops have a BB
freq of 8500, after vectorization the vectorized version of the loops have
freq=536. It then appears IRA/reload pick the loop block as a spill location
because the frequency is less than the surrounding preheader/exit blocks. To
test this theory I compiled the 2 testcases under gdb and modified the
frequency of the loop block at the start of ira() to be slightly greater than
the preheader and the loads no longer occurred in the loop.

For the first testcase, the loop is colder than the surrounding code even with
r241172, but my change in r241173 made some changes in the CFG by removing a
peeled copy of the loop. So there's a difference in CFGs which leads to
differences in BB frequencies that I suspect is not passing some threshhold in
the latter case and resulting in spill in the loop.

For the second testcase, my patch in r241170 resulted in no changes to the CFG,
only changes to the BB frequencies. After unrolling, the loop in r241169 ends
up having a frequency greater than the surrounding code due to the incorrect
code that was in loop-unroll.c. r241170 corrected that code and maintained the
initial representation that the loop is colder than the surrounding code, which
again leads to spill in the loop. Even though spill is not the desired result,
I maintain that the changes in r241170 are the correct thing to do.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536
[Bug 77536] Vectorizer not maintaining relationship of relative block
frequencies in absence of real profile data

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Tomasz Kamiński from comment #4)
> Oh, you mean that compiler is not allowed to turn comparison of p == b into
> false at compile time, using 5.10 [expr.eq] p2.1? 

No, it's very much allowed to do that.  But I'm skeptical that it's allowed to
turn !(a though std::less requires total order, < and <= usage are undefined if used
> with two different arrays.

Which defect?  That just means the implementation has to be more complex, e.g.
casting to intptr_t before comparing.

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
I think this deserves a Defect report to the C++ committee because even though
std::less requires total order, < and <= usage are undefined if used with two
different arrays.

[Bug libstdc++/78423] [c+11] error: use of deleted function 'std::basic_ostringstream

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Bharath from comment #0)
> Due to project constraints we are not supposed to upgrade our gcc to version
> 5 & above.Can you please guide is there any other way we can fix above
> errors without upgrading our gcc version.

Change your code so it doesn't use features that aren't supported by your
toolchain.

[Bug libstdc++/78423] [c+11] error: use of deleted function 'std::basic_ostringstream

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |5.0

--- Comment #1 from Andrew Pinski  ---
GCC 4.9.x is no longer maintained sorry.  We maintain a release for ~2 years.

>Can you please guide is there any other way we can fix above errors without 
>upgrading our gcc version.

You could try to backport the referenced patch to GCC 4.9.x and go from there.

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

[Bug libstdc++/54316] [C++11] move constructor for stringstream

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||snbraj at sasken dot com

--- Comment #11 from Andrew Pinski  ---
*** Bug 78423 has been marked as a duplicate of this bug. ***

[Bug libstdc++/78423] New: [c+11] error: use of deleted function 'std::basic_ostringstream

[snbraj at sasken dot com]

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

Bug ID: 78423
   Summary: [c+11] error: use of deleted function
'std::basic_ostringstream
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: snbraj at sasken dot com
  Target Milestone: ---

Hi 

I am getting below error when I tries to build with gcc-4.9.

-I../../../../common/inc/qstream -I../../../../../dependencies/mcpp/src 
../../src//sectionAdapter.cpp -o ../../src//sectionAdapter.o
../../src//GLAdapter.cpp: In member function 'virtual void
SDP::sectionAdapter::Process_sectionShaderSource(ObjectId32, int32_t,
Data::PointerData*, Data::PointerData*)':
../../src//sectionAdapter.cpp:1224:28: error: use of deleted function
'std::basic_ostringstream&
std::basic_ostringstream::operator=(const
std::basic_ostringstream&)'
 s_preprocessed = std::ostringstream();
^
In file included from ../../src//sectionAdapter.h:14:0,

As per discussion in the below link this issue got fixed in GCC 5.

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

Due to project constraints we are not supposed to upgrade our gcc to version 5
& above.Can you please guide is there any other way we can fix above errors
without upgrading our gcc version.

Kindly let me know if you need any more information.

Regards
Bharath

[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Yeah, I've also noticed that in my working-directory gcc build (-O0,
reconfigured hundreds of times, ...) the test fails, while in my cleanly
bootstrapped one it succeeds, with the same -march=/-mtune= options.
Apparently tree if-conversion just makes different decisions, until then the
dumps are identical.  Will do side-by-side debugging on Monday unless somebody
beats me to do that.

[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The test fails for me as well (that's how I noticed it).  This is on trunk,
with a straightforward build with -mtune=generic and -march=x86-64 passed by
the driver.  But it only fails on one of my machines (my laptop) and not on the
other.  I know yet what's different between two that triggers it.

[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
I tried r242601 with -mtune=generic -march=x86-64. There is no cmov at all.

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[w6ws at earthlink dot net]

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

--- Comment #8 from Walter Spector  ---
Hi Janus,

The ifort compiler has no problem with your example in Comment #5.  That
example should be Standard Fortran 90.

The newer F2008 data pointer initialization stuff is largely in §4.5.4.6,
paragraph 2:

"A pointer variable or component is data-pointer-initialization compatible with
a target if the pointer is type compatible with the target, they have the same
rank, all nondeferred type parameters of the pointer have the same values as
the corresponding type parameters of the target, and the target is contiguous
if the pointer has the CONTIGUOUS attribute."

Note the repeated use of the word "target".  :)

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> Related to pr42122?

Don't think so.

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> As an alternative to removing the assert, one could possibly prevent SAVEd
> variables in the main PROGRAM from being declared as "static" (which might
> also cure the performance regressions that Dominique reported for my patch
> for PR 55207)?

Related to pr42122?

[Bug fortran/54613] [F03] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
At https://gcc.gnu.org/ml/fortran/2016-11/msg00179.html I wrote 

pr54613, sixth and eighth tests,

Actually the tests were extracted from
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/5eAz5ns6AG0,
i.e.,

module m2procs 
   implicit none 
   contains 
  recursive function fun(depth) result(r) 
 integer r 
 integer depth 
 integer x(minval([1],mask=[.TRUE.])) 
 integer y 
 save 

 x = 0 
 if(depth > 0) y = fun(depth-1) 
 x = x+1 
 r = x(1) 
  end function fun 
end module m2procs 

program minval2 
   use m2procs 
   implicit none 

   write(*,*) fun(1) 
end program minval2 

and

[Book15] f90/bug% diff -up pr54613_5.f90 pr54613_7.f90
--- pr54613_5.f90   2012-09-18 10:43:48.0 +0200
+++ pr54613_7.f90   2012-09-18 10:44:56.0 +0200
@@ -4,7 +4,7 @@ module m2procs 
   recursive function fun(depth) result(r) 
  integer r 
  integer depth 
- integer x(minval([1],mask=[.TRUE.])) 
+ integer x(sum(minloc([1]))) 
  integer y 
  save 

@@ -15,9 +15,9 @@ module m2procs 
   end function fun 
 end module m2procs 

-program minval2 
+program minloc2 
use m2procs 
implicit none 

write(*,*) fun(1) 
-end program minval2 
+end program minloc2

[Bug middle-end/78411] [7 Regression] FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
We used to expect and emitted 4 cmovs before r239414, which changed it to 6 and
also changed the expectations, which is what is emitted even with current
trunk.
I can't reproduce the failure, even with -march=corei7 -mtune=corei7 that
likely H.J. uses. Perhaps he has cmov in some pathname or somewhere else, maybe
the test should scan for "cmov\[a-z]\[a-z]?\t" or something similar.

[Bug middle-end/68360] GCC bitfield processing code is very inefficient

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
> Here's another example where GCC generates suboptimal code for bitfield
> initialization on x64: https://godbolt.org/g/WeqAr5.

Again the code is better for example on SPARC:

sll %o1, 30, %o1
sethi   %hi(-1073741824), %g1
andn%o2, %g1, %o2
or  %o1, %o2, %o1
jmp %o7+8
 st %o1, [%o0]

It is very bad on x86 because, when get_best_mode is invoked as such:

get_best_mode (bitsize=2, bitpos=0, bitregion_start=0, bitregion_end=31, 
align=32, largest_mode=SImode, volatilep=false)
at /home/eric/svn/gcc/gcc/stor-layout.c:2800

it returns QImode.  If it returned SImode as on SPARC, the code would be:

sall$2, %edx
andl$3, %esi
orl %edx, %esi
movl%esi, (%rdi)
ret

[Bug target/25112] [m68k] Suboptimal equality comparisons with small integers

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Note that due to the 2-address nature of the m68k, this transformation is only
valid when both registers die.

We need the register holding the immediate to die because the register will no
longer be holding that immediate.

We need the register we're comparing against the immediate to die because we're
going to change its value.

Finally the register we're comparing against the immediate must be a data
register otherwise addq/subq will not set the condition codes.

It essentially needs to be a 3 insn -> 3 insn peephole2.  The key realization
is that we're going to depend on test elimination in final to eliminate the
comparison.  The peep2 just makes it painfully obvious to final how to do that.

Patch nearly ready...

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
One could consider running a reference matrix multiply of size 32 in a loop and
do timing tests to determine whether to use -mprefer-avx128. 0n this machine
from comment 8

mavx = 1.276 mavx mprefer-avx128 = 3.460

There is some margin there for a fairly good test. Or is there another way to
tell?

[Bug rtl-optimization/78422] FAIL: gcc.c-torture/execute/cbrt.c execution failure

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Fixed by r242526.

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #9)
> Next question - what happens if you add
> 
> -mvzeroupper -mavx
> 
> to the line in the Makefile?  Does that make a difference in speed?

-mvzeroupper slows all way down with or without -mprefer-avx128

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

--- Comment #5 from nsz at gcc dot gnu.org ---
i plan to backport the fix, but it seems my fix is not correct and broke the
ieee_8.fp90 test.

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Walter Spector from comment #6)
> Your test case in Comment #5 is fine - because it is not attempting to
> initialize the pointer at compile time.  Initializing a pointer at compile
> time is a F2008 feature.

I know. But in the end it's just a pointer assignment as well. Why should the
rules be so much different?

Can you possibly point me to the relevant place in the F08 standard, which
allows comment #5, but forbids comment #0?


> If I feed my original test case into ifort (v17), I get:
> 
> /tmp/wws> ifort ptr2.f90
> ptr2.f90(10): error #8813: The target must have the TARGET attribute.  
> [DATA]
>   integer, pointer :: idata => data%i
> ---^

Well, ok. But just because ifort rejects it, it doesn't necessarily mean that
it's valid ;)

What does ifort say on the example in comment #5? And what about this example,
which is again similar to your original case:

program p
  implicit none

  type data_t
integer :: i = 9
  end type

  type(data_t), target :: d
  type(data_t), pointer :: dp => d
!   integer, pointer :: ip => d%i  ! certainly legal
  integer, pointer :: ip => dp%i  ! also legal!?!

  print *,ip
end


gfortran again throws an ICE on this, but if I instead use the commented-out
line, it works fine.

[Bug c/78408] C loop initial declarations generate wrong code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
significantly more efficient code than a = b = (struct buf) {} - the former
is 2x memset, the latter 1x memset + 1x memcpy.
So, shall we for large aggregates gimplify those differently as an
optimization?

[Bug fortran/68717] [6/7 Regression] New (bogus?) warnings when compiling some gfortran.dg tests with -flto after r231239

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Is this PR (and pr68649) related to pr33097, pr40976, pr42122, and/or pr44471?

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[w6ws at earthlink dot net]

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

--- Comment #6 from Walter Spector  ---
Hi Janus,

Your test case in Comment #5 is fine - because it is not attempting to
initialize the pointer at compile time.  Initializing a pointer at compile time
is a F2008 feature.  I was testing this F2008 feature when I encountered the
ICE which prompted this bug report.

If I feed my original test case into ifort (v17), I get:

/tmp/wws> ifort ptr2.f90
ptr2.f90(10): error #8813: The target must have the TARGET attribute.   [DATA]
  integer, pointer :: idata => data%i
---^
compilation aborted for ptr2.f90 (code 1)
/tmp/wws>

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[sch...@linux-m68k.org]

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

--- Comment #26 from Andreas Schwab  ---
Note that the patch in comment 8 is already included in r242526.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #25 from Dominik Vogt  ---
A quick regression test with both patches; s390x with just -m64 and
-languages=c has only two failures left:

+FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler
f43:\\n\\trisbg\\t%r2,%r2,32,128+61,64-12
+FAIL: gcc.target/s390/risbg-ll-2.c scan-assembler
f9:\\n\\trisbg\\t%r3,%r2,48,63,64-48

This is probably not a bug in the patch, its just that the patterns for the
RISBG instruction are very sensitive to any change in rtl.  Maybe you'd like to
have a quick look aat those two tests to verify they are not cause by an
obivous bug.  If that's not the case I can take over fixing them - I'm working
on related patterns anyway, and they're awful to understand.

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Next question - what happens if you add

-mvzeroupper -mavx

to the line in the Makefile?  Does that make a difference in speed?

[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01951.html

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[sch...@linux-m68k.org]

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

--- Comment #24 from Andreas Schwab  ---
This also fixes bootstrap on ia64.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #23 from Michael Matz  ---
(In reply to Dominik Vogt from comment #22)
> Does this patch replace the one in comment 8 or should they both be used?

I checked it in isolation, but the former one does fix a bug as well, so
probably use both.

[Bug middle-end/78416] wrong code for division by (u128)~INT64_MAX at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Any plan to back-port the fix? If no, could you please close the PR?

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm-none-eabi
 CC||amker at gcc dot gnu.org

--- Comment #4 from amker at gcc dot gnu.org ---
There is an ICE for this test on arm.

Thanks.

[Bug rtl-optimization/78422] New: FAIL: gcc.c-torture/execute/cbrt.c execution failure

[amker at gcc dot gnu.org]

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

Bug ID: 78422
   Summary: FAIL: gcc.c-torture/execute/cbrt.c execution failure
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Hi,
According to https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01637.html, the
patch causes below failures on aarch64:
FAIL: gcc.c-torture/execute/cbrt.c   -O1  execution test
FAIL: gcc.c-torture/execute/cbrt.c   -O2  execution test
FAIL: gcc.c-torture/execute/cbrt.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/cbrt.c   -O3 -g  execution test

Thanks

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01942.html

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #22 from Dominik Vogt  ---
Does this patch replace the one in comment 8 or should they both be used?

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #21 from Dominik Vogt  ---
(In reply to Michael Matz from comment #16)
> Uhh:
> 
>  Successfully matched this instruction:
>  (set (subreg:DI (reg:SI 73) 0)
> -(lshiftrt:DI (reg/v:DI 63 [ X ])
> -(const_int 56 [0x38])))
> +(zero_extract:DI (reg/v:DI 63 [ X ])
> +(const_int 32 [0x20])
> +(const_int -24 [0xffe8])))

Why does it do this, shouldn't be this just "(zero_extract (reg) (8) (0))"? 
Zero extending that to 32 or 64 bits is built into "zero_extract", it's not
necessary to code it into SIZE and POS.

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

[tomaszkam at gmail dot com]

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

--- Comment #4 from Tomasz Kamiński  ---
Oh, you mean that compiler is not allowed to turn comparison of p == b into
false at compile time, using 5.10 [expr.eq] p2.1? 

Some reference from clang: https://llvm.org/bugs/show_bug.cgi?id=13507. Note
that I am unable to reproduce problem on clang.

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

[tomaszkam at gmail dot com]

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

--- Comment #3 from Tomasz Kamiński  ---
> I don't see this as prohibiting the transformation.  The standard seems to be 
> saying that they might or might not compare as equal, which presumably 
> depends on how variables are laid out in memory.  The optimization seems 
> wrong to me.

But, the code snippet is not using == on this pointer, but std::less
specialization that is required to form total order, but in the attached
scenario as not because for p and b nor of following hold:
1) r(p, b)
2) r(b, p)
3) b is same as p (!r(p, b) && !r(b, p))
Which proves that r is not an total order. So the guarantee on the less is
no longer provided.

[Bug c++/67631] brace initialization bug

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to Tomasz Kamiński from comment #1)
> This is probably effect on changing !lt(a,b) && !lt(b, a) into !(a !(b to 5.10 [expr.eq] p2.1:
> If at least one of the operands is a pointer, pointer conversions (4.11),
> function pointer conversions (4.13), and qualification conversions (4.5) are
> performed on both operands to bring them to their composite pointer
> type (Clause 5). Comparing pointers is defined as follows:
> — (2.1) If one pointer represents the address of a complete object, and
> another pointer represents the address one past the last element of a
> different complete object, the result of the comparison is unspecified.
> 
> However I believe that in light of 20.14.6 [comparisons] p14, above
> transformation is not allowed.

I don't see this as prohibiting the transformation.  The standard seems to be
saying that they might or might not compare as equal, which presumably depends
on how variables are laid out in memory.  The optimization seems wrong to me.

[Bug rtl-optimization/78400] [7 Regression] ICE: in df_refs_verify, at df-scan.c:4045 when building powerpc crosscompiler

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-18
 Ever confirmed|0   |1

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #20 from Michael Matz  ---
The below patch fixes at least the gcc.c-torture/execute/20030408-1.c
testcase.  Checking others as well, perhaps I manage to bootstrap later.
But if Dominik is faster... :)

diff --git a/gcc/combine.c b/gcc/combine.c
index 0210685..d1b8557 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -8108,9 +8108,16 @@ make_compound_operation (rtx x, enum rtx_code in_code)
&& GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE (inner))
&& subreg_lowpart_p (x))
  {
+   int len = mode_width;
new_rtx = make_compound_operation (XEXP (inner, 0), next_code);
+   /* Don't extract bits outside the underlying mode.  */
+   if (CONST_INT_P (XEXP (inner, 1))
+   && (INTVAL (XEXP (inner, 1)) + len
+   > GET_MODE_PRECISION (GET_MODE (inner
+ len = GET_MODE_PRECISION (GET_MODE (inner))
+   - INTVAL (XEXP (inner, 1));
new_rtx = make_extraction (mode, new_rtx, 0, XEXP (inner, 1),
-  mode_width, 1, 0, in_code == COMPARE);
+  len, 1, 0, in_code == COMPARE);
break;
  }

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

[krebbel at gcc dot gnu.org]

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

--- Comment #23 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Nov 18 14:44:54 2016
New Revision: 242590

URL: https://gcc.gnu.org/viewcvs?rev=242590=gcc=rev
Log:
Re-apply: Drop excess size used for run time allocated stack variables.

The patch got reverted after hitting PR77359 which turned out to be a
rs6000 backend problem.  Reapplying after the PR got fixed.

gcc/ChangeLog:

2016-11-18  Dominik Vogt  

Re-apply after PR bootstrap/77359 is fixed:
2016-08-23  Dominik Vogt  

* explow.c (get_dynamic_stack_size): Take known alignment of stack
pointer + STACK_DYNAMIC_OFFSET into account when calculating the
size needed.

--This line, and those below, will be
ignored--

Mgcc/ChangeLog
Mgcc/explow.c

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

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #19 from Dominik Vogt  ---
(In reply to Segher Boessenkool from comment #17)
> Combine should probably not try to generate this extract, I wonder if it
> can exist on any target.  So where is it coming from?
> 
> Of course the target should not "successfully" match it ;-)

There is a discussion going on about this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822

I'm working on an s390[x] patch to reject such combinations, but the middleend
should probably not generate this in the first place.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #18 from Michael Matz  ---
(In reply to Segher Boessenkool from comment #17)
> Combine should probably not try to generate this extract, I wonder if it
> can exist on any target.  So where is it coming from?

Easy:

  (subreg:SI (lshiftrt:DI (reg/v:DI 63 [ X ])
(const_int 56 [0x38])) 4)

On s390x this is a lowpart subreg.  This is now rewritten as extraction
with pos==56 and len==32 (as the wanted mode is SImode).  Note that 56+32 is
larger than 64, i.e. outside the mode of the argument (DImode).  But that's 
supposed to be okay with make_extraction, especially if the arg is !MEM_P.
There even an explicit mention of this in make_extraction:

  if (BITS_BIT_ENDIAN)
{...

  /* POS may be less than 0 now, but we check for that below.
 Note that it can only be less than 0 if !MEM_P (inner).  */
}

Of course, pos here indeed is < 0 (it's -24).  But I see no sensible
checking of it for being less than zero.  There are some that were probably
intended to check this but they are guarded such that they don't work in this
case:

  else if (!MEM_P (inner))
...
  if (GET_MODE (inner) != wanted_inner_mode
  && (pos_rtx != 0
  || orig_pos + len > GET_MODE_BITSIZE (wanted_inner_mode)))
return NULL_RTX;

The above would trigger, except that GET_MODE(inner) == wanted_inner_mode.

Now there are multiple ways to deal with this:
1) don't call make_extraction with pos+len>GET_MODE_PRECISION(inner)
2) Bail out in make_extraction more often, as the comment above claims

I think I'll try (1) first as it's going to generate more extracts.

> Of course the target should not "successfully" match it ;-)

True, but OTOH no target should probably match negative positions at which
points it seems more appropriate to not even ask the target to reject such :)

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
I think so.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

--- Comment #9 from Maxim Ostapenko  ---
Can we close this?

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

[krebbel at gcc dot gnu.org]

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

--- Comment #22 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Nov 18 14:28:49 2016
New Revision: 242589

URL: https://gcc.gnu.org/viewcvs?rev=242589=gcc=rev
Log:
RS6000: Fix PR 77359: Properly align local variables in functions calling
alloca.

gcc/ChangeLog:

2016-11-18  Dominik Vogt  

* config/rs6000/rs6000.c (rs6000_stack_info): PR/77359: Properly align
local variables in functions calling alloca.  Also update the ASCII
drawings
* config/rs6000/rs6000.h (STARTING_FRAME_OFFSET, STACK_DYNAMIC_OFFSET):
PR/77359: Likewise.
* config/rs6000/aix.h (STARTING_FRAME_OFFSET, STACK_DYNAMIC_OFFSET):
PR/77359: Copy AIX specific versions of the rs6000.h macros to aix.h.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/aix.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Walter Spector from comment #0)
> 
>   type(data_t), pointer :: data
>   integer, pointer :: idata => data%i

Thinking about it some more, I'm actually not sure why this should be illegal.

It's certainly true that 'data' itself does not have the TARGET attribute. But
the thing that 'data' points to (whatever it is) certainly must be a TARGET,
otherwise 'data' couldn't point to it, right?

[Side note: There is actually a runtime problem with your test case, since
'data' is not associated. But we probably don't need to detect this at compile
time.]

To clarify my point, let me give you an expanded example, which I think is
valid and runs nicely with gfortran:


program p
  implicit none

  type data_t
integer :: i = 9
  end type

  type(data_t), target :: d
  type(data_t), pointer :: dp
  integer, pointer :: ip

  dp => d
  ip => d%i   ! certainly legal
  ip => dp%i  ! also legal!?!
  print *,ip
end


If you agree that this is valid, the original code in comment 0 should also be
valid, I think.

[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|vect-strided-a-u8-i2-gap.c  |[7 Regression]
   |fails on armeb  |vect-strided-a-u8-i2-gap.c
   ||fails on armeb

[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
AFAICT this PR is mostly fixed since gcc-5. However I see a remaining glitch
with the following variant of the original test

module settings

type keyword
!  character(60), allocatable :: c(:)   ! works but should it?
!  character(80), allocatable :: c(:)   ! works
   character(:), allocatable :: c(:)
end type keyword

type(keyword) :: kw(10)

contains

subroutine save_kw

!allocate(kw(1)%c(10))
allocate(character(80) :: kw(1)%c(10))

kw(1)%c(1) = 'abcd'

print *, "'", kw(1)%c(1), "'"
if (trim(kw(1)%c(1)).eq.'abcd') then  ! problem here
   print *, 'yes'
else
   print *, 'no'
endif

end subroutine save_kw

end module settings

!*

program ice
use settings

call save_kw

end program ice

which prints

 'abcd 
  '
 yes

at run time, i.e., the second quote is missing.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
Combine should probably not try to generate this extract, I wonder if it
can exist on any target.  So where is it coming from?

Of course the target should not "successfully" match it ;-)

[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
Mine, will fix today.  Thanks for the report!

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #16 from Michael Matz  ---
Uhh:

 Successfully matched this instruction:
 (set (subreg:DI (reg:SI 73) 0)
-(lshiftrt:DI (reg/v:DI 63 [ X ])
-(const_int 56 [0x38])))
+(zero_extract:DI (reg/v:DI 63 [ X ])
+(const_int 32 [0x20])
+(const_int -24 [0xffe8])))
 allowing combination of insns 22 and 23
 original costs 4 + 4 = 8
 replacement cost 4
 deferring deletion of insn with uid = 22.
-modifying insn i323: r73:SI#0=r63:DI 0>>0x38
+modifying insn i323: r73:SI#0=zero_extract(r63:DI,0x20,0xffe8)

Note the "-24" for the position of the extract!

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #15 from Michael Matz  ---
(In reply to Dominik Vogt from comment #14)
> With the fix I couldn't reproduce the error message in four attempts, but
> genattrtab still hangs.  Maybe this is bad luck, but maybe the error is
> gone.  Running a regression test without bootstrapping on s390x,
> --with-arch=zEC12, --languages=c, there is a long list of tests that fail:
> 
>  Running target unix/-m64
> +FAIL: gcc.c-torture/execute/20030408-1.c   -O1  execution test

Okay, I can reproduce this now.  Looking...

[Bug fortran/78395] [OOP] error on polymorphic assignment

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vehre at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Somewhat reduced test case (without all the abstract stuff):

> program minimal
>   use types_mod
>   implicit none
> 
>   class(t1), allocatable :: v4
>   class(t2), allocatable :: v6
> 
>   allocate(v4, source=t1(4)) ! Also fails if I use `allocate(t1 :: v4)`

allocate(v6) ! is missing here, right ??!!??

>   v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
> 
> end

Patch in regtesting.

[Bug middle-end/78419] ICE with target_clone on invalid target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/78420] std::less<T*> is not an total order with optimization enabled

[tomaszkam at gmail dot com]

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

--- Comment #1 from Tomasz Kamiński  ---
This is probably effect on changing !lt(a,b) && !lt(b, a) into !(a

[Bug testsuite/78421] New: vect-strided-a-u8-i2-gap.c fails on armeb

[clyon at gcc dot gnu.org]

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

Bug ID: 78421
   Summary: vect-strided-a-u8-i2-gap.c fails on armeb
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: armeb

Since r241991, gcc.dg/vect/vect-strided-a-u8-i2-gap.c fails on armeb:
  gcc.dg/vect/vect-strided-a-u8-i2-gap.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 2 loops" 1
  gcc.dg/vect/vect-strided-a-u8-i2-gap.c scan-tree-dump-times vect "vectorized
2 loops" 1


This was discussed in the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00550.html

[Bug c++/78420] New: std::less<T*> is not an total order with optimization enabled

[tomaszkam at gmail dot com]

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

Bug ID: 78420
   Summary: std::less is not an total order with optimization
enabled
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomaszkam at gmail dot com
  Target Milestone: ---

The 20.14.6 [comparisons] p14:
For templates greater, less, greater_equal, and less_equal, the specializations
for any pointer type yield a total order, even if the built-in operators <, >,
<=
, >= do not. 

Requires that the less is an total order, which means that the one of the
following is true for every pair of pointer values a,b:
1) lt(a, b)
2) lt(b, a)
3) !lt(a,b) && !lt(b, a) //i.e. a == b, where equality is generated from lessw
where lt is object on less.

This does not hold for following code snippet when compared with O2:
#include 

int b[8];
int a[8];

int main()
{
auto p = a + 8;
std::less lt;
std::cout << p << ' ' << b 
  << ' ' << lt(p, b) 
  << ' ' << lt(b, p) 
  << ' ' << (!lt(p, b) && !lt(b, p)) << std::endl;
}
The output is: 0x6015c0 0x6015c0 0 0 0
(link to live example, require optimization to be enabled:
http://melpon.org/wandbox/permlink/vyY82MsxrxWNyOOJ#).

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug other/78419] ICE with target_clone on invalid target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-18
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
You don't need an invalid target name to trigger it, if you just remove the
foo,
part, it will still trigger it.

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||*darwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-18
 CC||iains at gcc dot gnu.org
   Host||*darwin*
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 Ever confirmed|0   |1
  Build||*darwin*

--- Comment #1 from Iain Sandoe  ---

Just to add one note, which is that Apple's gcc-4.2.1 implementation for blocks
was not actually submitted (and therefore doesn't exist on an FSF server); 
it's my understanding that means we cannot use / forward port it.

I'm working on a new version - based on trying to match what clang's current
code-gen produces.

[Bug other/78419] ICE with target_clone on invalid target

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Valgrind has some more info:

ig25@linux-fd1f:~/Krempel/Target> valgrind
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1 t2.c
==23596== Memcheck, a memory error detector
==23596== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==23596== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==23596== Command: /home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1 t2.c
==23596== 
 foo foo_int
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
  ==23596== Invalid write of
size 8
==23596==at 0x135DAB5: separate_attrs (multiple_target.c:165)
==23596==by 0x135DAB5: expand_target_clones(cgraph_node*, bool)
(multiple_target.c:264)
==23596==by 0x135E114: ipa_target_clone (multiple_target.c:351)
==23596==by 0x135E114: (anonymous
namespace)::pass_target_clone::execute(function*) (multiple_target.c:379)
==23596==by 0xAFBFFC: execute_one_pass(opt_pass*) (passes.c:2370)
==23596==by 0xAFCE11: execute_ipa_pass_list(opt_pass*) (passes.c:2805)
==23596==by 0x7DB053: ipa_passes (cgraphunit.c:2339)
==23596==by 0x7DB053: symbol_table::compile() [clone .part.47]
(cgraphunit.c:2425)
==23596==by 0x7DD816: compile (cgraphunit.c:2587)
==23596==by 0x7DD816: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2584)
==23596==by 0xBCBE92: compile_file() (toplev.c:493)
==23596==by 0x63B57C: do_compile (toplev.c:2012)
==23596==by 0x63B57C: toplev::main(int, char**) (toplev.c:2146)
==23596==by 0x63D8D6: main (main.c:39)
==23596==  Address 0x59cc258 is 0 bytes after a block of size 8 alloc'd
==23596==at 0x4C29110: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23596==by 0x1432B67: xmalloc (xmalloc.c:148)
==23596==by 0x135DA7D: expand_target_clones(cgraph_node*, bool)
(multiple_target.c:262)
==23596==by 0x135E114: ipa_target_clone (multiple_target.c:351)
==23596==by 0x135E114: (anonymous
namespace)::pass_target_clone::execute(function*) (multiple_target.c:379)
==23596==by 0xAFBFFC: execute_one_pass(opt_pass*) (passes.c:2370)
==23596==by 0xAFCE11: execute_ipa_pass_list(opt_pass*) (passes.c:2805)
==23596==by 0x7DB053: ipa_passes (cgraphunit.c:2339)
==23596==by 0x7DB053: symbol_table::compile() [clone .part.47]
(cgraphunit.c:2425)
==23596==by 0x7DD816: compile (cgraphunit.c:2587)
==23596==by 0x7DD816: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2584)
==23596==by 0xBCBE92: compile_file() (toplev.c:493)
==23596==by 0x63B57C: do_compile (toplev.c:2012)
==23596==by 0x63B57C: toplev::main(int, char**) (toplev.c:2146)
==23596==by 0x63D8D6: main (main.c:39)
==23596== 
==23596== Invalid read of size 8
==23596==at 0x135DB40: expand_target_clones(cgraph_node*, bool)
(multiple_target.c:284)
==23596==by 0x135E114: ipa_target_clone (multiple_target.c:351)
==23596==by 0x135E114: (anonymous
namespace)::pass_target_clone::execute(function*) (multiple_target.c:379)
==23596==by 0xAFBFFC: execute_one_pass(opt_pass*) (passes.c:2370)
==23596==by 0xAFCE11: execute_ipa_pass_list(opt_pass*) (passes.c:2805)
==23596==by 0x7DB053: ipa_passes (cgraphunit.c:2339)
==23596==by 0x7DB053: symbol_table::compile() [clone .part.47]
(cgraphunit.c:2425)
==23596==by 0x7DD816: compile (cgraphunit.c:2587)
==23596==by 0x7DD816: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2584)
==23596==by 0xBCBE92: compile_file() (toplev.c:493)
==23596==by 0x63B57C: do_compile (toplev.c:2012)
==23596==by 0x63B57C: toplev::main(int, char**) (toplev.c:2146)
==23596==by 0x63D8D6: main (main.c:39)
==23596==  Address 0x59cc258 is 0 bytes after a block of size 8 alloc'd
==23596==at 0x4C29110: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23596==by 0x1432B67: xmalloc (xmalloc.c:148)
==23596==by 0x135DA7D: expand_target_clones(cgraph_node*, bool)
(multiple_target.c:262)
==23596==by 0x135E114: ipa_target_clone (multiple_target.c:351)
==23596==by 0x135E114: (anonymous
namespace)::pass_target_clone::execute(function*) (multiple_target.c:379)
==23596==by 0xAFBFFC: execute_one_pass(opt_pass*) (passes.c:2370)
==23596==by 0xAFCE11: execute_ipa_pass_list(opt_pass*) (passes.c:2805)
==23596==by 0x7DB053: ipa_passes (cgraphunit.c:2339)
==23596==by 0x7DB053: symbol_table::compile() [clone .part.47]
(cgraphunit.c:2425)
==23596==by 0x7DD816: compile (cgraphunit.c:2587)
==23596==by 0x7DD816: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2584)
==23596==by 0xBCBE92: compile_file() (toplev.c:493)
==23596==by 0x63B57C: do_compile (toplev.c:2012)
==23596==by 0x63B57C: toplev::main(int, char**) (toplev.c:2146)
==23596==by 0x63D8D6: main (main.c:39)
==23596== 

t2.c:20:1: error: attribute(target("foo")) is unknown
 }
 ^
t2.c:11:8: warning: attribute(target_clones("foo")) is 

[Bug other/78419] New: ICE with target_clone on invalid target

[tkoenig at gcc dot gnu.org]

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

Bug ID: 78419
   Summary: ICE with target_clone on invalid target
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

ig25@linux-fd1f:~/Krempel/Target> cat t2.c 
static double foo_int(double *restrict, double *restrict, int)
__attribute__ ((target_clones("avx,foo,avx2,avx512f,default")))
;

double foo(double *restrict a, double *restrict b, int n)
{
  return foo_int(a,b,n);
}


double foo_int(double *restrict a, double *restrict b, int n)
{
  double s;
  int i;
  s = 0.0;
  for (i=0; i gcc -S t2.c
t2.c:20:1: error: attribute(target("foo")) is unknown
 }
 ^
t2.c:11:8: warning: attribute(target_clones("foo")) is not valid for current
target
 double foo_int(double *restrict a, double *restrict b, int n)
^~~
*** Error in `/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': free():
invalid next size (fast): 0x0301ec60 ***
=== Backtrace: =
/lib64/libc.so.6(+0x727df)[0x7f467a3e87df]
/lib64/libc.so.6(+0x7804e)[0x7f467a3ee04e]
/lib64/libc.so.6(+0x78d56)[0x7f467a3eed56]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1[0x135de19]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1[0x135e115]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1(_Z16execute_one_passP8opt_pass+0x12d)[0xafbffd]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1(_Z21execute_ipa_pass_listP8opt_pass+0x92)[0xafce12]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1[0x7db054]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1(_ZN12symbol_table25finalize_compilation_unitEv+0x157)[0x7dd817]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1[0xbcbe93]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1(_ZN6toplev4mainEiPPc+0x6ed)[0x63b57d]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1(main+0x27)[0x63d8d7]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f467a397b05]
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1[0x63dcc3]
=== Memory map: 
0040-01ef6000 r-xp  08:04 2621565   
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1
020f6000-020fc000 r--p 01af6000 08:04 2621565   
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1
020fc000-02108000 rw-p 01afc000 08:04 2621565   
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1
02108000-02255000 rw-p  00:00 0 
02ff7000-030f6000 rw-p  00:00 0  [heap]
7f4679f5e000-7f4679f74000 r-xp  08:04 795089
/home/ig25/lib64/libgcc_s.so.1
7f4679f74000-7f467a174000 ---p 00016000 08:04 795089
/home/ig25/lib64/libgcc_s.so.1
7f467a174000-7f467a175000 r--p 00016000 08:04 795089
/home/ig25/lib64/libgcc_s.so.1
7f467a175000-7f467a176000 rw-p 00017000 08:04 795089
/home/ig25/lib64/libgcc_s.so.1
7f467a176000-7f467a376000 rw-p  00:00 0 
7f467a376000-7f467a517000 r-xp  08:04 794245
/lib64/libc-2.19.so
7f467a517000-7f467a716000 ---p 001a1000 08:04 794245
/lib64/libc-2.19.so
7f467a716000-7f467a71a000 r--p 001a 08:04 794245
/lib64/libc-2.19.so
7f467a71a000-7f467a71c000 rw-p 001a4000 08:04 794245
/lib64/libc-2.19.so
7f467a71c000-7f467a72 rw-p  00:00 0 
7f467a72-7f467a82 r-xp  08:04 795125
/lib64/libm-2.19.so
7f467a82-7f467aa1f000 ---p 0010 08:04 795125
/lib64/libm-2.19.so
7f467aa1f000-7f467aa2 r--p 000ff000 08:04 795125
/lib64/libm-2.19.so
7f467aa2-7f467aa21000 rw-p 0010 08:04 795125
/lib64/libm-2.19.so
7f467aa21000-7f467aa24000 r-xp  08:04 795122
/lib64/libdl-2.19.so
7f467aa24000-7f467ac23000 ---p 3000 08:04 795122
/lib64/libdl-2.19.so
7f467ac23000-7f467ac24000 r--p 2000 08:04 795122
/lib64/libdl-2.19.so
7f467ac24000-7f467ac25000 rw-p 3000 08:04 795122
/lib64/libdl-2.19.so
7f467ac25000-7f467ac45000 r-xp  08:04 788292
/lib64/ld-2.19.so
7f467ade9000-7f467aded000 rw-p  00:00 0 
7f467ae09000-7f467ae45000 rw-p  00:00 0 
7f467ae45000-7f467ae46000 r--p 0002 08:04 788292
/lib64/ld-2.19.so
7f467ae46000-7f467ae47000 rw-p 00021000 08:04 788292
/lib64/ld-2.19.so
7f467ae47000-7f467ae48000 rw-p  00:00 0 
7fff214e2000-7fff21504000 rw-p  00:00 0 
[stack]
7fff215fc000-7fff215fe000 r-xp  00:00 0  [vdso]
7fff215fe000-7fff2160 r--p  00:00 0

[Bug fortran/78398] missing warnings and inconsistencies with -Wuninitialized

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 5 up to trunk (7.0). Note that I don't get any warning with 4.8
and 4.9.

> This may be related to PR 34721.

Certainly for the missing warnings for 'print *,i'.

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin16   |x86_64-apple-darwin*
   Host|x86_64-apple-darwin16   |x86_64-apple-darwin*
  Build|x86_64-apple-darwin16   |x86_64-apple-darwin*

--- Comment #3 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #2)
> Created attachment 40082 [details]
> Reference results for the obj-c++ test suite before r242377
> 
> Note that due to pr63651 I am using the 10.9 SDK for the tests.

It shows up regardless of the SDK in use, I haven't had a chance to analyse yet
- but suspect this is a set of conditions that happens only to occur here.

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-18
 Ever confirmed|0   |1

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

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> As an alternative to removing the assert, one could possibly prevent SAVEd
> variables in the main PROGRAM from being declared as "static" (which might
> also cure the performance regressions that Dominique reported for my patch
> for PR 55207)?

This could possibly be accomplished like this:

Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 242584)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -635,7 +635,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
  initialized variables are SAVE_IMPLICIT and explicitly saved are
  SAVE_EXPLICIT.  */
   if (!sym->attr.use_assoc
-   && (sym->attr.save != SAVE_NONE || sym->attr.data
+   && ((sym->attr.save != SAVE_NONE &&
!sym->ns->proc_name->attr.is_main_program)
+   || sym->attr.data
|| (sym->value && sym->ns->proc_name->attr.is_main_program)
|| (flag_coarray == GFC_FCOARRAY_LIB
&& sym->attr.codimension && !sym->attr.allocatable)))

That indeed removes the ICE on comment 0, however it causes loads of testsuite
regressions, so it's certainly not a very good idea.

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Created attachment 40082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40082=edit
Reference results for the obj-c++ test suite before r242377

Note that due to pr63651 I am using the 10.9 SDK for the tests.

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-18
 Ever confirmed|0   |1

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Created attachment 40081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40081=edit
Results for the obj-c++ test suite after r242377

[Bug objc++/78418] New: [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

Bug ID: 78418
   Summary: [7 Regression] Several failures in the obj-c++ test
suite after revision r242377 on x86_64-apple-darwin16
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, jason at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

Created attachment 40080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40080=edit
preprocessed file for torture/strings/const-str-10.mm

Several failures appeared in the obj-c++ test suite after revision r242377 on
x86_64-apple-darwin16. They are due to the following ICE

[Book15] f90/bug% /opt/gcc/gcc7p-242377p4y/bin/g++ const-str-10.mii -c
-fnext-runtime -mno-constant-cfstrings
/opt/gcc/p_work/gcc/testsuite/obj-c++.dg/torture/strings/const-str-10.mm:31:34:
internal compiler error: tree check: expected var_decl or parm_decl or
result_decl, have const_decl in lvalue_kind, at cp/tree.c:145
 const NSConstantString *appKey = @"MyApp";
  ^

[Bug rtl-optimization/78416] New: wrong code for division by (u128)~INT64_MAX at -O0

[zsojka at seznam dot cz]

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

Bug ID: 78416
   Summary: wrong code for division by (u128)~INT64_MAX at -O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 40079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40079=edit
reduced testcase

Compiler output:
$ gcc testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242583-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242583-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161118 (experimental) (GCC) 


All tested 64bit targets seem to be affected:
aarch64-unknown-linux-gnu
powerpc64-unknown-linux-gnu
sparc64-unknown-linux-gnu
x86_64-pc-linux-gnu
x86_64-pc-linux-gnux32

The .expand dump has:
;; x_2 = x_1 / 0x8000;

(insn 6 5 7 (set (reg:TI 90)
(mem/c:TI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -16 [0xfff0])) [1 xD.1797+0 S16 A128]))
"testcase.c":7 -1
 (nil))

(insn 7 6 8 (parallel [
(set (reg:TI 89)
(lshiftrt:TI (reg:TI 90)
(const_int 63 [0x3f])))
(clobber (reg:CC 17 flags))
]) "testcase.c":7 -1
 (expr_list:REG_EQUAL (udiv:TI (reg:TI 90)
(const_int -9223372036854775808 [0x8000]))
(nil)))


Which, I think, is wrong. But I have been wrong many times already.

[Bug target/78417] New: target_clones default for powerpc64

[tkoenig at gcc dot gnu.org]

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

Bug ID: 78417
   Summary: target_clones default for powerpc64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following does not work as expected.

Either default is an invalid target for target_clones, or it is missing.
Bit of a Catch-22 there :-)

The reason why I'm interested is PR 78379; I think PowerPC could also
profit from processor-specific versions of matmul in the library.

[tkoenig@gcc1-power7 ~]$ cat target.c
static double foo_int(const double *restrict, const double *restrict, int)
__attribute__ ((target_clones("cpu=power7,cpu=power8,default")))
;

double foo(const double *restrict a, const double *restrict b, int n)
{
  return foo_int(a,b,n);
}

static double foo_int(const double *restrict a, const double *restrict b, int
n)
{
  double s;
  int i;
  s = 0.0;
  for (i=0; i

[Bug middle-end/68360] GCC bitfield processing code is very inefficient

[roman.perepelitsa at gmail dot com]

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

Roman Perepelitsa  changed:

   What|Removed |Added

 CC||roman.perepelitsa at gmail dot 
com

--- Comment #3 from Roman Perepelitsa  ---
Here's another example where GCC generates suboptimal code for bitfield
initialization on x64: https://godbolt.org/g/WeqAr5.

  #include 

  struct S {
S(uint32_t a, uint32_t b);

uint32_t a : 2;
uint32_t b : 30;
  };

  S::S(uint32_t a, uint32_t b) : a(a), b(b) {}

Here's the code generated for the constructor when compiled with -O2.

Clang 3.9:

andl$3, %esi
leal(%rsi,%rdx,4), %eax
movl%eax, (%rdi)
retq

GCC 7.0:

movl%esi, %eax
movzbl  (%rdi), %esi
andl$3, %eax
andl$-4, %esi
orl %eax, %esi
leal0(,%rdx,4), %eax
movb%sil, (%rdi)
movl(%rdi), %edx
andl$3, %edx
orl %eax, %edx
movl%edx, (%rdi)
ret

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin16   |x86_64-apple-darwin1[4-6]
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2016-11/msg01348.ht |patches/2016-11/msg01903.ht
   |ml  |ml
   Host|x86_64-apple-darwin16   |x86_64-apple-darwin1[4-6]
  Build|x86_64-apple-darwin16   |x86_64-apple-darwin1[4-6]

--- Comment #53 from Rainer Orth  ---
Just reposted the combined patch for reference.

[Bug fortran/78395] [OOP] error on polymorphic assignment

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
(In reply to janus from comment #2)
> (In reply to janus from comment #1)
> > gfortran 6.2.0 says:
> > 
> >v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
> >   1
> > Error: Assignment to an allocatable polymorphic variable at (1) is not yet
> > supported
> 
> It seems this error message was removed on trunk by Andre's r241439.

Well, that error message was not only removed, but the feature reported missing
was implemented.

While doing so, I happened to find a piece of code dealing with
typebound-procedures, that when removed did not cause any regression. I
therefore assume, that it just was not tested in the testsuite and will have a
look what I can do about it.

[Bug libquadmath/78415] New: sqrtq does not round correctly when round mode is upward

[walter.mascarenhas at gmail dot com]

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

Bug ID: 78415
   Summary: sqrtq does not round correctly when round mode is
upward
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walter.mascarenhas at gmail dot com
  Target Milestone: ---

//
// The code below shows that sqrtq does not round
// correctly when the rounding mode is upwards.
//
#include 
#include 
#include 
#include 

int main()
{
  __float128 x = 1.0;
  x += 2.0 * FLT128_EPSILON;

  std::fesetround(FE_UPWARD);
  __float128 su = sqrtq(x);

  // the sqrt is rounded to 1 + 2 epsilon, whereas the least __float128
  // above the mathematical sqrt(1 + 2 epsilon) is 1 + epsilon:
  // The Taylor series for sqrt around 1 yields
  // sqrt(1 + 2 epsilon) ~ 1 + epsilon - epsilon^2/2 < 1 + epsilon.

  assert(su == x);
}

[Bug libquadmath/78414] libquamath converts (long double) INFINITY to NAN

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Dup.

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

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||walter.mascarenhas at gmail 
dot co
   ||m

--- Comment #6 from Uroš Bizjak  ---
*** Bug 78414 has been marked as a duplicate of this bug. ***

[Bug libquadmath/78414] New: libquamath converts (long double) INFINITY to NAN

[walter.mascarenhas at gmail dot com]

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

Bug ID: 78414
   Summary: libquamath converts (long double) INFINITY to NAN
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walter.mascarenhas at gmail dot com
  Target Milestone: ---

Created attachment 40078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40078=edit
a simple code showing the bug

Libquadmath converts the INFINITY long double to a NAN __float128

[Bug rtl-optimization/78400] [7 Regression] ICE: in df_refs_verify, at df-scan.c:4045 when building powerpc crosscompiler

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Looks like a separate shrink-wrapping issue