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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
The following patch fixes the issue.

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index e24b3922..b8e174c5 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -197,7 +197,7 @@ check_buffers (st_parameter_dt *dtp)
 }

 done:
-  dtp->u.p.at_eol = (c == '\n' || c == EOF);
+  dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF);
   return c;
 }

Regression tested on trunk with Linux.

[Bug rtl-optimization/70710] New: [5/6/7 Regression] Compile time hog w/ -O -g -fpeel-loops

[asolokha at gmx dot com]

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

Bug ID: 70710
   Summary: [5/6/7 Regression] Compile time hog w/ -O -g
-fpeel-loops
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 5.3.0 and later takes infinite time to compile the following reduced
snippet w/ -O[123] (or -Ofast) -g -fpeel-loops on x86_64-pc-linux-gnu:

long int mh = 0;
int du = 0;

void
vg (void)
{
  int qe;
  char u1;

  for (qe = 0; qe < 16; ++qe)
{
  mh &= du;
  du &= mh;
  u1 = du;
}
  mh = 0;
}

Several top calls brought up by perf:

  48.52%  cc1  [.] nonzero_bits1
  17.45%  cc1  [.] cached_nonzero_bits
  14.68%  cc1  [.] reg_nonzero_bits_for_combine
   1.29%  cc1  [.] bitmap_bit_p
   1.12%  cc1  [.] target_default_pointer_address_modes_p
   0.85%  cc1  [.] val_signbit_known_set_p
   0.27%  cc1  [.] rtx_equal_p
   0.26%  cc1  [.] commutative_operand_precedence
   0.22%  cc1  [.] simplify_binary_operation_1
   0.18%  cc1  [.] simplify_replace_fn_rtx
   0.15%  cc1  [.] volatile_insn_p
   0.12%  cc1  [.] simplify_binary_operation
   0.12%  cc1  [.] avoid_constant_pool_reference
   0.11%  cc1  [.] ggc_internal_alloc
   0.10%  cc1  [.] simplify_const_binary_operation
   0.07%  cc1  [.] simplify_associative_operation
   0.06%  cc1  [.] validate_subreg
   0.05%  cc1  [.] swap_commutative_operands_p
   0.05%  cc1  [.] copy_rtx
   0.04%  cc1  [.] simplify_gen_binary
   0.02%  cc1  [.] simplify_subreg

The original code had stuck for about 14 hours in compilation before I noticed
that.

[Bug c++/70709] New: gcc hangs on valid C++ code on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 70709
   Summary: gcc hangs on valid C++ code on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu. 

It also affects 4.8.x and later, and is a regression from 4.7.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160417 (experimental) [trunk revision 235070] (GCC) 
$ 
$ g++-4.7 -c small.cpp
$ clang++-3.8 -c small.cpp
$ 
$ g++-trunk -c small.cpp^C
$ timeout -s 9 10 g++-trunk -c small.cpp
Killed
$ 


-


struct A
{
  A (int);
};

struct B
{
  B () {} 
  A a[0];
};

struct C
{
  C () {} 
  B a[0];
};

[Bug c++/70708] New: Suboptimal code generated when using _mm_set_sd (X64)

[kobalicek.petr at gmail dot com]

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

Bug ID: 70708
   Summary: Suboptimal code generated when using _mm_set_sd (X64)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kobalicek.petr at gmail dot com
  Target Milestone: ---

The ABI already uses XMM registers for floating point operations. Compare the
following two snippets:

  double MyMinV1(double a, double b) {
return a  b ? a : b;
  }

  double MyMinV2(double a, double b) {
__m128d x = _mm_set_sd(a);
__m128d y = _mm_set_sd(b);
return _mm_cvtsd_f64(_mm_min_sd(x, y));
  }

And the code generated:

  MyMinV1(double, double):
minsd   xmm0, xmm1
ret

  MyMinV2(double, double):
movsd   QWORD PTR [rsp-24], xmm0
movsd   QWORD PTR [rsp-16], xmm1
movsd   xmm0, QWORD PTR [rsp-24]
movsd   xmm1, QWORD PTR [rsp-16]
minsd   xmm0, xmm1
ret

The problem is obvious, the _mm_set_sd() intrinsic really generates movsd even
if the content is already in the XMM register in the right place. I checked
also CLang and it generates an optimal code for both functions.

You can reproduce the test-case here:

 
https://gcc.godbolt.org/#compilers:!((compiler:g6,options:'-O2+-Wall+',source:'%23include+%3Cxmmintrin.h%3E%0A%0Adouble+MyMinV1(double+a,+double+b)+%7B%0A++return+a+%3C+b+%3F+a+:+b%3B%0A%7D%0A%0Adouble+MyMinV2(double+a,+double+b)+%7B%0A++__m128d+x+%3D+_mm_set_sd(a)%3B%0A++__m128d+y+%3D+_mm_set_sd(b)%3B%0A++return+_mm_cvtsd_f64(_mm_min_sd(x,+y))%3B%0A%7D%0A')),filterAsm:(commentOnly:!t,directives:!t,intel:!t,labels:!t),version:3

It looks like all GCC versions are affected.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #19 from psturm at computervoice dot com ---
H.J,

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

On a separate topic, do you know an Intel colleague named Kirill Shutemov? I am
having a problem with a kernel warning about a pmd_set_huge failure and an ACPI
warning on my Xeon D-1540 development system when I load the ixgbe driver. The
driver guys told me to post on linux-mm and I did, but no reply just yet. It
seems Kirill Shumetov is active in the kernel memory management and this is an
issue manifesting on an Intel system (both CPU and 10g ethernet). If not him,
do you know anyone else I can contact about this?

Thanks,

Paul

- Original Message -
From: "hjl.tools at gmail dot com" 
To: "psturm" 
Sent: Sunday, April 17, 2016 6:02:45 PM
Subject: [Bug testsuite/70150] Additonal test failures with
--enable-default-pie

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

--- Comment #18 from H.J. Lu  ---
(In reply to psturm from comment #17)
> Yes, they do appear when only using --enable-default-ssp, so I don't think
> they are relevant.

I suggest you open a new bug report if you haven't done so.

[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp

[psturm at computervoice dot com]

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

--- Comment #2 from psturm at computervoice dot com ---
2 new failures appeared when testing with only --enable-default-ssp using the
hjl/pr70150 branch:

> FAIL: gcc.target/i386/cleanup-1.c execution test
> FAIL: gcc.target/i386/cleanup-2.c execution test

Are these also to be expected or is it something more?

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
(In reply to psturm from comment #17)
> Yes, they do appear when only using --enable-default-ssp, so I don't think
> they are relevant.

I suggest you open a new bug report if you haven't done so.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #17 from psturm at computervoice dot com ---
Yes, they do appear when only using --enable-default-ssp, so I don't think they
are relevant.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #5 from Jakub Jelinek  ---
Strange, I thought the default bootstrap is to build stage2 without debug info,
while you have stabs in both files.
Have you looked at where the differences start first (build both the stage2 and
stage3 with -fdump-tree-all-nouid -fdump-rtl-all-nouid --param
min-nondebug-insn-uid=1 ?
Are the stage2/stage3 sbitmap.c sources built with the same options?
Do you know which sort is unstable, or is that just a guess?

[Bug sanitizer/70683] [7 Regression] -fcompare-debug bug with -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |7.0

[Bug sanitizer/70683] [7 Regression] -fcompare-debug bug with -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression]|[7 Regression]
   |-fcompare-debug bug with|-fcompare-debug bug with
   |-fsanitize=address  |-fsanitize=address

--- Comment #2 from Jakub Jelinek  ---
In gcc 6.x this is masked off by not making the constexpr fn table deletable.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
The regression occurred at r200238, which was a fix for PR57633.

I am working on a fix.

[Bug c/70707] New: INT_MAX used before it is defined

[dethbomb at hotmail dot com]

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

Bug ID: 70707
   Summary: INT_MAX used before it is defined
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dethbomb at hotmail dot com
  Target Milestone: ---

Im a complete newb to linux and gcc so please forgive if this is not the
correct way to do things. Or if this is not actually wrong then please ignore.

I saw what appeared to me to be incorrect C code while browsing "limits.h".
The following 2 cpp lines.

#  define INT_MIN   (-INT_MAX - 1)
#  define INT_MAX   2147483647


INT_MAX is used before it is defined. The preprocessor seems to accept this in
gcc because INT_MAX is defined immediately afterwards.But if a different
preprocessor would be used this could cause problems?

printf("%i\n",INT_MIN);

does give the correct value. But im not sure if its because it may be defined
elsewhere in my source code thru some other header file.

regards,
Lewis

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

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
sbitmap.s was one of the smaller files.  All of the debugging information seems
to be present, but emitted in a different order in the stage2 versus stage3.

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

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
Created attachment 38299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38299=edit
Stage2 sbitmap.s

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

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Created attachment 38300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38300=edit
Stage3 sbitmap.s

[Bug c++/70702] Build failure of ARM cross compiler under Cygwin - libc_name_p

[olivier at gautherot dot net]

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

--- Comment #2 from Olivier Gautherot  ---
Last correction: the build under FreeBSD uses GCC 5.3 and requires the same fix
to build.

[Bug tree-optimization/70701] incomplete value numbering when memcpy-ing from array

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Er, sorry, a "const" disappeared when I posted.

const int a[]={1,2,3};
int f(){
  int*b=__builtin_malloc(12);
  __builtin_memcpy(b,a,12);
  return b[0];
}

this fails to optimize (without forwprop).


int a[]={1,2,3};
int f(){
  a[0]=42;
  int*b=__builtin_malloc(12);
  __builtin_memcpy(b,a,12);
  return b[0];
}

this is optimized.

[Bug libgcc/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c, #define COMMA ,

[angelo70 at gmail dot com]

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

--- Comment #2 from angelo  ---
Well the final error is :

/home/angelo/archivio/aziende/sysam/buildall/gcc-5.2.0/libgcc/config/m68k/linux-atomic.c:198:13:
internal compiler error: in emit_library_call_value_1, at calls.c:4401
 return (__sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval) \
 ^
/home/angelo/archivio/aziende/sysam/buildall/gcc-5.2.0/libgcc/config/m68k/linux-atomic.c:203:1:
note: in expansion of macro 'SUBWORD_BOOL_CAS'
 SUBWORD_BOOL_CAS (unsigned char,  1)

I tried also gcc 5.3.0, same error using --with-arch=cf.

Seems like m68k branch is not considered at all.

[Bug libgcc/68082] issue on 64 bit shift

[angelo70 at gmail dot com]

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

--- Comment #5 from angelo  ---
Any news ?

Trying also --with-arch=cf breaks the compilation.
So i can't have in any way valid libgcc code i.e. for m5307.

[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types

[ssameer at gmail dot com]

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

Sameer Sheorey  changed:

   What|Removed |Added

 CC||ssameer at gmail dot com

--- Comment #17 from Sameer Sheorey  ---
The second fragment still fails in gcc 5.3.1 (OpenSuse 13.2). I noticed that
the C++11 version succeeds:

struct A {
A() {}
};
thread_local A a;

Is it possible to migrate this to the OpenMP implementation as well?

[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Sun Apr 17 18:30:21 2016
New Revision: 235086

URL: https://gcc.gnu.org/viewcvs?rev=235086=gcc=rev
Log:
PR bootstrap/70706
* predict.h (tree_estimate_probability): Update prototype.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.h

[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure

[graham.stott at btinternet dot com]

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

--- Comment #3 from graham.stott at btinternet dot com ---
still  fails predict.h needs updating prototype also

 Original message 
From: "hubicka at gcc dot gnu.org"  
Date: 17/04/2016  19:05  (GMT+00:00) 
To: gcc-bugs@gcc.gnu.org 
Subject: [Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure 

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

--- Comment #1 from Jan Hubicka  ---
Author: hubicka
Date: Sun Apr 17 18:04:51 2016
New Revision: 235085

URL: https://gcc.gnu.org/viewcvs?rev=235085=gcc=rev
Log:

    PR bootstrap/70706
    * graphite.c (graphite_finalize): Update call to
    tree_estimate_probability.

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

[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
> libbackend.a(graphite.o): In function `graphite_finalize(bool)':
> /export/gnu/import/git/gcc-test-profiled/bld/gcc/../../src-trunk/gcc/graphite.c:259:
> undefined reference to `tree_estimate_probability()'
> collect2: error: ld returned 1 exit status
> ../../src-trunk/gcc/lto/Make-lang.in:71: recipe for target 'lto1' failed
> make[6]: *** [lto1] Error 1

I have comitted the following as obvious. It is not clear to me what graphite
is
trying to reach here and it will definitly leat to random results with profile
feedback (we will likely end up with guessed profile but non-zero counts)
but we can deal with that incrementally.

PR bootstrap/70706
* graphite.c (graphite_finalize): Update call to
tree_estimate_probability.
Index: graphite.c
===
--- graphite.c  (revision 235064)
+++ graphite.c  (working copy)
@@ -256,7 +256,7 @@ graphite_finalize (bool need_cfg_cleanup
   cleanup_tree_cfg ();
   profile_status_for_fn (cfun) = PROFILE_ABSENT;
   release_recorded_exits (cfun);
-  tree_estimate_probability ();
+  tree_estimate_probability (false);
 }

   free_original_copy_tables ();

[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Author: hubicka
Date: Sun Apr 17 18:04:51 2016
New Revision: 235085

URL: https://gcc.gnu.org/viewcvs?rev=235085=gcc=rev
Log:

PR bootstrap/70706
* graphite.c (graphite_finalize): Update call to
tree_estimate_probability.

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

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
(In reply to psturm from comment #15)
> Tested with hjl/pr70150 branch and no unexpected errors using
> --enable-default-pie.
> 
> However, when testing the same branch with both --enable-default-pie and
> --enable-default-ssp, a couple new failures did show up (in addition to the
> 11 expected failures):
> 
> FAIL: gcc.target/i386/cleanup-1.c execution test
> FAIL: gcc.target/i386/cleanup-2.c execution test
> 
> I am not sure whether this is relevant or not?

Do they fail with only --enable-default-ssp?

[Bug bootstrap/70706] New: [7 Regression] r235082 caused bootstrap failure

[hjl.tools at gmail dot com]

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

Bug ID: 70706
   Summary: [7 Regression] r235082 caused bootstrap failure
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz
  Target Milestone: ---

r235082 caused:

libbackend.a(graphite.o): In function `graphite_finalize(bool)':
/export/gnu/import/git/gcc-test-profiled/bld/gcc/../../src-trunk/gcc/graphite.c:259:
undefined reference to `tree_estimate_probability()'
collect2: error: ld returned 1 exit status
../../src-trunk/gcc/lto/Make-lang.in:71: recipe for target 'lto1' failed
make[6]: *** [lto1] Error 1

when GCC is configured with

--prefix=/usr/7.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-libmpx --with-build-config=bootstrap-lto
--disable-werror --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

and built with

# make -j8 profiledbootstrap

[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #9 from Dominique d'Humieres  ---
*** Bug 70705 has been marked as a duplicate of this bug. ***

[Bug fortran/70705] Associate construct with array section causes ICE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
It looks like a duplicate of pr49636.

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

[Bug fortran/70705] New: Associate construct with array section causes ICE

[townsend at astro dot wisc.edu]

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

Bug ID: 70705
   Summary: Associate construct with array section causes ICE
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 38298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38298=edit
Example program

In the example program attached, compilation (gfortran -o ice ice.f90) causes
the following ICE:

ice.f90:16:0:

 x = 0.
 1
internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1201

ice.f90:16:0: internal compiler error: Abort trap: 6
gfortran.exec: internal compiler error: Abort trap: 6 (program f951)

cheers,

Rich

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

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-17
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Cnofirmed.

[Bug bootstrap/70704] New: [6 Regressions] AIX bootstrap comparison failure

[dje at gcc dot gnu.org]

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

Bug ID: 70704
   Summary: [6 Regressions] AIX bootstrap comparison failure
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

GCC 6.0 RC fails bootstrap on AIX due to comparison failure of all object files
for --enable-checking=release.  This appears to be an unstable sort issue.

[Bug c++/70018] [4.9/5/6/7 Regression] Possible issue around IPO and C++ comdats discovered as pure/const

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Author: hubicka
Date: Sun Apr 17 16:04:05 2016
New Revision: 235081

URL: https://gcc.gnu.org/viewcvs?rev=235081=gcc=rev
Log:

PR ipa/70018
* cgraph.h (cgraph_node::set_const_flag,
cgraph_node::set_pure_flag): Update prototype to return bool;
update comment.
* cgraph.c (cgraph_node::call_for_symbol_thunks_and_aliases): Thunks
of interposable symbol are interposable, too.
(cgraph_set_const_flag_1): Rename to ...
(set_const_flag_1): ... this one; change to self recursive function
instead of call_for_symbol_thunks_and_aliases. Handle correctly
clearnig the flag in all variants and also virtual thunks of const
functions are pure; track if any change was done.
(cgraph_node::set_const_flag): Update.
(struct set_pure_flag_info): New struct.
(cgraph_set_pure_flag_1): Rename to ...
(set_pure_flag_1): ... this one; take set_pure_flag_info parameter
rather than pointer encoded flags; track if any changes was done;
handle correctly clearning flag and setting flag of aliases already
declared const.
(cgraph_node::set_pure_flag): Update.
(cgraph_node::set_nothrow_flag): Handle correctly clearning the flag.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h

[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.

[vda.linux at googlemail dot com]

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

--- Comment #18 from Denis Vlasenko  ---
Created attachment 38297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38297=edit
Comparison of generated code with 7.0.0.svn on i86

With div cost of 3:

  :
-   0:  8b 44 24 04 mov0x4(%esp),%eax
-   4:  b9 64 00 00 00  mov$0x64,%ecx
-   9:  31 d2   xor%edx,%edx
-   b:  f7 f1   div%ecx
-   d:  c3  ret

With div cost of 13:

+   0:  b9 1f 85 eb 51  mov$0x51eb851f,%ecx
+   5:  89 c8   mov%ecx,%eax
+   7:  f7 64 24 04 mull   0x4(%esp)
+   b:  89 d1   mov%edx,%ecx
+   d:  89 c8   mov%ecx,%eax
+   f:  c1 e8 05shr$0x5,%eax
+  12:  c3  ret

[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.

[vda.linux at googlemail dot com]

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

--- Comment #17 from Denis Vlasenko  ---
Any chance of this being finally done?

I proposed a simple, working patch in 2007, it's 2016 now and all these years
users of -Os suffer from slow divisions in important cases usch as "signed_int
/ 16" and "unsigned_int / 10".

I understand your desire to do it "better", to make gcc count size of div/idiv
more accurately, without having to lie to it in the insn size table. But with
you guys constantly distracted by other, more important issues, what happened
here is that _nothing_ was done...

I retested the patch with current svn (the future 7.0.0), using test program
with 15000 divisions from comment 3:

Bumping division cost up to 8 is no longer enough, this only makes gcc to be
better towards some (not all) 2^N divisors. Bumping div cost to 9..12 helps
with most of remaining 2^N divisor cases, and for two exceptional cases of x /
641 and x / 6700417. Only bumping div cost to 13, namely, changing div costs as
follows:

const
struct processor_costs ix86_size_cost = {/* costs for tuning for size */
...
  {COSTS_N_BYTES (13),  /* cost of a divide/mod for QI */
   COSTS_N_BYTES (13),  /*  HI */
   COSTS_N_BYTES (13),  /*  SI */
   COSTS_N_BYTES (13),  /*  DI */
   COSTS_N_BYTES (15)}, /*  other */

makes it work as it used to in 4.4.x days: out of 15000 cases in t.c, 975 cases
are optimized so that they don't use "div" anymore.

This should have made it smaller too... but did not, because meanwhile gcc has
regressed in another area. Now it inserts superfluous register moves. See bug
70703 which I just filed. Essentially, instead of
movl$6700417, %eax
mull4(%esp)
movl%edx, %eax
ret
gcc generates:
movl$6700417, %ecx
movl%ecx, %eax 
mull4(%esp)
movl%edx, %ecx 
movl%ecx, %eax
ret

Sizes of compiled testcases (objN denotes cost of "div", A...D correspond to
costs of 10..13):

   textdata bss dec hex filename
 242787   0   0  242787   3b463 gcc.obj3/divmod-7.0.0-Os.o
 242813   0   0  242813   3b47d gcc.obj8/divmod-7.0.0-Os.o
 242838   0   0  242838   3b496 gcc.obj9/divmod-7.0.0-Os.o
 242844   0   0  242844   3b49c gcc.objA/divmod-7.0.0-Os.o
 242844   0   0  242844   3b49c gcc.objB/divmod-7.0.0-Os.o
 242844   0   0  242844   3b49c gcc.objC/divmod-7.0.0-Os.o
 247573   0   0  247573   3c715 gcc.objD/divmod-7.0.0-Os.o

So.
Any chance of this patch being accepted sometime before 2100? ;)

[Bug middle-end/70703] New: Regression in register usage on x86

[vda.linux at googlemail dot com]

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

Bug ID: 70703
   Summary: Regression in register usage on x86
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vda.linux at googlemail dot com
  Target Milestone: ---

$ cat bad.c
unsigned ud_x_641_mul(unsigned x) {
/* optimized version of x / 641 */
return ((unsigned long long)x * 0x663d81) >> 32;
}

With gcc from current svn:
$ gcc -m32 -fomit-frame-pointer -O2 bad.c -S && cat bad.s
...
ud_x_641_mul:
.cfi_startproc
movl$6700417, %ecx
movl%ecx, %eax
mull4(%esp)
movl%edx, %ecx
movl%ecx, %eax
ret

Same result with -Os. Note two pointless mov insns.

gcc 5.3.1 is "better", it adds only one unnecessary insn:

ud_x_641_mul:
.cfi_startproc
movl$6700417, %ecx
movl%ecx, %eax
mull4(%esp)
movl%edx, %eax
ret

gcc 4.4.x and 4.7.2 were generating this code, which looks optimal:
ud_x_641_mul:
.cfi_startproc
movl$6700417, %eax
mull4(%esp)
movl%edx, %eax
ret

I did not test other versions of gcc yet.

[Bug c++/70702] Build failure of ARM cross compiler under Cygwin - libc_name_p

[olivier at gautherot dot net]

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

--- Comment #1 from Olivier Gautherot  ---
Additional note: by adding the static keyword, I got the following error:

In file included from ../../gcc/cp/except.c:1023:0:
cfns.gperf: In function 'const char* libc_name_p(const char*, unsigned int)':
cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)'
rdeclared inline with 'gnu_inline' attribute
cfns.gperf:26:21: note: 'const char* libc_name_p(const char*, unsigned int)'
prviously declared here
cfns.gperf: At global scope:
cfns.gperf:26:21: warning: inline function 'const char* libc_name_p(const char*
unsigned int)' used but never defined
Makefile:1065: recipe for target 'cp/except.o' failed
make: *** [cp/except.o] Error 1

It was fixed by declaring consistently the prototype in the 3 occurences as:

#ifdef __GNUC__
__inline
#ifdef __GNUC_STDC_INLINE__
__attribute__ ((__gnu_inline__))
#endif
#endif
static const char * libc_name_p (const char *, unsigned int);

[Bug c++/70702] New: Build failure of ARM cross compiler under Cygwin - libc_name_p

[olivier at gautherot dot net]

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

Bug ID: 70702
   Summary: Build failure of ARM cross compiler under Cygwin -
libc_name_p
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olivier at gautherot dot net
  Target Milestone: ---

Created attachment 38296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38296=edit
Build script for reference

I tried to build an ARM cross compiler under Cygwin64 and got an error (symbol
not found) on libc_name_p. After some investigation, I tracked the root cause
down to the files gcc/cp/cfns.{h,gperf}. I suggest the following fix:

Replace

  "const char * libc_name_p (const char *, unsigned int);"

with

  "static const char * libc_name_p (const char *, unsigned int);"

By adding the "static" keyword, we ensure that the function is properly
inlined. There are 3 occurrences in cfns.h and cfns.gperf.

I attached my build scripts for reference.

Note: The same build scripts worked fine under Linux (Ubuntu, Centos) and
FreeBSD, with various versions of GCC and Clang/FreeBSD. The reason why GCC on
Cygwin misbehaved is still unclear.

[Bug fortran/67538] ICE with invalid source allocation

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/66911] ICE on allocate character with source as a derived type component

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/65795] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug sanitizer/70624] [6/7 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #9 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #8)
> This is fixed on x86_64-apple-darwin10 without regression on
> x86_64-apple-darwin15 by the following patch
> 
> --- ../_clean/libsanitizer/asan/asan_mac.cc   2015-11-23 10:17:05.0
> +0100
> +++ libsanitizer/asan/asan_mac.cc 2016-04-15 13:22:01.0 +0200
> @@ -97,10 +97,14 @@ void DisableReexec() {
>reexec_disabled = true;
>  }
>  
> -extern "C" double dyldVersionNumber;
> +extern "C" SANITIZER_WEAK_ATTRIBUTE double dyldVersionNumber;
>  static const double kMinDyldVersionWithAutoInterposition = 360.0;
>  
>  bool DyldNeedsEnvVariable() {
> +  // Although sanitizer support was added to LLVM on Darwin 10.7+, GCC users
> +  // still may want use them on older systems. On older Darwin platforms,
> dyld
> +  // doesn't export dyldVersionNumber symbol and we simply can return true.
> +  if (!) return true;
>// If running on OS X 10.11+ or iOS 9.0+, dyld will interpose even if
>// DYLD_INSERT_LIBRARIES is not set. However, checking OS version via
>// GetMacosVersion() doesn't work for the simulator. Let's instead check

This looks good to (and works for) me; 
please can we ask for this to be committed "upstream" and then imported?

BTW, there _are_ folks using both GCC and LLVM on Darwin10 for "day job" stuff,
so it is still very much of interest.

[Bug tree-optimization/70701] New: incomplete value numbering when memcpy-ing from array

[glisse at gcc dot gnu.org]

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

Bug ID: 70701
   Summary: incomplete value numbering when memcpy-ing from array
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Looking at PR58483 (seems more relevant than PR62156), I tried this simple
testcase:

int a[]={1,2,3};
int f(){
  // a[0]=42;
  int*b=__builtin_malloc(12);
  __builtin_memcpy(b,a,12);
  return b[0];
}

Compiling with -O3 -fdisable-tree-forwprop1 -fdisable-tree-forwprop2
-fdisable-tree-forwprop3 (otherwise forwprop turns memcpy into a MEM
assignment), we fail to optimize b[0] to 1. We do go through the memcpy path in
vn_reference_lookup_3 and that part seems to work fine, but then that's it, we
don't grab the value. If I add a statement a[0]=42; at the beginning of the
function, then we do get that value in FRE1.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #40 from Iain Sandoe  ---
Created attachment 38295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38295=edit
Further tweak for Darwin10

Sorry, this one slipped thorough the cracks, and I guess we're no longer in the
"apply as obvious" state.  It's hardly critical (but also pretty safe). 
Dominique, can we double-check it works as expected?

[Bug testsuite/70699] Add dot-file scan to pr70161.c test-case

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
pinged: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00783.html

[Bug tree-optimization/70700] ICE using -fdump-tree-all-graph option

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-17
 Ever confirmed|0   |1

--- Comment #2 from vries at gcc dot gnu.org ---
Confirmed using:
... 
$ gcc -O3 parse.i -fdump-tree-all-graph
...

[Bug tree-optimization/70700] ICE using -fdump-tree-all-graph option

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 38294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38294=edit
parse.i

[Bug tree-optimization/70700] New: ICE using -fdump-tree-all-graph option

[vries at gcc dot gnu.org]

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

Bug ID: 70700
   Summary: ICE using -fdump-tree-all-graph option
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Reported by t.w. lefering by email:

Using GCC snapshot gcc-6-20160410.tar.bz2 and the
-fdump-tree-all-graph option to generate graph data
internal gcc error happens when compiling Linux sparse:

parse.c:1362:22: internal compiler error: in operator[], at vec.h:714

in tree-ssa-structalias.c line 1212 is build_pred_graph()

at line 1229 the get_varinfo() using vec.h routines hits the internal compiler
error:

for (j = 1; j < FIRST_REF_NODE; j++)
{
  if (!get_varinfo (j)->is_special_var)
bitmap_set_bit (graph->direct_nodes, j);
}

Looks like the variable j gets out-of-range then hit this assert in vec.h:714

in vec.h:

template
inline T &
vec::operator[] (unsigned ix)
{
  gcc_checking_assert (ix < m_vecpfx.m_num);
  return m_vecdata[ix];
}

And this is in the generated output:

parse.c: In function 'const_qualifier':
parse.c:1362:22: internal compiler error: in operator[], at vec.h:714
 static struct token *const_qualifier(struct token *next, struct decl_state
*ctx)
  ^~~
0xce89e7 vec::operator[](unsigned int)
../.././gcc/vec.h:714
0xce89e7 vec::operator[](unsigned int)
../.././gcc/vec.h:1180
0xce89e7 get_varinfo
../.././gcc/tree-ssa-structalias.c:333
0xcf7cd7 get_varinfo
../.././gcc/vec.h:714
0xcf7cd7 build_pred_graph
../.././gcc/tree-ssa-structalias.c:1231
0xcf7cd7 solve_constraints
../.././gcc/tree-ssa-structalias.c:6961
0xcf9593 compute_points_to_sets
../.././gcc/tree-ssa-structalias.c:7062
0xcf9593 compute_may_aliases()
../.././gcc/tree-ssa-structalias.c:7389
0xa5afdc execute_function_todo
../.././gcc/passes.c:1930
0xa5baab execute_todo
../.././gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.