[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Chen Gang from comment #17)
> I guess the diff below should be OK, I shall give a make check test.

I would rather have the C front-end behavior for C++ rather than the opposite
way around.  Because _Pragma are considered statements.

[Bug middle-end/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
This is 465.tonto in SPEC CPU 2006.

[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||meissner at linux dot 
vnet.ibm.com

--- Comment #2 from Arseny Solokha  ---
Fixed during the last week, as of 6.0.0-alpha20151122 snapshot (in r230440,
apparently).

[Bug c/68480] -fno-strict-aliasing not respected

[manjeetdahiya at gmail dot com]

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

--- Comment #3 from Manjeet Dahiya  ---
(In reply to Manjeet Dahiya from comment #2)
> (In reply to Andreas Schwab from comment #1)
> > Did you mean gcc-5.1.0?
> 
> No. It is for gcc-4.1.0 :) We were checking for equivalence of code
> generated across different versions and found this bug. We saw that it is
> possible to file bug reports for earlier versions so we filed it.

The reason we tested gcc-4.1.0 was that it is still being used for development
of some of our tools.

ICE: SEGFAULT in mem rtx - GCC-4.5.1

[vikram1729]

Hi
I am building gcc-4.5.1 cross compiler. I am getting SEGFAULT ICE at
simplify-rtx.c:167, i.e. at this function

/* If X is a MEM referencing the constant pool, return the real value.  
 
Otherwise return X.  */
rtx  
avoid_constant_pool_reference (rtx x)   
 
{ 
   rtx c, tmp, addr;
   
   
-->   addr = targetm.delegitimize_address (addr); //SEGFAULT here
   /* Split the address into a base and integer offset.  */
   if (GET_CODE (addr) == CONST
   
}

When debugging, call debug_rtx(x) gives this pattern:
(mem/c/i:SI (plus:SI (reg/f:SI 129 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 __ul+0 S4 A32])

To solve it, I tried to implement my own delegitimize function:
static rtx
target_delegitimize_address (rtx orig_x)
{
   //rtx x = orig_x;
   rtx x = delegitimize_mem_from_attrs (orig_x);

   if (GET_CODE (x) != MEM) 
 return XEXP(x, 0);
 
   x = XEXP (x, 0);
   if (GET_CODE (x) == PLUS 
  && GET_CODE (XEXP (x, 1)) == CONST_INT
  && GET_CODE (XEXP (x, 0)) == REG) 
 //DON'T KNOW WHAT TO WRITE HERE. Tried this but failed: return XVECEXP
(XEXP(x, 1), 0, 0);

  return orig_x;
}

Is it a backend problem?

Thanks & Regards
-VSP



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/ICE-SEGFAULT-in-mem-rtx-GCC-4-5-1-tp1208514.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug target/68494] New: [ARM] Use vector multiply by lane

[michael.collison at linaro dot org]

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

Bug ID: 68494
   Summary: [ARM] Use vector multiply by lane
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.collison at linaro dot org
  Target Milestone: ---

The following test case should utilize vector multiply by a single lane.

short taps[4];

void fir_t5(int len, short * __restrict p, short *__restrict x, short
*__restrict taps)
{
  len = len & ~31;
  for (int i = 0; i < len; i++)
{
  int tmp = 0;
  for (int j = 0; j < NTAPS; j++)
{
  tmp += x[i - j] * taps[j];
}

  p[i] = tmp;
}
}

[Bug middle-end/68488] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

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

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

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug middle-end/68480] -fno-strict-aliasing not respected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
 Resolution|--- |WONTFIX

--- Comment #4 from Andrew Pinski  ---
4.1 is no longer support and has not been for over 5 years now.  Closing as
won't fix.

There was some known issues in pre GCC 4.7 where aliasing was broken (there are
a few bug reports already closed about it).

[Bug c++/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[vvsed at hotmail dot com]

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

--- Comment #2 from Vladimir Sedach  ---
It is not just about "long long".

_mm_store_ps() is also wrong, while _mm_store_pd() / _mm_store_si128() are OK:


#include 
#include 

int main(int argc, const char *argv[])
{
__attribute__((aligned(16))) int_x[4] = {0};
int * volatile x = _x;
__m128i m = _mm_set1_epi32(1);

_mm_storel_epi64((__m128i *)x, m);  //wrong
//  _mm_storel_pi((__m64 *)x, *(__m128 *));   //ok

_mm_store_ps((float *)x, *(__m128 *));//wrong
//  _mm_store_pd((double *)x, *(__m128d *));  //ok
//  _mm_store_si128((__m128i *)x, *(__m128i *));  //ok

fprintf(stdout, "%d %d \npress Enter", x[0], x[1]);

getc(stdin);
return 0;
}

[Bug c++/68495] New: Error when expanding nontype variadic argument in trailing return type

[sneves at dei dot uc.pt]

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

Bug ID: 68495
   Summary: Error when expanding nontype variadic argument in
trailing return type
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sneves at dei dot uc.pt
  Target Milestone: ---

Minimal example, works on Clang and MSVC but fails to compile on every GCC
version since 4.7:

  template struct int_seq {};

  constexpr struct {
  constexpr int operator()(int x) const { return x + 1; }
  } f1 {};

  template
  auto f2(F f, int_seq) -> int_seq {
  return {};
  }

  int main() {
  f2(f1, int_seq<0, 1, 2, 3>{});
  }

Replacing `int_seq` by `int_seq` in the return type causes
the snippet to compile successfully.

[Bug libfortran/51119] MATMUL slow for large matrices

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #20 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #19)
> If I can get something working I am thinking something like
> -fexternal-blas-n, if -n not given then default to current libblas
> behaviour. This way users have some control. With GPUs, it is not unusual to
> have hundreds of cores.  We can also, at run time, see if the opencl is
> already initialized which may mean used elsewhere so don't mess with it.

Hidden behind a -fexternal-blas-n switch might be an option. Including GPUs
seems even a tad more tricky. We have a paper on GPU (small) matrix
multiplication, http://dbcsr.cp2k.org/_media/gpu_book_chapter_submitted.pdf .
BTW, another interesting project is the libxsmm library more aimed at small
(<128) matrices see : https://github.com/hfp/libxsmm . Not sure if this info is
useful in this context, but it might provide inspiration.

[Bug target/68390] Incorrect code due to indirect tail call of varargs function with hard float ABI

[kugan at gcc dot gnu.org]

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

--- Comment #1 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sun Nov 22 23:07:58 2015
New Revision: 230730

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

2015-11-23  Kugan Vivekanandarajah  

PR target/68390
* config/arm/arm.c (arm_function_ok_for_sibcall): Get function type
for indirect function call.

gcc/testsuite/ChangeLog:

2015-11-23  Kugan Vivekanandarajah  

PR target/68390
* gcc/testsuite/gcc.c-torture/execute/pr68390.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68390.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/42121] g++ should warn or error on internal 0 size array in struct

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02595.html

[Bug target/38939] MULLW on often faster than SLWI ADD SLWI ADD..

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
The problem is that expand_mult (in expmed.c) calculates the cost of
the reg*0x01010101 as six cycles, namely, two to construct the constant
in a register and then four for the reg-reg multiply.  The shift
sequence is just four cycles, so that is chosen.  expand_mult does not
realise this is within a loop and the construction of the constant will
be hoisted out of the loop.

Confirmed.

[Bug c++/68490] New: error initializing a structure with a flexible array member

[msebor at gcc dot gnu.org]

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

Bug ID: 68490
   Summary: error initializing a structure with a flexible array
member
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

g++ accepts definitions of flexible array members as an extension for
compatibility with C.  In C mode, as an extension, gcc and compatible compilers
accept initialized definitions of objects of structures containing flexible
array members, provided such objects have static storage duration.  Some of the
compatible compatible (Clang) also accept the extension in C++ mode.

However, as the test case below shows, g++ rejects such uses.  Since flexible
array members are accepted by g++ for compatibility with C (most notably gcc),
it seems that the initialized definitions should be accepted by g++ as well.

$ cat z.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic -O2  -S -o/dev/null z.cpp
struct A {
int n;
int a [];
};

struct A foo (void)
{
static struct A a = { 2, { 1, 0 } };

return a;
}

z.cpp:3:12: warning: ISO C++ forbids zero-size array ‘a’ [-Wpedantic]
 int a [];
^

z.cpp: In function ‘A foo()’:
z.cpp:8:39: error: too many initializers for ‘int [0]’
 static struct A a = { 2, { 1, 0 } };
   ^

[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
I'm not having any luck reproducing this.  I built a 32-bit PPC GNU/Linux (on
the GCC compile farm, which is a PPC64 machine, using glibc 2.18).  I deleted
the libgo files and rebuilt them with -fstack-protector-strong.  I built a new
go tool.  It seems to work fine.

Let's try this: if you can still recreate this problem, send me the crashing
binary.  Maybe I can see something there.

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  ---
If I can get something working I am thinking something like -fexternal-blas-n,
if -n not given then default to current libblas behaviour. This way users have
some control. With GPUs, it is not unusual to have hundreds of cores.  We can
also, at run time, see if the opencl is already initialized which may mean used
elsewhere so don't mess with it.

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Nov 23 00:40:51 2015
New Revision: 230734

URL: https://gcc.gnu.org/viewcvs?rev=230734=gcc=rev
Log:
2015-11-22  Jerry DeLisle  

PR libfortran/52251
* io/transfer.c (formatted_transfer_scalar_write): Reset skips count.
(finalize_transfer): For ADVANCE_NO, emit pending spaces and reset the
skip count.

2015-11-22  Jerry DeLisle  

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


Added:
trunk/gcc/testsuite/gfortran.dg/fmt_t_8.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug middle-end/68492] New: [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

[hjl.tools at gmail dot com]

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

Bug ID: 68492
   Summary: [6 Regression] internal compiler error: in
vect_is_simple_use, at tree-vect-stmts.c:8266
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On i686, r230020 caused:

gfortran -m32  -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math
-fwhole-program -flto=jobserver -fuse-linker-plugin  types.fppized.o
system.fppized.o str.fppized.o int.fppized.o real.fppized.o intvec.fppized.o
realvec.fppized.o binmat.fppized.o cpxvec.fppized.o realmat.fppized.o
parallel.fppized.o intmat.fppized.o buffer.fppized.o intvecvec.fppized.o
strvec.fppized.o binvec.fppized.o unitnumber.fppized.o textfile.fppized.o
opvector.fppized.o file.fppized.o cpxmat.fppized.o opmatrix.fppized.o
archive.fppized.o diis.fppized.o reflection.fppized.o cif.fppized.o
cpxmat3.fppized.o realmat3.fppized.o spacegroup.fppized.o slatershell.fppized.o
slatershellvec.fppized.o interpolator.fppized.o slaterbasis.fppized.o
shell1.fppized.o unitcell.fppized.o shell.fppized.o shellvec.fppized.o
basis.fppized.o coppensorbital.fppized.o coppensorbitalvec.fppized.o
coppensbasis.fppized.o atom.fppized.o reflectionvec.fppized.o rys.fppized.o
cpxmat4.fppized.o gaussian.fppized.o gaussian2.fppized.o realmat4.fppized.o
intmat3.fppized.o shell2.fppized.o atomvec.fppized.o crystal.fppized.o
scfdata.fppized.o basisvec.fppized.o realmat5.fppized.o gaussian4.fppized.o
shell4.fppized.o time.fppized.o colour.fppized.o colourfunction.fppized.o
intvecmat3.fppized.o intvecintvechash.fppized.o marchingcube.fppized.o
plotgrid.fppized.o isosurface.fppized.o realmat3vec.fppized.o cluster.fppized.o
cpxmat5.fppized.o shellpair.fppized.o shellpairvec.fppized.o
coppensbasisvec.fppized.o irrep.fppized.o irrepvec.fppized.o
pointgroup.fppized.o slaterbasisvec.fppized.o shell1quartet.fppized.o
roby.fppized.o dftgrid.fppized.o mol.fppized.o mol_main.fppized.o
run_mol.fppized.o blas.o lapack.o -o tonto
mol.fppized.f90: In function 'd_sfchi2_d_thermal':
mol.fppized.f90:20073:0: internal compiler error: in vect_is_simple_use, at
tree-vect-stmts.c:8266
function d_sfchi2_d_thermal(U) result(res)


Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [/tmp/ccNjbbMQ.ltrans8.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.

[Bug c++/68489] New: arrays of flexible array members are silently accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 68489
   Summary: arrays of flexible array members are silently accepted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Related to bug 68478, g++ accepts definitions of C flexible array members as an
extension for compatibility.  However, C doesn't intend to allow declaring
arrays of structures containing flexible array members.  Such uses are rejected
by gcc (with a hard error), and diagnosed either as warnings (Clang) or hard
errors (IBM XLC++) in C++ programs.

However, as the test case below shows, g++ silently accepts such uses:

$ cat z.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic -O2  -S -o/dev/null z.cpp
struct A {
int n;
int a [];
};

struct A a[2];   // should be diagnosed/rejected

z.cpp:3:12: warning: ISO C++ forbids zero-size array ‘a’ [-Wpedantic]
 int a [];
^

[Bug libgcc/68491] New: libgcc calls __get_cpuid with 0 level breaks on early athlon.

[christos at zoulas dot com]

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

Bug ID: 68491
   Summary: libgcc calls __get_cpuid with 0 level breaks on early
athlon.
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christos at zoulas dot com
  Target Milestone: ---

http://nxr.netbsd.org/xref/src/external/gpl3/gcc/dist/libgcc/config/i386/cpuinfo.c#284
calls __get_cpuid with 0 level, then we end up in:
http://nxr.netbsd.org/xref/src/external/gpl3/gcc/dist/gcc/config/i386/cpuid.h#263
and end up calling __cpuid even though __get_cpuid_max returns 0. This breaks
on early i486 processors that don't have the cpuid instruction and we end up
getting SIGILL. Our fix is to explicitly check for 0 to prevent that:

 unsigned int *__ecx, unsigned int *__edx)
 {
   unsigned int __ext = __level & 0x8000;
+  unsigned int __maxlevel = __get_cpuid_max (__ext, 0);

-  if (__get_cpuid_max (__ext, 0) < __level)
+  if (__maxlevel == 0 || __maxlevel < __level)
 return 0;

   __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);

[Bug tree-optimization/68493] New: [6 Regression] [graphite] ICE in copy_loop_phi_args

[asolokha at gmx dot com]

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

Bug ID: 68493
   Summary: [6 Regression] [graphite] ICE in copy_loop_phi_args
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

1. 6.0.0-alpha20151115 ICEs on the following reduced testcase when compiling w/
-floop-interchange at -O1, -O2, -O3, or -Ofast:

int ce[2];
int o5;
int p7;

int
main(void)
{
  int j1;
  ce[0] = 0;
  for (j1 = 0; j1 < 2; ++j1)
for (o5 = 1; o5 >= 0; --o5)
  p7 += ce[o5];
  return 0;
}

% gcc-6.0.0-alpha20151122 -O2 -floop-interchange u21pw9kn.c
u21pw9kn.c: In function 'main':
u21pw9kn.c:6:1: internal compiler error: in copy_loop_phi_args, at sese.c:1133
 main(void)
 ^~~~

2. Additionally, it fails the same way on the testcase below w/
-floop-interchange -O1:

int du;

int
main(void)
{
  int u7[2];
  int ar;

  for (ar = 0; ar < 2; ++ar) {
int xo;

for (xo = 0; xo < 2; ++xo) {
  du += u7[ar];
  u7[0] = 0;
}
  }

  return 0;
}

% gcc-6.0.0-alpha20151122 -O1 -floop-interchange da3mkq0z.c
da3mkq0z.c: In function 'main':
da3mkq0z.c:4:1: internal compiler error: in copy_loop_phi_args, at sese.c:1133
 main(void)
 ^~~~

3. 6.0.0-alpha20151122 also fails on both, but w/o verbose ICE description
(probably, due to refactoring performed in r230566 and r230567):

u21pw9kn.c: In function 'main':
u21pw9kn.c:6:1: internal compiler error: Segmentation fault
 main(void)
 ^~~~

[Bug c/68480] -fno-strict-aliasing not respected

[manjeetdahiya at gmail dot com]

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

--- Comment #2 from Manjeet Dahiya  ---
(In reply to Andreas Schwab from comment #1)
> Did you mean gcc-5.1.0?

No. It is for gcc-4.1.0 :) We were checking for equivalence of code generated
across different versions and found this bug. We saw that it is possible to
file bug reports for earlier versions so we filed it.

[Bug c/68480] New: strict-aliasing not respected

[manjeetdahiya at gmail dot com]

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

Bug ID: 68480
   Summary: strict-aliasing not respected
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manjeetdahiya at gmail dot com
  Target Milestone: ---

When I compile following code with -O2 -m32 -S -fno-strict-aliasing
-fno-unrolling -fno-builtin. GCC seems to be not respecting
-fno-strict-aliasing. I don't encounter this issue in gcc-4.8.

struct list { int hd; struct list * tl; };

struct list * reverselist (struct list * l)
{
  struct list * r, * r2;
  for (r = NULL; l != NULL; l = l->tl) {
r2 = mymalloc(sizeof(struct list));
r2->hd = l->hd;
r2->tl = r;
r = r2;
  }
  return r;
}

The issue is that statement A precedes B. It is fine in gcc-4.8.4.

Assembly gcc-4.1.0:
movl  (%ebx), %eax  # .hd, .hd
movl  %esi, 4(%edx) # r, .tl
movl  %edx, %esi  # D.3244, r
A:  movl  4(%ebx), %ebx # .tl, l
B:  movl  %eax, (%edx)  # .hd, .hd
testl %ebx, %ebx  # l

Assembly gcc-4.8.4:
movl  (%ebx), %edx  # l_16->hd, D.5537
movl  %esi, 4(%eax) # r, r_7->tl
movl  %edx, (%eax)  # D.5537, r_7->hd
movl  4(%ebx), %ebx # l_16->tl, l
testl %ebx, %ebx  # l

[Bug c/68485] New: ICE while building gpsd package on microblaze

[sergio.pr...@e-labworks.com]

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

Bug ID: 68485
   Summary: ICE while building gpsd package on microblaze
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergio.pr...@e-labworks.com
  Target Milestone: ---

Package gpsd 3.15 fails to build with an internal compiler error on the
microblaze architecture.

This is the build command used (toolchain generated from Buildroot):

/home/sprado/workspace/build/buildroot/bugs/6872/host/usr/bin/microblazeel-buildroot-linux-gnu-gcc
-o rtcm2_json.os -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os
--sysroot=/home/sprado/workspace/build/buildroot/bugs/6872/host/usr/microblazeel-buildroot-linux-gnu/sysroot
-Wextra -Wall -Wno-uninitialized -Wno-missing-field-initializers -Wcast-align
-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith
-Wreturn-type -pthread -Wmissing-declarations -pthread -fPIC -O2
"-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" rtcm2_json.c

This is the error message:

:0:0: warning: "_LARGEFILE_SOURCE" redefined
:0:0: note: this is the location of the previous definition
rtcm2_json.c: In function ‘json_rtcm2_read’:
rtcm2_json.c:258:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
 }
 ^

Apparently the problem is related to optimization. Disabling -fschedule-insns
and -fexpensive-optimizations fix the problem.

[Bug fortran/47040] Make error message for empty array constructor more helpful/correct

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug ada/68481] New: GNAT rejects protected procedure with aspect Interrupt_Handler => True (explicitly)

[georggcc at googlemail dot com]

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

Bug ID: 68481
   Summary: GNAT rejects protected procedure with aspect
Interrupt_Handler => True (explicitly)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georggcc at googlemail dot com
  Target Milestone: ---

The protected procedure declared in P1 makes gcc reject its body,
and only if Interrupt_Handler is given the value True explicitly.

package L1 is
   protected P1 is

  procedure On_1 with Interrupt_Handler => True;

   end P1;
end L1;

package Body L1 is
   protected body P1 is

  procedure On_1 is
  begin
 null;
  end On_1;

   end P1;
end L1;

gcc -c -gnatvwa l1.adb

GNAT 5.2.1 20151121 [gcc-5-branch revision 230708]
Copyright 1992-2015, Free Software Foundation, Inc.

Compiling: l1.adb
Source file time stamp: 2015-11-22 09:45:05
Compiled at: 2015-11-22 10:45:16

 4.   procedure On_1 is
  |
>>> expected type "System.Interrupts.Dynamic_Interrupt_Protection"
>>> found private type "System.Tasking.Protected_Objects.Protection"

 10 lines: 2 errors


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/bauhaus/mine5/libexec/gcc/x86_64-apple-darwin13.4.0/5.2.1/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: /Users/bauhaus/src/gcc/configure --prefix=/Users/bauhaus/mine5
--disable-nls --disable-multilib --disable-libstdcxx-pch
--enable-languages=c,ada,c++ CC=gcc
Thread model: posix
gcc version 5.2.1 20151121 [gcc-5-branch revision 230708] (GCC)

[Bug target/44995] define a macro for presence of -mregnames option

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #5 from Segher Boessenkool  ---
Closing then.

[Bug target/43871] -mcpu=power4 -mtune=cell emits power7/cell-only opcodes

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Still happens.  rs6000_cpu is set based on the -mtune= setting instead
of based on the -mcpu setting.  I'll take it.

[Bug target/68482] New: No vectorization for x86-64

[lvqcl.mail at gmail dot com]

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

Bug ID: 68482
   Summary: No vectorization for x86-64
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lvqcl.mail at gmail dot com
  Target Milestone: ---

GCC ver: 5.2.0 and 4.9.2
Arch: x86-64
Options: -S -O2 -ftree-vectorize -msse2
Code:

#include 

void test(int32_t* input, int32_t* out, unsigned x1, unsigned x2)
{
unsigned i, j;
unsigned end = x1;

for(i = j = 0; i < 1000; i++) {
int32_t sum = 0;
end += x2;
for( ; j < end; j++)
sum += input[j];
out[i] = sum;
}
}

GCC is able to vectorize the loop for IA32 arch, but not x86-64.

The innermost loop for IA32:
L4:
movdqu  (%ecx), %xmm1
addl$1, %ebx
addl$16, %ecx
cmpl%ebx, 4(%esp)
paddd   %xmm1, %xmm0
ja  L4

The innermost loop for x86-64:
.L3:
movl%eax, %r10d
addl$1, %eax
addl(%rcx,%r10,4), %edx
cmpl%eax, %r8d
jne .L3

[Bug other/68483] New: gcc 5.2: suboptimal code compared to 4.9

[lvqcl.mail at gmail dot com]

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

Bug ID: 68483
   Summary: gcc 5.2: suboptimal code compared to 4.9
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lvqcl.mail at gmail dot com
  Target Milestone: ---

#include 

void test(int32_t* input, int32_t* out, unsigned x1, unsigned x2)
{
unsigned i, j;
unsigned end = x1;

for(i = j = 0; i < 1000; i++) {
int32_t sum = 0;
end += x2;
for( ; j < end; j++)
sum += input[j];
out[i] = sum;
}
}

options used: -S -O2 -ftree-vectorize -msse2
GCC 5.2 generates the following code:
...
movdqa  %xmm0, %xmm1
movl8(%esp), %ebx
psrldq  $8, %xmm1
paddd   %xmm1, %xmm0
movdqa  %xmm0, %xmm3
pshufd  $255, %xmm0, %xmm2
addl%ebx, %eax
cmpl%ebx, %esi
pshufd  $85, %xmm0, %xmm1
punpckhdq   %xmm0, %xmm3
movd%xmm2, %ecx
punpckldq   %xmm3, %xmm1
movd%ecx, %xmm2
punpcklqdq  %xmm2, %xmm1
paddd   %xmm1, %xmm0
movd%xmm0, %ecx
...

while GCC 4.9.2 generates this:
...
movdqa  %xmm0, %xmm1
movl8(%esp), %ebx
psrldq  $8, %xmm1
paddd   %xmm1, %xmm0
movdqa  %xmm0, %xmm1
addl%ebx, %eax
cmpl%ebx, %esi
psrldq  $4, %xmm1
paddd   %xmm1, %xmm0
movd%xmm0, %ecx
...

GCC 4.9.2: 1 psrldq instruction
GCC 5.2.0: 2 pshufd, 2 movd, 2 punpckldq, 1 punpcklqdq instructions.

Also, GCC 5.2.0 can generate the same code as GCC 4.9.2, but it requires
-mssse3 option for this. It's strange that -mssse3 is necessary to generate
more efficient SSE2 code.

[Bug testsuite/43496] gcc.target/powerpc/gcse-1.c fails on powerpc-unknown-linux-gnu with -fpic/-fPIC

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Confirmed, I'll take it.

[Bug target/41868] cell microcode instruction (addic.) is generated for a trivial loop with -O2 optimizations, hurting performance badly

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #10 from Segher Boessenkool  ---
We no longer generate addic. for this testcase, but that is an accident
(combine first makes dec+cmp into an addic., but then also combines it
with the conditional branch into a bdnz pattern; this needs splitting
later, and since r218591 we no longer split to addic.).

*add3_imm_{dot,dot2} should have rs6000_gen_cell_microcode in
the condition.  Mine.

[Bug c/68480] -fno-strict-aliasing not respected

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Did you mean gcc-5.1.0?

[Bug target/43763] segfault when using by -mwarn-cell-microcode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
Still happens.

[Bug lto/42534] ICE with -flto when using __attribute__((__aligned__(X)))

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Segher Boessenkool  ---
Yep, doesn't fail any more (on no open branch).  Closing.

[Bug c++/68484] New: _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[vvsed at hotmail dot com]

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

Bug ID: 68484
   Summary: _mm_storel_epi64((__m128i *)x, m); does nothing if "x"
is a "volatile" ptr
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vvsed at hotmail dot com
  Target Milestone: ---

Created attachment 36803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36803=edit
It's *.ii file for the above source.

The following program prints "0 0" instead of "1 1".
If we use _mm_storel_pi() instead of _mm_storel_epi64(), it's OK.
The CPU is Intel Haswell with Windows 7.1.
Same with 4.8, 4.9, 5.1 g++ versions.


/*
D:\Tools\MinGW64\bin\g++.exe -m64 -O2 -Wall -Wextra -save-temps gcerr.cpp
-ovx_class_gc

Compiler: http://tdm-gcc.tdragon.net/about

_mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr
*/

#include 
#include 

int main(int argc, const char *argv[])
{
int _x[2] = {0};
int * volatile x = _x;
__m128i m = _mm_set1_epi32(1);
chars[1];

_mm_storel_epi64((__m128i *)x, m);
//  _mm_storel_pi((__m64 *)x, *(__m128 *));   //OK

fprintf(stdout, "%d %d \npress Enter", x[0], x[1]);

gets(s);
return 0;
}

[Bug fortran/67460] [5 Regression] Spurious: f951: all warnings being treated as errors

[dominiq at gcc dot gnu.org]

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

--- Comment #9 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Nov 22 19:23:39 2015
New Revision: 230724

URL: https://gcc.gnu.org/viewcvs?rev=230724=gcc=rev
Log:
2015-11-22  Dominique d'Humieres  

Backport from mainline
2015-09-14  Manuel Lopez-Ibanez  

PR fortran/67460
* diagnostic.c (diagnostic_initialize): Do not set
some_warnings_are_errors.
(diagnostic_finish): Use DK_WERROR count instead.
(diagnostic_report_diagnostic): Do not set
some_warnings_are_errors.
* diagnostic.h (struct diagnostic_context): Remove
some_warnings_are_errors.

PR fortran/67460
* gfortran.dg/pr67460.f90: New test.

--This line, and those

MChangeLog
Mdiagnostic.h
Mdiagnostic.c
Mtestsuite/ChangeLog
Atestsuite/gfortran.dg/pr67460.f90

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67460.f90
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/diagnostic.c
branches/gcc-5-branch/gcc/diagnostic.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67460] [5 Regression] Spurious: f951: all warnings being treated as errors

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #10 from Dominique d'Humieres  ---
Fixed on trunk and 5 branch, closing as FIXED. Thanks for the report.

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Nov 22 19:41:20 2015
New Revision: 230726

URL: https://gcc.gnu.org/viewcvs?rev=230726=gcc=rev
Log:
2015-11-22  Steven G. Kargl  

PR fortran/68486
* simplify.c (gfc_simplify_cshift):  Add EXPR_OP to mix.

2015-11-22  Steven G. Kargl  

PR fortran/68486
* gfortran.dg/simplify_cshift_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/simplify_cshift_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk with r230726.

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
Created attachment 36805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36805=edit
Expanded test case

Attached is an expanded test case. Could someone review and confirm this is
valid.  I need to work some code in interface.c to eliminate an error I am
getting and want to make sure the error is valid or not.

[Bug fortran/68218] ALLOCATE with size given by a module function

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to vehre from comment #3)
> Author: vehre
> Date: Sun Nov  8 17:37:42 2015
> New Revision: 229956
> 
> URL: https://gcc.gnu.org/viewcvs?rev=229956=gcc=rev

Is it possible to commit this also to the 5 branch before the
upcoming 5.3 release?

[Bug rtl-optimization/37471] Move invariant pulls too many cmps out of a loop

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-22
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 6.0

--- Comment #6 from Segher Boessenkool  ---
Oh wow.

... Still happens with trunk.  Confirmed.

[Bug middle-end/36770] PowerPC missed autoincrement opportunity

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed|2008-07-09 18:22:19 |2015-11-22
 CC||segher at gcc dot gnu.org
  Known to work||6.0
  Known to fail||4.9.3

--- Comment #7 from Segher Boessenkool  ---
Trunk handles this perfectly.  Don't know about GCC 5.  4.9 doesn't.

[Bug rtl-optimization/37262] Two branches of the same condition being emitted

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-22
 CC||segher at gcc dot gnu.org
  Known to work||6.0
 Ever confirmed|0   |1
  Known to fail||4.9.3

--- Comment #3 from Segher Boessenkool  ---
Your first testcase works on both 4.9 and 6.0 now.  The second
still fails on 4.9, but works on 6.  I don't know about GCC 5.

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> This patch ... removes the ICE and it passes regression testing.

Confirmed.

[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
Is the test case corrupted somehow?

I get syntax errors compiling it:

test.f03:30:35:

   type, bind(c) :: Args_Basic_epv_t
   1

Warning: Derived type 'args_basic_epv_t' with BIND(C) attribute at (1) is
empty, and may be inaccessible by the C companion processor
test.f03:130:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1

Error: Unclassifiable statement at (1)
test.f03:103:8:

 if (b1) then
1

Error: IF clause at (1) requires a scalar LOGICAL expression
test.f03:99:8:

 if (b) then
1

Error: IF clause at (1) requires a scalar LOGICAL expression

[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> Is the test case corrupted somehow? ...

This is what I get on x86_64-apple-darwin14 when there is no ICE, but depending
on the "mood" of my machine I sometime I get the ICEs reported in comment 7. So
I suspect there is some uninitialized variable(s), dangling pointer(s), ... in
the error chain, but I am unable to have a consistent way to reproduce the
problem.

I have just compiled the test 12 times with 8 normal error chains and 4 ending
with an iCE.

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed. I have attached a test case. I think that the gcc_unreachable ();
should be replaced with a fallback to the intrinsic version in the library when
possible.

[Bug c++/68484] _mm_storel_epi64((__m128i *)x, m); does nothing if "x" is a "volatile" ptr

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
-fno-strict-aliasing
The intrinsic is implemented inline as:
*(long long *)__P = ...
which exposes the strict aliasing. I don't know how much we want to promise for
those functions. It would be possible to use a may_alias typedef for long long,
but I'll let someone else decide if we want to.

[Bug target/68482] No vectorization for x86-64

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
The extra cast so 32-bit unsigned and 64-bit pointers can interact confuses the
compiler. Trunk (gcc-6) seems to work fine though, can you confirm?

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

[nszabolcs at gmail dot com]

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

Szabolcs Nagy  changed:

   What|Removed |Added

 CC||nszabolcs at gmail dot com

--- Comment #13 from Szabolcs Nagy  ---
if gcc treats p-q as (ssize_t)p-(ssize_t)q and makes
optimization decisions based on signed int range then
that's broken and leads to wrong code gen.

e.g. gcc optimizes if(n - 0x7fff > 0).. away
(but not if(-0x7fff-1 - n > 0), but that's another
bug), so

$ cat bug.c
#include 
int main()
{
char *p = mmap((void*)(0x8000-4096), 2*4096, PROT_READ|PROT_WRITE,
   MAP_FIXED|MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
char *q = (void*)(0x7fff); // p+4095
if ((p+4096) - q > 0) return 0; // wrongly optimized away
return 1;
}

$ gcc-5.2-i386 -fomit-frame-pointer -fno-asynchronous-unwind-tables -O3 -S
bug.c
$ cat bug.s
.file   "bug.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.section.text.startup,"ax",@progbits
.LHOTB0:
.p2align 2,,3
.globl  main
.type   main, @function
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl   -4(%ecx)
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
subl$8, %esp
pushl   $0
pushl   $0
pushl   $-1
pushl   $50
pushl   $3
pushl   $8192
pushl   $2147479552
callmmap
addl$32, %esp
movl$1, %eax
movl-4(%ebp), %ecx
leave
leal-4(%ecx), %esp
ret
.size   main, .-main
.section.text.unlikely
.LCOLDE0:
.section.text.startup
.LHOTE0:
.ident  "GCC: (GNU) 5.2.0"
.section.note.GNU-stack,"",@progbits

after the mmap call %eax is unconditionally set to 1.

at runtime the mmap succeeds and the returned object
crosses the 0x8000 boundary, so the return value is
incorrect.

(i found this bug report after incorrectly getting SIGILL
at ptrdiffs with
-fsanitize=undefined -fsanitize-undefined-trap-on-error )

[Bug rtl-optimization/36693] missed optimization for pointer access with offset on powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||

--- Comment #2 from Segher Boessenkool  ---
GCC now generates the same code for both, no matter what tuning.

get_and_increment1:
lwz 9,0(3)
addi 10,9,4
stw 10,0(3)
lwz 3,0(9)
blr

Closing as fixed.

[Bug c++/68487] New: [concepts] bad "invalid reference to variadic concept" error

[ryan.burn at gmail dot com]

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

Bug ID: 68487
   Summary: [concepts] bad "invalid reference to variadic concept"
error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code should compile but it gives the error:

main.cpp:7:15: error: invalid reference to function concept ‘template constexpr bool C()’
 requires C();
   ^


template  concept bool C() {   
  return true;   
}   

template
  requires requires(const Xs&... xs) {   
requires C();   
  }   
struct A {   
};   

int main() {   
  return 0;   
} 

[Bug fortran/68486] New: [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 68486
   Summary: [6 Regression] 187.facerec in SPEC CPU 2000 failed to
build
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, r230718 gave:

gfortran -c -o gaborRoutines.o   -DSPEC_CPU2000_LP64 -O2 -ffast-math  
gaborRoutines.f90
f951: internal compiler error: in gfc_simplify_cshift, at
fortran/simplify.c:1823
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
specmake: *** [gaborRoutines.o] Error 1

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Created attachment 36804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36804=edit
Test showing the problem

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  ---
I have done some experimenting.  Since gcc supports OMP and I think to some
extent ACC why not come up with a MATMUL that exploits these if present?  On
the darwin platform discussed in comment #12, the performance is excellent. 
Does darwin implementation provided exploit OpenCL?  What is it using?  Why not
enable that on other platforms if present.

I am going to explore OpenCL and clBLAS to see if I can get it to work.  If I
am successful, I would like to hide it behind MATMUL if possible.  Any other
opinions?

[Bug target/68482] No vectorization for x86-64

[lvqcl.mail at gmail dot com]

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

--- Comment #2 from lvqcl.mail at gmail dot com ---
(In reply to Marc Glisse from comment #1)
> The extra cast so 32-bit unsigned and 64-bit pointers can interact confuses
> the compiler. Trunk (gcc-6) seems to work fine though, can you confirm?

I never compiled GCC myself (and I use Windows), so I found and downloaded 
"gcc version 6.0.0 20151121 (experimental)" from
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/

The loop is vectorized:
.L4:
movdqu  (%rbx), %xmm0
addl$1, %r9d
addq$16, %rbx
cmpl%r9d, %edx
paddd   %xmm0, %xmm1
ja  .L4

[Bug libfortran/51119] MATMUL slow for large matrices

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #18 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #17)
> I have done some experimenting.  Since gcc supports OMP and I think to some
> extent ACC why not come up with a MATMUL that exploits these if present?  On
> the darwin platform discussed in comment #12, the performance is excellent. 
> Does darwin implementation provided exploit OpenCL?  What is it using?  Why
> not enable that on other platforms if present.
> 
> I am going to explore OpenCL and clBLAS to see if I can get it to work.  If
> I am successful, I would like to hide it behind MATMUL if possible.  Any
> other opinions?

yes, this is tricky. In a multithreaded code executing matmul, what is the
strategy (nested parallelism, serial, ...) ? We usually link in a serial blas
because threading in the library is usually not good for performance of the
code overall, i.e. nested parallelism tends to perform badly. Also, how many
threads would you use by default (depending on matrix size, machine load) ?
Users on an N core machine might run N jobs in parallel, and not expect those
to start several threads each. 

Maybe, this could be part of the auto-parallelize (or similar) option that gcc
has ?

[Bug other/68483] gcc 5.2: suboptimal code compared to 4.9

[lvqcl.mail at gmail dot com]

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

--- Comment #1 from lvqcl.mail at gmail dot com ---
(In reply to lvqcl.mail from comment #0)
"gcc version 6.0.0 20151121 (experimental)" from dongsheng-daily (mingw-w64)
generates the same code as 4.9.2. So this regression was fixed in 6.x branch.

[Bug middle-end/68488] New: [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[hjl.tools at gmail dot com]

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

Bug ID: 68488
   Summary: [6 Regression] internal compiler error: in
expand_insn, at optabs.c:6947
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r230487 failed to build 189.lucas in SPEC CPU 2000:

gfortran -O2 -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin -DSPEC_CPU2000_LP64 lucas_distrib_spec.o -o lucas
lucas_distrib_spec.f90: In function 'lucas_distrib':
lucas_distrib_spec.f90:378:0: internal compiler error: in expand_insn, at
optabs.c:6947
   err_abs=4*dnint(sqrt(1d0*n))


0x9321e3 expand_insn(insn_code, unsigned int, expand_operand*)
../../src-trunk/gcc/optabs.c:6947
0x80c2b4 expand_direct_optab_fn
../../src-trunk/gcc/internal-fn.c:2124
0x62d00a expand_call_stmt
../../src-trunk/gcc/cfgexpand.c:2565
0x62d00a expand_gimple_stmt_1
../../src-trunk/gcc/cfgexpand.c:3525
0x62d00a expand_gimple_stmt
../../src-trunk/gcc/cfgexpand.c:3688
0x62fbca expand_gimple_basic_block
../../src-trunk/gcc/cfgexpand.c:5694
0x635486 execute
../../src-trunk/gcc/cfgexpand.c:6309
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccRUTyPS.ltrans1.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[gang.chen.5i5j at gmail dot com]

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

--- Comment #17 from Chen Gang  ---
I guess the diff below should be OK, I shall give a make check test.

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 7b10764..257 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -5170,7 +5170,9 @@ c_parser_statement_after_labels (c_parser *parser,
vec *chain)
   c_parser_consume_token (parser);
   break;
 case CPP_PRAGMA:
-  c_parser_pragma (parser, pragma_stmt);
+  c_parser_error (parser,
+ "don't allow if, while, do, swith, or label"
+);
   break;
 default:
 expr_stmt: