[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Apr 24 05:07:21 2016
New Revision: 235391

URL: https://gcc.gnu.org/viewcvs?rev=235391=gcc=rev
Log:
2016-04-23  Jerry DeLisle  

PR libgfortran/70684
* io/list_read (check_buffers): Add '\r' to check for end of line.
factor.

* gfortran.dg/list_read_14.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/list_read_14.f90
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libgfortran/ChangeLog
branches/gcc-6-branch/libgfortran/io/list_read.c

[Bug c++/70776] New: ICE on invalid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[su at cs dot ucdavis.edu]

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

Bug ID: 70776
   Summary: ICE on invalid code on x86_64-linux-gnu: Segmentation
fault (program cc1plus)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It seems to affect at least all GCC versions 4.4.x and later. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160423 (experimental) [trunk revision 235384] (GCC) 
$ 
$ g++-trunk small.cpp -c
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





template < int > struct A;

template < typename, typename = void > struct B;

template < typename T > 
struct B < T, typename A < B < T >::value >::type >
{
  B < int > b;   // OK: B < int > *b; 
};

[Bug tree-optimization/70775] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 70775
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
Segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It is a regression from 5.3.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160423 (experimental) [trunk revision 235384] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-5.3 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:17:1: internal compiler error: Segmentation fault
 fn2 ()
 ^~~
0xb6718f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x74e89c vec_safe_length<loop*, va_gc>
../../gcc-source-trunk/gcc/vec.h:524
0x74e89c loop_depth
../../gcc-source-trunk/gcc/cfgloop.h:444
0x74e89c flow_loop_nested_p(loop const*, loop const*)
../../gcc-source-trunk/gcc/cfgloop.c:64
0xdb7837 vect_is_simple_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:2627
0xdb9011 vect_force_simple_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:3026
0xdb9011 vect_analyze_scalar_cycles_1
../../gcc-source-trunk/gcc/tree-vect-loop.c:865
0xdbc807 vect_analyze_scalar_cycles
../../gcc-source-trunk/gcc/tree-vect-loop.c:939
0xdbc807 vect_analyze_loop_2
../../gcc-source-trunk/gcc/tree-vect-loop.c:1845
0xdbc807 vect_analyze_loop(loop*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:2264
0xdd7611 vectorize_loops()
../../gcc-source-trunk/gcc/tree-vectorizer.c:532
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ 


--


struct S
{
  int f1;
  int f2;
} a;

int b, c, d, e;
short f;

int
fn1 (int p1, unsigned p2)
{
  return p1 + p2;
}

void
fn2 ()
{
  struct S g;
  int h;
  for (; c; c++)
for (f = -3; f < 3; f = fn1 (f, 8))
  {
a.f1 = e;
if (b)
  a = g;
else
  for (; h; h++)
d = b;
  }
}

[Bug c++/70774] New: constexpr function with reference parameter gives reinterpret_cast from integer to pointer error

[steven.spark at gmail dot com]

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

Bug ID: 70774
   Summary: constexpr function with reference parameter gives
reinterpret_cast from integer to pointer error
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven.spark at gmail dot com
  Target Milestone: ---

Here is the simplified code:

--
#define PORTX (*(volatile unsigned char *)(0x1B))

constexpr volatile unsigned char * testRef(volatile unsigned char & x) {
return 
}
volatile unsigned char* addr = testRef(PORTX); /// OK

constexpr volatile unsigned char* addr2 = testRef(PORTX); /// error: 
   /// reinterpret_cast from integer to pointer
--


This compiled without problem with gcc 4.8.1, but fails with 4.9.2.


Using built-in specs.
COLLECT_GCC=avr-g++.exe
Target: avr
Configured with:
/home/toolsbuild/workspace/avr8-gnu-toolchain/src/gcc/configure
LDFLAGS=-L/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs/lib
CPPFLAGS= --target=avr --host=i686-w64-mingw32 --build=x86_64-pc-linux-gnu
--prefix=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86
--libdir=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86/lib
--enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared
--disable-libada --disable-libssp --disable-nls --with-avrlibc=yes
--with-mpfr=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs
--with-gmp=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs
--with-mpc=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs
--enable-win32-registry=avrtoolchain
--with-pkgversion=AVR_8_bit_GNU_Toolchain_3.5.0_1662
--with-bugurl=http://www.atmel.com
Thread model: single
gcc version 4.9.2 (AVR_8_bit_GNU_Toolchain_3.5.0_1662) 



I'm writing code for AVR micro controller where every byte counts, so compile
time evaluation is key. I was trying out the new Atmel Studio 7 IDE which comes
with the new 4.9.2 gcc when I came across this problem. In my real world code
I'm using constexpr constructor and constexpr instances of my pin handler class
- to make life easier and encapsulate port, data direction and other registers. 

Note: If I use pointer instead of reference then it compiles fine:

constexpr volatile unsigned char * testAddr(volatile unsigned char * x) {
return x;
}
constexpr volatile unsigned char* addr3 = testAddr(); /// OK


Why is this? Am I doing something wrong? How can I use (port) references in
constexpr functions?

This also does NOT work:

constexpr volatile unsigned char& ref5 = PORTX; /// error

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

[kugan]

Hi Richard,

As you have said in the other email, I tried implementing with the 
add_reapeats_to_ops_vec but the whole repeat vector is designed for 
MULT_EXPR chain. I tried changing it but it turned out to be not 
straightforward without lots of re-write. Therefore I tried to implement 
based on your review here. Please tell me what you think.



+/* Transoform repeated addition of same values into multiply with
+   constant.  */

Transform


Done.



+static void
+transform_add_to_multiply (gimple_stmt_iterator *gsi, gimple *stmt,
vec *ops)

split the long line


Done.



op_list looks redundant - ops[start]->op gives you the desired value
already and if you
use a vec> you can have a more C++ish start,end pair.

+  tree tmp = make_temp_ssa_name (TREE_TYPE (op), NULL, "reassocmul");
+  gassign *mul_stmt = gimple_build_assign (tmp, MULT_EXPR,
+  op, build_int_cst
(TREE_TYPE(op), count));

this won't work for floating point or complex numbers - you need to use sth like
fold_convert (TREE_TYPE (op), build_int_cst (integer_type_node, count));


Done.



For FP types you need to guard the transform with flag_unsafe_math_optimizations


Done.



+  gimple_set_location (mul_stmt, gimple_location (stmt));
+  gimple_set_uid (mul_stmt, gimple_uid (stmt));
+  gsi_insert_before (gsi, mul_stmt, GSI_SAME_STMT);

I think you do not want to set the stmt uid


assert in reassoc_stmt_dominates_p (gcc_assert (gimple_uid (s1) && 
gimple_uid (s2))) is failing. So I tried to add the uid of the adjacent 
stmt and it seems to work.



and you want to insert the
stmt right
after the def of op (or at the original first add - though you can't
get your hands at


Done.


that easily).  You also don't want to set the location to the last stmt of the
whole add sequence - simply leave it unset.

+  oe = operand_entry_pool.allocate ();
+  oe->op = tmp;
+  oe->rank = get_rank (op) * count;

?  Why that?  oe->rank should be get_rank (tmp).

+  oe->id = 0;

other places use next_operand_entry_id++.  I think you want to simply
use add_to_ops_vec (oe, tmp); here for all of the above.


Done.



Please return whether you did any optimization and do the
qsort of the operand vector only if you did sth.


Done.



Testcase with FP math missing.  Likewise with complex or vector math.


Btw, does it handle associating

   x + 3 * x + x

to

   5 * x

?


Added this to the testcase and verified it is working.

Regression tested and bootstrapped on x86-64-linux-gnu with no new 
regressions.


Is this OK for trunk?

Thanks,
Kugan


gcc/testsuite/ChangeLog:

2016-04-24  Kugan Vivekanandarajah  

PR middle-end/63586
* gcc.dg/tree-ssa/pr63586-2.c: New test.
* gcc.dg/tree-ssa/pr63586.c: New test.
* gcc.dg/tree-ssa/reassoc-14.c: Adjust multiplication count.

gcc/ChangeLog:

2016-04-24  Kugan Vivekanandarajah  

PR middle-end/63586
* tree-ssa-reassoc.c (transform_add_to_multiply): New.
(reassociate_bb): Call transform_add_to_multiply.



diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c
index e69de29..2774fbd 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
+
+float f1_float (float x)
+{
+float y = x + x;
+y = y + x;
+y = y + x;
+y = y + x;
+y = y + x;
+y = y + x;
+y = y + x;
+return y;
+}
+
+float f1_float2 (float x)
+{
+float y = x + 3 * x + x;
+return y;
+}
+
+int f1_int (int x)
+{
+int y = x + 3 * x + x;
+return y;
+}
+
+/* { dg-final { scan-tree-dump-times "\\\*" 4 "reassoc1" } } */
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr63586.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr63586.c
index e69de29..a0f705b 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr63586.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr63586.c
@@ -0,0 +1,59 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-reassoc1" } */
+
+unsigned f1 (unsigned x)
+{
+unsigned y = x + x;
+y = y + x;
+y = y + x;
+y = y + x;
+y = y + x;
+y = y + x;
+y = y + x;
+return y;
+}
+
+unsigned f2 (unsigned x, unsigned z)
+{
+unsigned y = x + x;
+y = y + x;
+y = y + x;
+y = y + z;
+y = y + z;
+y = y + z;
+y = y + z;
+return y;
+}
+
+unsigned f3 (unsigned x, unsigned z, unsigned k)
+{
+unsigned y = x + x;
+y = y + x;
+y = y + x;
+y = y + z;
+y = y + z;
+y = y + z;
+y = y + k;
+return y;
+}
+
+unsigned f4 (unsigned x, unsigned z, unsigned k)
+{
+unsigned y = k + x;
+y = y + x;
+y = y + x;
+y = y + z;
+y = y + z;
+y = y + z;
+y = y + x;
+return y;
+}
+
+unsigned f5 (unsigned x, unsigned y, unsigned z)
+{
+return x + x + x + x + y + y + y + y 

[Bug c++/70770] [5 Regression] constexpr expansion Internal compiler error

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE
Summary|constexpr expansion |[5 Regression] constexpr
   |Internal compiler error |expansion Internal compiler
   ||error

--- Comment #3 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/70353] [5 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||mira.fontan at gmail dot com

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

[Bug c++/70768] Increased compilation time

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
This is the file in question:

https://github.com/ericniebler/range-v3/blob/master/test/algorithm/transform.cpp

[Bug gcov-profile/70773] New: Profiling makes sudoku solver slower

[tulipawn at gmail dot com]

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

Bug ID: 70773
   Summary: Profiling makes sudoku solver slower
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Created attachment 38334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38334=edit
.c, .i and .gcda files

Compiling the attached sudoku solver the usual way and running the benchmark:

$ gcc -O3  -Wall sudoku.c -o sudokuC
$ time ./sudokuC 1>&2 > /dev/null

takes 1.25s, whereas doing a profile build:

$ gcc -O3  -Wall sudoku.c -o sudokuC -fprofile-generate
$ time ./sudokuC 1>&2 > /dev/null
$ gcc -O3  -Wall sudoku.c -o sudokuC -fprofile-use
$ time ./sudokuC 1>&2 > /dev/null

takes 1.5s which means it's 20% slower. Probably shouldn't happen.

[Bug c++/70768] Increased compilation time

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to James Almer from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > Well, you simply need more RAM to compile this testcase, because gcc-6 uses
> > slightly over 2GB peak, so your machine starts swapping.
> > On my machine (with 8GB RAM) gcc-6 is actually slightly faster.
> > 
> > (For gcc-7 you need to configure it with --enable-checking=release to
> > compare timings.)
> 
> Tried to assign more RAM to the vm and it indeed fixed the trashing and
> slowness with gcc-6 and newer.
> 
> gcc-6/7 uses like 2.1GB of RAM to compile this file whereas gcc-5 uses only
> 1.6GB. Is this intended/expected, or can it be considered a memory hog?

Maybe. gcc-5:

 phase lang. deferred:  66.28 (84%) usr   2.57 (69%) sys  68.88 (83%) wall
2722388 kB (82%) ggc
 phase opt and generate  :  12.25 (15%) usr   0.92 (25%) sys  13.19 (16%) wall 
469818 kB (14%) ggc
 phase finalize  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 |name lookup:   1.80 ( 2%) usr   0.12 ( 3%) sys   1.99 ( 2%) wall 
279075 kB ( 8%) ggc
 |overload resolution:  58.89 (74%) usr   2.53 (68%) sys  61.26 (74%) wall
2619094 kB (79%) ggc
 template instantiation  :  60.34 (76%) usr   2.66 (72%) sys  62.90 (76%) wall
2791073 kB (84%) ggc
 TOTAL :  79.35 3.7283.14   
3325932 kB

gcc-6:

 phase lang. deferred:  74.36 (87%) usr   3.38 (72%) sys  77.73 (86%) wall
3725459 kB (84%) ggc
 phase opt and generate  :  10.30 (12%) usr   1.17 (25%) sys  11.46 (13%) wall 
572078 kB (13%) ggc
 |name lookup:   2.18 ( 3%) usr   0.27 ( 6%) sys   2.19 ( 2%) wall 
134001 kB ( 3%) ggc
 |overload resolution:  62.60 (73%) usr   3.25 (69%) sys  66.14 (73%) wall
3543436 kB (80%) ggc
 template instantiation  :  64.42 (75%) usr   3.42 (72%) sys  67.78 (75%) wall
3798026 kB (86%) ggc
 TOTAL :  85.52 4.7290.24   
4424695 kB

Re: [Patch AArch64] Fix PR target/63874

[Ramana Radhakrishnan]

On Thu, Mar 31, 2016 at 5:30 PM, James Greenhalgh
 wrote:
> On Thu, Mar 31, 2016 at 02:11:49PM +0100, Ramana Radhakrishnan wrote:
>> Hi,
>>
>>   In this PR we have a situation where we aren't really detecting
>> weak references vs weak definitions. If one has a weak definition
>> that binds locally there's no reason not to put out PC relative
>> relocations.
>>
>> However if you have a genuine weak reference that is
>> known not to bind locally it makes very little sense
>> to put out an entry into the literal pool which doesn't always
>> work with DSOs and shared objects.
>>
>> Tested aarch64-none-linux-gnu bootstrap and regression test with no 
>> regressions
>>
>> This is not a regression and given what we've seen recently with protected
>> symbols and binds_locally_p I'd rather this were queued for GCC 7.
>>
>> Ok ?
>
> Based on the bugzilla report, this looks OK for GCC 7 to me. But I don't
> know the dark corners of the elf specification, so I'd rather leave the
> final review to Richard or Marcus.

Richard / Marcus, ping ?


Ramana
>
> Thanks,
> James
>
>> gcc/
>>
>> * config/aarch64/aarch64.c (aarch64_classify_symbol): Typo in comment fixed.
>>   Only force to memory if it is a weak external reference.
>>
>> gcc/testsuite
>>
>> * gcc.target/aarch64/pr63874.c: New test.
>

[Bug c++/70768] Increased compilation time

[jamrial at gmail dot com]

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

--- Comment #2 from James Almer  ---
(In reply to Markus Trippelsdorf from comment #1)
> Well, you simply need more RAM to compile this testcase, because gcc-6 uses
> slightly over 2GB peak, so your machine starts swapping.
> On my machine (with 8GB RAM) gcc-6 is actually slightly faster.
> 
> (For gcc-7 you need to configure it with --enable-checking=release to
> compare timings.)

Tried to assign more RAM to the vm and it indeed fixed the trashing and
slowness with gcc-6 and newer.

gcc-6/7 uses like 2.1GB of RAM to compile this file whereas gcc-5 uses only
1.6GB. Is this intended/expected, or can it be considered a memory hog?

[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/69143] PowerPC64: aggregate results are badly handled

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to H.J. Lu from comment #3)
> Similar to PR 28831, PR 23782?

Indeed, though looks more like a base case for PR28831 than PR23782 at first
glance. 

Ramana

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #42 from Jakub Jelinek  ---
Even
PATH=/opt/freeware/bin/:$PATH /home/jakub/gcc-6.0.1-RC-20160415/configure
--disable-werror --enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm
--with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
--with-included-gettext --enable-checking=release
PATH=/opt/freeware/bin/:$PATH make -j48 > LOG 2>&1 &
got through comparison without failure (still finishing bootstrap, but compare
file already exists).

[Bug c++/70755] [ARM] excessive struct alignment for globals

[bruck.michael at googlemail dot com]

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

--- Comment #3 from Michael Bruck  ---
(In reply to Michael Bruck from comment #2)
> (In reply to Richard Earnshaw from comment #1)
> > This is a deliberate design choice.  By doing this we gain significant
> > benefits from having aligned objects, which helps with data copying and
> > other optimizations.
> > 
> > Consider, for example, the object
> > 
> > struct x
> > {
> >   char a;
> >   char b;
> >   char c;
> >   char d;
> > };
> > 
> > struct x A, B;
> > 
> > f()
> > {
> >   B = A;
> > }
> > 
> > Since the objects are aligned then this function can be optimized to single
> > 32-bit load and store operations that work very efficiently.
> > 
> > As you've noticed, it is possible to force the alignment down to the
> > architectural minimums by annotations, but for most users it makes little
> > difference and the defaults are preferable.
> 
> "for most users"
> 
> Maybe I should have specified -mcortex-m0 on the command line to illustrate
> the point. For most Cortex-M0 users with 16 kB this 300% memory waste is a
> bad trade-off.
> 
> Can you implement a command line option to deactivate this behavior?
> 
> Your reply did not address b) and c), should I open a separate bug to
> discuss these?


A struct with only one bool does not derive the benefits described in your
example and should be exempted from this modified alignment for this reason
alone.(In reply to Richard Earnshaw from comment #1)
> This is a deliberate design choice.  By doing this we gain significant
> benefits from having aligned objects, which helps with data copying and
> other optimizations.
> 
> Consider, for example, the object
> 
> struct x
> {
>   char a;
>   char b;
>   char c;
>   char d;
> };
> 
> struct x A, B;
> 
> f()
> {
>   B = A;
> }
> 
> Since the objects are aligned then this function can be optimized to single
> 32-bit load and store operations that work very efficiently.
> 
> As you've noticed, it is possible to force the alignment down to the
> architectural minimums by annotations, but for most users it makes little
> difference and the defaults are preferable.

A struct with only one bool does not derive the benefits described in your
example and should be exempted from this modified alignment for this reason
alone.

[Bug c++/70755] [ARM] excessive struct alignment for globals

[bruck.michael at googlemail dot com]

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

--- Comment #2 from Michael Bruck  ---
(In reply to Richard Earnshaw from comment #1)
> This is a deliberate design choice.  By doing this we gain significant
> benefits from having aligned objects, which helps with data copying and
> other optimizations.
> 
> Consider, for example, the object
> 
> struct x
> {
>   char a;
>   char b;
>   char c;
>   char d;
> };
> 
> struct x A, B;
> 
> f()
> {
>   B = A;
> }
> 
> Since the objects are aligned then this function can be optimized to single
> 32-bit load and store operations that work very efficiently.
> 
> As you've noticed, it is possible to force the alignment down to the
> architectural minimums by annotations, but for most users it makes little
> difference and the defaults are preferable.

"for most users"

Maybe I should have specified -mcortex-m0 on the command line to illustrate the
point. For most Cortex-M0 users with 16 kB this 300% memory waste is a bad
trade-off.

Can you implement a command line option to deactivate this behavior?

Your reply did not address b) and c), should I open a separate bug to discuss
these?

[Bug c/70772] Wrong warning about unspecified behavior for comparison with string literal

[ch3root at openwall dot com]

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

--- Comment #1 from Alexander Cherepanov  ---
clang bug -- https://llvm.org/bugs/show_bug.cgi?id=27495 .

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
(In reply to Andy May from comment #14)
--- snip ---
> 
> Of course, I really appreciate the work that goes into this. I've already
> made a local patch file with your fix so that the mxe.cc gcc builds with it
> and now our program runs correctly.
> 

Your testing and confirming the original issue is fixed helps greatly, thanks.

> I look after a project with ~2.5 million lines of Fortran, some which were
> written 40 years ago on punch cards.

So many of us learned on those punch cards. (yeeehah!)

[Bug c/70772] New: Wrong warning about unspecified behavior for comparison with string literal

[ch3root at openwall dot com]

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

Bug ID: 70772
   Summary: Wrong warning about unspecified behavior for
comparison with string literal
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

While compiling such program:

int main()
{
  "abc" == "def";
}

I get this warning:

$ gcc -Wall -Wno-unused-value example.c 
example.c: In function ‘main’:
example.c:3:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
   "abc" == "def";
 ^~

The warning is wrong, this equality cannot be true.

I understand that the warning is intended to catch comparisons like "abc" ==
"abc" which indeed have an unspecified result. But the current warning is too
promiscuous.
The easy fix is to reformulate closer to "comparison with string literal is
always false or has an unspecified result".
The more thorough fix is to separately catch cases that could be proved to be
false at compile time.

Re: [PATCH, fortran, v3] Use Levenshtein spelling suggestions in Fortran FE

[Bernhard Reutner-Fischer]

On March 7, 2016 3:57:16 PM GMT+01:00, David Malcolm  
wrote:
>On Sat, 2016-03-05 at 23:46 +0100, Bernhard Reutner-Fischer wrote:
>[...]
>
>> diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
>> index 405bae0..72ed311 100644
>> --- a/gcc/fortran/misc.c
>> +++ b/gcc/fortran/misc.c
>[...]
>
>> @@ -274,3 +275,41 @@ get_c_kind(const char *c_kind_name,teropKind_tki
>> nds_table[])
>>  
>>return ISOCBINDING_INVALID;
>>  }
>> +
>> +
>> +/* For a given name TYPO, determine the best candidate from
>> CANDIDATES
>> +   perusing Levenshtein distance.  Frees CANDIDATES before
>> returning.  */
>> +
>> +const char *
>> +gfc_closest_fuzzy_match (const char *typo, char **candidates)
>> +{
>> +  /* Determine closest match.  */
>> +  const char *best = NULL;
>> +  char **cand = candidates;
>> +  edit_distance_t best_distance = MAX_EDIT_DISTANCE;
>> +
>> +  while (cand && *cand)
>> +{
>> +  edit_distance_t dist = levenshtein_distance (typo, *cand);
>> +  if (dist < best_distance)
>> +{
>> +   best_distance = dist;
>> +   best = *cand;
>> +}
>> +  cand++;
>> +}
>> +  /* If more than half of the letters were misspelled, the
>> suggestion is
>> + likely to be meaningless.  */
>> +  if (best)
>> +{
>> +  unsigned int cutoff = MAX (strlen (typo), strlen (best)) / 2;
>> +
>> +  if (best_distance > cutoff)
>> +{
>> +  XDELETEVEC (candidates);
>> +  return NULL;
>> +}
>> +  XDELETEVEC (candidates);
>> +}
>> +  return best;
>> +}
>
>FWIW, there are two overloaded variants of levenshtein_distance in
>gcc/spellcheck.h, the first of which takes a pair of strlen values;
>your patch uses the second one:
>
>extern edit_distance_t
>levenshtein_distance (const char *s, int len_s,
> const char *t, int len_t);
>
>extern edit_distance_t
>levenshtein_distance (const char *s, const char *t);
>
>So one minor tweak you may want to consider here is to calculate
>  strlen (typo)
>once at the top of gfc_closest_fuzzy_match, and then pass it in to the
>4-arg variant of levenshtein_distance, which would avoid recalculating
>strlen (typo) for every candidate.

I've pondered this back then but came to the conclusion to use the variant 
without len because to use the 4 argument variant I would have stored the 
candidates strlen in the vector too and was not convinced about the memory 
footprint for that would be justified. Maybe it is, but I would prefer the 
following tweak in the 4 argument variant:
If you would amend the 4 argument variant with a

  if (len_t == -1)
len_t = strlen (t);
before the
   if (len_s == 0)
 return len_t;
   if (len_t == 0)
 return len_s;

checks then I'd certainly use the 4 arg variant :)

WDYT?
>
>I can't comment on the rest of the patch (I'm not a Fortran expert),
>though it seems sane to 
>
>Hope this is constructive

It is, thanks for your thoughts!

cheers,

[Bug tree-optimization/70771] New: ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714

[su at cs dot ucdavis.edu]

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

Bug ID: 70771
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
operator[], at vec.h:714
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It is a regression from 5.3.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160423 (experimental) [trunk revision 235384] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.3 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
small.c: In function ‘main’:
small.c:18:1: internal compiler error: in operator[], at vec.h:714
 main ()
 ^~~~
0xba5e89 vec<edge_def*, va_gc, vl_embed>::operator[](unsigned int)
../../gcc-source-trunk/gcc/vec.h:714
0xba5e89 gimple_phi_arg_edge
../../gcc-source-trunk/gcc/gimple.h:4339
0xba5e89 replace_uses_by(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/tree-cfg.c:1818
0xba60b1 gimple_merge_blocks
../../gcc-source-trunk/gcc/tree-cfg.c:1938
0x74cf75 merge_blocks(basic_block_def*, basic_block_def*)
../../gcc-source-trunk/gcc/cfghooks.c:787
0xbaecc4 cleanup_tree_cfg_bb
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:660
0xbaf598 cleanup_tree_cfg_1
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:710
0xbaf598 cleanup_tree_cfg_noloop
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:761
0xbaf598 cleanup_tree_cfg()
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:812
0xa9ad74 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1921
0xa9b7cb execute_todo
../../gcc-source-trunk/gcc/passes.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$






int a, b, c, d;

static void
fn1 ()
{ 
  for (b = 0; b < 1; b++)
  for (c = 0; c < 1; c++)
{ 
  if (a)
break;
  b = 1;
}
  for (;;)
;
}

int
main ()
{ 
  if (d)
fn1 ();
  return 0;
}

Re: Second GCC 6.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

On Sat, Apr 23, 2016 at 01:15:12PM -0400, Jack Howarth wrote:
> Shouldn't there also be a back port of...

IMHO no, as I said on IRC, that can wait for 6.2.

Jakub

Re: Second GCC 6.1 Release Candidate available from gcc.gnu.org

[Jack Howarth]

Shouldn't there also be a back port of...


r235231 | bje | 2016-04-19 20:44:21 -0400 (Tue, 19 Apr 2016) | 2 lines

Attach PR number to most recent entry.


r235222 | bje | 2016-04-19 17:08:47 -0400 (Tue, 19 Apr 2016) | 3 lines

* testsuite/lib/libjava.exp (libjava_arguments): Use 'file
normalize' rather than the defunct DejaGnu 'absolute' proc.

and perhaps...


r235372 | clyon | 2016-04-22 15:28:58 -0400 (Fri, 22 Apr 2016) | 7 lines

[testsuite] gcc-dg: handle all return values when shouldfail is set

2016-04-22  Christophe Lyon  <christophe.l...@linaro.org>

* lib/gcc-dg.exp (${tool}_load): Add default return value handler.

for dejagnu 1.6 compatibility?

On Sat, Apr 23, 2016 at 11:20 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> The second release candidate for GCC 6.1 is available from
>
>  ftp://gcc.gnu.org/pub/gcc/snapshots/6.0.1-RC-20160423
>
> and shortly its mirrors.  It has been generated from SVN revision 235378.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux.  Please test it and report any issues to
> bugzilla.
>
> We have a P1 AIX bootstrap issue reported, but I haven't managed to
> reproduce it, so this release candidate does not deal with that.
>
> If all goes well, I'd like to release 6.1 next week.

[Bug c++/70770] constexpr expansion Internal compiler error

[mira.fontan at gmail dot com]

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

--- Comment #2 from Mira Fontan  ---
Created attachment 38333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38333=edit
preprocessed file

[Bug c++/70770] constexpr expansion Internal compiler error

[mira.fontan at gmail dot com]

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

--- Comment #1 from Mira Fontan  ---
Command line output:

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) 
COLLECT_GCC_OPTIONS='-D' 'DEBUG' '-D' 'RUN_UNITTEST' '-D' 'UNDER_LINUX' '-D'
'_GLIBCXX_USE_CXX11_ABI=0' '-I' '../.' '-I' '.' '-fno-common'
'-ffunction-sections' '-fdata-sections' '-fno-rtti' '-Wpedantic' '-pthread'
'-Wvariadic-macros' '-fsigned-char' '-Wabi' '-Wall' '-Warray-bounds'
'-Wbool-compare' '-Wcast-align' '-Wcomment' '-Wconversion'
'-Wdeprecated-declarations' '-Wdelete-incomplete' '-Wdisabled-optimization'
'-Wempty-body' '-Wenum-compare' '-Wextra' '-Wformat=1' '-Wformat-extra-args'
'-Wformat-security' '-Wformat-zero-length' '-Wchar-subscripts' '-Winit-self'
'-Wint-to-pointer-cast' '-Winvalid-pch' '-Wlogical-not-parentheses'
'-Wlogical-op' '-Wmissing-braces' '-Wmissing-field-initializers'
'-Wsuggest-attribute=noreturn' '-Wno-inline' '-Wno-long-long' '-Wnonnull'
'-Wodr' '-Woverflow' '-Wpacked' '-Wparentheses' '-Wpointer-arith'
'-Wredundant-decls' '-Wreturn-type' '-Wsequence-point' '-Wshadow'
'-Wshift-count-negative' '-Wshift-count-overflow' '-Wsign-compare'
'-Wsign-conversion' '-Wsizeof-array-argument' '-Wsizeof-pointer-memaccess'
'-Wstrict-aliasing' '-Wstrict-overflow' '-Wswitch' '-Wswitch-bool'
'-Wswitch-default' '-Wswitch-enum' '-Wtrigraphs' '-Wundef' '-Wuninitialized'
'-O0' '-Wunused-but-set-parameter' '-Wunused-but-set-variable'
'-Wunused-function' '-Wunused-label' '-Wunused-parameter' '-Wunused-value'
'-Wunused-variable' '-Wunknown-pragmas' '-Wwrite-strings' '-Wabi-tag'
'-Wcast-qual' '-Wdelete-non-virtual-dtor' '-Wdeprecated' '-Wnon-virtual-dtor'
'-Wold-style-cast' '-Woverloaded-virtual' '-Wreorder' '-Wsign-promo'
'-Wsuggest-final-methods' '-Wsuggest-final-types' '-Wunused-macros' '-ftrapv'
'-fno-omit-frame-pointer' '-fstack-protector' '-fstack-protector-all'
'-Wstack-protector' '-O0' '-fsanitize=address' '-Wno-exit-time-destructors'
'-Wno-global-constructors' '-Wno-format-nonliteral'
'-Wno-suggest-attribute=format' '-ansi' '-std=c++14' '-Werror' '-g' '-MMD'
'-MT' 'game/CMakeFiles/game.dir/ray.cpp.o' '-MF'
'game/CMakeFiles/game.dir/ray.cpp.o.d' '-o'
'game/CMakeFiles/game.dir/ray.cpp.o' '-c' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -I ../. -I . -imultiarch
x86_64-linux-gnu -MMD game/CMakeFiles/game.dir/ray.cpp.d -MF
game/CMakeFiles/game.dir/ray.cpp.o.d -MT game/CMakeFiles/game.dir/ray.cpp.o
-D_GNU_SOURCE -D_REENTRANT -D DEBUG -D RUN_UNITTEST -D UNDER_LINUX -D
_GLIBCXX_USE_CXX11_ABI=0 ../game/ray.cpp -mtune=generic -march=x86-64 -ansi
-std=c++14 -Wpedantic -Wvariadic-macros -Wabi -Wall -Warray-bounds
-Wbool-compare -Wcast-align -Wcomment -Wconversion -Wdeprecated-declarations
-Wdelete-incomplete -Wdisabled-optimization -Wempty-body -Wenum-compare -Wextra
-Wformat=1 -Wformat-extra-args -Wformat-security -Wformat-zero-length
-Wchar-subscripts -Winit-self -Wint-to-pointer-cast -Winvalid-pch
-Wlogical-not-parentheses -Wlogical-op -Wmissing-braces
-Wmissing-field-initializers -Wsuggest-attribute=noreturn -Wno-inline
-Wno-long-long -Wnonnull -Wodr -Woverflow -Wpacked -Wparentheses
-Wpointer-arith -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow
-Wshift-count-negative -Wshift-count-overflow -Wsign-compare -Wsign-conversion
-Wsizeof-array-argument -Wsizeof-pointer-memaccess -Wstrict-aliasing
-Wstrict-overflow -Wswitch -Wswitch-bool -Wswitch-default -Wswitch-enum
-Wtrigraphs -Wundef -Wuninitialized -Wunused-but-set-parameter
-Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter
-Wunused-value -Wunused-variable -Wunknown-pragmas -Wwrite-strings -Wabi-tag
-Wcast-qual 

[Bug c++/70770] New: constexpr expansion Internal compiler error

[mira.fontan at gmail dot com]

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

Bug ID: 70770
   Summary: constexpr expansion Internal compiler error
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mira.fontan at gmail dot com
  Target Milestone: ---

Command line:

/usr/bin/g++   -DDEBUG -DRUN_UNITTEST -DUNDER_LINUX -D_GLIBCXX_USE_CXX11_ABI=0
-I../. -I. -fno-common -ffunction-sections -fdata-sections -fno-rtti -pedantic
-pthread -Wvariadic-macros -fsigned-char -Wabi -Wabi-tag -Wall -Warray-bounds
-Wbool-compare -Wcast-align -Wcomment -Wconversion -Wdeprecated-declarations
-Wdelete-incomplete -Wdisabled-optimization -Wempty-body -Wenum-compare -Wextra
-Wformat -Wformat-extra-args -Wformat-security -Wformat-zero-length
-Wchar-subscripts -Winit-self -Wint-to-pointer-cast -Winvalid-pch
-Wlogical-not-parentheses -Wlogical-op -Wmissing-braces
-Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn
-Wno-inline -Wno-long-long -Wunknown-pragmas -Wnonnull -Wodr -Woverflow
-Wpacked -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type
-Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow
-Wsign-compare -Wsign-conversion -Wsizeof-array-argument
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-overflow -Wswitch
-Wswitch-bool -Wswitch-default -Wswitch-enum -Wtrigraphs -Wundef
-Wuninitialized -O0 -Wunused-but-set-parameter -Wunused-but-set-variable
-Wunused-function -Wunused-label -Wunused-parameter -Wunused-value
-Wunused-variable -Wunknown-pragmas -Wunreachable-code -Wwrite-strings
-Wabi-tag -Wcast-qual -Wdelete-non-virtual-dtor -Wdeprecated
-Wno-format-nonliteral -Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual
-Wreorder -Wsign-promo -Wsuggest-final-methods -Wsuggest-final-types
-Wunused-macros -ftrapv -fno-omit-frame-pointer  -fstack-protector
-fstack-protector-all -Wstack-protector -O0 -fsanitize=address
-Wno-exit-time-destructors -Wno-global-constructors -Wno-format-nonliteral
-Wno-missing-format-attribute -ansi -std=c++14  -Werror -g -MMD -MT
game/CMakeFiles/game.dir/ray.cpp.o -MF game/CMakeFiles/game.dir/ray.cpp.o.d -o
game/CMakeFiles/game.dir/ray.cpp.o -c ../game/ray.cpp -v -save-temps

[Bug c++/66256] noexcept evaluation done before end of class

[mmehlich at semanticdesigns dot com]

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

Michael Mehlich  changed:

   What|Removed |Added

 CC||mmehlich at semanticdesigns 
dot co
   ||m

--- Comment #1 from Michael Mehlich  ---
I agree, name resolution should consider all declarations in the class,
but apparently gcc does name resolution on the exception specification way too
early.

An example where this causes no error message being created for obviously wrong
code is the swap function in the pair template in the header file
bits/stl_pair.h (for gcc 5.3.0/cygwin), which is declared as
  void
  swap(pair& __p)
  noexcept(noexcept(swap(first, __p.first))
   && noexcept(swap(second, __p.second)))

clang 3.7.1. properly reports an error for the swap in the exception
specification.
BTW: The header file could be fixed easily by adding std:: in front of these
swap occurrences.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #41 from Jakub Jelinek  ---
(In reply to David Edelsohn from comment #40)
> I see that you did not have /opt/freeware/bin in your path on AIX. How did
> it even build without GNU Make and other build requirements?

I've used gmake -j64 instead of make -j64.
I can retry with PATH=/opt/freeware/bin:$PATH instead, sure.
Do you use relative or absolute path from the build dir to the source dir btw?
On my boxes I almost always create a subdir of the source dir and do
../configure ..., but on this box I've placed the build dir next to the source
dir and used absolute pathname.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

--- Comment #40 from David Edelsohn  ---
I see that you did not have /opt/freeware/bin in your path on AIX. How did it
even build without GNU Make and other build requirements?

Re: [wwwdocs] Reduce use of MetaHTML for navigation

[Gerald Pfeifer]

On Sun, 17 Apr 2016, Gerald Pfeifer wrote:
> When I initially created this in the early 2000s, CSS did barely 
> exist and was hardly used.  Now in 2016 it makes sense to use it
> fully (a first phase of conversation happened a few years ago)
> and reduce our dependency on MetaHTML even further.

After that change, we can now simplify things further.

Committed.

Gerald

Remove now obsolete nav-title-style and nav-body-style MetaHTML functions.

Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.129
diff -u -r1.129 style.mhtml
--- style.mhtml 21 Apr 2016 23:04:36 -  1.129
+++ style.mhtml 23 Apr 2016 16:13:06 -
@@ -3,8 +3,6 @@
 
 
 
- class="td_title" 
- class="td_con" 
 
 ;;; The "install/" pages are HTML, not XHTML.
 

[PING^2] Re: [PATCH 1/4] Add gcc-auto-profile script

[Andi Kleen]

Andi Kleen  writes:

Ping^2 for the patch series!

> Andi Kleen  writes:
>
> Ping for the patch series!
>
>> From: Andi Kleen 
>>
>> Using autofdo is currently something difficult. It requires using the
>> model specific branches taken event, which differs on different CPUs.
>> The example shown in the manual requires a special patched version of
>> perf that is non standard, and also will likely not work everywhere.
>>
>> This patch adds a new gcc-auto-profile script that figures out the
>> correct event and runs perf. The script is installed with on Linux systems.
>>
>> Since maintaining the script would be somewhat tedious (needs changes
>> every time a new CPU comes out) I auto generated it from the online
>> Intel event database. The script to do that is in contrib and can be
>> rerun.
>>
>> Right now there is no test if perf works in configure. This
>> would vary depending on the build and target system, and since
>> it currently doesn't work in virtualization and needs uptodate
>> kernel it may often fail in common distribution build setups.
>>
>> So Linux just hardcodes installing the script, but it may fail at runtime.
>>
>> This is needed to actually make use of autofdo in a generic way
>> in the build system and in the test suite.
>>
>> So far the script is not installed.
>>
>> gcc/:
>> 2016-03-27  Andi Kleen  
>>
>>  * doc/invoke.texi: Document gcc-auto-profile
>>  * gcc-auto-profile: Create.
>>
>> contrib/:
>>
>> 2016-03-27  Andi Kleen  
>>
>>  * gen_autofdo_event.py: New file to regenerate
>>  gcc-auto-profile.
>> ---
>>  contrib/gen_autofdo_event.py | 155 
>> +++
>>  gcc/doc/invoke.texi  |  31 +++--
>>  gcc/gcc-auto-profile |  70 +++
>>  3 files changed, 251 insertions(+), 5 deletions(-)
>>  create mode 100755 contrib/gen_autofdo_event.py
>>  create mode 100755 gcc/gcc-auto-profile
>>
>> diff --git a/contrib/gen_autofdo_event.py b/contrib/gen_autofdo_event.py
>> new file mode 100755
>> index 000..db4db33
>> --- /dev/null
>> +++ b/contrib/gen_autofdo_event.py
>> @@ -0,0 +1,155 @@
>> +#!/usr/bin/python
>> +# generate Intel taken branches Linux perf event script for autofdo 
>> profiling
>> +
>> +# Copyright (C) 2016 Free Software Foundation, Inc.
>> +#
>> +# GCC is free software; you can redistribute it and/or modify it under
>> +# the terms of the GNU General Public License as published by the Free
>> +# Software Foundation; either version 3, or (at your option) any later
>> +# version.
>> +#
>> +# GCC is distributed in the hope that it will be useful, but WITHOUT ANY
>> +# WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> +# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> +# for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with GCC; see the file COPYING3.  If not see
>> +# .  */
>> +
>> +# run it with perf record -b -e EVENT program ...
>> +# The Linux Kernel needs to support the PMU of the current CPU, and
>> +# it will likely not work in VMs.
>> +# add --all to print for all cpus, otherwise for current cpu
>> +# add --script to generate shell script to run correct event
>> +#
>> +# requires internet (https) access. this may require setting up a proxy
>> +# with export https_proxy=...
>> +#
>> +import urllib2
>> +import sys
>> +import json
>> +import argparse
>> +import collections
>> +
>> +baseurl = "https://download.01.org/perfmon;
>> +
>> +target_events = (u'BR_INST_RETIRED.NEAR_TAKEN',
>> + u'BR_INST_EXEC.TAKEN',
>> + u'BR_INST_RETIRED.TAKEN_JCC',
>> + u'BR_INST_TYPE_RETIRED.COND_TAKEN')
>> +
>> +ap = argparse.ArgumentParser()
>> +ap.add_argument('--all', '-a', help='Print for all CPUs', 
>> action='store_true')
>> +ap.add_argument('--script', help='Generate shell script', 
>> action='store_true')
>> +args = ap.parse_args()
>> +
>> +eventmap = collections.defaultdict(list)
>> +
>> +def get_cpu_str():
>> +with open('/proc/cpuinfo', 'r') as c:
>> +vendor, fam, model = None, None, None
>> +for j in c:
>> +n = j.split()
>> +if n[0] == 'vendor_id':
>> +vendor = n[2]
>> +elif n[0] == 'model' and n[1] == ':':
>> +model = int(n[2])
>> +elif n[0] == 'cpu' and n[1] == 'family':
>> +fam = int(n[3])
>> +if vendor and fam and model:
>> +return "%s-%d-%X" % (vendor, fam, model), model
>> +return None, None
>> +
>> +def find_event(eventurl, model):
>> +print >>sys.stderr, "Downloading", eventurl
>> +u = urllib2.urlopen(eventurl)
>> +events = json.loads(u.read())
>> +u.close()
>> +
>> +found = 0
>> +for j in events:
>> +if j[u'EventName'] in 

[wwwdocs] Buildstat update for 4.8

[Tom G. Christensen]

Latest results for 4.8.x

-tgc

Testresults for 4.8.5:
  hppa1.1-hp-hpux11.11
  powerpc64le-unknown-linux-gnu
  s390x-ibm-linux-gnu (3)

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving revision 1.15
diff -u -r1.15 buildstat.html
--- buildstat.html  1 Oct 2015 06:21:15 -   1.15
+++ buildstat.html  23 Apr 2016 15:44:14 -
@@ -59,6 +59,14 @@
 
 
 
+hppa1.1-hp-hpux11.11
+
+Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02725.html;>4.8.5
+
+
+
+
 hppa2.0w-hp-hpux11.00
 
 Test results:
@@ -216,6 +224,7 @@
 powerpc64le-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00640.html;>4.8.5,
 https://gcc.gnu.org/ml/gcc-testresults/2015-06/msg02566.html;>4.8.5
 
 
@@ -235,6 +244,9 @@
 s390x-ibm-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01584.html;>4.8.5,
+https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01575.html;>4.8.5,
+https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01570.html;>4.8.5,
 https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00493.html;>4.8.5,
 https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00485.html;>4.8.5,
 https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00473.html;>4.8.5

[Bug target/69143] PowerPC64: aggregate results are badly handled

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Similar to PR 28831, PR 23782?

[wwwdocs] Buildstat update for 5.x

[Tom G. Christensen]

Latest results for 5.x

-tgc

Testresults for 5.3.0:
  armv7l-unknown-linux-gnueabi
  arm-unknown-linux-gnueabi
  hppa-unknown-linux-gnu
  mips-unknown-linux-gnu
  mipsel-unknown-linux-gnu
  powerpc-unknown-linux-gnu
  sparc-sun-solaris2.10
  sparc64-sun-solaris2.10
  sparc-unknown-linux-gnu
  x86_64-unknown-linux-gnu (2)

Testresults for 5.2.0:
  arm-unknown-linux-gnueabi
  hppa-unknown-linux-gnu
  mips-unknown-linux-gnu
  mipsel-unknown-linux-gnu
  powerpc64-unknown-linux-gnu
  sparc-unknown-linux-gnu

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/buildstat.html,v
retrieving revision 1.6
diff -u -r1.6 buildstat.html
--- buildstat.html  6 Jan 2016 15:48:52 -   1.6
+++ buildstat.html  23 Apr 2016 15:25:04 -
@@ -31,9 +31,19 @@
 
 
 
+armv7l-unknown-linux-gnueabi
+
+Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2016-02/msg00279.html;>5.3.0
+
+
+
+
 arm-unknown-linux-gnueabi
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01344.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00378.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg00965.html;>5.1.0
 
 
@@ -42,6 +52,8 @@
 hppa-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02075.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg01144.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg00763.html;>5.1.0
 
 
@@ -91,6 +103,8 @@
 mips-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01134.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg01303.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg01101.html;>5.1.0
 
 
@@ -99,6 +113,8 @@
 mipsel-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01133.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg01145.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg01480.html;>5.1.0
 
 
@@ -123,7 +139,8 @@
 powerpc64-unknown-linux-gnu
 
 Test results:
-https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02803.html;>5.3.0
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02803.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg01557.html;>5.2.0
 
 
 
@@ -139,6 +156,7 @@
 powerpc-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02465.html;>5.3.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00261.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg01751.html;>5.1.0
 
@@ -148,6 +166,7 @@
 sparc-sun-solaris2.10
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01463.html;>5.3.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg01141.html;>5.2.0
 
 
@@ -164,6 +183,7 @@
 sparc64-sun-solaris2.10
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01462.html;>5.3.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg01142.html;>5.2.0
 
 
@@ -172,6 +192,8 @@
 sparc-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01345.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00560.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-05/msg00966.html;>5.1.0
 
 
@@ -196,6 +218,8 @@
 x86_64-unknown-linux-gnu
 
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01427.html;>5.3.0,
+https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg00587.html;>5.3.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00628.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-08/msg02501.html;>5.2.0,
 https://gcc.gnu.org/ml/gcc-testresults/2015-08/msg01782.html;>5.2.0,

Second GCC 6.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

The second release candidate for GCC 6.1 is available from

 ftp://gcc.gnu.org/pub/gcc/snapshots/6.0.1-RC-20160423

and shortly its mirrors.  It has been generated from SVN revision 235378.

I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux.  Please test it and report any issues to
bugzilla.

We have a P1 AIX bootstrap issue reported, but I haven't managed to
reproduce it, so this release candidate does not deal with that.

If all goes well, I'd like to release 6.1 next week.

Re: [RFC][PATCH][PR40921] Convert x + (-y * z * z) into x - y * z * z

[kugan]

I am not sure I understand this. I tried doing this. If I add  -1 and rhs1
for the NEGATE_EXPR to ops list,  when it come to rewrite_expr_tree constant
will be sorted early and would make it hard to generate:
  x + (-y * z * z) => x - y * z * z

Do you want to swap the constant in MULT_EXPR chain (if present) like in
swap_ops_for_binary_stmt and then create a NEGATE_EXPR ?


In addition to linearize_expr handling you need to handle a -1 in the MULT_EXPR
chain specially at rewrite_expr_tree time by emitting a NEGATE_EXPR instead
of a MULT_EXPR (which also means you should sort the -1 "last").


Hi Richard,

Thanks. Here is an attempt which does this.

Regression tested and bootstrapped on x86-64-linux-gnu with no new 
regressions.


Is this OK for trunk?

Thanks,
Kugan

2016-04-23  Kugan Vivekanandarajah  

PR middle-end/40921
* gcc.dg/tree-ssa/pr40921.c: New test.

gcc/ChangeLog:

2016-04-23  Kugan Vivekanandarajah  

PR middle-end/40921
* tree-ssa-reassoc.c (try_special_add_to_ops): New.
(linearize_expr_tree): Call try_special_add_to_ops.
(reassociate_bb): Convert MULT_EXPR by (-1) to NEGATE_EXPR.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c
index e69de29..f587a8f 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c
@@ -0,0 +1,20 @@
+
+/* { dg-do compile } */
+/* { dg-options "-O2  -fdump-tree-optimized -ffast-math" } */
+
+unsigned int foo (unsigned int x, unsigned int y, unsigned int z)
+{
+  return x + (-y * z*z);
+}
+
+float bar (float x, float y, float z)
+{
+  return x + (-y * z*z);
+}
+
+float bar (float x, float y, float z)
+{
+  return x + (-y * z*z * 5.0);
+}
+
+/* { dg-final { scan-tree-dump-times "_* = -y_" 0 "optimized" } } */
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index d23dabd..1b38207 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -4252,6 +4252,45 @@ acceptable_pow_call (gimple *stmt, tree *base, 
HOST_WIDE_INT *exponent)
   return true;
 }
 
+/* Try to derive and add operand entry for OP to *OPS.  Return false if
+   unsuccessful.  */
+
+static bool
+try_special_add_to_ops (vec *ops,
+   enum tree_code code,
+   tree op, gimple* def_stmt)
+{
+  tree base = NULL_TREE;
+  HOST_WIDE_INT exponent = 0;
+
+  if (TREE_CODE (op) != SSA_NAME)
+return false;
+
+  if (code == MULT_EXPR
+  && acceptable_pow_call (def_stmt, , ))
+{
+  add_repeat_to_ops_vec (ops, base, exponent);
+  gimple_set_visited (def_stmt, true);
+  return true;
+}
+  else if (code == MULT_EXPR
+  && is_gimple_assign (def_stmt)
+  && gimple_assign_rhs_code (def_stmt) == NEGATE_EXPR
+  && !HONOR_SNANS (TREE_TYPE (op))
+  && (!HONOR_SIGNED_ZEROS (TREE_TYPE (op))
+  || !COMPLEX_FLOAT_TYPE_P (TREE_TYPE (op
+{
+  tree rhs1 = gimple_assign_rhs1 (def_stmt);
+  tree cst = build_minus_one_cst (TREE_TYPE (op));
+  add_to_ops_vec (ops, rhs1);
+  add_to_ops_vec (ops, cst);
+  gimple_set_visited (def_stmt, true);
+  return true;
+}
+
+  return false;
+}
+
 /* Recursively linearize a binary expression that is the RHS of STMT.
Place the operands of the expression tree in the vector named OPS.  */
 
@@ -4266,8 +4305,6 @@ linearize_expr_tree (vec *ops, gimple 
*stmt,
   bool binrhsisreassoc = false;
   enum tree_code rhscode = gimple_assign_rhs_code (stmt);
   struct loop *loop = loop_containing_stmt (stmt);
-  tree base = NULL_TREE;
-  HOST_WIDE_INT exponent = 0;
 
   if (set_visited)
 gimple_set_visited (stmt, true);
@@ -4303,26 +4340,11 @@ linearize_expr_tree (vec *ops, gimple 
*stmt,
 
   if (!binrhsisreassoc)
{
- if (rhscode == MULT_EXPR
- && TREE_CODE (binrhs) == SSA_NAME
- && acceptable_pow_call (binrhsdef, , ))
-   {
- add_repeat_to_ops_vec (ops, base, exponent);
- gimple_set_visited (binrhsdef, true);
-   }
- else
+ if (!try_special_add_to_ops (ops, rhscode, binrhs, binrhsdef))
add_to_ops_vec (ops, binrhs);
 
- if (rhscode == MULT_EXPR
- && TREE_CODE (binlhs) == SSA_NAME
- && acceptable_pow_call (binlhsdef, , ))
-   {
- add_repeat_to_ops_vec (ops, base, exponent);
- gimple_set_visited (binlhsdef, true);
-   }
- else
+ if (!try_special_add_to_ops (ops, rhscode, binlhs, binlhsdef))
add_to_ops_vec (ops, binlhs);
-
  return;
}
 
@@ -4360,14 +4382,7 @@ linearize_expr_tree (vec *ops, gimple 
*stmt,
   linearize_expr_tree (ops, SSA_NAME_DEF_STMT (binlhs),
   is_associative, set_visited);
 
-  if (rhscode == MULT_EXPR
-  && TREE_CODE (binrhs) == SSA_NAME
-  && acceptable_pow_call (SSA_NAME_DEF_STMT 

[Bug ada/70759] Ada rts fails to build with -mabi=ilp32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
internal_reference_types probably needs to go away.

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #39 from Jakub Jelinek  ---
(In reply to David Edelsohn from comment #38)
> The gt* files don't differ.
> 
> I normally use
> 
> --disable-werror --enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm
> --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
> --with-included-gettext --enable-checking=release

Used
/home/jakub/gcc-6.0.1-RC-20160415/configure --disable-werror
--enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm
--with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
--with-included-gettext --enable-checking=release
myself now (inside of /home/jakub/rc1/) and it bootstrapped just fine too.

Re: internal_reference_types

[Eric Botcazou]

> The function internal_reference_types appears to have been introduced
> exclusively for the Ada frontend.  It is responsible for PR70759 (ada
> rts doesn't build with -mabi=ilp32).  What purpose does it serve and
> what breaks when it is removed?  The history doesn't give any hints.

Not clear to me either and the premise is probably wrong for Ada these days.

-- 
Eric Botcazou

Re: [patch] removing aged ifdef 0 from boehm-gc/os_dep.c

[Joseph Myers]

On Wed, 13 Apr 2016, g...@glenstark.net wrote:

> This is my first effort at contributing to gcc, so I thought I would try
> with some of the easy stuff listed here:
> https://gcc.gnu.org/projects/beginner.html
> 
> Attached is a patch removing a block which has been #if 0'd out since
> 2006.  I tested the build afterward.
> 
> I look forward to your feedback.

As boehm-gc is an externally maintained project (see "Upstream packages" 
at ), such cleanups should be 
done upstream only, and get into GCC through merges from the upstream 
version.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug c++/70769] New: function definition wrongfully allowed inside comma separated member declaration list

[fourmisain+gcc at gmail dot com]

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

Bug ID: 70769
   Summary: function definition wrongfully allowed inside comma
separated member declaration list
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fourmisain+gcc at gmail dot com
  Target Milestone: ---

This code should not compile while it does:

class C {
  int n, f(int) {
return 42;
  }
};

To break it down (using C++14 standard draft n4140), the only
member-declaration (§9.2) which declares multiple members at once is of the
form
  attribute-specifier-seq(opt) decl-specifier-seq(opt)
member-declarator-list(opt);

Note that in the above code, the required semicolon at the end is missing, so
this is already in violation of the standard, but the code still compiles
without even a warning (using -std=c++14 -Wall -pedantic) if you add that
missing semicolon.

So continuing the argument, "int n, f(int) {return 42;}" would have to be a
member-declarator-list, so "f(int){return 42;}" would have to be a
member-declarator and since it does not contain a colon it is one of the two:
  declarator virt-specifier-seq(opt) pure-specifier(opt)
  declarator brace-or-equal-initializer(opt)
Since "{return 42;}" is not a valid brace-or-equal-initializer, "f(int){return
42;}" has to be a declarator.

Afaik, this is not true and it also conflicts with the following:
If it were a declarator, you would be allowed to use it inside a
init-declarator-list, therefore the following code would have to compile:

int n, f(int) {
  return 42;
}

But it (rightfully) does not:
"error: a function-definition is not allowed here before '{' token"

So this error message needs to be applied to the above class case.


I was made aware that the above "hack" is often used on CodeFights to save
precious characters. They seems to wrap code into a class and compile it with
g++ 5.0.

Re: split_live_ranges_for_shrink_wrap and !SHRINK_WRAPPING_ENABLED?

[Denis Chertykov]

2016-04-18 11:53 GMT+03:00 Senthil Kumar Selvaraj
:
> Hi,
>
>   While tracking down a performance regression for the AVR target from
>   4.9.x to trunk, I noticed that failing the SHRINK_WRAPPING_ENABLED
>   check in ira.c led to noticeably worse code for the following
>   case. That check prevents live range splitting of pseudos containing
>   formal args, and between 4.9.x and now, the check was modified from
>   just flag_shrink_wrap to now flag_shrink_wrap && targetm.have_simple_return.
>
> #include 
>
> extern int bar(uint32_t, uint16_t);
> extern int baz(void);
>
> int foo(uint8_t x, uint32_t y, uint16_t z)
> {
>uint8_t status;
>switch(x)
>{
>   case 0:
> status = bar(y, z);
> if (status == 0)
>status = baz();
> break;01
>
>}
>return status;
> }
>
> If the live range splitting of pseudos containing formal args is not
> done in IRA, then reload uses callee-saved registers (SI r12), resulting in
> extra saves and restores in the prologue/epilogue.
>
> 
> (insn 3 2 5 2 (set (reg/v:SI 12 r12 [orig:47 y ] [47])
> (reg:SI 20 r20 [ y ])) ../ctrl_access.c:7 95 {*movsi}
>  (nil))
> (note 5 3 8 2 NOTE_INSN_FUNCTION_BEG)
> (insn 8 5 9 2 (set (cc0)
> (compare (reg:QI 24 r24 [ x ])
> (const_int 0 [0]))) ../ctrl_access.c:9 404 {*cmpqi}
>  (nil))
> (jump_insn 9 8 13 2 (set (pc)
> (if_then_else (ne (cc0)
> (const_int 0 [0]))
> (label_ref:HI 25)
> (pc))) ../ctrl_access.c:9 428 {branch}
>  (int_list:REG_BR_PROB 6102 (nil))
>  -> 25)
> (note 13 9 14 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
> (insn 14 13 15 3 (set (reg:HI 20 r20)
> (reg/v:HI 18 r18 [orig:48 z ] [48])) ../ctrl_access.c:12 83 {*movhi}
>  (nil))
> (insn 15 14 16 3 (set (reg:SI 22 r22)
> (reg/v:SI 12 r12 [orig:47 y ] [47])) ../ctrl_access.c:12 95 {*movsi}
>  (nil))
> 
>
> leading to code like
> 
> push r12
> push r13
> push r14
> push r15
> /* prologue: function */
> /* frame size = 0 */
> /* stack size = 4 */
> .L__stack_usage = 4
> movw r12,r20
> movw r14,r22
> cpse r24,__zero_reg__
> rjmp .L2
> movw r20,r18
> movw r24,r14
> movw r22,r12
> call bar
> 
>
> Whereas in 4.9.2, live range splitting allows reload to generate far
> better RTL, like so
>
> 
> (insn 8 5 9 2 (set (cc0)
> (compare (reg:QI 24 r24 [ x ])
> (const_int 0 [0]))) ../ctrl_access.c:9 404 {*cmpqi}
>  (nil))
> (jump_insn 9 8 13 2 (set (pc)
> (if_then_else (ne (cc0)
> (const_int 0 [0]))
> (label_ref:HI 25)
> (pc))) ../ctrl_access.c:9 428 {branch}
>  (int_list:REG_BR_PROB 6102 (nil))
>  -> 25)
> (note 13 9 42 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
> (insn 42 13 14 3 (set (reg/v:SI 22 r22 [orig:48 y ] [48])
> (reg/v:SI 20 r20 [orig:48 y ] [48])) 95 {*movsi}
>  (nil))
> (insn 14 42 16 3 (set (reg:HI 20 r20)
> (reg/v:HI 18 r18 [orig:49 z ] [49])) ../ctrl_access.c:12 83 {*movhi}
>  (nil))
> 
>
> leading to code like
> 
> cpse r24,__zero_reg__
> rjmp .L2
> movw r24,r22
> movw r22,r20
> movw r20,r18
> call bar
> 
>
> In either case, shrink wrapping isn't done in the end, but the live
> range splitting ends up helping reload, AFAICT.
>
> I verified that adding simple_return pattern to avr.md fixes the
> regression, but the code size increase if shrink wrapping
> really does happen would badly hurt a flash constrained target like the
> AVR. I also noticed that targets like sh and arm (for thumb) disable it when
> optimizing for size (using the condition part in simple_return pattern)
> - understandable.
>
> What do you guys think is the right way to deal with this? Should I look
> into why range splitting helps reload and have reload itself handle this?

It's a place for experiments.
Generally, live range splitting must be very useful for targets with
constrained register classes and for targets with small amount of
registers.

Denis.

New hashtable power 2 rehash policy

[François Dumont]

Hi

Here is a patch to introduce a new power of 2 based rehash policy. 
It enhances performance as it avoids modulo float operations. I have 
updated performance benches and here is the result:


54075.cctr1 benches 455r  446u8s
0mem0pf
54075.ccstd benches 466r  460u6s
0mem0pf
54075.ccstd2 benches 375r  369u6s
0mem0pf


std2 benches is the one using power of 2 bucket count.

Note that I made use of __detected_or_t to avoid duplicating all 
the code of _Rehash_base<>.


It brings a simplification of _Insert<>, it doesn't take a 
_Unique_keys template parameter anymore. It allowed to remove a 
specialization.


It also improve behavior when we reach maximum number of buckets, 
we won't keep on trying to increase the number as it is impossible.


Last it fixes a small problem in 54075.cc bench. We were using 
__uset_traits rather than __umset_traits in definition of __umset. 
Results were not the expected ones.


2016-04-22  François Dumont 

* include/bits/hashtable_policy.h
(_Prime_rehash_policy::__has_load_factor): New. Mark rehash policy
having load factor management.
(_Mask_range_hashing): New.
(_NextPower2): New.
(_Power2_rehash_policy): New.
(_Inserts<>): Remove last template parameter _Unique_keys. Use the same
implementation when keys are unique no matter if iterators are constant
or not.
* src/c++11/hashable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt):
Consider when last prime number has been reach.
* testsuite/23_containers/unordered_set/hash_policy/power2_rehash.cc:
New.
* testsuite/performance/23_containers/insert/54075.cc: Add bench using
the new hash policy.
* testsuite/performance/23_containers/insert_erase/41975.cc: Likewise.

Tested under linux x64_86, ok to commit ?

François


Index: include/bits/hashtable_policy.h
===
--- include/bits/hashtable_policy.h	(révision 235348)
+++ include/bits/hashtable_policy.h	(copie de travail)
@@ -457,6 +457,8 @@
   /// smallest prime that keeps the load factor small enough.
   struct _Prime_rehash_policy
   {
+using __has_load_factor = std::true_type;
+
 _Prime_rehash_policy(float __z = 1.0) noexcept
 : _M_max_load_factor(__z), _M_next_resize(0) { }
 
@@ -501,6 +503,136 @@
 mutable std::size_t	_M_next_resize;
   };
 
+  /// Range hashing function assuming that second args is a power of 2.
+  struct _Mask_range_hashing
+  {
+typedef std::size_t first_argument_type;
+typedef std::size_t second_argument_type;
+typedef std::size_t result_type;
+
+result_type
+operator()(first_argument_type __num,
+	   second_argument_type __den) const noexcept
+{ return __num & (__den - 1); }
+  };
+
+
+  /// Helper type to compute next power of 2.
+  template
+struct _NextPower2
+{
+  static _SizeT
+  _Get(_SizeT __n)
+  {
+	_SizeT __next = _NextPower2<_SizeT, (_N >> 1), false>::_Get(__n);
+	__next |= __next >> _N;
+	if (_Increment)
+	  ++__next;
+
+	return __next;
+  }
+};
+
+  template
+struct _NextPower2<_SizeT, 1, false>
+{
+  static _SizeT
+  _Get(_SizeT __n)
+  {
+	--__n;
+	return __n |= __n >> 1;
+  }
+};
+
+  /// Rehash policy providing power of 2 bucket numbers. Ease modulo
+  /// operations.
+  struct _Power2_rehash_policy
+  {
+using __has_load_factor = std::true_type;
+
+_Power2_rehash_policy(float __z = 1.0) noexcept
+: _M_max_load_factor(__z), _M_next_resize(0) { }
+
+float
+max_load_factor() const noexcept
+{ return _M_max_load_factor; }
+
+// Return a bucket size no smaller than n (as long as n is not above the
+// highest power of 2).
+std::size_t
+_M_next_bkt(std::size_t __n) const
+{
+  constexpr auto __max_bkt
+	= std::size_t(1) << ((sizeof(std::size_t) << 3) - 1);
+
+  std::size_t __res = _NextPower2::_Get(__n);
+
+  if (__res == 0)
+	__res = __max_bkt;
+
+  if (__res == __max_bkt)
+	// Set next resize to the max value so that we never try to rehash again
+	// as we already reach the biggest possible bucket number.
+	// Note that it might result in max_load_factor not being respected.
+	_M_next_resize = std::size_t(0) - 1;
+  else
+	_M_next_resize
+	  = __builtin_floor(__res * (long double)_M_max_load_factor);
+
+  return __res;
+}
+
+// Return a bucket count appropriate for n elements
+std::size_t
+_M_bkt_for_elements(std::size_t __n) const
+{ return __builtin_ceil(__n / (long double)_M_max_load_factor); }
+
+// __n_bkt is current bucket count, __n_elt is current element count,
+// and __n_ins is number of elements to be inserted.  Do we need to
+// increase bucket count?  If so, return make_pair(true, n), where n
+// is the new bucket count.  If not, return 

[Bug c++/70767] std::numeric_limits::digits is wrong unless --std=c++11 used

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559
It has status CD1, I don't remember if that means it applies retroactively or
not.
(by the way, the 4.8 branch is not maintained anymore)

[Bug c++/70768] Increased compilation time

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
(In reply to James Almer from comment #0)
> Created attachment 38332 [details]
> Preprocessed output
> 
> The attached preprocessed output (Created from the source using GCC 5, 6 and
> 7 for the purpose of this ticket) takes almost twice as long to compile
> using GCC 6.0.1 RC and especially GCC 7.0 compared to GCC 5.3 on a linux
> x86_64 machine with 2gb of RAM.
> 
> GCC 5.3 performed the best for all three preprocessed files.
> GCC 6.0.1 performed about the same as GCC 5.3 using the gcc5 preprocessed
> file. It however trashed my HDD a lot trying to compile the preprocessed
> output from both GCC 6 and GCC 7, and took longer to finish them. This may
> hint at increased RAM usage and explain the odd time values, but i didn't
> check.
> GCC 7 performed the worst across the table, even with the gcc5 preprocessed
> file.

Well, you simply need more RAM to compile this testcase, because gcc-6 uses
slightly over 2GB peak, so your machine starts swapping.
On my machine (with 8GB RAM) gcc-6 is actually slightly faster.

(For gcc-7 you need to configure it with --enable-checking=release to compare
timings.)