[Bug ada/68345] New: gnat build broken on dragonfly due to omission of r229342

2015-11-14 Thread gnugcc at marino dot st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

Bug ID: 68345
   Summary: gnat build broken on dragonfly due to omission of
r229342
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

Due to waiting on big locale patch, I haven't been testing gcc regularly.  I
just did today and gnat files to build on dragonfly:

s-taprop.adb:326:32: ambiguous operand in conversion
s-taprop.adb:326:32: possible interpretation at s-osinte.ads:333
s-taprop.adb:326:32: possible interpretation at s-osinte.ads:334
s-taprop.adb:981:52: ambiguous operand in conversion
s-taprop.adb:981:52: possible interpretation at s-osinte.ads:333
s-taprop.adb:981:52: possible interpretation at s-osinte.ads:334
../gcc-interface/Makefile:311: recipe for target 's-taprop.o' failed
gmake[8]: *** [s-taprop.o] Error 1


the reason is that Get_Page_Size was changed to return an int, and this was
done for a number of systems except dragonfly:

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=229342

The same change done on s-osinte-freebsd.ads by r229342 needs to be done on
s-osinte-dragonfly.ads

DragonFly is an officially (and well) supported system on GCC!  It should not
be omitted like this.

[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342

2015-11-14 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

Arnaud Charlet  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org

--- Comment #1 from Arnaud Charlet  ---
Can you please submit a patch on gcc-patches@ ?

[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342

2015-11-14 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

--- Comment #2 from Arnaud Charlet  ---
Author: charlet
Date: Sat Nov 14 09:09:01 2015
New Revision: 230373

URL: https://gcc.gnu.org/viewcvs?rev=230373&root=gcc&view=rev
Log:
2015-11-13  Arnaud Charlet  

PR ada/68345
* s-osinte-dragonfly.ads (Get_Page_Size): C function returns an int.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/s-osinte-dragonfly.ads

[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342

2015-11-14 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Arnaud Charlet  ---
I applied a change blindly, let me know how it goes.

Arno

[Bug bootstrap/68346] New: [6 Regression] Bootstrap failure on i686-linux

2015-11-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346

Bug ID: 68346
   Summary: [6 Regression] Bootstrap failure on i686-linux
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Most likely since the c++ delayed folding merge, but I admit I've bootstrapped
trunk on i686-linux 8 days ago, so the window is larger, trunk no longer
bootstraps on i686-linux:
../../gcc/gimple-fold.c: In function ‘bool
gimple_fold_builtin_printf(gimple_stmt_iterator*, tree, tree,
built_in_function)’:
../../gcc/gimple-fold.c:2621:30: error: self-comparison always evaluates to
true [-Werror=tautological-compare]
&& (size_t) (int) len == len
  ^~
This code is not new in there, but supposedly before that we either have not
been folding the arguments for -Wtautological-compare, or not so aggressively.
I'd say it is quite common idiom to cast a variable to some other type and
compare to itself, with the intent that if the type is the same, it is a no-op
check, but if the type is narrower or has different signedness, it filters out
some undesirable values.

[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux

2015-11-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux

2015-11-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346

--- Comment #1 from Jakub Jelinek  ---
Note one even can't work around this warning through say:
&& (sizeof (int) >= sizeof (size_t) ? 1 : (size_t) (int) len == len)

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

2015-11-14 Thread anthony.brandon at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

--- Comment #27 from Anthony Brandon  ---
Created attachment 36706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36706&action=edit
First version of patch for PR19808

This is the current version of my patch.
It still needs some work.
The Wuninitialized part should be combined with the Winit_self part,
and it should be made to detect multiple uninitialized values in a single
initializer.

[Bug libfortran/68347] New: Multiple build errors in libgfortran

2015-11-14 Thread alexey.a.rychkov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

Bug ID: 68347
   Summary: Multiple build errors in libgfortran
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexey.a.rychkov at gmail dot com
  Target Milestone: ---

There are multiple bogus symbols in files (stray \33, etc):

libgfortran/kinds.h
libgfortran/kinds.inc
libgfortran/fpu-target.inc
libgfortran/c99_protos.inc

which lead to multiple compilation errors.

The gcc source code was downloaded from
ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-5.2.0/gcc-5.2.0.tar.bz2

[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342

2015-11-14 Thread gnugcc at marino dot st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345

--- Comment #4 from John Marino  ---
Hi Arno,

I made the same exact change internally.  It built and the full testsuite was
run afterwards:


=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-test-dragonfly4.3

=== g++ tests ===

Running target unix

=== gnat Summary ===

# of expected passes2467
# of expected failures  21
# of unsupported tests  5
/build/home/marino-huge/gcc-test-area/build/gcc/gnatmake version 6.0.0 20151114
(experimental)

=== objc tests ===


I think it would be okay to just "blindly" make the same changes to DragonFly
that you do for FreeBSD in the future.  It will almost always be the correct
thing, and if it isn't I'll still catch it with regular build checks.

Thanks for the quick fix,
john

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

2015-11-14 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

--- Comment #28 from Manuel López-Ibáñez  ---
Hi Anthony, adding testcases to the patch will help clarify what is working and
what you expect to work but it isn't:
https://gcc.gnu.org/wiki/HowToPrepareATestcase

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-14
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> There are multiple bogus symbols in files (stray \33, etc):
>
> libgfortran/kinds.h
> libgfortran/kinds.inc
> libgfortran/fpu-target.inc
> libgfortran/c99_protos.inc
>
> which lead to multiple compilation errors.

AFAICT these files are generated during bootstrap. On which platform do you see
this? Can you give some examples of the faulty lines? Have you ever
successfully bootstrapped 5.2?

grep "\x33" ../5_build/x86_64-apple-darwin14.5.0/libgfortran/*

does not return anything on x86_64-apple-darwin14 for gcc version 5.2.1
revision r230040 (or trunk 6.0).

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread alexey.a.rychkov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #2 from Alexey Rychkov  ---
#define GFC_REAL_4_HUGE   ^[[01;31m^[[K^[[m^[[K 3.40282347e38f
#define GFC_REAL_4_LITERAL_SUFFIX f
#define GFC_REAL_4_LITERAL(X) (X ## f)
#define GFC_REAL_4_DIGITS   ^[[01;31m^[[K^[[m^[[K 24
#define GFC_REAL_4_RADIX   ^[[01;31m^[[K^[[m^[[K 2

^[[01;31m^[[K#^[[m^[[Kifndef C99_PROTOS_H
^[[01;31m^[[K#^[[m^[[Kdefine C99_PROTOS_H 1
^[[01;31m^[[K#^[[m^[[Kifndef HAVE_ACOSF
^[[01;31m^[[K#^[[m^[[Kdefine HAVE_ACOSF 1
^[[01;31m^[[K#^[[m^[[Kendif

The system is CentOS release 6.7

I did just this:

cd gcc-5.2.0
mkdir build && cd build
../configure --disable-multilib
make

I'm not sure if this can affect something, but I was using tmux on top of ssh
session...

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #3 from Dominique d'Humieres  ---
> I'm not sure if this can affect something, but I was using tmux on top
> of ssh session...

Can you try again without tmx? I am not that familiar with sequences such as
"^[[01;31m^[[K^[[m^[[K", but I associate them to output "styles" to the
terminal.

The file kind.h is generated by

/bin/sh ../../../work/libgfortran/mk-kinds-h.sh
'/opt/gcc/build_w/./gcc/gfortran -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem
/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem
/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include-I . -Wall -Werror
-fimplicit-none -fno-repack-arrays -fno-underscoring  -g -O2' > kinds.h || rm
kinds.h

where /opt/gcc/build_w , /opt/gcc/work, and /opt/gcc/gcc6w are respectively my
build, source, and install directories.

What is the output of

/bin/sh /opt/gcc/work/libgfortran/mk-kinds-h.sh '/opt/gcc/build_w/gcc/gfortran
-B/opt/gcc/build_w/gcc/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ 
-I/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libgfortran -Wall -Werror
-fimplicit-none -fno-repack-arrays -fno-underscoring  -g -O2'

(with suitable replacements of /opt/gcc/work/ and /opt/gcc/build_w).

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #4 from Andreas Schwab  ---
Did you set GREP_OPTIONS?

[Bug fortran/61450] ICE in gfc_global_used()

2015-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61450

--- Comment #1 from Dominique d'Humieres  ---
With the updated patch below the ICE is now replaced with

pr61450.f90:6:15:

   integer i1
2   
   bind(c,name="foo") :: i1

 end module



 subroutine truc() bind(c,name="foo")
   1

Error: Global binding name 'foo' at (1) is already being used at (2)

Any reason why the original patch has been delayed for more than a year?

If it helps, I can take care of the packaging.

Dominique

--- ../_clean/gcc/fortran/parse.c   2015-11-11 15:23:35.0 +0100
+++ gcc/fortran/parse.c 2015-11-14 12:49:41.0 +0100
@@ -5237,33 +5237,32 @@ gfc_global_used (gfc_gsymbol *sym, locus
   switch(sym->type)
 {
 case GSYM_PROGRAM:
-  name = "PROGRAM";
+  name = "as a PROGRAM ";
   break;
 case GSYM_FUNCTION:
-  name = "FUNCTION";
+  name = "as a FUNCTION ";
   break;
 case GSYM_SUBROUTINE:
-  name = "SUBROUTINE";
+  name = "as a SUBROUTINE ";
   break;
 case GSYM_COMMON:
-  name = "COMMON";
+  name = "as a COMMON ";
   break;
 case GSYM_BLOCK_DATA:
-  name = "BLOCK DATA";
+  name = "as a BLOCK DATA ";
   break;
 case GSYM_MODULE:
-  name = "MODULE";
+  name = "as a MODULE ";
   break;
 default:
-  gfc_internal_error ("gfc_global_used(): Bad type");
-  name = NULL;
+  name = "";
 }

   if (sym->binding_label)
-gfc_error ("Global binding name %qs at %L is already being used as a %s "
+gfc_error ("Global binding name %qs at %L is already being used %s"
   "at %L", sym->binding_label, where, name, &sym->where);
   else
-gfc_error ("Global name %qs at %L is already being used as a %s at %L",
+gfc_error ("Global name %qs at %L is already being used %sat %L",
   sym->name, where, name, &sym->where);
 }

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread mikael at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  ---
according to https://gcc.gnu.org/install/configure.html:
> building where objdir is a subdirectory of srcdir is unsupported. 

this:

(In reply to Alexey Rychkov from comment #2)
> cd gcc-5.2.0
> mkdir build && cd build
> ../configure --disable-multilib

is unsupported.

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread alexey.a.rychkov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #6 from Alexey Rychkov  ---
(In reply to Andreas Schwab from comment #4)
> Did you set GREP_OPTIONS?

Yes, GREP_OPTIONS='--color=always'

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread alexey.a.rychkov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #7 from Alexey Rychkov  ---
(In reply to Dominique d'Humieres from comment #3)
> > I'm not sure if this can affect something, but I was using tmux on top
> > of ssh session...
> 
> Can you try again without tmx? I am not that familiar with sequences such as
> "^[[01;31m^[[K^[[m^[[K", but I associate them to output "styles" to the
> terminal.
> 
> The file kind.h is generated by
> 
> /bin/sh ../../../work/libgfortran/mk-kinds-h.sh
> '/opt/gcc/build_w/./gcc/gfortran -B/opt/gcc/build_w/./gcc/
> -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/
> -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem
> /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem
> /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include-I . -Wall -Werror
> -fimplicit-none -fno-repack-arrays -fno-underscoring  -g -O2' > kinds.h ||
> rm kinds.h
> 
> where /opt/gcc/build_w , /opt/gcc/work, and /opt/gcc/gcc6w are respectively
> my build, source, and install directories.
> 
> What is the output of
> 
> /bin/sh /opt/gcc/work/libgfortran/mk-kinds-h.sh
> '/opt/gcc/build_w/gcc/gfortran -B/opt/gcc/build_w/gcc/
> -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/
> -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ 
> -I/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libgfortran -Wall -Werror
> -fimplicit-none -fno-repack-arrays -fno-underscoring  -g -O2'
> 
> (with suitable replacements of /opt/gcc/work/ and /opt/gcc/build_w).

Executing

/bin/sh ../libgfortran/mk-kinds-h.sh './gcc/gfortran
-B/home/arychkov/gcc-5.2.0/build/gcc/ -I/home/arychkov/gcc-5.2.0/libgfortran
-Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring  -g -O2'

results in valid output.

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #8 from Dominique d'Humieres  ---
> ... results in valid output.

So Mikael probably got the point: don't buil in the source directory. Instead
of

> cd gcc-5.2.0
> mkdir build && cd build
> ../configure --disable-multilib
> make

do

cd gcc-5.2.0
mkdir ../build && cd ../build
../gcc-5.2.0/configure --disable-multilib
make

(or similar!-).

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread alexey.a.rychkov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #9 from Alexey Rychkov  ---
(In reply to Dominique d'Humieres from comment #8)
> > ... results in valid output.
> 
> So Mikael probably got the point: don't buil in the source directory.
> Instead of
> 
> > cd gcc-5.2.0
> > mkdir build && cd build
> > ../configure --disable-multilib
> > make
> 
> do
> 
> cd gcc-5.2.0
> mkdir ../build && cd ../build
> ../gcc-5.2.0/configure --disable-multilib
> make
> 
> (or similar!-).

Are you sure that problem is not in GREP_OPTIONS='--color=always' which
according to man results in color output using default color scheme '01;31'?

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

--- Comment #10 from Dominique d'Humieres  ---
> Are you sure that problem is not in GREP_OPTIONS='--color=always' which
> according to man results in color output using default color scheme '01;31'?

No! but you can do the test by unsetting GREP_OPTIONS. What I am sure is that
building in the source directory is not supported.

[Bug libfortran/68347] Multiple build errors in libgfortran

2015-11-14 Thread alexey.a.rychkov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347

Alexey Rychkov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #11 from Alexey Rychkov  ---
Now it is compiles without any problems.

The reason of the problem was in --color=always which results in special chars
controlling color of output of grep to be generated even when using with pipe.

[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

2015-11-14 Thread mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can't reproduce on x86_64-linux with ether gcc-6 r230377, gcc-5 r230369, or
gcc-4.9 r230368.

[Bug c++/68348] New: ice in cxx_eval_constant_expression at cp/constexpr.c:3172

2015-11-14 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348

Bug ID: 68348
   Summary: ice in cxx_eval_constant_expression at
cp/constexpr.c:3172
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 36707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36707&action=edit
gzipped C++ source code

I used gcc trunk dated 20151114 to compile the attached C++ code.

The compiler said


../../analitzaplot/plotter2d.cpp: In member function ‘QRectF
Analitza::Plotter2D
::normalizeUserViewport(QRectF)’:
../../analitzaplot/plotter2d.cpp:944:41:   in constexpr expansion of
‘#‘result_d
ecl’ not supported by dump_expr#.QRectF::width()’
../../analitzaplot/plotter2d.cpp:968:1: internal compiler error: Segmentation
fa
ult

0xd6ab3f crash_signal
../../src/trunk/gcc/toplev.c:336
0x7f3d12 cxx_eval_constant_expression
../../src/trunk/gcc/cp/constexpr.c:3172
0x7f5d5a cxx_eval_indirect_ref
../../src/trunk/gcc/cp/constexpr.c:2609
0x7f2dbf cxx_eval_constant_expression
../../src/trunk/gcc/cp/constexpr.c:3363

[Bug c/68349] New: ice in decompose_normal_address with -O2 at tlanal.c:6086

2015-11-14 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349

Bug ID: 68349
   Summary: ice in decompose_normal_address with -O2 at
tlanal.c:6086
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 36708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36708&action=edit
C source code

I used gcc trunk dated 20151114 to compile the attached C code.

The compiler said

$ ../results/bin/gcc -c -O2 bug245.c
findhyphen.c: In function ‘DoHyphens’:
findhyphen.c:291:1: internal compiler error: in decompose_normal_address, at
rtlanal.c:6086

0xaeec83 decompose_normal_address
../../src/trunk/gcc/rtlanal.c:6086
0xaeec83 decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
../../src/trunk/gcc/rtlanal.c:6163
0x9b8355 process_address_1
../../src/trunk/gcc/lra-constraints.c:2874
0x9b8355 process_address
../../src/trunk/gcc/lra-constraints.c:3133

[Bug rtl-optimization/68349] ;ice in decompose_normal_address with -O2 at rtlanal.c:6086

2015-11-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-14
 CC||trippels at gcc dot gnu.org
Summary|ice in  |;ice in
   |decompose_normal_address|decompose_normal_address
   |with -O2 at rtlanal.c:6086  |with -O2 at rtlanal.c:6086
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
int a, b;
unsigned long strlen();
typedef struct sHyphenNode {
  char sepcnts[0];
  struct sHyphenNode *Daughters[];
} * PHyphenNode;
int GetIndex();
PHyphenNode c;
void DoHyphens_Field_1() {
  char d[300], e[300];
  int z, f, l = strlen();
  for (; z;)
;
  for (; l; z++) {
f = z;
for (; f < l; f++) {
  c = c->Daughters[GetIndex(d[f])];
  a = 0;
  for (; a <= f - z; a++)
if (e[z + a])
  e[z] = c->sepcnts[a];
}
  }
  if (e[z])
b = 1;
}

[Bug libstdc++/68350] New: std::uninitialized_copy overly restrictive for trivially_copyable types

2015-11-14 Thread philipp.ochsendorf+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

Bug ID: 68350
   Summary: std::uninitialized_copy overly restrictive for
trivially_copyable types
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philipp.ochsendorf+gcc at gmail dot com
  Target Milestone: ---

I think the following decision is too restrictive:

return std::__uninitialized_copy<__is_trivial(_ValueType1)
  && __is_trivial(_ValueType2)
  && __assignable>::
__uninit_copy(__first, __last, __result);

(cf. stl_uninitialized.h:123ff). The following should be sufficient:

return std::__uninitialized_copy::
__uninit_copy(__first, __last, __result);

Found this in 5.2.0 and 6.0. Probably it's in versions prior to 5.2.0 as well.

[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172

2015-11-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-14
 CC||trippels at gcc dot gnu.org
Summary|ice in  |[6 regression] ICE:
   |cxx_eval_constant_expressio |segfault in
   |n at cp/constexpr.c:3172|cxx_eval_constant_expressio
   ||n at cp/constexpr.c:3172
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
typedef double qreal;
class QRectF {
public:
  constexpr QRectF() : xp(), yp(), w(), h() {}
  constexpr qreal width() const noexcept;
  double xp;
  double yp;
  double w;
  double h;
};
constexpr qreal QRectF::width() const noexcept { return w; }
QRectF normalizeUserViewport() {
  QRectF normalizeduvp;
  normalizeduvp.width();
  return normalizeduvp;
}

[Bug fortran/67803] ICE on concatenating wrong character array constructor

2015-11-14 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Nov 14 17:31:16 2015
New Revision: 230379

URL: https://gcc.gnu.org/viewcvs?rev=230379&root=gcc&view=rev
Log:
2015-11-14  Steven G. Kargl  

PR fortran/67803
* array.c (gfc_match_array_constructor): If array constructor included
a CHARACTER typespec, check array elements for compatible type.

2015-11-14  Steven G. Kargl  

PR fortran/67803
* gfortran.dg/pr67803.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67803.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68298] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

2015-11-14 Thread mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can't reproduce this SEGV on x86_64-linux with current gcc-5 or gcc-6.

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

2015-11-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes, G++ didn't support is_trivially_copyable when that condition was written.

[Bug fortran/67803] ICE on concatenating wrong character array constructor

2015-11-14 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Nov 14 17:43:15 2015
New Revision: 230380

URL: https://gcc.gnu.org/viewcvs?rev=230380&root=gcc&view=rev
Log:
2015-11-14  Steven G. Kargl  

PR fortran/67803
* array.c (gfc_match_array_constructor): If array constructor included
a CHARACTER typespec, check array elements for compatible type.

2015-11-14  Steven G. Kargl  

PR fortran/67803
* gfortran.dg/pr67803.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67803.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/array.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67803] ICE on concatenating wrong character array constructor

2015-11-14 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux

2015-11-14 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-14
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/68344] No warning for old-style function declarations.

2015-11-14 Thread egall at gwmail dot gwu.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68344

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
I think -Wstrict-prototypes does what you're looking for here:

$ /usr/local/bin/gcc -Wold-style-declaration -Wold-style-definition
-Wstrict-prototypes -Wmissing-parameter-type -Wmissing-prototypes -std=c11
-pedantic -c pr68344.c
pr68344.c:1:1: warning: function declaration isn’t a prototype
[-Wstrict-prototypes]
 int a();
 ^

[Bug c/68344] No warning for old-style function declarations.

2015-11-14 Thread i.hamsa at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68344

--- Comment #2 from i.hamsa at gmail dot com ---
Indeed. I somehow missed that option. It probably would be logical for
-Wold-style-declaration to imply -Wstrict-prototypes, but this is a minor
issue.

[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux

2015-11-14 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Sat Nov 14 18:54:16 2015
New Revision: 230382

URL: https://gcc.gnu.org/viewcvs?rev=230382&root=gcc&view=rev
Log:
PR bootstrap/68346
* call.c (build_new_op_1): Don't fold arguments to
warn_tautological_cmp.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtautological-compare.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/68351] New: ICE in ssl.h with -g

2015-11-14 Thread guille at cal dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351

Bug ID: 68351
   Summary: ICE in ssl.h with -g
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at cal dot berkeley.edu
  Target Milestone: ---

Created attachment 36709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36709&action=edit
this is the OSX 10.9.5 /usr/include/openssl/ssl.h

t.c:
#include 
int main()  { return 0; }

# c++-6.0.0 -g t.c

In file included from /usr/include/openssl/asn1.h:76:0,
 from /usr/include/openssl/objects.h:962,
 from /usr/include/openssl/evp.h:100,
 from /usr/include/openssl/x509.h:75,
 from /usr/include/openssl/ssl.h:185,
 from t.c:1:
/usr/include/openssl/bn.h:335:3: error: TYPE_CANONICAL is not compatible
   {
   ^
 
asm_written public unsigned DI
size 
unit size 
align 64 symtab 31264032 alias set -1 canonical type 0x1434272a0
pointer_to_this >
decl_3 VOID file /usr/include/openssl/bn.h line 333 col 8
align 1 offset_align 1 context 
chain 
decl_3 VOID file /usr/include/openssl/bn.h line 332 col 15
align 1 offset_align 1 context  chain >> context

full-name "struct bn_gencb_st"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
 
full-name "BN_GENCB"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
/usr/include/openssl/bn.h:335:3: internal compiler error: verify_type failed

/usr/include/openssl/bn.h:335:3: internal compiler error: Abort trap: 6
c++-6.0.0: internal compiler error: Abort trap: 6 (program cc1plus)

[Bug c++/68351] ICE in ssl.h with -g

2015-11-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-14
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attach the preprocessed file. See: http://gcc.gnu.org/bugs/

[Bug c++/68351] ICE in ssl.h with -g

2015-11-14 Thread guille at cal dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351

--- Comment #2 from Guille  ---
Created attachment 36710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36710&action=edit
This is the preprocessed file.

[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux

2015-11-14 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/68351] ICE in ssl.h with -g

2015-11-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

2015-11-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||guille at cal dot berkeley.edu

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

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

2015-11-14 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239

H.J. Lu  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #16 from H.J. Lu  ---
It was triggered by r222305.  It may be a latent bug.

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

2015-11-14 Thread guille at cal dot berkeley.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214

--- Comment #18 from Guille  ---
I may be missing something: I could build latest openssl no problem, but
'#include \int main(){return 0;}' ICEs on my system's installed
openssl (OSX 10.9.5). 

(In reply to Magnus Fromreide from comment #16)
> Should the importance of this bug be raised?
> It is a bit embarrasing that the program
> 
> #include 
> 
> ice's

[Bug c++/68352] New: [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT

2015-11-14 Thread daspamster at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68352

Bug ID: 68352
   Summary: [Cygwin] internal compiler error: Segmentation fault
max() _GLIBCXX_USE_NOEXCEPT
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daspamster at gmail dot com
  Target Milestone: ---

My toy code won't compile on Cygwin when a simple "Hello world' will.
I'm including one big file, with everything but the first 62 lines being the
contents of "permute.cpp", my one source file.

[Bug c++/68352] [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT

2015-11-14 Thread daspamster at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68352

--- Comment #1 from Ben Kane  ---
Created attachment 36711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36711&action=edit
all except permute.ii (attaching separately)

[Bug c++/68352] [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT

2015-11-14 Thread daspamster at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68352

--- Comment #2 from Ben Kane  ---
Created attachment 36712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36712&action=edit
permute.ii (1.5 MB)

I uploaded it to Wikisend because of the file size. It disappears in 90 days :)

[Bug tree-optimization/66974] -Warray-bounds false positive with -O3

2015-11-14 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
(In reply to Ganesh Ajjanagadde from comment #2)

For what it's worth, telling gcc that the argument is constrained to the
limited range of values either by converting it like so:

order = ((struct { unsigned order: 2; }){ order }).order;

or by declaring the function to take an argument of that type eliminates the
warnings and results in far simpler object code.

[Bug libstdc++/68353] New: [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std'

2015-11-14 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68353

Bug ID: 68353
   Summary: [6 Regression] libstdc++-v3/include/bits/basic_string.
h:5524:31: error: 'wcstoll' is not a member of 'std'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-hpux*
Target: hppa*-*-hpux*
 Build: hppa*-*-hpux*

Created attachment 36713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36713&action=edit
Preprocessed source

In stage1, we have:

make[4]: Entering directory
`/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-
v3'
Making all in includemake[5]: Entering directory
`/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include'
mkdir -p ./hppa64-hp-hpux11.11/bits/stdc++.h.gch/test/gnu/gcc/objdir/./gcc/xgcc
-shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/sys-include-x c++-header
-nostdinc++ -g -O2 
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h \
-o hppa64-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/string:52:0,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/ios_base.h:41,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ios:42,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/istream:38,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/sstream:38,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:45,
 from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ccomplex:38,
 from
/test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:52:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:
In function 'long long int std::__cxx11::stoll(const wstring&, std::size_t*,
int)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5524:31:
error: 'wcstoll' is not a member of 'std'
   { return __gnu_cxx::__stoa(&std::wcstoll, "stoll", __str.c_str(),
   ^~~

/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:
In function 'long long unsigned int std::__cxx11::stoull(const wstring&,
std::size_t*, int)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5529:31:
error: 'wcstoull' is not a member of 'std'
   { return __gnu_cxx::__stoa(&std::wcstoull, "stoull", __str.c_str(),
   ^~~

/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:
In function 'float std::__cxx11::stof(const wstring&, std::size_t*)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5535:31:
error: 'wcstof' is not a member of 'std'
   { return __gnu_cxx::__stoa(&std::wcstof, "stof", __str.c_str(), __idx); }
   ^~~

/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:
In function 'long double std::__cxx11::stold(const wstring&, std::size_t*)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5543:31:
error: 'wcstold' is not a member of 'std'
   { return __gnu_cxx::__stoa(&std::wcstold, "stold", __str.c_str(), __idx); }
   ^~~

make[5]: *** [hppa64-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
make[5]: Leaving directory
`/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include'
make[4]: *** [all-recursive] Error 1

[Bug tree-optimization/66974] -Warray-bounds false positive with -O3

2015-11-14 Thread gajjanagadde at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974

--- Comment #5 from Ganesh Ajjanagadde  ---
That I do not consider a readable or scalable solution.
Furthermore, this is a bug, and the FFmpeg codebase gets compiled across a wide
array of compilers. We can't insert hacks for specific GCC versions.

Thanks for pointing it out nonetheless.

[Bug c++/68354] New: -Warray-bounds on a flexible array member in C++

2015-11-14 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68354

Bug ID: 68354
   Summary: -Warray-bounds on a flexible array member in C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C++ mode (but not in C mode), g++ silently (without -Wpedantic) accepts both
a definition of a struct with a flexible array member and an object of such a
type without an initializer but issues a warning for accesses to the array (see
below).  Debugging reveals that unlike the C front end, the C++ front end sets
the bounds on flexible arrays to [0, SIZE_MAX].  The code in check_array_ref in
tree-vrp.c then trips up on such an array because it first assumes that
flexible arrays have no bounds, and further assumes that no array has an upper
bound of SIZE_MAX when adding one to the bound.  When the computation wraps
around to zero, the function incorrectly deduces that the array is empty and
issues a warning.

It seems wrong for the C++ front end to set the upper bound to SIZE_MAX for any
array.  First, because GCC itself assumes that no object is larger than
SIZE_MAX / 2.  Second, when the size of the array element is greater than 1 as
in the case below, even the most permissive upper bound cannot be SIZE_MAX.

$ cat u.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -S
-Wall -Wextra -o/dev/null u.cpp 
struct S {
int n;
int a[];
} s;

int i;

void f ()
{
i = s.a [0];
}

u.cpp: In function ‘void f()’:
u.cpp:10:15: warning: array subscript is above array bounds [-Warray-bounds]
 i = s.a [0];
   ^

[Bug c++/68354] -Warray-bounds on a flexible array member in C++

2015-11-14 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68354

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-15
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Working on a patch.

[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

2015-11-14 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68332

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-15
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
Whoops, I forgot about this.  Mine.

[Bug libstdc++/68353] [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std'

2015-11-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68353

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-15
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

2015-11-14 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328

--- Comment #2 from Zhendong Su  ---
(In reply to Mikael Pettersson from comment #1)
> I can't reproduce on x86_64-linux with ether gcc-6 r230377, gcc-5 r230369,
> or gcc-4.9 r230368.

Mikael, not sure why you can't reproduce the miscompilation. I can still
reproduce it with r230832 as shown below: 

$ 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151114 (experimental) [trunk revision 230382] (GCC) 
$ 
$ gcc-trunk -O2 pr68328.c
$ ./a.out
0
$ gcc-trunk -Os pr68328.c
$ ./a.out
$

[Bug rtl-optimization/68298] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)

2015-11-14 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298

--- Comment #2 from Zhendong Su  ---
(In reply to Mikael Pettersson from comment #1)
> I can't reproduce this SEGV on x86_64-linux with current gcc-5 or gcc-6.

Mikael, I can still reproduce it with r230382 as shown below: 

$ 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151114 (experimental) [trunk revision 230382] (GCC) 
$ 
$ gcc-trunk -m64 -O3 pr68298.c
$ ./a.out
Segmentation fault (core dumped)
$ 
$ gcc-trunk -m64 -O2 pr68298.c
$ ./a.out
0
$

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

2015-11-14 Thread olegendo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277

--- Comment #8 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #7)
> (In reply to Kazumoto Kojima from comment #6)
> I've changed the predicate of the 2nd operand to arith_operand instead
> of const_int_operand in your patch and run testsuite.

Yes, of course, sorry.

> There is one new failure:
> 
> FAIL: gfortran.dg/pr65450.f90   -O3 -g  execution test
> 
> which is
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Weird.  I'm afraid that even my first patch makes wrong codes silently,
> though it doesn't fail for the above test.

With that test and the patch I see one difference:

before:
dt  r11
add r7,r12
mov.w   .L65,r7<<<
add r1,r7

after:
dt  r11
add r7,r12
mov r1,r7  <<<
add r1,r7


The insn in .reload is:

(note 133 132 747 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn 747 133 134 9 (set (reg:SI 7 r7)
(const_int 4000 [0xfa0])) 256 {movsi_ie}
 (nil))

(insn 134 747 135 9 (parallel [
(set (reg:SI 12 r12 [orig:295 ivtmp.165 ] [295])
(plus:SI (reg:SI 12 r12 [orig:295 ivtmp.165 ] [295])
(reg:SI 7 r7)))
(clobber (scratch:SI))
]) 65 {addsi3_scr}
 (nil))

(insn 135 134 748 9 (parallel [
(set (reg:SI 7 r7 [orig:298 ivtmp.172 ] [298])
(plus:SI (reg:SI 1 r1 [orig:280 ivtmp.135 ] [280])
(const_int 4000 [0xfa0])))
(clobber (reg:SI 0 r0))
]) 65 {addsi3_scr}
 (nil))


addsi_scr will convert this to something like

   mov.w   #4000, r7
   add r1,r7

but then .postreload sees the previous same constant load in insn 747, removes
it and changes the add insn to:

(insn 135 134 748 9 (set (reg:SI 7 r7 [orig:298 ivtmp.172 ] [298])
(plus:SI (reg:SI 1 r1 [orig:280 ivtmp.135 ] [280])
(reg:SI 7 r7))) 66 {*addsi3}
 (nil))

so we get overlapping regs for operands[0] and operands[2] which is not
checked.  In fact, the very same bug is hidden in the addsi3_scr pattern which
we have added recently, but it seems it hasn't been triggered (yet).

The patch below is a bit of a hammer, but hopefully it works as intended. 
CSiBE code size change is +- 0 everywhere, but there are some differences in
the generated code.  Postreload is able to remove some redundant constant
loads.

I've checked that gfortran.dg/pr65450.f90 and attachment 36686 look OK with
this patch.  Could you please give it another test run?


Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 230158)
+++ gcc/config/sh/sh.md (working copy)
@@ -2232,11 +2232,51 @@
}
 }
   else if (!reg_overlap_mentioned_p (operands[0], operands[1]))
-emit_move_insn (operands[0], operands[1]);
+{
+  if (!reg_overlap_mentioned_p (operands[0], operands[2]))
+   emit_move_insn (operands[0], operands[1]);
+  else
+   operands[2] = operands[1];
+}
 }
   [(set_attr "type" "arith")])

+;; Old reload might generate add insns directly (not through the expander) for
+;; the memory address of complex insns like atomic insns when reloading.
 (define_insn_and_split "*addsi3"
+  [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+   (plus:SI (match_operand:SI 1 "arith_reg_operand" "r")
+(match_operand:SI 2 "arith_or_int_operand" "rn")))]
+  "TARGET_SH1 && !sh_lra_p ()
+   && reload_completed
+   && !reg_overlap_mentioned_p (operands[0], operands[1])"
+  "#"
+  "&& 1"
+  [(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
+{
+  if (operands[2] == const0_rtx)
+{
+  emit_move_insn (operands[0], operands[1]);
+  DONE;
+}
+
+  if (CONST_INT_P (operands[2]))
+{
+  if (satisfies_constraint_I08 (operands[2]))
+   emit_move_insn (operands[0], operands[1]);
+  else
+   {
+ emit_move_insn (operands[0], operands[2]);
+ operands[2] = operands[1];
+   }
+}
+  else if (!reg_overlap_mentioned_p (operands[0], operands[2]))
+emit_move_insn (operands[0], operands[1]);
+  else
+operands[2] = operands[1];
+})
+
+(define_insn_and_split "*addsi3"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r,r")
(plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r")
 (match_operand:SI 2 "arith_operand" "rI08,Z")))]

[Bug target/68355] New: Constant byte is passed on stack

2015-11-14 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355

Bug ID: 68355
   Summary: Constant byte is passed on stack
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-tools-1 pr67239]$ cat foo.ii
template
struct integral_constant
{
  static constexpr _Tp value = __v;
  typedef _Tp value_type;
  typedef integral_constant<_Tp, __v> type;
  constexpr operator value_type() const { return value; }
};

typedef integral_constant true_type;

extern void xxx (true_type c);
extern true_type y;

void
yyy ()
{
  xxx (y);
}
[hjl@gnu-tools-1 pr67239]$  gcc -S  -std=gnu++11 -S  -O2 foo.ii  
[hjl@gnu-tools-1 pr67239]$ cat foo.s
.file   "foo.ii"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  _Z3yyyv
.type   _Z3yyyv, @function
_Z3yyyv:
.LFB1:
.cfi_startproc
subq$16, %rsp
.cfi_def_cfa_offset 24
pushq   $0
.cfi_def_cfa_offset 32
call_Z3xxx17integral_constantIbLb1EE
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   _Z3yyyv, .-_Z3yyyv
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.2.1 20150929 (Red Hat 5.2.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 pr67239]$ 

It causes PR 67329 due to DW_CFA_GNU_args_size generated by "push $0", which
is ignored by callee.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

2015-11-14 Thread olegendo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277

--- Comment #9 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #6)
> I think that that trial and AMS show the backend like SH requires
> something even for the old reload, though I'm not sure that
> the 2nd postreload_cse is the right thing for that.

The 2nd postreload might be a wallpapering work around.  But it would allow us
to switch to LRA by default without regressing code size / performance, if I
understand correctly.

Of course the proper fix would be having AMS and constant optimization and R0
pre-alloc and 2-operand-optimizations (the ones we've been fighting with the
addsi3 patterns) and ...

At the current (lack of) pace I don't know when all of that will be done.  So
my idea was to at least reduce the R0 problem for users by making LRA the
default in GCC 6.  If we have to add the 2nd postreload temporarily, so be it. 
When the other solutions become more mature and stable, we can remove the 2nd
postreload thing again.

[Bug target/68355] Constant byte is passed on stack

2015-11-14 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-15
 Blocks||67239
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is PR 67239.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
[Bug 67239] [6 Regression] FAIL:
23_containers/unordered_set/insert/hash_policy.cc execution test