[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
I have tested the patch in comment #2 (after fighting
with autoconf in maintainer-mode).  I'll commit tomorrow.

[Bug c/62198] New: spurious warning - initialization discards qualifier from pointer target type for pointer to array

[gary at intrepid dot com]

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

Bug ID: 62198
   Summary: spurious warning - initialization discards qualifier
from pointer target type for pointer to array
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com

Although this bug is filed against the 5.0 trunk, it can be duplicated with at
least 4.8.3.

Given:
$ cat q.c

typedef unsigned long size_t;
extern const void *alloc (size_t);

int main()
{
  const int (*X0)[10] = alloc (10 * sizeof (int));
  return !X0;
}

When compiled with gcc 4.8.3 the following warning is issued:

$ gcc -fpreprocessed -c q.c   
q.c: In function ‘main’:
q.c:7:25: warning: initialization discards ‘const’ qualifier from pointer
target type [enabled by default]
   const int (*X0)[10] = alloc (10 * sizeof (int));
 ^
Same thing for GCC 5.0 (trunk version 214178):

$ xgcc -fpreprocessed -c q.c
q.c: In function ‘main’:
q.c:7:25: warning: initialization discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
   const int (*X0)[10] = alloc (10 * sizeof (int));
 ^
Clang 3.4 issues no warning:

$ clang  -Wall -pedantic -Wextra  -c q.c


Given that the qualifier 'const' is associated with the array's element type,
it seems that the front end should derive the qualifier from the element type
when it is the target type of a declared pointer, before making the "discards
qualifier" check.

[Bug c++/62129] [4.9/5 Regression] internal compiler error: in output_constant, at varasm.c:4755

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/62150] [5.0 regression] test case g++.dg/ext/arm-fp16/fp16-mangle-1.C failed on ARM

[tony.wang at arm dot com]

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

wangzheyu  changed:

   What|Removed |Added

 CC||tony.wang at arm dot com

--- Comment #2 from wangzheyu  ---
Also happened on thumb1/thumb2.

[Bug c/62197] New: Option -Bprefix does not affect the search for the assembler

[r.berber at computer dot org]

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

Bug ID: 62197
   Summary: Option -Bprefix does not affect the search for the
assembler
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r.berber at computer dot org

A simple example showing the problem:

$ uname -a
Linux DiskStation 3.2.40 #4493 SMP Wed Jul 9 21:14:19 CST 2014 x86_64 GNU/Linux

$ gcc -dumpversion
4.9.1

$ echo 'main(){}' > dummy.c

$ strace gcc -B/opt/src/binutils-build/ld/tmpdir/gas/ dummy.c 2>&1 | grep "/as"
access("/opt/bin/as", X_OK) = 0

$ /opt/src/binutils-build/ld/tmpdir/gas/as -V
GNU assembler version 2.24 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.24

Every other program and file is searched for as the manual says, except the
assembler.

Using the alternative, GCC_EXEC_PREFIX, results in failure to find cc1.

[Bug lto/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from amker at gcc dot gnu.org ---
Closing.

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

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #8)
> > I will try to test a patch, meanwhile, I am wondering if any combine expert
> > has something to share.
> 
> distribute_notes is certainly an endless source of bugs.
One patch is sent at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01718.html
It's a scratch patch for discussion's purpose. Though I think it's right to
find distribution place for REG_DEAD note starting from i2 if it kills the
register, I am not sure if it's fixing the issue in a case by case manner.  So
it's highly appreciated if any expert in this area can share some opinions, or
review the patch?

> 
> > BTW, combine pass seems to be another ad-hoc implementation like reload, I 
> > saw
> > several "Don't know" in comments during this investigation!
> 
> You would need to define what an "ad-hoc implementation" is exactly.  See
> the top of the file for the origin of the pass.
Err, I may used the wrong word.  These are just frustrating words after seeing
several "Don't know" comments in the code.  Please ignore them.

Thanks.

[Bug target/62111] ICE when building Linux kernel for sh64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #11 from Segher Boessenkool  ---
Re: #c7:

In sh.c, change "char amount[6]" to "signed char
amount[6]" -- does that help?

[Bug c++/61214] [4.9/5 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 4.9.2 and trunk.

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Wed Aug 20 02:03:56 2014
New Revision: 214209

URL: https://gcc.gnu.org/viewcvs?rev=214209&root=gcc&view=rev
Log:
PR tree-optimization/62091
* g++.dg/ipa/devirt-39.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ipa/devirt-39.C

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Wed Aug 20 01:54:40 2014
New Revision: 214208

URL: https://gcc.gnu.org/viewcvs?rev=214208&root=gcc&view=rev
Log:
PR c++/61214
PR tree-optimization/62091
* decl2.c (decl_needed_p): Return true for virtual functions when
devirtualizing.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-39.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/decl2.c

[Bug c++/61214] [4.9/5 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Wed Aug 20 01:54:40 2014
New Revision: 214208

URL: https://gcc.gnu.org/viewcvs?rev=214208&root=gcc&view=rev
Log:
PR c++/61214
PR tree-optimization/62091
* decl2.c (decl_needed_p): Return true for virtual functions when
devirtualizing.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-39.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/decl2.c

[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.1   |4.9.2

--- Comment #12 from Jason Merrill  ---
Fixed for 4.9.2.

[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Wed Aug 20 01:17:37 2014
New Revision: 214206

URL: https://gcc.gnu.org/viewcvs?rev=214206&root=gcc&view=rev
Log:
PR c++/61566
* pt.c (instantiate_class_template_1): Ignore lambda on
CLASSTYPE_DECL_LIST.
(push_template_decl_real): A lambda is not primary.
* lambda.c (maybe_add_lambda_conv_op): Distinguish between being
currently in a function and the lambda living in a function.

Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/lambda.c
branches/gcc-4_9-branch/gcc/cp/pt.c
   
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template13.C

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Wed Aug 20 01:16:31 2014
New Revision: 214205

URL: https://gcc.gnu.org/viewcvs?rev=214205&root=gcc&view=rev
Log:
PR c++/60417
* init.c (build_vec_init): Set CONSTRUCTOR_IS_DIRECT_INIT on
init-list for trailing elements.
* typeck2.c (process_init_constructor_array): Likewise.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/init/explicit2.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/init.c
branches/gcc-4_9-branch/gcc/cp/typeck2.c

[Bug c++/62196] New: running time segment fault with valarray

[pangbw at gmail dot com]

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

Bug ID: 62196
   Summary: running time segment fault with valarray
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com

The code would segment fault at running time, I see the same result with G++
4.6.3(which comes with Ubuntu 12.04) and 4.9.1:

#include 
#include 

int main(int argc, char *argv[])
{
  const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
  const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
  const std::valarray v0(vl, 27), vm6(vu, 6);
  const bool vb[] = {false, false, true, true, false, true};
  const std::valarray vmask(vb, 6);
  std::valarray x = v0;

  for(int i = 0; i < x.size(); i++)
std::cout << x[i];
  std::cout << std::endl;

  x[vmask] = vm6;

  for(int i = 0; i < x.size(); i++)
std::cout << x[i];
  std::cout << std::endl;
  return 0;
}

The command line is just simply as:
g++ -std=c++0x x.cpp

[Bug preprocessor/51303] -Wmissing-include-dirs warnings reported as [enabled by default]

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #4 from Manuel López-Ibáñez  ---
FIXED for GCC 5.0

[Bug preprocessor/51303] -Wmissing-include-dirs warnings reported as [enabled by default]

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
Author: manu
Date: Tue Aug 19 22:52:02 2014
New Revision: 214201

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

2014-08-20  Manuel López-Ibáñez  

PR preprocessor/51303
* incpath.c (remove_duplicates): Use cpp_warning.

gcc/c-family/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR preprocessor/51303
* c-common.c (struct reason_option_codes_t option_codes):
Add CPP_W_MISSING_INCLUDE_DIRS. Sort alphabetically.

gcc/testsuite/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR preprocessor/51303
* gcc.dg/cpp/Wmissingdirs.c: Test for the warning option.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/incpath.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/Wmissingdirs.c

[Bug preprocessor/60975] -Wvariadic-macros does not print warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #5 from Manuel López-Ibáñez  ---
FIXED in GCC 5.0

[Bug preprocessor/60975] -Wvariadic-macros does not print warning

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
Author: manu
Date: Tue Aug 19 22:37:49 2014
New Revision: 214200

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

2014-08-20  Manuel López-Ibáñez  

PR c/60975
PR c/53063
* doc/options.texi (CPP): Document it.
* doc/invoke.texi (Wvariadic-macros): Fix documentation.
* optc-gen.awk: Handle CPP.
* opth-gen.awk: Likewise.

gcc/c-family/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR c/60975
PR c/53063
* c.opt (Wvariadic-macros): Use CPP and LangEnabledBy.
* c-opts.c (c_common_handle_option): Call cpp_handle_option_auto.
(c_common_post_options): Call init_global_opts_from_cpp.
(sanitize_cpp_opts): Do not handle Wvariadic-macros here.

gcc/testsuite/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR c/60975
PR c/53063
* gcc.dg/cpp/Wvariadic-1p.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/Wvariadic-1p.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/options.texi
trunk/gcc/optc-gen.awk
trunk/gcc/opth-gen.awk
trunk/gcc/testsuite/ChangeLog

[Bug c/53063] encode group options in the .opt files

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
Author: manu
Date: Tue Aug 19 22:37:49 2014
New Revision: 214200

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

2014-08-20  Manuel López-Ibáñez  

PR c/60975
PR c/53063
* doc/options.texi (CPP): Document it.
* doc/invoke.texi (Wvariadic-macros): Fix documentation.
* optc-gen.awk: Handle CPP.
* opth-gen.awk: Likewise.

gcc/c-family/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR c/60975
PR c/53063
* c.opt (Wvariadic-macros): Use CPP and LangEnabledBy.
* c-opts.c (c_common_handle_option): Call cpp_handle_option_auto.
(c_common_post_options): Call init_global_opts_from_cpp.
(sanitize_cpp_opts): Do not handle Wvariadic-macros here.

gcc/testsuite/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR c/60975
PR c/53063
* gcc.dg/cpp/Wvariadic-1p.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/Wvariadic-1p.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/options.texi
trunk/gcc/optc-gen.awk
trunk/gcc/opth-gen.awk
trunk/gcc/testsuite/ChangeLog

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #27 from Eric Botcazou  ---
Thanks.  This seems to be a conjunction of several factors, the initial one
being that the 4.8+ compiler generates (e.g for the reduced testcase at -O):

addl r14 = @ltoffx(_rtld_local#+15032385536), r1
;;
ld8.mov r14 = [r14], _rtld_local#+15032385536

The huge number is not problematic per se, although it very likely runs afoul
of some limitation/quirk here, since the value loaded from the GOT is
truncated.

In fact it looks like the value loaded from the GOT is just the huge number,
that is to say the value of _rtld_local has been zeroed during the relocation.

This may come from _rtld_local being in the .sdata section, in which case there
is a relevant comment in sdata_symbolic_operand:

  /* Deny the stupid user trick of addressing outside the object.  Such
 things quickly result in GPREL22 relocation overflows.  Of course,
 they're also highly undefined.  From a pure pedant's point of view
 they deserve a slap on the wrist (such as provided by a relocation
 overflow), but that just leads to bugzilla noise.  */

In other words, the compiler skips the efficient @gprel relocation on purpose,
only to generate the @ltoffx relocation, which doesn't work either here...

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #33349|0   |1
is obsolete||

--- Comment #26 from Eric Botcazou  ---
Created attachment 33365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33365&action=edit
Better reduced testcase

[Bug target/62195] [5 Regression] Invalid mnemonic 'xxlxor' on powerpc-apple-darwin9 with -m64

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-19
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Following the thread on IRC makers as ASSIGNED to meiss...@gcc.gnu.org.

[Bug target/62195] New: [5 Regression] Invalid mnemonic 'xxlxor' on powerpc-apple-darwin9 with -m64

[dominiq at lps dot ens.fr]

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

Bug ID: 62195
   Summary: [5 Regression] Invalid mnemonic 'xxlxor' on
powerpc-apple-darwin9 with -m64
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, meissner at gcc dot gnu.org,
segher at gcc dot gnu.org
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9

Between revisions r213754 (no error) and r214053 I get the following failures
on powerpc-apple-darwin9 with -m64:

Running target unix/-m64
FAIL: gcc.c-torture/compile/920501-15.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/920501-15.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/920501-15.c   -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/920501-15.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/920501-15.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/920501-15.c   -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.c-torture/compile/920501-15.c   -O2 -flto  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.c-torture/compile/920928-2.c   -O2 -flto  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O3 -fomit-frame-pointer -funroll-loops
 (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.c-torture/compile/pr34091.c   -O2 -flto  (test for excess errors)

The errors are of the kind

/var/tmp//ccPo810U.s:8:Invalid mnemonic 'xxlxor'

and require -On and -m64 with n>0.

[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #19 from Janne Blomqvist  ---
(In reply to Jerry DeLisle from comment #17)
> I have a patch in the works.  The idea is to query the locale at the time
> the Unit is connected and save the LC_NUMERIC character in the unit
> structure. Then, if the decimal character matches the DECIMAL_STATUS
> (decimal="point" or decimal="comma") active at the time of reading, change
> the decimal character internally to the current locale character previously
> saved. This way, only one call to locale is needed per unit connection,
> preserving efficiency. The real string will then be converted correctly,
> regardless of locale.

While clever, I'm not sure this approach works. A program can change the locale
between opening the file and reading from it (potentially in another thread,
since the locale is a process-wide property).

What can be done instead is to use the POSIX 2008 extended locale functionality
(newlocale) to create a "locale object" in the default C locale and then use
functions like strtod_l (for some reason not in POSIX 2008, though at least
glibc and BSD/OSX have it, IIRC) that take such a locale object as argument.
This is fairly new though and not available everywhere, but ought to be robust.

See also PR 47007.

As an aside, AFAIK the "C" and "POSIX" locales are the same, just two names for
the same thing. "C" might be more portable, as that should work everywhere
there is a C implementation.

[Bug c++/62153] warn for bool expression compared with integer different from 0/1

[sirl at gcc dot gnu.org]

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

--- Comment #8 from Franz Sirl  ---
Hmm, what about the assignment part of the merged bug 44077:

 _Bool var = 3;

Does the fix warn about this? Should I create a new bug report for this part?

[Bug c/62194] New: Add deadfield attribute to ignore initializers for a structure field

[josh at joshtriplett dot org]

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

Bug ID: 62194
   Summary: Add deadfield attribute to ignore initializers for a
structure field
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josh at joshtriplett dot org

This request is the result of a discussion at Kernel Summit 2014, about
handling conditional code without massive transitions or excessive preprocessor
abuse.

Frequently, a structure will have a field that is only used with specific
configurations.  For instance, a driver may have an "ops" structure with
suspend/resume methods, but those methods will only be called if the kernel
configuration supports suspend/resume.  If we configure suspend/resume out of
the kernel, nothing will call or otherwise read foo->suspend(...).  However,
drivers will still have designated assignments to that structure field:

struct something_ops {
...
.suspend = foo_suspend,
.resume = foo_resume,
...
}

Currently, this has to work in one of two ways: either the structure fields
unconditionally exist in all cases so that the designated assignments don't
break (keeping a reference to the functions and preventing them from being
compiled out), or the structure field and corresponding designated assignments
must be #ifdef'd out (requiring a massive transition and a pile of ugly
preprocessor directives proportional to the number of structures).

Discussion at Kernel Summit came up with the following alternative:

Create a new attribute "deadfield".  A field with that attribute is not
actually included in the layout of the structure.  Writes or designated
assignments to the field get ignored.  Attempting to read from the field
produces an error.  Values assigned to dead fields are treated as
__attribute__((unused)).

That would then allow definitions of instances of the structure to remain
unmodified in all configurations.

Optionally, the "deadfield" attribute could take a single parameter, which is a
constant value to substitute for any read from the field rather than producing
an error.  For instance, a function pointer field may have a do-nothing stub
function (which GCC can then inline and turn into no code), or a flag field may
have a constant value (allowing subsequent constant-folding).

I'm willing to work on a patch for this.

[Bug c++/62189] Different result between 4.6 and 4.9.1

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
You need to change your expected outcome of your test-suite. According to the
C++ standard, the expected outcome is 0. As of [func.wrap.func.con] p9:

Postconditions: !*this if any of the following hold:
— f is a null function pointer value.
[..]

Therefore, gcc 4.9.1 is right.

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
> I will try to test a patch, meanwhile, I am wondering if any combine expert
> has something to share.

distribute_notes is certainly an endless source of bugs.

> BTW, combine pass seems to be another ad-hoc implementation like reload, I saw
> several "Don't know" in comments during this investigation!

You would need to define what an "ad-hoc implementation" is exactly.  See the
top of the file for the origin of the pass.

[Bug c++/62153] warn for bool expression compared with integer different from 0/1

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
-Wbool-compare has been added.

[Bug ada/62193] New: There is a bug in the Ada runtime which causes some Ada time functions to fail on the MinGW 32-bit platform .

[jdgress...@amli-denton.com]

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

Bug ID: 62193
   Summary: There is a bug in the Ada runtime which causes some
Ada time functions to fail on the MinGW 32-bit
platform .
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdgress...@amli-denton.com

Created attachment 33364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33364&action=edit
A patch which corrects a problem that occurs in 32-bit Windows Ada when the
compiler is built with a C runtime with a 64-bit time_t type

There is a bug in the gcc Ada runtime which causes some routines
in the Ada.Calendar runtime package (and its child packages) to produce
incorrect results on the MinGW 32-bit Windows platform. I found the bug when
using the V4.8.1 MinGW Windows 32-bit, but it is a long-standing bug that still
exists in
later releases.

This can be demonstrated with the following Ada program when it
is compiled with the MinGW 32-bit 4.8.1 compiler:

with Ada.Calendar,
Ada.Text_IO;

use Ada.Calendar,
Ada.Text_IO;

procedure Simple_BugTest
is
Test_Date: Time;
YN: Year_number;
MN: Month_Number;
DN: Day_Number;
SN: Day_Duration;
ISN: Integer;

begin
Test_Date := Time_Of(2013, 10, 3);
Split(Test_Date, YN, MN, DN, SN);
ISN := Integer(SN);
Put_Line("Time_Of(2013, 10, 3) is ");
Put("Year:" & Integer'Image(YN));
Put(", Month:" & Integer'Image(MN));
Put(", Day:" & Integer'Image(DN));
Put_Line(", Seconds:" & Integer'Image(ISN));
end Simple_BugTest;

When compiled with the MinGW 4.8.1-4 Ada compiler, which uses
the MinGW 4.0.3-1 runtime package, this produces the following
incorrect output:

Time_Of(2013, 10, 3) is
Year: 2013, Month: 9, Day: 29, Seconds: 68327

When compiled with an Ada runtime patch which corrects the
problem, the output becomes:

Time_Of(2013, 10, 3) is
Year: 2013, Month: 10, Day: 3, Seconds: 0

which is correct.

The bug which causes the problem is in the Ada runtime library
source code, found in the gcc/ada subdirectory of the compiler
source. It is caused by an incorrect assumption about time
types which is embedded in the Ada and C source code files
in the gcc/ada subdirectory.

The Ada calendar routines define the Ada version of the time_t type as

type time_t is range
-(2 (Standard'Address_Size - Integer'(1))) ..
+(2 (Standard'Address_Size - Integer'(1)) - 1);

The key item here is the Ada expression

Standard'Address_Size

The MinGW Ada compiler is a 32-bit compiler.
The result is that the Ada time_t is a 32-bit
signed integer type. A value of this type is passed to the
C procedure __gnat_localtime_tzoff which is in a C file named
sysdep.c in the Ada runtime source code directory.

In the C code, the receiving argument of this Ada time_t type
is a C time_t type, the first argument of __gnat_localtime_tzoff,
declared as:

const time_t *timer

This is where the trouble starts. When the C time_t is a 64-bit
type, the value passed into __gnat_localtime_tzoff contains the
Ada time_t value as 32 bits of a 64-bit value, and the other 32
bits are nonsense.

In short, the Ada runtime library code is assuming that Ada
Standard'Address_Size and C sizeof(time_t) are always the same
value. The V4 release of the MinGW runtime has broken that assumption.

The patch works by defining a new time type for use in the
__gnat_localtime_tzoff function: ada_time_t.

This new type is based on the existing type intptr_t found in
 and is defined by the patch as

typedef intptr_t ada_time_t;

The offending time declaration is in the first argument of
__gnat_localtime_tzoff:

void
__gnat_localtime_tzoff (const time_t timer,
const int is_historic, long *off)

The patch corrects that to

void
__gnat_localtime_tzoff (const ada_time_t ada_timer,
const int is_historic, long *off)

The patch defines a new local variable in __gnat_localtime_tzoff:

time_t timer;

The local variable is then initialized:

timer = (time_t) *ada_timer;

This line is where the bug is actually fixed. The 32-bit Ada time
type is properly extended to a 64-bit type, but it would just be
a trivial copy when compiled by a 64-bit compiler.

The new local variable timer then replaces all instances of *timer
in the body of the function __gnat_localtime_tzoff.

Note that a patch like this would work on any 32-bit platform which
introduced a new 64-bit time_t type in its C runtime. That is why I
did not base ada_time_t on a Windows-specific type.

The patch is in the attachment.

[Bug c++/62153] warn for bool expression compared with integer different from 0/1

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue Aug 19 18:50:00 2014
New Revision: 214183

URL: https://gcc.gnu.org/viewcvs?rev=214183&root=gcc&view=rev
Log:
PR c++/62153
* doc/invoke.texi: Document -Wbool-compare.
c-family/
* c-common.c (maybe_warn_bool_compare): New function.
* c-common.h (maybe_warn_bool_compare): Declare.
* c.opt (Wbool-compare): New option.
c/
* c-typeck.c (build_binary_op): If either operand of a comparison
is a boolean expression, call maybe_warn_bool_compare.
cp/
* call.c (build_new_op_1): Remember the type of arguments for
a comparison.  If either operand of a comparison is a boolean
expression, call maybe_warn_bool_compare.
testsuite/
* c-c++-common/Wbool-compare-1.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wbool-compare-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/62192] New: Segmentation fault when linking with Qt libraries

[lakjdsfiudslkfj at mailinator dot com]

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

Bug ID: 62192
   Summary: Segmentation fault when linking with Qt libraries
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lakjdsfiudslkfj at mailinator dot com

Created attachment 33363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33363&action=edit
gdb backtrace

Hi,

I'm currently having some difficulties linking to my library when my main
executable is linked with some Qt libraries. I'm running FreeBSD 10 and gcc47
but the latest 410 package for FreeBSD exhibits the same behavior.

My main.cc looks like this:

---
#include "foo.h"

int main() {
  foo();
}
---

My library libfoo consists of a file foo.cc:

---
#include 
#include 

void foo() {
  std::string lol = "test";
  std::cout << lol << std::endl;;
}
---

foo.h for completeness:
--
void foo();
--

and is compiled via
g++ -g -c -fPIC foo.cc -o libfoo.o
g++ -shared -fPIC libfoo.o -o libfoo.so

After this my main.cc is compiled/linked:

g++ -g -O0 -I/tmp/delme2 -DQT_SHARED -I/usr/local/include/qt4
-I/usr/local/include/qt4/QtCore -L/usr/local/lib/qt4 -lQtCore -L/tmp/delme2
-lfoo main.cc

running a.out yields "segmentation fault (core dumped)  ./a.out"

with clang++ -g -O0 -I/tmp/delme2 -DQT_SHARED -I/usr/local/include/qt4
-I/usr/local/include/qt4/QtCore -L/usr/local/lib/qt4 -lQtCore -L/tmp/delme2
-lfoo main.cc

the output is "test" as expected.

It also works when I remove the Qt libraries, i.e.
g++ -g -O0 -I/usr/local/include -I/tmp/delme2 -L/tmp/delme2 -lfoo main.cc

Am I doing something wrong here? Is it a Qt problem rather than gcc? But why
does it work with clang then? I attached a GDB backtrace just in case.

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
My patch doesn't fix the ICE in comment 7, just devirtualization on
devirt-38.C.

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Tue Aug 19 18:25:45 2014
New Revision: 214181

URL: https://gcc.gnu.org/viewcvs?rev=214181&root=gcc&view=rev
Log:
PR tree-optimization/62091
* decl2.c (decl_needed_p): Return true for virtual functions when
devirtualizing.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/g++.dg/ipa/devirt-38.C

[Bug target/62191] New: extra shift generated for vector integer division by constant 2

[spatel at rotateright dot com]

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

Bug ID: 62191
   Summary: extra shift generated for vector integer division by
constant 2
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spatel at rotateright dot com

Using gcc 4.9:

$ cat sdiv.c
typedef int vecint __attribute__((vector_size(16))); 
vecint f(vecint x) { 
return x/2;
} 

$ gcc -O2 sdiv.c -S -o  -
...
movdqa%xmm0, %xmm1
psrad$31, %xmm1<--- splat the sign bit
psrld$31, %xmm1<--- then shift sign bit down to LSB
paddd%xmm1, %xmm0  <--- add sign bit to quotient
psrad$1, %xmm0 <--- div via alg shift right
ret

--

I don't think the first shift right algebraic is necessary. We splat the sign
bit and then shift that right logically, so the upper bits are all zero'd
anyway. 

This is a special case for signed integer division by 2. You need that first
'psrad' for any other power of 2 because the subsequent logical shift would not
also be a shift of 31.

[Bug lto/62190] New: LTO DWARF produces __unknown__ type for unsigned int function argument type

[mark at gcc dot gnu.org]

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

Bug ID: 62190
   Summary: LTO DWARF produces __unknown__ type for unsigned int
function argument type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark at gcc dot gnu.org

Take the following program:

/* LTO sometimes outputs __unknown__ for an unsigned int argument type. */
/* { dg-do run } */
/* { dg-options "-gdwarf" } */

static __attribute__((noclone, noinline)) int
func (unsigned int n)
{
  return (int) n;
}

int
main (int argc, char **argv)
{
  return func (0);
}

/* { dg-final { gdb-test 12 "type:func" "int (unsigned int)" } } */

And compile it with /opt/local/build/gcc-obj/gcc/xgcc
-B/opt/local/build/gcc-obj/gcc/ ltounsignedint.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none -g -o ./ltounsignedint.exe

Or just drop it in gcc/testsuite/gcc.dg/guality/ltounsignedint.c and run make
check-c RUNTESTFLAGS=guality.exp=ltounsignedint.c

Notice how the formal_parameter n gets a type with name "__unknown__":

 [46]  formal_parameter
   name (string) "n"
   decl_file(data1) 1
   decl_line(data1) 6
   type (ref4) [59]
   location (exprloc) 
[   0] reg5

 [59]base_type
 byte_size(data1) 4
 encoding (data1) unsigned (7)
 name (strp) "__unknown__"

[Bug c++/62189] New: Different result between 4.6 and 4.9.1

[pangbw at gmail dot com]

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

Bug ID: 62189
   Summary: Different result between 4.6 and 4.9.1
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com

For this program, I get different result for G++ 4.6.3 and G++ 4.9.1, and I
have a C++ test suite which thinks 4.6.3 is right:

#include   
   #include  
  int (*pfb_)() = nullptr; 
 int main() 
{   
  std::function< int() > e (pfb_);
  std::cout << !!e << std::endl;
  return 0; 
}

For 4.6.3 the output is 1 but for 4.9.1 the output is 0.

[Bug lto/53808] Undefined symbol when building a library with lto

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Tue Aug 19 17:29:41 2014
New Revision: 214177

URL: https://gcc.gnu.org/viewcvs?rev=214177&root=gcc&view=rev
Log:
PR lto/53808
PR c++/61659
* decl.c (maybe_commonize_var): Don't use DECL_COMDAT to trigger
comdat_linkage.

Added:
trunk/gcc/testsuite/g++.dg/abi/spec1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug ipa/61659] [4.9/5 Regression] Extra undefined symbol because of devirtualization

[jason at gcc dot gnu.org]

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

--- Comment #22 from Jason Merrill  ---
Author: jason
Date: Tue Aug 19 17:29:41 2014
New Revision: 214177

URL: https://gcc.gnu.org/viewcvs?rev=214177&root=gcc&view=rev
Log:
PR lto/53808
PR c++/61659
* decl.c (maybe_commonize_var): Don't use DECL_COMDAT to trigger
comdat_linkage.

Added:
trunk/gcc/testsuite/g++.dg/abi/spec1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c/45584] typeof with casting from const to non-const does not work properly

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #3 from Marek Polacek  ---
Should be fixed now.

[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-19
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.  I assume you found this by using a libc with
a malloc that has buffer overflow detection.  The obvious
patch is 

Index: m4/bessel.m4
===
--- m4/bessel.m4(revision 213593)
+++ m4/bessel.m4(working copy)
@@ -163,7 +163,7 @@ bessel_yn_r'rtype_kind` ('rtype` * const

   x2rev = GFC_REAL_'rtype_kind`_LITERAL(2.)/x;

-  for (i = 2; i <= n1+n2; i++)
+  for (i = 2; i <= n2 - n1; i++)
 {
 #if defined('rtype_name`_INFINITY)
   if (unlikely (last2 == -'rtype_name`_INFINITY))

I'll commit this later.

[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to David Binderman from comment #8)
> Created attachment 33361 [details]
> C++ source code

Please ignore this attachment. It is for a different bug.

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #4 from DJ Delorie  ---
Perhaps you need this patch:

https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman  ---
Created attachment 33362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33362&action=edit
C++ source code

[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #8 from David Binderman  ---
Created attachment 33361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33361&action=edit
C++ source code

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Aug 19 16:23:36 2014
New Revision: 214168

URL: https://gcc.gnu.org/viewcvs?rev=214168&root=gcc&view=rev
Log:
Set install_gold_as_default to no first

PR other/62168
* configure.ac: Set install_gold_as_default to no first.
 * configure: Regenerated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug c++/62186] segfault on map.insert

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The order outside translation units of initialization is unspecified in c++.

[Bug tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)

[vp at gcc dot gnu.org]

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

vp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vp at gcc dot gnu.org

--- Comment #37 from vp at gcc dot gnu.org ---
I see this issue in AArch64 as well on 4.9 branch and on the trunk causing
performance regression.

Since MG3P is inlined at MAIN__, all the four calls to RESID are in MAIN__. Two
of which are to the clone resid_.constprop.1 (not vectorized) and one to resid_
(vectorized) and the last one inlined (not vectorized and it looks very similar
to the resid_.constprop.1 version).

I could however, improve by passing -fno-inline-functions and -fno-ipa-cp at
-Ofast (so that all the calls are to resid_ which gets vectorized).

Anyone working on this issue?

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
I am not sure this is fixed. Attached code, when
compiled by 20140817, with flags -std=gnu++11 -O2,
does the following

$ ../results/bin/gcc -c -std=gnu++11 -O2 bug161.cc
listformatter.cpp: In member function ‘icu_53::UnicodeString&
icu_53::ListFormatter::format(const icu_53::UnicodeString*, int32_t,
icu_53::UnicodeString&, int32_t, int32_t&, UErrorCode&) const’:
listformatter.cpp:304:16: internal compiler error: in before_dom_children, at
tree-ssa-pre.c:4410
0xbecf2c eliminate_dom_walker::before_dom_children(basic_block_def*)
../../src/trunk/gcc/tree-ssa-pre.c:4410
0xf72c67 dom_walker::walk(basic_block_def*)
../../src/trunk/gcc/domwalk.c:177
0xbe9fd2 eliminate
../../src/trunk/gcc/tree-ssa-pre.c:4525
0xbeb1dc execute
../../src/trunk/gcc/tree-ssa-pre.c:4940
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/45584] typeof with casting from const to non-const does not work properly

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from ppalka at gcc dot gnu.org ---
Author: ppalka
Date: Tue Aug 19 14:14:15 2014
New Revision: 214151

URL: https://gcc.gnu.org/viewcvs?rev=214151&root=gcc&view=rev
Log:
2014-08-19  Patrick Palka  

PR c/45584
* c-typeck.c (build_c_cast): Do a conversion even when the
TYPE_MAIN_VARIANTs are the same.

2014-08-19  Patrick Palka  

PR c/45584
* gcc.dg/pr13519-1.c: Adjust.



Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr13519-1.c

[Bug c++/62150] [5.0 regression] test case g++.dg/ext/arm-fp16/fp16-mangle-1.C failed on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.3, 4.9.0, 4.9.1
   Keywords||wrong-code
   Last reconfirmed||2014-08-19
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|test case   |[5.0 regression] test case
   |g++.dg/ext/arm-fp16/fp16-ma |g++.dg/ext/arm-fp16/fp16-ma
   |ngle-1.C failed on ARM  |ngle-1.C failed on ARM
  Known to fail||5.0

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

[Bug libfortran/62188] New: Array bounds overrun in bessel_yn_r4/8/16 and other functions

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 62188
   Summary: Array bounds overrun in bessel_yn_r4/8/16 and other
functions
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com

There's an array bounds overrun in
gfortran/generated/bessel_r4.c:bessel_yn_r4().  The function is passed the
arguments n1 and n2 (n1 <= n2) and allocates memory for (n2 - n1 + 1) result
values:

  size_t size = n2 < n1 ? 0 : n2-n1+1;
  ...
  ret->base_addr = xmallocarray (size, sizeof (GFC_REAL_4));

But later on it writes from index 0 to n1 + n2:

  for (...; i <= n1+n2; ...)
...  ^
ret->base_addr[i*stride] = ...;

The loop should be

  for (i = 2; i < n2-n1; i++)

instead.  The same bug exists in bessel_r8.c and bessel_r16.c and has been
present since at least gcc-4.8.  The existing test cases (bessel_.f90) all
use 0 or low values > 0, so they have not caught this bug yet.

[Bug libstdc++/62187] New: std::string==const char* could compare sizes first

[glisse at gcc dot gnu.org]

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

Bug ID: 62187
   Summary: std::string==const char* could compare sizes first
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

Hello,

when I compare 2 basic_string with ==, libstdc++ only uses the optimization of
first checking that the sizes are the same (before calling compare) if
__is_char<_CharT> and the traits and allocator are the default ones. I don't
understand why, but assuming there is a good reason, I believe the optimization
should still apply when comparing std::string and const char*.

(this applies to __vstring as well)

This was noticed in PR 62156, where we also see that std::string("foo") does a
memcpy of size 3 then sets the 4th char to '\0', where a single memcpy of size
4 would make sense.

[Bug lto/62179] undefined reference linking failure when combining "extern template"

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

[Bug c++/62186] New: segfault on map.insert

[james1479 at gmail dot com]

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

Bug ID: 62186
   Summary: segfault on map.insert
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: james1479 at gmail dot com

Getting a segfault on map.insert if called as a global initialiser from another
source file.

 a.cpp
#include 

std::map m;

int g() {
m.insert( std::pair(1,1) );
return 0;
}
 main.cpp  
int g(int i);
int a = g(1);

int main() { return 0; }
##

This code either works or segfaults depending on which order they are passed to
g++:
% g++ a.cpp main.cpp
% ./a.out 
% g++ main.cpp a.cpp
% ./a.out 
[1]9548 segmentation fault (core dumped)  ./a.out

This also happens if they are compiled to .o files and linked together:
% g++ -c a.cpp 
% g++ -c main.cpp
% g++ a.o main.o 
% ./a.out 
% g++ main.o a.o
% ./a.out
[1]10485 segmentation fault (core dumped)  ./a.

The program works if compiled as a single source program. 

Or if `int a = g(1);` is moved inside the main function.

Or if m.clear() is called before the insert.

g++ version (from archlinux repo):
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9.1/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-isl-version-check
--disable-cloog-version-check --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.1 (GCC)

[Bug middle-end/62140] [GCC-4.10.0][ASAN] ICE: : in build2_stat, at tree.c:4265

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||jakub at redhat dot com,
   ||tetra2005 at gmail dot com

--- Comment #3 from Yuri Gribov  ---
This is probably duplicate of #61897 .

[Bug debug/59051] DW_tag_restrict_type not used

[mark at gcc dot gnu.org]

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

--- Comment #2 from Mark Wielaard  ---
Author: mark
Date: Tue Aug 19 11:50:55 2014
New Revision: 214143

URL: https://gcc.gnu.org/viewcvs?rev=214143&root=gcc&view=rev
Log:
Emit DW_tag_restrict_type for restrict-qualified pointers.

gcc/ChangeLog

PR debug/59051
* dwarf2out.c (modified_type_die): Handle TYPE_QUAL_RESTRICT.

gcc/testsuite/ChangeLog

PR debug/59051
* gcc.dg/guality/restrict.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/guality/restrict.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Libsanitizer does not support building with -fexceptions. Patch was proposed in
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01764.html

[Bug sanitizer/62089] Sanitizer may fail to instrument struct accesses

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

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

--- Comment #3 from Yury Gribov  ---
Fixed.

[Bug c++/62185] New warning for "defined as a struct here but previously declared as a class" / [-Wmismatched-tags]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This warning is useless and is a broken warning.

[Bug c++/62185] New: New warning for "defined as a struct here but previously declared as a class" / [-Wmismatched-tags]

[burnus at gcc dot gnu.org]

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

Bug ID: 62185
   Summary: New warning for "defined as a struct here but
previously declared as a class" / [-Wmismatched-tags]
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

I am not really sure whether it's worthwhile, but browsing through the warnings
for our code, I found the following one by Clang, which GCC doesn't seem to
have:


foo.cc:5:1: warning: 'foo' defined as a struct here but previously declared as
a class [-Wmismatched-tags]
struct foo {
^
foo.cc:2:1: note: did you mean struct here?
class foo;
^
struct


Clang emits this warning with -Wall.


Test case:

// Assume some forward declaration in a header file
class foo;

// Assume a C file, #including the header file
struct foo {
  int a;
};

[Bug c/62141] [GCC-4.10.0][ASAN] ICE: Segmentation fault: 11

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
I couldn't repro with fresh trunk on x86_64-apple-darwin12.5.0 and
x86_64-unknown-linux-gnu.

[Bug c/61271] 10 * possible coding error with logical not (!)

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Author: mpolacek
Date: Tue Aug 19 11:35:39 2014
New Revision: 214142

URL: https://gcc.gnu.org/viewcvs?rev=214142&root=gcc&view=rev
Log:
PR c/61271
* cgraphunit.c (handle_alias_pairs): Fix condition.

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

[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 19 Aug 2014, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
> 
> --- Comment #5 from Marc Glisse  ---
> (In reply to rguent...@suse.de from comment #4)
> > Eventually worth "fixing" the libstdc++ side to generate better
> > initial code?
> 
> Replacing memcpy(,,3)+assign(,'\0') with memcpy(,,4) can indeed be done at the
> libstdc++ level (although simplify_builtin_call in tree-ssa-forwprop.c already
> does a transformation extremely similar and could be extended). As shown in
> comment #3, the test/jump will disappear when we move to C++11.
> 
> But essentially, it can't avoid doing memcpy, setting the length of the 
> string,
> and calling memcmp.
> 
> One surprising thing it does not is, at the beginning of operator==, check if
> the sizes are the same before calling memcmp...
> 
> > Other than that it seems this would need careful special-handling
> > in value-numbering ...
> 
> That seems like the best place indeed.
> 
> > not sure if optimizing std::string("foo") == "bar" is important.
> 
> The question is how many other optimizations this would enable. I remember
> other cases where we couldn't see through memcpy well enough (PR 58483 for
> instance, there were others probably more relevant), but I don't know if this
> would help them.
> 
> In any case, I agree this isn't a priority.

The special thing with memcmp is that it evaluates to a value
we'd like to compute while the usual look-through-memcpy is
for value-numbering loads.

So it won't be that easy...

IMHO it would be nicer if we'd fix PR52171 which should be able
to catch your simple case then via existing value-numbering code
at least if the compare includes the trailing zero.

[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to rguent...@suse.de from comment #4)
> Eventually worth "fixing" the libstdc++ side to generate better
> initial code?

Replacing memcpy(,,3)+assign(,'\0') with memcpy(,,4) can indeed be done at the
libstdc++ level (although simplify_builtin_call in tree-ssa-forwprop.c already
does a transformation extremely similar and could be extended). As shown in
comment #3, the test/jump will disappear when we move to C++11.

But essentially, it can't avoid doing memcpy, setting the length of the string,
and calling memcmp.

One surprising thing it does not is, at the beginning of operator==, check if
the sizes are the same before calling memcmp...

> Other than that it seems this would need careful special-handling
> in value-numbering ...

That seems like the best place indeed.

> not sure if optimizing std::string("foo") == "bar" is important.

The question is how many other optimizations this would enable. I remember
other cases where we couldn't see through memcpy well enough (PR 58483 for
instance, there were others probably more relevant), but I don't know if this
would help them.

In any case, I agree this isn't a priority.

[Bug target/62178] [AArch64] Performance regression on matrix matrix multiply due to r211211

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #3 from bin.cheng  ---
I think it's a flaw in iv candidates choosing algorithm revealed by my patch.
Though r211211 does change cost of addressing modes, it doesn't change the cost
of optimal candidate set.  The problem with iv candidates choosing algorithm is
it's a heuristic one and would fail to find the optimal set for this specific
case.

In details, the only cost differences between r211210/r211211 is like below 
***
*** 1,8 
  Use 1:
candcostcompl.depends on
!   11611
910
!   10411
1110
!   1250
!   14811
--- 1,8 
  Use 1:
candcostcompl.depends on
!   11311
910
!   10111
1110
!   1211
!   14511

The final candidates set choosed by r211210 is like below.

Initial set of candidates:
  cost: 19 (complexity 2)
  cand_cost: 10
  cand_use_cost: 5 (complexity 2)
  candidates: 11, 14
   use:0 --> iv_cand:14, cost=(4,2)
   use:1 --> iv_cand:11, cost=(1,0)
   use:2 --> iv_cand:11, cost=(0,0)
  invariants 1

Improved to:
  cost: 15 (complexity 0)
  cand_cost: 10
  cand_use_cost: 2 (complexity 0)
  candidates: 11, 13
   use:0 --> iv_cand:13, cost=(1,0)
   use:1 --> iv_cand:11, cost=(1,0)
   use:2 --> iv_cand:11, cost=(0,0)
  invariants 1

The final candidates set choosed by r211211 is like below.

Initial set of candidates:
  cost: 17 (complexity 3)
  cand_cost: 5
  cand_use_cost: 9 (complexity 3)
  candidates: 14
   use:0 --> iv_cand:14, cost=(4,2)
   use:1 --> iv_cand:14, cost=(5,1)
   use:2 --> iv_cand:14, cost=(0,0)

It is clear, r211211 doesn't change the optimal candidates set (which is
13/11).  It is the algorithm that can't find out the optimal set because it's
heuristic and would fail on this one.

With manual changes of candidates set, the diff of assembly code is like below.
*** 6,46 
  .typeIntmm, %function
  Intmm:
  moviv3.2s, 0
  adrpx6, a+128
! adrpx8, r+128
! adrpx10, r+3848
! adrpx9, b+128
! adrpx7, b+248
  addx6, x6, :lo12:a+128
! addx8, x8, :lo12:r+128
! addx10, x10, :lo12:r+3848
! addx9, x9, :lo12:b+128
! addx7, x7, :lo12:b+248
  .L2:
! movx5, x8
! movx4, x8
! movx3, x9
  .L4:
! strd3, [x4]
! addx2, x3, 3720
  moviv0.2s, 0
  movx1, x6
! movx0, x3
  .L3:
! ldrd1, [x0]
! addx0, x0, 124
  ld1r{v2.2s}, [x1], 4
! cmpx0, x2
  mlav0.2s, v2.2s, v1.2s
  bne.L3
! strd0, [x5], 8
  addx3, x3, 8
! cmpx3, x7
! addx4, x4, 8
  bne.L4
! addx8, x8, 124
  addx6, x6, 124
! cmpx8, x10
  bne.L2
  ret
  .sizeIntmm, .-Intmm
--- 6,42 
  .typeIntmm, %function
  Intmm:
  moviv3.2s, 0
+ adrpx4, r+128
  adrpx6, a+128
! adrpx7, r+3848
! adrpx5, b
! addx4, x4, :lo12:r+128
  addx6, x6, :lo12:a+128
! addx7, x7, :lo12:r+3848
! addx5, x5, :lo12:b
  .L2:
! movx3, 0
  .L4:
! strd3, [x4, x3]
! addx0, x3, 128
  moviv0.2s, 0
+ addx2, x3, 3848
+ addx2, x2, x5
  movx1, x6
! addx0, x5, x0
  .L3:
! ldrd1, [x0], 124
  ld1r{v2.2s}, [x1], 4
! cmpx2, x0
  mlav0.2s, v2.2s, v1.2s
  bne.L3
! strd0, [x4, x3]
  addx3, x3, 8
! cmpx3, 120
  bne.L4
! addx4, x4, 124
  addx6, x6, 124
! cmpx4, x7
  bne.L2
  ret
  .sizeIntmm, .-Intmm

You can see the inner most loop is back to optimized.  The additinal
instruction in the second loop is caused by addressing mode change, but I think
it can be fixed by enabling auto-increment addressing mode for IVOPT on
aarch64.  YES, we hasn't done that yet.


I will see how the IVOPT candidates choosing algorithm should be improved.

[Bug tree-optimization/62167] [tail-merge] dead type-unsafe load replaces type-safe load

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-19
 Ever confirmed|0   |1

[Bug tree-optimization/62167] [tail-merge] dead type-unsafe load replaces type-safe load

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 33360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33360&action=edit
tentative patch, testing atm

[Bug c/62183] [C/C++] Warning wished for "!int_val == const" / logical not is only applied to the left hand side of this comparison

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I implemented -Wlogical-not-parentheses a while ago.  It's not in -Wall yet
though, see PR61271.

[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||mpolacek at gcc dot gnu.org
Summary|[C/C++] Extend -Wempty-body |[C/C++] Extend -Wempty-body
   |to  |to 'while' loops

--- Comment #1 from Tobias Burnus  ---
For an empty "if" loop, GCC warns with -Wextra:

foo.cc:5:13: warning: suggest braces around empty body in an ‘if’ statement
[-Wempty-body]
   if (bar());
 ^


However, using a "while" loop, it doesn't. Clang warns (by default) in that
case:

foo.cc:5:16: warning: while loop has empty body [-Wempty-body]
  while (bar());
   ^
foo.cc:5:16: note: put the semicolon on a separate line to silence this warning


Again, I found that issue in a real-world code.

Test case:

int bar ();
void sleep();

int foo() {
  while (bar());
sleep();
  return 1;
}

[Bug c/62184] New: [C/C++] Extend -Wempty-body to

[burnus at gcc dot gnu.org]

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

Bug ID: 62184
   Summary: [C/C++] Extend -Wempty-body to
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

[Bug c/62183] New: [C/C++] Warning wished for "!int_val == const" / logical not is only applied to the left hand side of this comparison

[burnus at gcc dot gnu.org]

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

Bug ID: 62183
   Summary: [C/C++] Warning wished for "!int_val == const" /
logical not is only applied to the left hand side of
this comparison
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org

That's a bug I tend to make from time to time (and usually spot it
immediately), it popped up also in our C++ code, and Coverity also had found
some instances in the GCC code.

Namely, using "!a == b" only rarely makes sense and usually should be "a != b".
I didn't manage to get GCC to warn in this case while Clang warns by default.

For the code:

int foo(int i) {
  if (!i == 5)
return 0;
  else
return 1;
}


Clang prints:

foo.cc:2:7: warning: logical not is only applied to the left hand side of this
comparison [-Wlogical-not-parentheses]
  if (!i == 5)
  ^  ~~
foo.cc:2:7: note: add parentheses after the '!' to evaluate the comparison
first
  if (!i == 5)
  ^
   ( )
foo.cc:2:7: note: add parentheses around left hand side expression to silence
this warning
  if (!i == 5)
  ^
  ( )
foo.cc:2:10: warning: comparison of constant 5 with expression of type 'bool'
is always false [-Wtautological-constant-out-of-range-compare]
  if (!i == 5)
  ~~ ^  ~
2 warnings generated.

[Bug c++/62182] New: New warning wished: operator== and "equality comparison result unused [-Wunused-comparison]"/-Wunsed-value

[burnus at gcc dot gnu.org]

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

Bug ID: 62182
   Summary: New warning wished: operator== and "equality
comparison result unused
[-Wunused-comparison]"/-Wunsed-value
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org

For a simple:
  int i;
  i == 5;

GCC diagnoses (but warning is enabled not by default):
  warning: statement with no effect [-Wunused-value]
   i == 7;

CLANG does the same (warning enabled by default):
  warning: equality comparison result unused [-Wunused-comparison]
  i == 7;
  ~~^~~~
  note: use '=' to turn this equality comparison into an assignment
  i == 7;
^~
=


However, in our code C++ code, we used an operator==. In that case, GCC doesn't
warn while Clang does (by default):

foo.cc:6:7: warning: equality comparison result unused [-Wunused-comparison]
  str == "bar";
  ^~~~
foo.cc:6:7: note: use '=' to turn this equality comparison into an assignment
  str == "bar";
  ^~
  =


C++ test case:

#include 
#include 

int main() {
  std::string str("init");
  str == "bar";
  printf("%s\n", str.c_str());
  return 0;
}

[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #11 from Manuel López-Ibáñez  ---
I consider this FIXED. Almost all options now work. The ones that don't are due
to missing features in the *.opt files, which are tracked in PR53063.

[Bug lto/62179] undefined reference linking failure when combining "extern template"

[miles at gnu dot org]

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

--- Comment #2 from miles at gnu dot org ---
Sorry, that got submitted accidentally (it turns out that RET in the web
page Summary text-box is bound to "submit"!)  I'm not sure how to
delete a bogus report... ^^;

Could you delete that?

[I updated my copy of gcc and it seems the bug I was going to report _may_
have been fixed but I'm running into other problems so I'm not sure
yet.]

Thanks,

-miles



2014年8月19日火曜日、rguenth at gcc dot gnu.orgさんは書きました:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179
>
> Richard Biener  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2014-08-19
>  Ever confirmed|0   |1
>
> --- Comment #1 from Richard Biener  ---
> Waiting for ... the bugreport?  Testcase?
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug c++/62181] New: [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[burnus at gcc dot gnu.org]

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

Bug ID: 62181
   Summary: [C/C++] Expected new warning: "adding 'char' to a
string does not append to the string"
[-Wstring-plus-int]
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org

CLANG warns for the following code, GCC doesn't (with the options tried):


foo.cc:4:24: warning: adding 'char' to a string does not append to the string
[-Wstring-plus-int]
  const char *a = "aa" + 'a';
  ~^
foo.cc:4:24: note: use array indexing to silence this warning
  const char *a = "aa" + 'a';
   ^
  &[]
1 warning generated.


Interestingly, the warning does not trigger for integer literals - only for
single-character literals and for long/int/char returning functions. That's
probably because  "abcd" + 1  is the pointer address shifted by one, i.e.
pointing to "bcd". One can also argue whether the note is helpful or not.


In the real-world code, the LHS was a string class and the conversion of "aa"
to the string class was missing such that the "operator+" wasn't triggered.


Test case, gives three warnings (and three notes) with CLANG:

#include 

char bar() {
  return 1;
}
int foobar() {
  return 1;
}

int main() {
  const char *a = "aa" + 'c';
  const char *b = "bb" + bar();
  const char *c = "cc" + foobar();
  printf("%s, %s, %s\n", a, b, c);
  return 0;
}

[Bug c++/62175] Internal compiler error in gimplify_modify_expr gimplify.c:4616

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-19
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  Also takes 2gb of ram for building.  Reducing.

[Bug lto/62179] undefined reference linking failure when combining "extern template"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-08-19
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Waiting for ... the bugreport?  Testcase?

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[jan.capek at braiins dot cz]

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

--- Comment #3 from Jan Čapek  ---
(In reply to Andrew Pinski from comment #1)
> C11 says something different here.

I can see the following the -fstrict-volatile-bitfields documentation:

"This option should be used if accesses to volatile bit-fields (or other
structure fields, although the compiler usually honors those types anyway)
should use a single access of the width of the field's type, aligned to a
 natural alignment if possible."

And this is actually the case with gcc 4.7.2, it ignore the -fstrict
option, and also doesn't need volatile on the individual bit-fields and it
still generates correct code due to specifying the bitfield types.

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[jan.capek at braiins dot cz]

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

--- Comment #2 from Jan Čapek  ---
(In reply to Andrew Pinski from comment #1)
> C11 says something different here.

Can you be a bit more specific?

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Target|Renesas RX600   |
  Known to work|4.7.2   |
   Host|linux amd64 |
  Known to fail|4.9.0   |

--- Comment #1 from Andrew Pinski  ---
C11 says something different here.

[Bug target/62180] New: (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[jan.capek at braiins dot cz]

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

Bug ID: 62180
   Summary: (RX600) - compiler doesn't honor
-fstrict-volatile-bitfields and generates incorrect
machine code for I/O register access
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.capek at braiins dot cz

Created attachment 33359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33359&action=edit
broken output from gcc 4.9.0

I have come across this issue while testing 4.9.x series of the compiler with
Renesas RX600 target
The compiler now generates byte accesses when writing bitfields completely
ignoring their 'type'. The strict-volatile-bitfields options seems to have no
effect. Our original compiler version 4.7.2 seems to work correctly and
generates accesses to the bitfields based on their type. This is essentially
what the documentation for the 'strict-volatile-bitfields' says.
I have tested this with 4.8.2 and 4.8.3, too with the same result. The test
case demonstrates access to a 16-bit memory mapped peripheral register. It is
absolutely necessary that the register is always being written in 16-bit
quantities.


A simple testcase:

struct st_cmt0 {
  union {
unsigned short WORD;
struct {
  volatile unsigned short CKS:2;
  volatile unsigned short :4;
  volatile unsigned short CMIE:1;
  volatile unsigned short :9;
} BIT;
  } CMCR;
  unsigned short CMCNT;
  unsigned short CMCOR;
};



void test(volatile struct st_cmt0 *reg)
{
  reg->CMCR.BIT.CMIE = 1;
}


The output for gcc 4.7.2 is:

.file"test.c"
.section P,"ax"
.global_test
.type_test, @function
_test:
pushmr6-r11
add#-4, r0, r6
mov.Lr6, r0
mov.Lr1, [r6]
mov.L[r6], r11
mov.W[r11], r10 ; HONORS the 16-bit register size
  bset#6, r10
 mov.Wr10, [r11] ; HONORS the 16-bit register size
 rtsd#28, r6-r11
.size_test, .-_test
.ident"GCC: (GNU) 4.7.2"

The output for gcc 4.9.0 is:

.file"test.c"
.section P,"ax"
.global_test
.type_test, @function
_test:
pushmr6-r11
add#-4, r0, r6
mov.Lr6, r0
mov.Lr1, [r6]
mov.L[r6], r11
mov.B[r11], r10 ; broken -  reads only part of the register
bset#6, r10
mov.Br10, [r11] ; broken - writes only part of the register
rtsd#28, r6-r11
.size_test, .-_test
.ident"GCC: (GNU) 4.9.0"

[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Mon, 18 Aug 2014, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
> 
> --- Comment #2 from Marc Glisse  ---
> (In reply to Richard Biener from comment #1)
> > What kind of std::string code is this?  That is, can we expect
> > memcmp and memcpy to be adjacent (without intermediate memory operations?)
> 
> I don't remember the exact code, but it was similar to:
> std::string("foo")=="bar"
> which, with _GLIBCXX_EXTERN_TEMPLATE=0 (or LTO) gives:
> 
>   _29 = _50 + 24;
>   __builtin_memcpy (_29, "foo", 3);
>   if (_50 != &_S_empty_rep_storage)
> goto ;
> 
>   :
>   MEM[(struct _Rep *)_50].D.20711._M_length = 3;
>   MEM[(char_type &)_50 + 27] = 0;
>   __r_86 = __builtin_memcmp (_29, "bar", 3);
> 
> So it is setting the null character right after the string (could have used
> memcpy of size 4?) and the length right before, which requires tight alias
> checking to be sure that memcmp is not affected :-(
> 
> Probably a bit too specific to be worth it.

Eventually worth "fixing" the libstdc++ side to generate better
initial code?

Other than that it seems this would need careful special-handling
in value-numbering ... not sure if optimizing std::string("foo") == "bar"
is important.