[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

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

--- Comment #50 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 11 07:09:04 2015
New Revision: 222992

URL: https://gcc.gnu.org/viewcvs?rev=222992&root=gcc&view=rev
Log:
PR target/65780
* config/s390/linux.h (TARGET_BINDS_LOCAL_P): Define to
default_binds_local_p_2.
* config/arm/linux-elf.h (TARGET_BINDS_LOCAL_P): Likewise.
* config/aarch64/aarch64-linux.h (TARGET_BINDS_LOCAL_P): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-linux.h
trunk/gcc/config/arm/linux-elf.h
trunk/gcc/config/s390/linux.h

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

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

--- Comment #51 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 11 07:14:10 2015
New Revision: 222993

URL: https://gcc.gnu.org/viewcvs?rev=222993&root=gcc&view=rev
Log:
PR target/65780
* config/s390/linux.h (TARGET_BINDS_LOCAL_P): Define to
default_binds_local_p_2.
* config/arm/linux-elf.h (TARGET_BINDS_LOCAL_P): Likewise.
* config/aarch64/aarch64-linux.h (TARGET_BINDS_LOCAL_P): Likewise.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/aarch64-linux.h
branches/gcc-5-branch/gcc/config/arm/linux-elf.h
branches/gcc-5-branch/gcc/config/s390/linux.h

[Bug bootstrap/66038] SIGSEGV at stage 2 - build/genmatch fails in operand::gen_transform

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Sat, 9 May 2015, dougmencken at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> 
> --- Comment #3 from Douglas Mencken  ---
> (In reply to Richard Biener from comment #2)
> > I think you may run into a host compiler issue?  (ISTR a similar bug for
> > darwin)
> > 
> > What is your host compiler?  I suppose ppc-darwin still uses gcc 4.2.x,
> > right?
> 
> My stage0 compiler is 4.9.2 (not Apple-patched 4.2.1). I also mentioned its 
> "-v
> output" in above comment. But I doubt it is related to host compiler...
> 
> This is happening on stage2, and
> $ prev-gcc/build/genmatch --gimple ../gcc-5.1.0/gcc/match.pd
> works well.
> 
> It is
> $ gcc/build/genmatch --gimple ../gcc-5.1.0/gcc/match.pd
> that fails.
> 
> Backtrace.
> 
> $ gdb --args gcc/build/genmatch --gimple ../gcc-5.1.0/gcc/match.pd
> (gdb) run
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x419e04bc
> 0xdcb0 in operand::gen_transform ()
> (gdb) bt
> #0  0xdcb0 in operand::gen_transform ()
> #1  0x7fd8 in get_operator ()
> #2  0x99a0 in parser::parse_operator_list ()
> #3  0xcc38 in parser::parse_pattern ()
> #4  0xdc44 in parser::parser ()
> #5  0x0006357c in main () at
> ../../../../gcc-5.1.0/libstdc++-v3/libsupc++/eh_alloc.cc:121

Can you build stage2 with debuginfo?  (--without-build-config at 
configure)

That should imrpove the backtrace.

Thanks,
Richard.

[Bug middle-end/65984] [4.9 Regression] ICE: definition in block 4 does not dominate use in block 2 with -fnon-call-exceptions -fsanitize=enum

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE:   |[4.9 Regression] ICE:
   |definition in block 4 does  |definition in block 4 does
   |not dominate use in block 2 |not dominate use in block 2
   |with -fnon-call-exceptions  |with -fnon-call-exceptions
   |-fsanitize=enum |-fsanitize=enum

--- Comment #4 from Jakub Jelinek  ---
Fixed for 5.2+ so far.

[Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
A patch for the ARM backend instead has been posted in
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00278.html

[Bug fortran/58586] ICE with derived type with allocatable component passed by value

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Contrary to Dominique's comment in 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894#c30
> adding the patch in
> https://gcc.gnu.org/ml/fortran/2015-04/msg00058.html
> on top of r222970 doesn't break our code, and all of our tests run as 
> intended.

I was speaking of more recent patches such as

https://gcc.gnu.org/ml/fortran/2015-05/msg00017.html

or

https://gcc.gnu.org/ml/fortran/2015-05/msg00035.html

[Bug c++/66096] Unexpected __gnu_cxx::__concurrence_lock_error with _GLIBCXX_DEBUG

[egor_suvorov at mail dot ru]

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

Egor Suvorov  changed:

   What|Removed |Added

 CC||egor_suvorov at mail dot ru

--- Comment #2 from Egor Suvorov  ---
This bug was also reported to TDM-GCC's bugtracker at
http://sourceforge.net/p/tdm-gcc/bugs/264/

Smaller example:

#define _GLIBCXX_DEBUG
#include 

std::set a;

int main() {
std::set b;
}

[Bug rtl-optimization/66076] [5/6 Regression] ICE: in vec_safe_grow, at vec.h:618 with -funroll-loops -mno-prefer-avx128 -march=bdver4

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon May 11 09:35:53 2015
New Revision: 222999

URL: https://gcc.gnu.org/viewcvs?rev=222999&root=gcc&view=rev
Log:
gcc/
PR rtl-optimization/66076
* rtlanal.c (generic_subrtx_iterator ::add_single_to_queue):
Don't grow the heap array if it is already big enough from a
previous iteration.

gcc/testsuite/
PR rtl-optimization/66076
* gcc.dg/torture/pr66076.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66076.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/58586] ICE with derived type with allocatable component passed by value

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
Hm, ok, these are not just in a single file, cannot promise that I will be able
to look into them. :(

[Bug tree-optimization/66101] New: [5/6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[mpolacek at gcc dot gnu.org]

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

Bug ID: 66101
   Summary: [5/6 Regression] internal compiler error: in
verify_loop_structure, at cfgloop.c:1662
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

$ ./cc1 -quiet -O2 o.c 
o.c: In function ‘bar’:
o.c:8:5: warning: implicit declaration of function ‘longjmp’
[-Wimplicit-function-declaration]
 longjmp ();
 ^
o.c: In function ‘foo’:
o.c:16:3: warning: implicit declaration of function ‘_setjmp’
[-Wimplicit-function-declaration]
   _setjmp ();
   ^
o.c:29:1: error: size of loop 1 should be 3, not 5
 }
 ^
o.c:29:1: internal compiler error: in verify_loop_structure, at cfgloop.c:1662
0x8437cc verify_loop_structure()
/home/marek/src/gcc/gcc/cfgloop.c:1662
0xb9b354 loop_optimizer_init(unsigned int)
/home/marek/src/gcc/gcc/loop-init.c:124
0xc872fa execute
/home/marek/src/gcc/gcc/predict.c:3056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

int a, c, d, e;

int
bar ()
{
  int b = *(long *) 7 == 5 ? : 0;
  if (a || a > b)
longjmp ();
  return 1;
}

void
foo ()
{
  long f;
  _setjmp ();
  for (; d; c++)
switch (c)
  case 0:
  {
f = bar () >> 1;
if (e)
  goto L;
if (bar () >> 1)
  goto L;
  }
L:
  ;
}

[Bug tree-optimization/66101] [5/6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

[Bug tree-optimization/66101] [5/6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Started with r211625.

[Bug fortran/66102] New: dependency mishandling with reallocation on assignment

[mikael at gcc dot gnu.org]

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

Bug ID: 66102
   Summary: dependency mishandling with reallocation on assignment
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35518&action=edit
test

This test shows a number of memory errors at runtime.
Some of them are related to pr65792 and pr61831.

[Bug fortran/66102] dependency mishandling with reallocation on assignment

[mikael at gcc dot gnu.org]

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

--- Comment #1 from Mikael Morin  ---
(In reply to Mikael Morin from comment #0)
> This test shows a number of memory errors at runtime.
> Some of them are related to pr65792 and pr61831.

And this is a partial fix for what remains after these bugs are fixed.


Index: trans-array.c
===
--- trans-array.c   (révision 222978)
+++ trans-array.c   (copie de travail)
@@ -4465,7 +4465,10 @@ gfc_conv_resolve_dependencies (gfc_loopinfo * loop

nDepend = gfc_check_dependency (dest_expr, ss_expr, false);

- continue;
+ if (nDepend)
+   break;
+ else
+   continue;
}

   if (dest_expr->symtree->n.sym != ss_expr->symtree->n.sym)

[Bug lto/66103] New: [6 Regression] ICE verify_type failed

[burnus at gcc dot gnu.org]

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

Bug ID: 66103
   Summary: [6 Regression] ICE verify_type failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following program used to compile awhile ago, but now it ICEs when compiled
with "g++ -flto -g". It works without "-g"


class ios_base {
  public:
class Init {
public:
  Init ();
};
  };
  static ios_base::Init __ioinit;
class Foo {
  static const Foo m_var;
  static inline const Foo & getFoo () {
return m_var;
  }
};


input17c.ii:14:2: error: type variant has different TYPE_FIELDS
...
input17c.ii:14:2: internal compiler error: verify_type failed
0xf2b36d verify_type(tree_node const*)
../../gcc/tree.c:12971
0x970e54 gen_type_die_with_usage
../../gcc/dwarf2out.c:20247
0x96f47b gen_decl_die
../../gcc/dwarf2out.c:21007
0x9703ec dwarf2out_decl
../../gcc/dwarf2out.c:21394
0xcb962c emit_debug_global_declarations(tree_node**, int)
../../gcc/toplev.c:576
0x6d0c2d cp_write_global_declarations()
../../gcc/cp/decl2.c:4814

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||agriff at tin dot it

--- Comment #17 from Richard Biener  ---
*** Bug 66086 has been marked as a duplicate of this bug. ***

[Bug c/66086] Casting a pointer to an uintptr_t and later to a double confuses the optimizer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Dup.

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

[Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[6.0 Regression] memory |[6 Regression] memory leak
   |leak with source allocation |with source allocation in
   |in internal subprogram  |internal subprogram

[Bug tree-optimization/66101] [5/6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

[Bug lto/66103] [6 Regression] ICE verify_type failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug web/66104] New: svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/

[t...@vr-web.de]

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

Bug ID: 66104
   Summary: svn co
https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t...@vr-web.de
  Target Milestone: ---

Can't checkout branches
* gcc-5-branch
* gcc-4_9-branch
* gcc-4_8-branch

all have the same errors:
A libgomp/testsuite/libgomp.c++/loop-11.C
A libgomp/testsuite/libgomp.c++/udr-4.C
A libgomp/testsuite/libgomp.c++/loop-15.C
A libgomp/testsuite/Makefile.in
A libgomp/testsuite/libgomp.fortran
ERROR: Failed to check out http://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch
org.tmatesoft.svn.core.SVNException: svn: E175002: Processing REPORT request
response failed: XML-Dokumentstrukturen müssen innerhalb derselben Entität
beginnen und enden. (/svn/gcc/!svn/vcc/default) 
svn: E175002: REPORT request failed on '/svn/gcc/!svn/vcc/default'

This is since, at last friday, Mai, 11th 2015. Checkouts failing every time
since then.
Could you please have a look at your repositories?

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[robert.suchanek at imgtec dot com]

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

--- Comment #10 from Robert Suchanek  ---
Hi Vlad,

I'm pleased with the results so far. In the larger codebase, it behaves as the
original
patch reverted and I haven't seen a missed case. 

The code size doesn't seem to be hurt either. I see ~0.5% improvement on
average case which is good. Thanks a lot for the patch. I've thrown it against
standard regression and it will take some time to complete but I'm confident it
will pass. Initially it failed because of a missing declaration of the
new_class variable though.

[Bug bootstrap/66105] New: [6 regression] genpreds.c compile error in stage2 on powerpc64-linux

[mikpelinux at gmail dot com]

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

Bug ID: 66105
   Summary: [6 regression] genpreds.c compile error in stage2 on
powerpc64-linux
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to bootstrap gcc-6-20150510 on powerpc64-linux fails with:

/mnt/scratch/objdir6/./prev-gcc/xg++ -B/mnt/scratch/objdir6/./prev-gcc/
-B/mnt/scratch/install6/powerpc64-unknown-linux-gnu/bin/ -nostdinc++
-B/mnt/scratch/objdir6/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/scratch/objdir6/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/mnt/scratch/objdir6/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
 -I/mnt/scratch/objdir6/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include 
-I/mnt/scratch/gcc-6-20150510/libstdc++-v3/libsupc++
-L/mnt/scratch/objdir6/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/mnt/scratch/objdir6/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/mnt/scratch/gcc-6-20150510/gcc
-I/mnt/scratch/gcc-6-20150510/gcc/build
-I/mnt/scratch/gcc-6-20150510/gcc/../include 
-I/mnt/scratch/gcc-6-20150510/gcc/../libcpp/include  \
-o build/genpreds.o /mnt/scratch/gcc-6-20150510/gcc/genpreds.c
In file included from ./tm.h:33:0,
 from /mnt/scratch/gcc-6-20150510/gcc/genpreds.c:26:
/mnt/scratch/gcc-6-20150510/gcc/config/rs6000/option-defaults.h:46:20: error:
C++11 requires a space between string literal and macro [-Werror=c++11-compat]
 #define OPT_ARCH32 "!"OPT_64
^
cc1plus: all warnings being treated as errors
make[3]: *** [build/genpreds.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir6/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir6'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir6'
make: *** [bootstrap] Error 2

The previous weekly snapshot, gcc-6-20150503, bootstrapped fine.
This snapshot also bootstrapped fine on x86_64-linux.

Configured with:
/mnt/scratch/gcc-6-20150510/configure --prefix=/mnt/scratch/install6
--with-gmp=/home/mikpe/pkgs/linux-ppc64/gmp-6.0.0
--with-mpfr=/home/mikpe/pkgs/linux-ppc64/mpfr-3.1.2
--with-mpc=/home/mikpe/pkgs/linux-ppc64/mpc-1.0.3 --disable-plugin
--disable-lto --disable-nls --enable-threads=posix --with-cpu=default32
--enable-checking=release --disable-libmudflap --enable-linker-build-id
--enable-languages=c,c++,ada --disable-libsanitizer

[Bug bootstrap/66105] [6 regression] genpreds.c compile error in stage2 on powerpc64-linux

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
diff --git a/gcc/config/rs6000/option-defaults.h
b/gcc/config/rs6000/option-defaults.h
index 7da2c7c..95a1472 100644
--- a/gcc/config/rs6000/option-defaults.h
+++ b/gcc/config/rs6000/option-defaults.h
@@ -39,11 +39,11 @@
 #endif

 #if TARGET_DEFAULT & OPTION_MASK_64BIT
-#define OPT_ARCH64 "!"OPT_32
+#define OPT_ARCH64 "!" OPT_32
 #define OPT_ARCH32 OPT_32
 #else
 #define OPT_ARCH64 OPT_64
-#define OPT_ARCH32 "!"OPT_64
+#define OPT_ARCH32 "!" OPT_64
 #endif

 /* Support for a compile-time default CPU, et cetera.  The rules are:

[Bug tree-optimization/65791] Postpone expand_ifn_va_arg till after optimize_va_list_gpr_fpr_size

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
Is this the sort of thing we want? We use the hook to tell us what the offset
is (rather than to have to retrieve it ourselves) and use that in the
pass_stdarg optimization?

...
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 7bd9ff3..6ca594db 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -9033,7 +9033,7 @@ ix86_va_start (tree valist, rtx nextarg)

 static tree
 ix86_gimplify_va_arg (tree valist, tree type, gimple_seq *pre_p,
- gimple_seq *post_p)
+ gimple_seq *post_p, tree *gpr_offset_p, tree
*fpr_offset_p)
 {
   static const int intreg[6] = { 0, 1, 2, 3, 4, 5 };
   tree f_gpr, f_fpr, f_ovf, f_sav;
@@ -9269,15 +9269,19 @@ ix86_gimplify_va_arg (tree valist, tree type,
gimple_seq *pre_p,

   if (needed_intregs)
{
- t = build2 (PLUS_EXPR, TREE_TYPE (gpr), gpr,
- build_int_cst (TREE_TYPE (gpr), needed_intregs * 8));
+ tree gpr_offset = build_int_cst (TREE_TYPE (gpr), needed_intregs *
8);
+ if (gpr_offset_p)
+   *gpr_offset_p = gpr_offset;
+ t = build2 (PLUS_EXPR, TREE_TYPE (gpr), gpr, gpr_offset);
  gimplify_assign (gpr, t, pre_p);
}

   if (needed_sseregs)
{
- t = build2 (PLUS_EXPR, TREE_TYPE (fpr), fpr,
- build_int_cst (TREE_TYPE (fpr), needed_sseregs * 16));
+ tree fpr_offset = build_int_cst (TREE_TYPE (fpr), needed_sseregs *
16);
+ if (fpr_offset_p)
+   *fpr_offset_p = fpr_offset;
+ t = build2 (PLUS_EXPR, TREE_TYPE (fpr), fpr, fpr_offset);
  gimplify_assign (fpr, t, pre_p);
}

...

[Bug bootstrap/66105] [6 regression] genpreds.c compile error in stage2 on powerpc64-linux

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Author: trippels
Date: Mon May 11 11:24:35 2015
New Revision: 223002

URL: https://gcc.gnu.org/viewcvs?rev=223002&root=gcc&view=rev
Log:
Fix PR66105

2015-05-11  Markus Trippelsdorf  

PR bootstrap/66105
* config/rs6000/option-defaults.h: Add space between string literal
and macro name.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/option-defaults.h

[Bug bootstrap/66105] [6 regression] genpreds.c compile error in stage2 on powerpc64-linux

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
fixed.

[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Yep, I suppose we want to match both (TREE_TYPE/TYPE_ARG_TYPES and the decls
since both control how calls.c produce code and should agree in equivalent
functions anyway. I will look into why TREE_TYPE (fntype) and TREE_TYPE
(result_decl) disagreees.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[vp at gcc dot gnu.org]

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

Vidya Praveen  changed:

   What|Removed |Added

 CC||vp at gcc dot gnu.org

--- Comment #6 from Vidya Praveen  ---
glibc build fails as well (i observed for arm and aarch64).

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #55 from James Greenhalgh  ---
(In reply to torvald from comment #49)
> > bar = 0, foo = 0;
> > 
> > thread_a {
> >   __sync_lock_test_and_set (foo, 1)
> >   bar = 1
> > }
> > 
> > thread_b {
> >   /* If we can see the write to bar, the write
> >  to foo must also have happened.  */
> >   if (bar) /* Reads 1.  */
> >assert (foo) /* Should never read 0.  */
> > }
> 
> This is the case of allowing non-DRF normal accesses.  The *other* case I
> was thinking about is how the test would have to look like when *not*
> allowing them.  One way to do it would be:
> 
> thread_a {
>   __sync_lock_test_and_set (foo, 1)
>   __sync_lock_test_and_set (bar, 1) // or __sync_lock_release, or __sync RMW
> }
> 
> thread_b {
>   if (__sync_fetch_and_add (bar, 0))
> assert (foo)  // DRF if thread_a's write is the final one
> }
> 
> In this case, would the current ARM implementation still produce
> insufficient code?  If not, at least in this test case, we could argue that
> there's nothing wrong with what ARM does.  (The question whether we wan't to
> require DRF strictly for __sync usage is of course still open.)

In this case, the current implementation would be fine. Thread A looks like
this:

thread_a:
adrpx0, foo
mov w1, 1
ldr x0, [x0, #:lo12:foo]
.L2:
ldaxr   w2, [x0] /* Load acquire foo.  */
stxrw3, w1, [x0] /* Store release foo.  */
cbnzw3, .L2 /* Branch if not exclusive access.  */
adrpx0, bar
ldr x0, [x0, #:lo12:bar]
.L3:
ldaxr   w2, [x0] /* Load acquire bar.  */
stxrw3, w1, [x0] /* Store release bar.  */
cbnzw3, .L3
ret

And the architecture gives a specific requirement on the ordering of
store-release and load-acquire:

A Store-Release followed by a Load-Acquire is observed in program order by any
observers that are in both:
  — The shareability domain of the address accessed by the Store-Release.
  — The shareability domain of the address accessed by the Load-Acquire.

So yes, I think in this case we could argue that there is nothing wrong with
what ARM does, however I would expect the non-DRF code to be much more common
in the wild, so I think we still need to deal with this issue. (it is a shame
that the DRF code you provided will suffer from an extra barrier if
Matthew/Andrew's work is applied, but I think this is a corner case which we
probably don't want to put too much thought in to working around).

[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jan Hubicka from comment #5)
> Yep, I suppose we want to match both (TREE_TYPE/TYPE_ARG_TYPES and the decls
> since both control how calls.c produce code and should agree in equivalent
> functions anyway. I will look into why TREE_TYPE (fntype) and TREE_TYPE
> (result_decl) disagreees.

OK, I'm going to write a patch that will match both.

Martin

[Bug bootstrap/66038] SIGSEGV at stage 2 - build/genmatch fails in operand::gen_transform

[dougmencken at gmail dot com]

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

--- Comment #5 from Douglas Mencken  ---
(In reply to rguent...@suse.de from comment #4)
> Can you build stage2 with debuginfo?  (--without-build-config at 
> configure)
> 
> That should imrpove the backtrace.
> 
> Thanks,
> Richard.

Sure I can. Here you go:

(gdb) bt
#0  0xe208 in operand::gen_transform () at
../../gcc-5.1.0/gcc/hash-table.h:223
#1  0x8530 in get_operator (id=0x808bec "tcc_comparison") at
../../gcc-5.1.0/gcc/genmatch.c:1495
#2  0x9ef8 in parser::parse_operator_list (this=0xb698) at
../../gcc-5.1.0/gcc/genmatch.c:2941
#3  0xd190 in parser::parse_pattern (this=0xb698) at
../../gcc-5.1.0/gcc/hash-table.h:223
#4  0xe19c in parser::parser (this=0xb698, r_=0xb4f8) at
../../gcc-5.1.0/gcc/hash-table.h:223
#5  0x0005f3ac in main (argc=3146720, argv=0xb4f8) at
../../gcc-5.1.0/gcc/genmatch.c:3711
Current language:  auto; currently c++

[Bug debug/66068] [6 Regression] error: type variant has different TYPE_VFIELD

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |debug
   Target Milestone|--- |6.0
Summary|error: type variant has |[6 Regression] error: type
   |different TYPE_VFIELD   |variant has different
   ||TYPE_VFIELD

--- Comment #1 from Marek Polacek  ---
Reduced:

struct S a;
const struct S b;
struct S
{
};

[Bug debug/66068] [6 Regression] error: type variant has different TYPE_VFIELD

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug debug/66068] [6 Regression] error: type variant has different TYPE_VFIELD

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Another testcase:

union U a;
const union U b;
union U
{
};

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #56 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #55)
> (In reply to torvald from comment #49)
>
> > This is the case of allowing non-DRF normal accesses.  The *other* case I
> > was thinking about is how the test would have to look like when *not*
> > allowing them.  One way to do it would be:
> > 
> > thread_a {
> >   __sync_lock_test_and_set (foo, 1)
> >   __sync_lock_test_and_set (bar, 1) // or __sync_lock_release, or __sync RMW
> > }
>
> [..] (it is
> a shame that the DRF code you provided will suffer from an extra barrier if
> Matthew/Andrew's work is applied, but I think this is a corner case which we
> probably don't want to put too much thought in to working around).

I'm not familiar with the code but I would have thought that it would be 
straightforward to optimize away the first dmb. It seems like it would be a
simple peephole to spot a sequence of two atomic operations, both with __sync
barriers, and replace the first with the equivalent __atomic barrier.

[Bug target/65753] [i386] Incorrect tail call inhibition logic on i386 (32-bit)

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Author: amonakov
Date: Mon May 11 16:10:24 2015
New Revision: 223005

URL: https://gcc.gnu.org/viewcvs?rev=223005&root=gcc&view=rev
Log:
PR target/65753
* config/i386/i386.c (ix86_function_ok_for_sibcall): Allow PIC sibcalls
via function pointers.

testsuite:
* gcc.target/i386/pr65753.c: New test.



Added:
trunk/gcc/testsuite/gcc.target/i386/pr65753.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/66106] New: ICE on incomplete interface operator block (gfc_op2string)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 66106
   Summary: ICE on incomplete interface operator block
(gfc_op2string)
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code snippet with an incomplete interface operator block ...
   program p
  interface operator ( .gt. )
  end interface operator
   end

or this variation (wrong) ...
   program p
  interface operator ( .gt. )
  end interface gt
   end

or this variation (wrong) ...
   program p
  interface operator ( > )
  end interface gt
   end

prints (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: gfc_op2string(): Bad code

---

Whereas for example ...
   subroutine p
  interface assignment ( = )
  end interface assignment
   end

$ gfortran -c snippet.f90
Error: Expected 'END INTERFACE ASSIGNMENT (=)' at (1)

Kind regards.

[Bug fortran/66107] New: ICE on missing parameter value for initialisation (segfault)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 66107
   Summary: ICE on missing parameter value for initialisation
(segfault)
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code snippet with a missing parameter value for n ...
   program p
  character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
   end

prints (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: Segmentation fault

---

A modification of the example above ...
   program p
  integer :: n = 1   ! not a parameter
  call s
   contains
  subroutine s
 character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
  end subroutine
   end

or this variation ...
   program p
  call s(1)
   contains
  subroutine s(n)
 character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
  end subroutine
   end

prints, too
f951: internal compiler error: Segmentation fault

---

For example, this would be sufficient ...
   program p
  integer, parameter :: n = 1
  character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
   end

Kind regards.

[Bug c++/66108] New: cv-qualification deducation failure on conversion operator

[barry.revzin at gmail dot com]

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

Bug ID: 66108
   Summary: cv-qualification deducation failure on conversion
operator
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this code (taken from SO question)

#include 

struct A {
template  operator T***()
{
static_assert(std::is_same::value, "oops");
}
};

int main(){
A a;
const int * const * const * p1 = a;
}

This is exactly the example taken from the standard in [temp.deduct.conv]/7,
yet on gcc 5.1, the static assertion fails because T is deduced as const int
rather than int.

[Bug c++/66108] cv-qualification deducation failure on conversion operator

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
Forgot to add link:
http://stackoverflow.com/questions/30172533/template-argument-type-deduction-by-conversion-operator

[Bug c++/66109] New: defining constexpr objects without initializer

[vgheorgh at gmail dot com]

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

Bug ID: 66109
   Summary: defining constexpr objects without initializer
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vgheorgh at gmail dot com
  Target Milestone: ---

The following code 

struct Foo
{
constexpr Foo() = default;
};

int main()
{
constexpr Foo foo;  
}


should not compile. Unfortunately it compiles with all g++ versions (that
support c++11) up to and including 5.1 

>From [decl.constexpr]:

A constexpr specifier used in an object declaration declares the object as
const. Such an object shall have literal type and shall be initialized.

Therefore the correct way of usage should be

constexpr Foo foo{};

[Bug c++/66109] defining constexpr objects without initializer

[vgheorgh at gmail dot com]

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

--- Comment #1 from Vlad Gheorghiu  ---
Actually the `constexpr` ctor is not even necessary here to reproduce the bug.

[Bug target/65753] [i386] Incorrect tail call inhibition logic on i386 (32-bit)

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #6 from Alexander Monakov  ---
Fixed.

[Bug c++/65382] pointer-to-noexcept-function typealias allowed via using

[vgheorgh at gmail dot com]

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

--- Comment #2 from Vlad Gheorghiu  ---
More details: http://stackoverflow.com/q/30172483/3093378

[Bug c++/65382] pointer-to-noexcept-function typealias allowed via using

[vgheorgh at gmail dot com]

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

--- Comment #3 from Vlad Gheorghiu  ---
Please ignore the previous comment, posted by mistake for another bug I
reported

[Bug c++/66109] defining constexpr objects without initializer

[vgheorgh at gmail dot com]

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

--- Comment #2 from Vlad Gheorghiu  ---
More details at http://stackoverflow.com/q/30172483/3093378

[Bug tree-optimization/66110] New: uint8_t memory access not optimized

[kevin at koconnor dot net]

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

Bug ID: 66110
   Summary: uint8_t memory access not optimized
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin at koconnor dot net
  Target Milestone: ---

It appears that gcc does not do a good job of optimizing memory accesses to
'uint8_t' variables.  In particular, it appears as if "strict aliasing" is not
done on uint8_t variables, and it appears it is not done even if the uint8_t is
in a struct.

 GCC version:

$ ~/src/install-5.1.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/kevin/src/install-5.1.0/bin/gcc
COLLECT_LTO_WRAPPER=/home/kevin/src/install-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/home/kevin/src/install-5.1.0
--enable-languages=c
Thread model: posix
gcc version 5.1.0 (GCC) 

=== Compile command line:

~/src/install-5.1.0/bin/gcc -v -save-temps -O2 -Wall u8alias.c -c

=== Contents of u8alias.c:

typedef __UINT8_TYPE__ uint8_t;
typedef __UINT16_TYPE__ uint16_t;

struct s1 {
uint16_t f1;
uint8_t f2;
};

struct s2 {
struct s1 *p1;
};

void f1(struct s2 *p)
{
p->p1->f2 = 9;
p->p1->f2 = 10;
}

=== Contents of u8alias.i:

# 1 "u8alias.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "u8alias.c"
typedef unsigned char uint8_t;
typedef short unsigned int uint16_t;

struct s1 {
uint16_t f1;
uint8_t f2;
};

struct s2 {
struct s1 *p1;
};

void f1(struct s2 *p)
{
p->p1->f2 = 9;
p->p1->f2 = 10;
}

=== Results of compilation:

$ objdump -ldr u8alias.o

 :
f1():
   0:   48 8b 07mov(%rdi),%rax
   3:   c6 40 02 09 movb   $0x9,0x2(%rax)
   7:   48 8b 07mov(%rdi),%rax
   a:   c6 40 02 0a movb   $0xa,0x2(%rax)
   e:   c3  retq   

=== Expected results:

I expected the second redundant load to be eliminated - for example, clang
produces this assembler (after replacing the gcc specific uint8_t typedefs with
an include of ):

$ clang -Wall -O2 u8alias.c -c
$ objdump -ldr u8alias.o

 :
f1():
   0:   48 8b 07mov(%rdi),%rax
   3:   c6 40 02 0a movb   $0xa,0x2(%rax)
   7:   c3  retq   

=== Other notes:

If the code is changed so that there are two redundant writes to ->f1 then gcc
does properly optimize away the first store.  Also, if the above definition of
f2 is changed to an 8-bit bitfield (ie, "uint8_t f2 : 8;") then gcc does
properly optimize away the first store.

This occurs on other platforms besides x86_64.  (In particular, it happens on
avr-gcc where 8-bit integers are very common.)  I reproduced the above on gcc
5.1.0, but I've also seen it on variants of gcc 4.8 and gcc 4.9.

My guess is that the above is the result of an interpretation of the C99
specification - in particular section 6.5:

  An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:
[...]
  -- a character type.

However, I do not think that should apply to the above test case for either of
the two following reasons:

1 - the memory access was not to a character type, it was to an integer type
that happened to be 1 byte in size (ie, a uint8_t type)
2 - the memory access was not to a character type, it was to a member of
'struct s1'.

As noted above, clang (eg, 3.4.2) does perform the expected optimization.

[Bug tree-optimization/66110] uint8_t memory access not optimized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Uint8_t is a typedef by the c standard. And we typedef it to unsigned char
which means this is a character type.

[Bug fortran/66106] ICE on incomplete interface operator block (gfc_op2string)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.

F2003 standard states



C1202 (R1201) The generic-spec shall be included in the end-interface-stmt
  only if it is provided in the interface-stmt.
  ...
  If the end-interface-stmt includes OPERATOR(defined-operator ), the
  interface-stmt shall specify the same defined-operator.

This patch

Index: interface.c
===
--- interface.c (revision 222916)
+++ interface.c (working copy)
@@ -346,8 +346,12 @@ gfc_match_end_interface (void)
break;

  m = MATCH_ERROR;
- gfc_error ("Expecting % at %C, "
-"but got %s", s1, s2);
+ if (strcmp(s2, "none") == 0)
+   gfc_error ("Expecting % "
+  "at %C, ", s1);
+ else  
+   gfc_error ("Expecting % at %C, "
+  "but got %s", s1, s2);
}

}
Index: match.c
===
--- match.c (revision 222916)
+++ match.c (working copy)
@@ -110,6 +110,9 @@ gfc_op2string (gfc_intrinsic_op op)
 case INTRINSIC_PARENTHESES:
   return "parens";

+case INTRINSIC_NONE:
+  return "none";
+
 default:
   break;
 }

yields

% gfc6 -c jk.f90
jk.f90:3:28:

   end interface operator
1
Error: Expecting 'END INTERFACE OPERATOR (.gt.)' at (1), 
jk.f90:4:6:

end
  1
Error: END INTERFACE statement expected at (1)
f951: Error: Unexpected end of file in 'jk.f90'

[Bug tree-optimization/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

Kevin OConnor  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Kevin OConnor  ---
I understand that it is not incorrect to produce two redundant stores with the
sample code.  However, I do believe it would be correct to produce a single
store.

As such, I think this is an opportunity to improve gcc's optimization.  That
is, I think gcc could validly interpret the C spec so that two redundant
uint8_t stores could be replaced with one.

If this is not the best place to discuss that, what would be the best forum?

[Bug c++/66109] defining constexpr objects without initializer

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
Dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284

[Bug fortran/66111] New: [6 regression] ICE with matmul and vector subscripts

[mikael at gcc dot gnu.org]

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

Bug ID: 66111
   Summary: [6 regression] ICE with matmul and vector subscripts
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

implicit none
  integer, parameter :: n = 4
  integer, dimension(n, n) :: a, b, c
  integer, dimension(n*n)  :: p, res
  integer, dimension(n):: v

  integer :: i

  p = [ +59, -53, +47, -43, &
-37, +31, -29, +23, &
+19, -17, +13, -11, &
- 7, + 5, - 3, + 2  ]
  a = reshape(p, shape(a))
  b = reshape([(i, i=1, size(a))], shape(b))
  v = [ 3, 1, 2, 4]
  c = matmul(a, b)
  res = [ + 14, - 22, + 16, - 22, &
  +150, -158, +128, -138, &
  +286, -294, +240, -254, &
  +422, -430, +352, -370  ]
  !print *,c
  if (any(c /= reshape(res, shape(c call abort
  c(:,v) = matmul(a, b)
  if (any(c(:,v) /= reshape(res, shape(c call abort
  c(v,:) = matmul(a, b)
  if (any(c(v,:) /= reshape(res, shape(c call abort

end

[Bug fortran/66111] [6 regression] ICE with matmul and vector subscripts

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
CC'ing Thomas

[Bug fortran/66111] [6 regression] ICE with matmul and vector subscripts

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Some people write strange code :-)

[Bug fortran/66113] New: Variable n cannot appear in the expression with nested blocks

[tkoenig at gcc dot gnu.org]

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

Bug ID: 66113
   Summary: Variable n cannot appear in the expression with nested
blocks
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

ig25@linux-fd1f:~/Krempel/Block> cat block.f90
program main
  integer :: n
  n = 3
  block
block
  block
real, dimension(n) :: a
  end block
end block
  end block
end program main

ig25@linux-fd1f:~/Krempel/Block> gfortran block.f90
block.f90:7:24:

 real, dimension(n) :: a
1
Error: Variable »n« cannot appear in the expression at (1)

This is bogus.

Any solution should include the case of an arbitrary number
of nested blocks.

[Bug other/66112] New: __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

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

Bug ID: 66112
   Summary: __builtin_mul_overflow for int16_t emits poor code
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

I am using all the three signed integer overflow builtin's for the four 
types: int8_t, int16_t, int32_t and int64_t on Intel x64.  In all cases except
one this produces optimal code, the operation followed by "jo".  See the test
case below.
For the int32_t type, from  the last atoi down:

callatoi#
imull   %eax, %ebx  # b, tmp100
jo  .L3 #,

However, for int16_t this produces much larger code that does a 32 bit multiply
and checks for overflow by hand:

callatoi#
movswl  %bx, %esi   # D.5222, D.5222
cwtl
imull   %esi, %eax  # D.5222, tmp109
movl%eax, %edx  # tmp109, tmp110
movl%eax, %ecx  # tmp109, tmp111
sarl$16, %edx   #, tmp110
sarw$15, %cx#, tmp111
cmpw%dx, %cx# tmp110, tmp111
jne .L7 #,

Even though a simple "imulw" followed by "jo" would work.

---
#include 
#include 
int
main( int argc, const char *argv[] )
{
  int16_t result, a = (int16_t)atoi(argv[1]), b = (int16_t)atoi( argv[2] );
  if( __builtin_mul_overflow( a, b, &result ) )
printf( "Overflow\n");
 else
printf( "Product is %d\n", result );
}

[Bug c/65471] type interpretation in _Generic

[jens.gustedt at inria dot fr]

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

--- Comment #2 from Jens Gustedt  ---
For referece, I have now a paper at the ISO committee:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1930.htm

we will look at it in the automn session to decide what to do with it.

[Bug fortran/66113] Variable n cannot appear in the expression with nested blocks

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Is not the code invalid?

[Bug fortran/66113] Variable n cannot appear in the expression with nested blocks

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #1)
> Is not the code invalid?

I don't think it is invalid.

This works as expected:

program main
  integer :: n
  n = 3
block
  block
real, dimension(n) :: a
  end block
end block
end program main

[Bug fortran/66113] Variable n cannot appear in the expression with nested blocks

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
Some people write strange code. ;-)
This is related to the inline matmul patch isn't it?

[Bug fortran/66100] [6 Regression] ICE in simplify_bound

[mikael at gcc dot gnu.org]

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

--- Comment #2 from Mikael Morin  ---
Author: mikael
Date: Mon May 11 21:03:50 2015
New Revision: 223019

URL: https://gcc.gnu.org/viewcvs?rev=223019&root=gcc&view=rev
Log:
Fix fortran/66100 bound simplification ICE

PR fortran/66100
gcc/fortran/
* simplify.c (simplify_bound): Fix assert to accept subobject * arrays.
gcc/testsuite/
* gfortran.dg/bound_simplification_6.f90: New.


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

[Bug target/66114] New: some indirect_jump patterns use operands[] in their condition when they shouldn't

[tbsaunde at gcc dot gnu.org]

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

Bug ID: 66114
   Summary: some indirect_jump patterns use operands[] in their
condition when they shouldn't
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tbsaunde at gcc dot gnu.org
  Target Milestone: ---
Target: fr30-* pa-*

md.texi says that the condition in a named define_insn should not look at insn 
data.  however the indirect_jump patterns for the pa and fr30 ports look at
operands[]

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||dehao at gcc dot gnu.org,
   ||dehao at google dot com

--- Comment #4 from Sebastian Pop  ---
This patch seems to fix the problem:

diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
index ba2d5ab..6bd296a 100644
--- a/gcc/auto-profile.c
+++ b/gcc/auto-profile.c
@@ -1547,6 +1547,9 @@ afdo_annotate_cfg (const stmt_set &promoted_stmts)
 static void
 early_inline ()
 {
+  /* compute_inline_parameters needs an up to date SSA form.  */
+  update_ssa (TODO_update_ssa);
+
   compute_inline_parameters (cgraph_node::get (current_function_decl), true);
   unsigned todo = early_inliner (cfun);
   if (todo & TODO_update_ssa_any)


We have not verified yet which other pass is causing the SSA to be in an
inconsistent state: instead of adding a call to update_ssa() at this place, we
should have a verify_ssa(), and fix the other pass.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #8)
> You can revert the above changes to see what happens.  Looks safe
> changes to me, but some changes could reveal hidden problems.
> If the issue remains even if all those changes are reverted,
> there will be no easy way to narrow down.

Ah, I was actually just about to compile a list with the changes that went into
gcc-4.9 after -10 which was still working, so thanks for that.

I haven't worked with the gcc code base before, so any suggestions on how to
work through the code?

I would just checkout the code from git://gcc.gnu.org/git/gcc.git now and
revert change after change to see if that fixes it.

Adrian

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #9)
> I haven't worked with the gcc code base before, so any suggestions on how to
> work through the code?

Ah, I just realized Matthias put all these changes into handy patches which I
can just remove one by handy. That's easy :).

Will take some time but report back.

Adrian

[Bug target/66115] New: When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

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

Bug ID: 66115
   Summary: When using -O0 with -mavx the compiler uses aligned
loads for possibly unaligned function parameters
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carloscastro10 at hotmail dot com
  Target Milestone: ---

When compiling with -mavx, operands to SSE instructions are allowed to be
aligned. Consider the code below:

#include 

using namespace std;

int main()
{
  int *a = new int[5];
  __m128i sse0 = _mm_setzero_si128();
  sse0 = _mm_avg_epu8(sse0,*(__m128i*)(a+1)); // Unaligned parameter
  _mm_storeu_si128((__m128i*)(a),sse0);
  delete [] a;
}

When implemented using the compiler options "-O3 -mavx", the compiler outputs
the following (correct) code:

main:
subq$8, %rsp
movl$20, %edi
calloperator new[](unsigned long)
vpxor   %xmm0, %xmm0, %xmm0
movq%rax, %rdi
vpavgb  4(%rax), %xmm0, %xmm0
vmovdqu %xmm0, (%rax)
calloperator delete[](void*)
xorl%eax, %eax
addq$8, %rsp
ret

However, when implemented using "-O0 -mavx", the compiler incorrectly makes use
of aligned load operations (vmovdqa). This results in a segfault:

main:
pushq   %rbp
movq%rsp, %rbp
subq$80, %rsp
movl$20, %edi
calloperator new[](unsigned long)
movq%rax, -16(%rbp)
vpxor   %xmm0, %xmm0, %xmm0
vmovdqa %xmm0, -80(%rbp)
movq-16(%rbp), %rax
addq$4, %rax
vmovdqa (%rax), %xmm0
vmovdqa -80(%rbp), %xmm1
vmovdqa %xmm1, -64(%rbp)
vmovdqa %xmm0, -48(%rbp)
vmovdqa -48(%rbp), %xmm0
vmovdqa -64(%rbp), %xmm1
vpavgb  %xmm0, %xmm1, %xmm0
vmovdqa %xmm0, -80(%rbp)
movq-16(%rbp), %rax
movq%rax, -8(%rbp)
vmovdqa -80(%rbp), %xmm0
vmovdqa %xmm0, -32(%rbp)
vmovdqa -32(%rbp), %xmm0
movq-8(%rbp), %rax
vmovdqu %xmm0, (%rax)
cmpq$0, -16(%rbp)
je  .L2
movq-16(%rbp), %rax
movq%rax, %rdi
calloperator delete[](void*)
.L2:
movl$0, %eax
leave
ret

This problem is present in all versions of gcc all the way to 5.1

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

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

--- Comment #1 from carloscastro10 at hotmail dot com ---
Created attachment 35519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35519&action=edit
test.ii for the example

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I think this is invalid as __m128i as an alignment requirement of 16byte but
a+1 is not aligned to 16byte boundary.  It just happens to work for -O2.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

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

--- Comment #3 from carloscastro10 at hotmail dot com ---
The AVX specification relaxed the memory alignment requirements for SSE
operations when using the VEX prefix. In this case the use of a non-aligned
memory address for an operand is valid.

For reference, please read

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-1-manual.pdf

Section 14.9: Memory alignment, on page 14-33 (~347)

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to carloscastro10 from comment #3)
> The AVX specification relaxed the memory alignment requirements for SSE
> operations when using the VEX prefix. In this case the use of a non-aligned
> memory address for an operand is valid.

instruction != C type.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

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

--- Comment #5 from carloscastro10 at hotmail dot com ---
That is correct. And there is no requirement that a pointer to __m128i be
aligned to a 16-byte boundary.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to carloscastro10 from comment #5)
> That is correct. And there is no requirement that a pointer to __m128i be
> aligned to a 16-byte boundary.

Why do you think that?  That is a requirement and why your code is failing.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

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

--- Comment #7 from carloscastro10 at hotmail dot com ---
It cannot be a requirement. If it was, functions like __m128i _mm_loadu_si128
(__m128i const* mem_addr), which have always relied on mem_addr not being
necessarily aligned, would not work. What has changed is that, before AVX, SSE
arithmetic functions that took a pointer to __m128i as a parameter did require
that pointer to be aligned to a 16-byte boundary. After AVX, SSE arithmetic
functions encoded with a VEX prefix (for example vpavgb as opposed to pavgb) do
not require its operands to be aligned. 

In other words, if I compile this line:

sse0 = _mm_avg_epu8(sse0,*(__m128i*)(a));

with -msse4.1, then "a" needs to be aligned on a 16-byte boundary

If I compile it with -mavx, then "a" does not need to be aligned anymore. 

The problem only occurs with -O0, because it saves the operands to registers
before running the actual instruction. 

-O3 generates this instruction: 
vpavgb  4(%rax), %xmm0, %xmm0

That is a VEX-encoded instruction, so 4(%rax) does not need to be aligned. That
code runs fine and never crashes (it is a very simplified version of code I
have reliably running on a large codebase). 

-O0 generates these instructions:
addq$4, %rax
vmovdqa (%rax), %xmm0
...
vpavgb  %xmm0, %xmm1, %xmm0

In this case, vmovdqa ALWAYS requires the memory location given as parameter to
be aligned to a 16-byte boundary. The use of vmovdqa might be based on an
incorrect assumption, dating back to the days before AVX, that the memory
location passed to the _mm_avg_epu8 is aligned. When -mavx is selected the
compiler cannot make that assumption and should use vmovdqu instead.

[Bug c/36750] -Wmissing-field-initializers relaxation request

[nightstrike at gmail dot com]

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

--- Comment #12 from nightstrike  ---
(In reply to Daniel Sommermann from comment #11)
> Created attachment 33627 [details]
> Test case showing overly strict warning
> 
> This still produces false positives in C++11.
> 
> I attached a test case with several false positives. The compilation should
> be clean as there are no uninitialized members. Repros with g++ 4.9.1
> 
> Compile with "g++ test.cpp -std=c++11 -Wmissing-field-initializers`"
> 
> Produces:
> 
> dcsommer@dcsommer-ThinkPad-T440s:~/src/proxygen-oss-test/proxygen$ g++
> test.cpp -Wmissing-field-initializers -std=c++11
> test.cpp: In function ‘int main()’:
> test.cpp:7:10: warning: missing initializer for member ‘Foo::bar’
> [-Wmissing-field-initializers]
>Foo f1{};
>   ^
> test.cpp:7:10: warning: missing initializer for member ‘Foo::baz’
> [-Wmissing-field-initializers]
> test.cpp:8:11: warning: missing initializer for member ‘Foo::baz’
> [-Wmissing-field-initializers]
>Foo f2{0};
>^
> test.cpp:9:14: warning: missing initializer for member ‘Foo::baz’
> [-Wmissing-field-initializers]
>Foo f3 = {0};
>   ^
> test.cpp:10:15: warning: missing initializer for member ‘Foo::baz’
> [-Wmissing-field-initializers]
>Foo f4 = {0,};
>^


This reproduces with 4.9.2 as well.  Request reopen.

[Bug c++/66116] New: no DW_TAG_template_type_parameter for template instantiation

[chihin.ko at oracle dot com]

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

Bug ID: 66116
   Summary: no DW_TAG_template_type_parameter for template
instantiation
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chihin.ko at oracle dot com
  Target Milestone: ---

Created attachment 35520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35520&action=edit
test case

For attached std_list_iterators.cc, there is no DW_TAG_template_type_parameter
for DW_TAG_class_type  "allocator" :

< 2><0x3bd7>  DW_TAG_class_type
DW_AT_name  "allocator"
DW_AT_byte_size 0x0001
DW_AT_decl_file 0x0006 allocator.h
DW_AT_decl_line 0x005c
DW_AT_sibling   <0x3cbc>
< 3><0x3be3>DW_TAG_inheritance
  DW_AT_type  <0x80f8>
  DW_AT_data_member_location  DW_OP_plus_uconst 0
  DW_AT_accessibility DW_ACCESS_public
< 3><0x3bec>DW_TAG_typedef
  DW_AT_name  "reference"
  DW_AT_decl_file 0x0006 allocator.h
  DW_AT_decl_line 0x0063
  DW_AT_type  <0x8ee9>
...
...

[Bug tree-optimization/66117] New: GCC can not compile when graphite is enabled, due to missing isl headers.

[pbeeler80 at gmail dot com]

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

Bug ID: 66117
   Summary: GCC can not compile when graphite is enabled, due to
missing isl headers.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pbeeler80 at gmail dot com
  Target Milestone: ---

The full log is attached
The errors in short:
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:398:43: error: ‘isl_constraint’
has not been declared
 extern void print_isl_constraint (FILE *, isl_constraint *);
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:402:35: error: variable or
field ‘debug_isl_constraint’ declared void
 extern void debug_isl_constraint (isl_constraint *);
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:402:35: error: ‘isl_constraint’
was not declared in this scope
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:402:51: error: expected
primary-expression before ‘)’ token
 extern void debug_isl_constraint (isl_constraint *);
   ^
Makefile:1065: recipe for target 'graphite.o' failed
make[3]: *** [graphite.o] Error 1
x86_64-linux-gnu-g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../.././../gcc/gcc-SaberMod/gcc
-I../.././../gcc/gcc-SaberMod/gcc/.
-I../.././../gcc/gcc-SaberMod/gcc/../include
-I../.././../gcc/gcc-SaberMod/gcc/../libcpp/include
-I/tmp/sm-tc/build/temp-install/include -I/tmp/sm-tc/build/temp-install/include
-I/tmp/sm-tc/build/temp-install/include 
-I../.././../gcc/gcc-SaberMod/gcc/../libdecnumber
-I../.././../gcc/gcc-SaberMod/gcc/../libdecnumber/dpd -I../libdecnumber
-I../.././../gcc/gcc-SaberMod/gcc/../libbacktrace
-I/tmp/sm-tc/build/temp-install/include  -o graphite-isl-ast-to-gimple.o -MT
graphite-isl-ast-to-gimple.o -MMD -MP -MF
./.deps/graphite-isl-ast-to-gimple.TPo
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c
In file included from
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c:79:0:
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:398:43: error: ‘isl_constraint’
has not been declared
 extern void print_isl_constraint (FILE *, isl_constraint *);
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:402:35: error: variable or
field ‘debug_isl_constraint’ declared void
 extern void debug_isl_constraint (isl_constraint *);
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:402:35: error: ‘isl_constraint’
was not declared in this scope
../.././../gcc/gcc-SaberMod/gcc/graphite-poly.h:402:51: error: expected
primary-expression before ‘)’ token
 extern void debug_isl_constraint (isl_constraint *);
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c: In function
‘isl_union_set* generate_luj_sepclass(scop_p)’:
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c:882:70: error:
‘isl_union_set_empty’ was not declared in this scope
   domain_isl = isl_union_set_empty (isl_set_get_space (scop->context));
  ^
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c:900:70: error:
‘isl_union_set_from_set’ was not declared in this scope
  isl_union_set_union (domain_isl, isl_union_set_from_set (bb_domain_s));
  ^
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c:900:71: error:
‘isl_union_set_union’ was not declared in this scope
  isl_union_set_union (domain_isl, isl_union_set_from_set (bb_domain_s));
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c: In function
‘isl_ast_build* set_options(isl_ast_build*, isl_union_map*, isl_union_map*)’:
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c:990:59: error:
‘isl_union_set_from_set’ was not declared in this scope
 isl_union_set_from_set (isl_set_universe (range_space));  
   ^
../.././../gcc/gcc-SaberMod/gcc/graphite-isl-ast-to-gimple.c:992:42: error:
‘isl_union_set_universe’ was not declared in this scope
   domain = isl_union_set_universe (domain);
  ^
Makefile:1065: recipe for target 'graphite-isl-ast-to-gimple.o' failed
make[3]: *** [graphite-isl-ast-to-gimple.o] Error 1
x86_64-linux-gnu-g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fn

[Bug tree-optimization/66117] GCC can not compile when graphite is enabled, due to missing isl headers.

[pbeeler80 at gmail dot com]

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

--- Comment #1 from Paul Beeler  ---
Here is the gcc source:
https://github.com/SaberMod/GCC_SaberMod/tree/6.0.0
Also this patch seems to fix the issue:
https://github.com/SaberMod/GCC_SaberMod/commit/635b86c35d539bf229e4d4652fc67afe632589a4

[Bug c++/66118] New: Compiler segmentation fault when compiling std::function on aix6

[gabriel.sztejnworcel at yahoo dot com]

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

Bug ID: 66118
   Summary: Compiler segmentation fault when compiling
std::function on aix6
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel.sztejnworcel at yahoo dot com
  Target Milestone: ---

Created attachment 35521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35521&action=edit
Source + generated temp files

Getting the following error when compiling the attached source file (test.cpp
in the zip) on aix6 (the same file compiles with no problems on aix7):

g++: internal compiler error: Segmentation fault (program as)
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The command i used:
g++ test.cpp -std=c++11 -save-temps

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #8 from Jakub Jelinek  ---
It is the requirement.  _mm*_loadu* are a special case, but the C __m128i type
itself requires 16-byte alignment.  Just print __alignof__ (__m128i)...
Just use _mm*_loadu* if the load is from unaligned pointer, and recent versions
should when optimizing be able to optimize that case into a memory load in AVX
instruction.

[Bug tree-optimization/66117] GCC can not compile when graphite is enabled, due to missing isl headers.

[pbeeler80 at gmail dot com]

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

--- Comment #2 from Paul Beeler  ---
A second shot at a patch:
Included HAVE_isl in gcc/graphite-poly.h
Other files that include "graphite-poly.h" will have isl_constraint functions
defined.
https://github.com/SaberMod/GCC_SaberMod/commit/3494aee764bb64948d6cd2f2c430cfc8e69ba078

[Bug tree-optimization/66117] GCC can not compile when graphite is enabled, due to missing isl headers.

[pbeeler80 at gmail dot com]

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

--- Comment #3 from Paul Beeler  ---
Final patch will work to be the most minimal for changes and HAVE_isl
https://github.com/SaberMod/GCC_SaberMod/commit/114e4e9470260a839d55aad2421fb646af12697b

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu.org]

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

--- Comment #30 from Thomas Koenig  ---
Author: tkoenig
Date: Tue May 12 06:37:43 2015
New Revision: 223031

URL: https://gcc.gnu.org/viewcvs?rev=223031&root=gcc&view=rev
Log:
2015-05-12  Thomas Koenig  

PR fortran/66041
PR fortran/37131
* gfortran.h (gfc_array_spec):  Add field resolved.
* array.c (gfc_resolve_array_spec):  Resolve array spec
only once.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/gfortran.h

[Bug fortran/66041] [6 Regression] Matmul ICE

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Tue May 12 06:37:43 2015
New Revision: 223031

URL: https://gcc.gnu.org/viewcvs?rev=223031&root=gcc&view=rev
Log:
2015-05-12  Thomas Koenig  

PR fortran/66041
PR fortran/37131
* gfortran.h (gfc_array_spec):  Add field resolved.
* array.c (gfc_resolve_array_spec):  Resolve array spec
only once.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/gfortran.h

[Bug fortran/66113] Variable n cannot appear in the expression with nested blocks

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
The reason is that I want to make creation of temporary
variables for arrays more sane.

Currently, temporary arrays are handled using an allocatable array
variable. This obviously does not work if -fno-realloc-lhs is
specified, and introduces unneeded complexity in the generated
code, which is hard for the middle-end optimizers to remove.

What I want to do is, if I want to create a temporary variable for
an array, is to change

   real, dimension(something,other) :: a

   a(f(x),1:3)

into

   block
 freeze = f(x)
 size_1 = 1;
 size_2 = 3;
   block
  real, dimension(size_1, size_2) :: a_tmp
  a_tmp(:,;) = a(freeze, 1:3)
  ...
   end block
   end block

While this might work in the most simple cases, I don't want
to introduce instability by hitting a bug with too many nesting
levels.