[Bug tree-optimization/66261] New: operations that simplify whether the pointers are the same or not (++p;++q;--p;--q)

[glisse at gcc dot gnu.org]

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

Bug ID: 66261
   Summary: operations that simplify whether the pointers are the
same or not (++p;++q;--p;--q)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

In the example below, if p and q refer to different objects, the function does
nothing, and if they refer to the same object, it also does nothing. But we
don't manage to optimize it, and I don't know how we could do it (without being
incredibly specific). It might actually be slightly easier at the RTL level for
targets where adding a constant to an integer in memory is a single insn, so it
could be detected that ++q and --p commute. clang++, icpc and sunCC don't
simplify it either.

void f(int&p,int&q){
  ++p;++q;--p;--q;
}

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

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

--- Comment #33 from Chung-Kil Hur  ---
Dear Richard,

Thanks for the detailed response.

I have a suggestion for a solution of the problem, which is based on my paper
to appear at PLDI 2015.

* A Formal C Memory Model Supporting Integer-Pointer Casts.
  Jeehoon Kang, Chung-Kil Hur, William Mansky, Dmitri Garbuzov, Steve
Zdancewic, Viktor Vafeiadis.
  http://sf.snu.ac.kr/gil.hur/publications/intptrcast.pdf

The suggestion is simple.
You do not need to turn off the phiopt optimizations.
We propose to slightly change the following assumption.

> PTA considers that all pointers coming from integer constants
> point to global memory only.

Here, if you change this as follows, you can solve the problem.

* All pointers coming from integer constants can point to only global memory
and
  local variables whose addresses have been cast to integers.

Also, we expect that this would not decrease the optimization performance of
GCC very much because those variables whose addresses have been cast to
integers tend to be escaped (e.g. passed to a hash function, or stored in the
memory).

[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
(In reply to Tomasz Gajewski from comment #22)
> In comment #10 I've provided test patch to test case that exposed a problem
> (and in comment #11 some fix to all those tests). Currently I can't check if
> it applies cleanly and if errors occur. If you want probably I can find some
> time in next few weeks.

It applies cleanly, but all the tests pass for me.

[Bug libstdc++/66262] New: [REGRESSION] testsuite failure with libstdc++ (gcc-5) and g++-4.9 together

[costamagnagianfranco at yahoo dot it]

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

Bug ID: 66262
   Summary: [REGRESSION] testsuite failure with libstdc++ (gcc-5)
and g++-4.9 together
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: costamagnagianfranco at yahoo dot it
  Target Milestone: ---

Hi, sorry in advance for the low quality bug report.

I'm reporting this upstream, since I suspect the ABI broke in some bad way
between 4.9 and 5.0.

note: I tried to explain as much as possible on Debian bug [1]

Firstly I wasn't able to make it work with g++-5 and libstdc++ from gcc-5
package

After the Debian Maintainer rebuilt gcc-5 with 

   * Configure with
   --disable-libstdcxx-dual-abi --with-default-libstdcxx-abi=c++98
 While libstdc++ provides a dual ABI to support both the c++98 and c++11
 ABI, there is no committment on compatibility of the old experimental
 c++11 ABI from GCC 4.9 and the stable c++11 ABI in GCC 5.


and now I can build them with both g++-5 and libstdc++ from gcc-5.

the problem actually is that now Debian has libstdc++ from gcc-5, and the
default compiler still set to gcc-4.9.

With that combination (g++-4.9 and libstdc++ from gcc-5) the bug is there and I
can't upload in Debian the new release until I figure this out.

I can try to provide more informations, just feel free to ask me.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784655

[Bug libstdc++/66262] [REGRESSION] testsuite failure with libstdc++ (gcc-5) and g++-4.9 together

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Please attach a testcase that fails with libstdc++ from gcc-5 
and succeeds with libstdc++ from gcc-4.9.

[Bug libstdc++/66262] [REGRESSION] testsuite failure with libstdc++ (gcc-5) and g++-4.9 together

[costamagnagianfranco at yahoo dot it]

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

--- Comment #2 from Gianfranco  ---
I mentioned a testcase in the Debian bug report.
Unfortunately I'm not the upstream developer, I might find difficult to extract
what you exactly need...

[Bug libstdc++/66262] [REGRESSION] testsuite failure with libstdc++ (gcc-5) and g++-4.9 together

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Gianfranco from comment #2)
> I mentioned a testcase in the Debian bug report.
> Unfortunately I'm not the upstream developer, I might find difficult to
> extract what you exactly need...

Please see https://gcc.gnu.org/bugs/ for a list of what is needed.

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-23
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Confirmed.

Oddly, the memory leak goes away at any level of optimization. What makes this
odd is that the assumed shape array case has all the code for deallocation of
the allocatable component after the call to foo_1d:

  foo_1d (&C.3401, &atmp.3);
  if ((struct foo_t[1] * restrict) atmp.3.data != 0B)
{
  D.3411 = (atmp.3.dim[0].ubound - atmp.3.dim[0].lbound) + 1;
  D.3412 = atmp.3.dim[0].stride * D.3411;
  D.3413 = D.3412 + -1;
  S.6 = 0;
  while (1)
{
  if (S.6 > D.3413) goto L.3;
  if ((*(struct foo_t[1] * restrict) atmp.3.data)[S.6].bigarr
!= 0B)
{
  __builtin_free ((void *) (*(struct foo_t[1] * restrict)
atmp.3.data)[S.6].bigarr);
}
  (*(struct foo_t[1] * restrict) atmp.3.data)[S.6].bigarr = 0B;
  S.6 = S.6 + 1;
}
  L.3:;
}

and this disappears completely for the automatic array dummy. I am pretty sure
that ther problem lies in trans-array.c(gfc_conv_array_parameter), where the
deallocation of allocatable components appears after the return for g77 style
dummies. I cannot check this right now because I am doing a fresh bootstrap
with a clean tree.

Paul

[Bug libstdc++/64657] Support iterators with overloaded operator-comma

[fdumont at gcc dot gnu.org]

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

--- Comment #4 from François Dumont  ---
Author: fdumont
Date: Sat May 23 11:17:38 2015
New Revision: 223605

URL: https://gcc.gnu.org/viewcvs?rev=223605&root=gcc&view=rev
Log:
2015-05-23  François Dumont  fdum...@gcc.gnu.org>

PR libstdc++/64657
* include/debug/functions.h (__check_sorted_aux): Cast expression to
void.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/functions.h

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #3 from Peter Boyle  ---
http://stackoverflow.com/questions/30411079/counting-template-recursion-nest-depth

Appears to affect all versions of g++ with various errors.

Used:
http://melpon.org/wandbox/permlink/eK2AVfZXXss0ZDu6

All versions of clang after 3.1 accept the code.

Disambiguating "function(Container)" from function
manually by renaming function(Container) to ffunction(Container) makes it
operate in the same way as ICPC and Clang.

However, this should not have been necessary because substitution failure
should have caused it to select the right "function" in every case 

At least, I believe it should work as original, clang believes and icpc
believes, but g++ does not.

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  ---
PR61831 is possibly related.
But I don't think the PR61831 patch fixes this.

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

Peter Boyle  changed:

   What|Removed |Added

Version|5.1.0   |6.0

--- Comment #4 from Peter Boyle  ---
Also fails in HEAD

prog.cc:53:14: warning: unused parameter 'argc' [-Wunused-parameter]
 int main(int argc,char **argv)
  ^
prog.cc:53:26: warning: unused parameter 'argv' [-Wunused-parameter]
 int main(int argc,char **argv)
  ^
'
Internal compiler error: Error reporting routines re-entered.
0x5ccf96 push_tinst_level_loc(tree_node*, unsigned int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8464
0x5e8409 push_tinst_level(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8448
0x5e8409 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16238
0x5a5be9 add_template_candidate_real
/home/heads/gcc/gcc-source/gcc/cp/call.c:3057
0x5a626c add_template_candidate
/home/heads/gcc/gcc-source/gcc/cp/call.c:3154
0x5a626c add_candidates
/home/heads/gcc/gcc-source/gcc/cp/call.c:5281
0x5a8843 perform_overload_resolution
/home/heads/gcc/gcc-source/gcc/cp/call.c:3999
0x5a9d0a build_new_function_call(tree_node*, vec**, bool, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:4076
0x67114a finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/heads/gcc/gcc-source/gcc/cp/semantics.c:2410
0x5d478d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15201
0x5d5308 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:12512
0x60dd50 dump_template_bindings
/home/heads/gcc/gcc-source/gcc/cp/error.c:369
0x60dd50 dump_substitution
/home/heads/gcc/gcc-source/gcc/cp/error.c:1448
0x60f866 decl_to_string
/home/heads/gcc/gcc-source/gcc/cp/error.c:2910
0x60f866 cp_printer
/home/heads/gcc/gcc-source/gcc/cp/error.c:3491
0xfd6a10 pp_format(pretty_printer*, text_info*)
/home/heads/gcc/gcc-source/gcc/pretty-print.c:613
0xfd7780 pp_format_verbatim(pretty_printer*, text_info*)
/home/heads/gcc/gcc-source/gcc/pretty-print.c:672
0xfd7854 pp_verbatim(pretty_printer*, char const*, ...)
/home/heads/gcc/gcc-source/gcc/pretty-print.c:873
0x609eda print_instantiation_partial_context_line
/home/heads/gcc/gcc-source/gcc/cp/error.c:3290
0x609eda print_instantiation_partial_context
/home/heads/gcc/gcc-source/gcc/cp/error.c:3400
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/24016] Missing warning for unspecified evaluation order

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Since arithmetic on void * (treating sizeof(void) as 1) is a GNU extension,
that behavior is desirable.

[Bug other/66259] Combined gcc and binutils build from git-master fails, with gas/as-new not existing

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
For files that exist in the GCC and binutils source trees both,
you should take the one in the GCC tree (you do it the other way
around).  Does that work better for you?

[Bug other/66259] Combined gcc and binutils build from git-master fails, with gas/as-new not existing

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #2)
> For files that exist in the GCC and binutils source trees both,
> you should take the one in the GCC tree (you do it the other way
> around).  Does that work better for you?

I did that myself and it does not work. This broke within the last 9 months but
I don't have a date when it broke though.

[Bug c/66263] New: Performance regression from gcc-4.8 and up (trivial sudoku program)

[bdeyal at gmail dot com]

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

Bug ID: 66263
   Summary: Performance regression from gcc-4.8 and up (trivial
sudoku program)
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bdeyal at gmail dot com
  Target Milestone: ---

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

I ran the attached simple program with gcc-4.6, 4.7, 4.8, 4.9 and 5.1

This is a simple brute force + recursion program that finds all the solutions
for a given sudoku board. My input file had about half a million different
solutions.

System is fedora 21 with gcc 4.9.2
All other compilers were built locally.

my compilation command line was:

$(CC) -Ofast -W -Wall -DNDEBUG src/sudoku.c -o bin/sudoku


Running time results



gcc-4.6.4   0.483s
gcc-4.7.4   0.496s
gcc-4.8.4   0.749s
gcc-4.9.2   0.762s
gcc-5.1.0   0.776s


Files:
==
Attached preprocessed file to compile.

In addition here's the input file contents for solving:

- - - - - 1 - 3 -
- - 8 - - - - 7 5
- 1 - 9 - - - - -
- - 7 - - - - - 1
- - - 8 - 9 - - -
8 - - - 3 - - - -
- - - - - - - 9 -
9 2 - - - - 3 - -
- - - - - - - - -

to test you should run something like:

time ./sudoku --quiet < input_file.txt

where ./sudoku is the produced executable and input_file.txt is the sudoku
board from above.



Detailed compiler version and configure options:


$ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=gcc-4.6
COLLECT_LTO_WRAPPER=/opt/gcc46/libexec/gcc/x86_64-redhat-linux/4.6.4/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/gcc46 --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++
--enable-plugin --enable-initfini-array --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.4 (GCC)


$ gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=gcc-4.7
COLLECT_LTO_WRAPPER=/opt/gcc-4.7.4/libexec/gcc/x86_64-redhat-linux/4.7.4/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../gcc-4.7.4/configure --prefix=/opt/gcc-4.7.4
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,fortran --enable-plugin --enable-initfini-array
--disable-dssi --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.4 (GCC)


$ gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/opt/gcc48/libexec/gcc/x86_64-redhat-linux/4.8.4/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/gcc48 --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,fortran,go,lto --enable-plugin --enable-initfini-array
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.4 (GCC)


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)


$ gcc-5.0 -v
Using built-in specs.
COLLECT_GCC=gcc-5.0
COLLECT_LTO_WRAPPER=/opt/gcc5/libexec/gcc/x86_64-redhat-linux/5.1.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/gcc5/ --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-sys

[Bug c/66263] Performance regression from gcc-4.8 and up (trivial sudoku program)

[bdeyal at gmail dot com]

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

--- Comment #1 from EyalBD  ---
Created attachment 35606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35606&action=edit
Input file for running

[Bug c++/66264] New: [untaken optimization] switch & enums without default-case

[jk3064 at arcor dot de]

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

Bug ID: 66264
   Summary: [untaken optimization] switch & enums without
default-case
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jk3064 at arcor dot de
  Target Milestone: ---

example:
https://goo.gl/UFYF6G

Even when the switch() contains all enums, it won't use a lookuptable when no
default-case is given.

[Bug c/66265] New: strict aliasing with O2 fails to generate correct code and gives no warnings

[gougolith at gmail dot com]

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

Bug ID: 66265
   Summary: strict aliasing with O2 fails to generate correct code
and gives no warnings
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gougolith at gmail dot com
  Target Milestone: ---

Created attachment 35607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35607&action=edit
Sample code that exhibits the issue.

This may be a genuine bug since the issue manifests itself depending on the way
the memory allocation is done. Clearly the pointers are all the same type.

I turned on the following flags to generate the code:

gcc -Wall -O2 -pedantic -Wextra -Wall

Generates no warnings of any kind but the program is broken.


gcc -Wall -O2 -pedantic -Wextra -Wall -fno-strict-aliasing

Generates no warnings and correct program.

I'm sure this is a strict-aliasing issue but it makes no sense why no warning
is issued if that's the case?

[Bug c++/66266] New: Abbreviated function template does not behave as expected

[bruno.manga95 at gmail dot com]

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

Bug ID: 66266
   Summary: Abbreviated function template does not behave as
expected
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno.manga95 at gmail dot com
  Target Milestone: ---

Although abbreviated function templates are not part of ISO c++14 (but part of
the Concepts ts), the following code does not behave as its equivalent function
template (as described in n4377 section 8.3.5) and the assertion fails:

auto sum_auto(auto x, auto y)
{
return x+y;
}

template 
auto sum_template(T x, U y)
{
return x+y;
}

int main()
{
   //sum_auto returns 10 while sum_template returns 10.1
assert(sum_auto(5, 5.1) == sum_template(5, 5.1)); 
}

[Bug c++/66254] Member function shadowing enum classes

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The problem seems to be fixed in gcc HEAD 6.0.0 20150523 (experimental)

[Bug c++/66266] Abbreviated function template does not behave as expected

[bruno.manga95 at gmail dot com]

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

--- Comment #1 from Bruno Manganelli  ---
Probably another symptom of 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969

as inverting the arguments for auto_sum does not cause the assertion to fail.
Apologies for the duplicate.

[Bug ipa/65873] Failure to inline always_inline memcpy

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[5 Regression] Failure to   |Failure to inline
   |inline always_inline memcpy |always_inline memcpy

--- Comment #11 from Jan Hubicka  ---
Workaround backported to GCC 5.

[Bug c++/66267] New: internal compiler error: Segmentation fault

[cjedic at gmail dot com]

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

Bug ID: 66267
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjedic at gmail dot com
  Target Milestone: ---

I got the following segmentation fault from the following code:

..\calcGrades.cpp:32:3: internal compiler error: Segmentation fault
   }
   ^

#include  
#include 
#include 
#include 
using namespace std;

struct grades
 {
 string firstName;
 string lastName;
 intID;
 intprgmGrades[10];
 intexamGrades[3];
 intfexamGrade;
 double finalGrade;
 }student;

 double calculatePercentGrade(const grades person)
  {
 int total = 0;
 double pAvg, eAvg, fAvg, final;
 for(int i = 0; i < 10; i++)
 total += person.prgmGrades[i];
 pAvg = total/10;
 total = 0;
 for(int i = 0; i < 3; i++)
 total += person.examGrades[i];
 eAvg = total/3;
 fAvg = person.fexamGrade;
 final = (pAvg * 0.3) + (eAvg * 0.45) + (fAvg * 0.25);
 return final;
  }
  char calculateLetterGrade(const double percent)
  {
 if(percent < 60)
 return 'F';
 else if(percent < 70)
 return 'D';
 else if(percent < 80)
 return 'C';
 else if (percent < 90)
 return 'B';
 else
 return 'A';
  }

 int main()
 {


 ifstream fin("gradeBook.txt");
 char letterGrade;


 cout << "This program reads a data file of student grades, calculates
the \n"
  << "final grade, and displays the student’s name and final
grade.\n\n\n";
 cout << "   Final Grades \n\n";
 while(!fin.eof())
 {
 fin >> student.firstName >> student.lastName >> student.ID;
 for(int i = 0; i < 0; i++)
 fin >> student.prgmGrades[i];
 for(int i = 0; i< 3; i++)
 fin >> student.examGrades[i];
 fin >> student.fexamGrade;
 student.finalGrade = calculatePercentGrade(student);
 letterGrade = calculateLetterGrade(student.finalGrade);
 cout << student.firstName << ' ' << student.lastName  <<
"\t\t"
  << letterGrade << '\n';
 }

return 0;
 }

[Bug c++/65936] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Sat May 23 22:28:54 2015
New Revision: 223613

URL: https://gcc.gnu.org/viewcvs?rev=223613&root=gcc&view=rev
Log:
cp/
PR c++/65936
* pt.c (lookup_template_class_1): Copy may_alias attribute too.

testsuite/
PR c++/65936
* g++.dg/template/pr65936.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/pr65936.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66267] internal compiler error: Segmentation fault

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-23
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
gcc-4.7 is not supported anymore (if you really want the 4.7 branch, 4.7.4 is
available that fixes many issues with 4.7.0). Can you reproduce on a more
recent compiler (at least 4.8.x, preferably 5.x)? What command line are you
using to compile the file? On what platform? By the way, it is better to attach
the file as copy-pasting tends to break long lines in inconvenient places.

[Bug c++/65936] [6 Regression] ICE: canonical types differ for identical types

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Patch committed to trunk

[Bug c++/66268] New: struct { volatile int x; } should not be trivially copyable

[comexk at gmail dot com]

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

Bug ID: 66268
   Summary: struct { volatile int x; } should not be trivially
copyable
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: comexk at gmail dot com
  Target Milestone: ---

According to the C++14 standard, a struct containing volatile fields shouldn't
be trivially copyable.  9.6 states:

> A trivially copyable class is a class that:
> — has no non-trivial copy constructors (12.8),

and 12.8.12 states:

> A copy/move constructor for class X is trivial if it is not user-provided, 
> its parameter-type-list is equivalent to the parameter-type-list of an 
> implicit declaration, and if
[..]
> — class X has no non-static data members of volatile-qualified type, and


GCC disagrees:

#include 
#include 

int main() {
struct foo { volatile int x; };
std::cout << std::is_trivially_copyable::value << std::endl;
}

/tmp % g++-5 --version
g++-5 (Homebrew gcc5 5.1.0) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

/tmp % g++-5 -std=c++14 -o test test.cpp && ./test
1

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color

[manu at gcc dot gnu.org]

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

--- Comment #26 from Manuel López-Ibáñez  ---
Author: manu
Date: Sat May 23 23:02:52 2015
New Revision: 223614

URL: https://gcc.gnu.org/viewcvs?rev=223614&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2015-05-24  Manuel López-Ibáñez  

PR fortran/44054
* gfortran.h (struct gfc_error_buf): Rename as
gfc_error_buffer. Move closer to push, pop and free
methods. Reimplement using an output_buffer.
* error.c (errors, warnings, warning_buffer, cur_error_buffer):
Delete everywhere in this file.
(error_char): Delete all contents.
(gfc_increment_error_count): Delete.
(gfc_error_now): Update comment. Set error_buffer.flag.
(gfc_warning_check): Do not handle warning_buffer.
(gfc_error_1): Delete.
(gfc_error_now_1): Delete.
(gfc_error_check): Simplify.
(gfc_move_error_buffer_from_to): Renamed from
gfc_move_output_buffer_from_to.
(gfc_push_error): Handle only gfc_error_buffer.
(gfc_pop_error): Likewise.
(gfc_free_error): Likewise.
(gfc_get_errors): Remove warnings and errors.
(gfc_diagnostics_init): Use static error_buffer.
(gfc_error_1,gfc_error_now_1): Delete declarations.
* symbol.c, decl.c, trans-common.c, data.c, expr.c, expr.c,
frontend-passes.c, resolve.c, match.c, parse.c: Replace
gfc_error_1 with gfc_error and gfc_error_now_1 with gfc_error_1
everywhere.
* f95-lang.c (gfc_be_parse_file): Do not update errorcount and
warningcount here.
* primary.c (match_complex_constant): Replace gfc_error_buf and
output_buffer with gfc_error_buffer.



Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/error.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-common.c

[Bug other/66259] Combined gcc and binutils build from git-master fails, with gas/as-new not existing

[darlingm at gmail dot com]

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

--- Comment #4 from Michael Darling  ---
symlinking binutils source first, and overwriting symlinks with gcc source did
not help - same error.

Have to run out for a bit, but I almost have this narrowed down to the exact
commit that caused this.  I'll report back.

[Bug middle-end/66269] New: Issues with mixing strict aliasing (verify_type ICE with Ada)

[hubicka at gcc dot gnu.org]

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

Bug ID: 66269
   Summary: Issues with mixing strict aliasing (verify_type ICE
with Ada)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Hi,
after fixing few issues I get to the following ICE with Ada.  This is due to
LTO preloading - the "int" type is produced by LTO FE, while "integer" type is
a variant of integer_type_node produced by Ada.
They disagree by alias set (variant has alias set 0). This comes from streaming
that notes alias set 0 on variants. Alias sets 0 on variants won't however work
because get_alias_set goes to main variant first.  I wonder what is the proper
fix? Also I wonder how mixing -fstrict-aliasing and -fno-strict-aliasing is
supposed to work? I guess we need variants of types with alias set 0 and make
alias.c/tree-ssa-alias.c to honor (i.e. not go to main variant if it disagree
on alias-set-0-ness) that? 

This has chance to work IMO at LTO (it is still iffy), but at compile time I am
not sure how we can deal with -fno-strict-aliasing in optimize attribute. 
Someone would need to produce type variants all the time and be sure that the
main variant never gets alias set 0...

Honza

../../gcc/ada/a-except.adb:852:0: error: type variant differs by
TYPE_ALIAS_SET.
end Exception_Name_Simple;
^
  constant 32>
unit size  constant 4>
align 32 symtab 16383 alias set 4 canonical type 0x3fff79ae07e0 precision
32 min  max 
pointer_to_this >
  constant 32>
unit size  constant 4>
align 32 symtab 0 alias set 0 canonical type 0x3fff79ae07e0 precision 32
min  max  context >
../../gcc/ada/a-except.adb:852:0: internal compiler error: verify_type failed

[Bug middle-end/66269] Issues with mixing strict aliasing (verify_type ICE with Ada)

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Actually this reproduce very easily with mixing two units with
-fstrict-aliasing and -fno-strict-aliasing.

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[casey.webster at gmail dot com]

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

Casey Webster  changed:

   What|Removed |Added

 CC||casey.webster at gmail dot com

--- Comment #5 from Casey Webster  ---
This bug still exists in fortran 5.1.0 (released version).  My testcase ended
up being a duplicate of the original post, so I won't repost that.

% gfortran -Wall -o final_bug_2 final_bug_2.f90
final_bug_2.f90:13:6:

   use A
  1
Warning: Only array FINAL procedures declared for derived type ‘typea’ defined
at (1), suggest also scalar one [-Wsurprising]

% gfortran -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.1.0/gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.1.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/python
--enable-objc-gc --enable-languages=c,c++,java,go,objc,obj-c++,fortran
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.1.0 p1.0,
pie-0.6.3' --enable-libstdcxx-time --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp
--enable-libcilkrts --enable-lto --with-isl --disable-isl-version-check
--enable-libsanitizer
Thread model: posix
gcc version 5.1.0 (Gentoo 5.1.0 p1.0, pie-0.6.3)

[Bug c++/66270] New: ICE: canonical types differ for identical types

[jamrial at gmail dot com]

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

Bug ID: 66270
   Summary: ICE: canonical types differ for identical types
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 35608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35608&action=edit
Preprocessed source as generated by -freport-bug

GCC 6.0.0 svn 223625

In file included from Vec.h:3:0,
 from Example.cc:8:
Vec8Float.h: In member function ‘avx::vec::Value& avx::vec::operator[](std::size_t)’:
Vec8Float.h:104:21: internal compiler error: canonical types differ for
identical types avx::vec::Value* {aka float*} and float*
 return ymm[index];
 ^
0x72abbe comptypes(tree_node*, tree_node*, int)
/home/jamrial/gcc-svn/gcc/cp/typeck.c:1423
0x745b4a ocp_convert(tree_node*, tree_node*, int, int, int)
/home/jamrial/gcc-svn/gcc/cp/cvt.c:704
0x5ece73 convert_like_real
/home/jamrial/gcc-svn/gcc/cp/call.c:6591
0x5f897b initialize_reference(tree_node*, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:9780
0x734c9c check_return_expr(tree_node*, bool*)
/home/jamrial/gcc-svn/gcc/cp/typeck.c:8730
0x76fc6e finish_return_stmt(tree_node*)
/home/jamrial/gcc-svn/gcc/cp/semantics.c:887
0x715a1e cp_parser_jump_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:11064
0x715a1e cp_parser_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:9707
0x715ff2 cp_parser_statement_seq_opt
/home/jamrial/gcc-svn/gcc/cp/parser.c:10095
0x71614b cp_parser_compound_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:10049
0x71637b cp_parser_function_body
/home/jamrial/gcc-svn/gcc/cp/parser.c:19223
0x71637b cp_parser_ctor_initializer_opt_and_function_body
/home/jamrial/gcc-svn/gcc/cp/parser.c:19259
0x717200 cp_parser_function_definition_after_declarator
/home/jamrial/gcc-svn/gcc/cp/parser.c:23519
0x71a804 cp_parser_late_parsing_for_member
/home/jamrial/gcc-svn/gcc/cp/parser.c:24202
0x6f58f9 cp_parser_class_specifier_1
/home/jamrial/gcc-svn/gcc/cp/parser.c:20079
0x6f58f9 cp_parser_class_specifier
/home/jamrial/gcc-svn/gcc/cp/parser.c:20105
0x6f58f9 cp_parser_type_specifier
/home/jamrial/gcc-svn/gcc/cp/parser.c:14734
0x708bce cp_parser_decl_specifier_seq
/home/jamrial/gcc-svn/gcc/cp/parser.c:11965
0x7181f8 cp_parser_single_declaration
/home/jamrial/gcc-svn/gcc/cp/parser.c:23773
0x718f3d cp_parser_explicit_specialization
/home/jamrial/gcc-svn/gcc/cp/parser.c:14630