[Bug c++/55434] const array with elements initialized by constructor marked non-const in debug info

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #5 from Paolo Carlini  ---
Fixed in 5.1.0.

[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist

[marejde at gmail dot com]

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

--- Comment #1 from Martin Ejdestig  ---
Sorry, a copy paste error slipped in. Last print out should be:

std::cout << "error_code operator bool: " << (error_code ? true : false) <<
'\n';

Output is still the same though.

[Bug c/71418] New: gcc ICE on x86_64-linux-gnu in min_align_of_type, at stor-layout.c:2402

[helloqirun at gmail dot com]

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

Bug ID: 71418
   Summary: gcc ICE on x86_64-linux-gnu in min_align_of_type, at
stor-layout.c:2402
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following invalid code causes an ICE when compiled with the current gcc
trunk on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It appears to be a 7 regression.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160604 (experimental) [trunk revision 237092] (GCC)


$ gcc-trunk abc.c
abc.c:1:25: error: lvalue required as increment operand
 _Alignas (char)   ID0 [ ++ 7 ] ;
 ^~
abc.c:1:1: warning: data definition has no type or storage class
 _Alignas (char)   ID0 [ ++ 7 ] ;
 ^~~~
abc.c:1:19: warning: type defaults to ‘int’ in declaration of ‘ID0’
[-Wimplicit-int]
 _Alignas (char)   ID0 [ ++ 7 ] ;
   ^~~
abc.c:1:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in min_align_of_type, at stor-layout.c:2402
 _Alignas (char)   ID0 [ ++ 7 ] ;
 ^~~~
0xe60277 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9802
0xbaf9dd tree_class_check
../../gcc-source-trunk/gcc/tree.h:3153
0xbaf9dd min_align_of_type(tree_node*)
../../gcc-source-trunk/gcc/stor-layout.c:2402
0x656259 grokdeclarator
../../gcc-source-trunk/gcc/c/c-decl.c:6319
0x65783a start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc-source-trunk/gcc/c/c-decl.c:4442
0x6bc0c5 c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:1963
0x6c6065 c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1549
0x6c68f9 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1430
0x6c68f9 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:17930
0x728e82 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ cat abc.c
_Alignas (char)   ID0 [ ++ 7 ] ;

[Bug tree-optimization/70390] [6/7 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Not sure if the GRAPHITE assert is necessary or merely a hint that some
> optimization didn't apply - that is, do we actually generate wrong-code
> if it triggers?
> 
> Index: gcc/graphite-isl-ast-to-gimple.c
> ===
> --- gcc/graphite-isl-ast-to-gimple.c(revision 234449)
> +++ gcc/graphite-isl-ast-to-gimple.c(working copy)
> @@ -2112,7 +2112,7 @@ copy_loop_close_phi_args (basic_block ol
>  
>if (is_gimple_reg (res) && scev_analyzable_p (res, region->region))
> /* Loop close phi nodes should not be scev_analyzable_p.  */
> -   gcc_unreachable ();
> +   /*gcc_unreachable ()*/;
>  
>gphi *new_close_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
>tree new_res = create_new_def_for (res, new_close_phi,
> @@ -2497,7 +2497,7 @@ copy_cond_phi_nodes (basic_block bb, bas
> continue;
>if (is_gimple_reg (res) && scev_analyzable_p (res, region->region))
> /* Cond phi nodes should not be scev_analyzable_p.  */
> -   gcc_unreachable ();
> +   /*gcc_unreachable ()*/;
>  
>gphi *new_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
>tree new_res = create_new_def_for (res, new_phi,
> 
> "fixes" the ICE.

Instead of running into the ICE, we run into this if-stmt 13 lines below:
...
  if (!new_name)
return false;
...

And code-generation is aborted:
...
[codegen] Adding loop close phi: e_lsm.14_25 = PHI <_40(43)>
[codegen] setting rename: old_name = g_lsm.18_102, new_name = g_lsm.18_93
codegen error: reverting back to the original code.
...

[Bug tree-optimization/42587] bswap not recognized for memory

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

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

--- Comment #9 from Andreas Schwab  ---
The test fails on powerpc, both -m32 and -m64.

[Bug tree-optimization/71408] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[kugan at gcc dot gnu.org]

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

--- Comment #4 from kugan at gcc dot gnu.org ---
Patch posted for review at
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00330.html

[Bug target/66960] Add interrupt attribute to x86 backend

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Added:
> trunk/gcc/testsuite/gcc.dg/guality/pr68037-1.c
> trunk/gcc/testsuite/gcc.dg/guality/pr68037-2.c
> trunk/gcc/testsuite/gcc.dg/guality/pr68037-3.c

These tests fail on darwin:

Undefined symbols for architecture x86_64:
  "fn", referenced from:
  _main in ccPxehCk.o
 (maybe you meant: _fn)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

The patch

--- /opt/gcc/_clean/gcc/testsuite/gcc.dg/torture/pr68037-3.c2016-06-03
17:11:31.0 +0200
+++ pr68037-3_db.c  2016-06-04 03:56:13.0 +0200
@@ -65,6 +65,6 @@ main ()
push$" STRING (FLAGS) ";\
push$" STRING (CS) ";   \
push$" STRING (IP) ";   \
-   jmp fn");
+   jmp _fn");
   return 0;
 }

allows the test to succeed.

[Bug target/71208] [6 regression] mmix: C++ code fails to link

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  ---
Hmmm. I have problems building gcc-6.1.0 for mmix, by the methods that has
worked in the past and to the best of my knowledge are the official ones.

First, from a separate directory, I build and install binutils-2.25.1 (as you
mentioned this exhibits the same problems as with 2.26 and to avoid mixing up
with fallout from the default-init-array change) in a local prefix.  The CFLAGS
setting is for the anticipated debugging:

$ ~/derp/gcctop/pr71208/binutils-2.25.1/configure --prefix
~/derp/gcctop/pr71208/p --target mmix CFLAGS=-g3
$ make all
$ make install

Then I unpack newlib, rename newlib-2.24 to gcc-6.1.0, unpack gcc-6.1.0 to
override common files, and configure, in a separate directory:
$ ~/derp/gcctop/pr71208/gcc-6.1.0/configure --prefix ~/derp/gcctop/pr71208/p
--target mmix
(noting that the binutils installed is picked up by the build machinery)
$ make all
...
checking for /home/hp/derp/gcctop/pr71208/go/./gcc/xgcc
-B/home/hp/derp/gcctop/pr71208/go/./gcc/
-B/home/hp/derp/gcctop/pr71208/p/mmix/bin/
-B/home/hp/derp/gcctop/pr71208/p/mmix/lib/ -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/include -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/sys-includeoption to produce PIC...
-fPIC -DPIC
checking if /home/hp/derp/gcctop/pr71208/go/./gcc/xgcc
-B/home/hp/derp/gcctop/pr71208/go/./gcc/
-B/home/hp/derp/gcctop/pr71208/p/mmix/bin/
-B/home/hp/derp/gcctop/pr71208/p/mmix/lib/ -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/include -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/sys-includePIC flag -fPIC -DPIC
works... no
checking if /home/hp/derp/gcctop/pr71208/go/./gcc/xgcc
-B/home/hp/derp/gcctop/pr71208/go/./gcc/
-B/home/hp/derp/gcctop/pr71208/p/mmix/bin/
-B/home/hp/derp/gcctop/pr71208/p/mmix/lib/ -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/include -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/sys-includestatic flag -static works...
no
checking if /home/hp/derp/gcctop/pr71208/go/./gcc/xgcc
-B/home/hp/derp/gcctop/pr71208/go/./gcc/
-B/home/hp/derp/gcctop/pr71208/p/mmix/bin/
-B/home/hp/derp/gcctop/pr71208/p/mmix/lib/ -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/include -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/sys-includesupports -c -o file.o... yes
checking if /home/hp/derp/gcctop/pr71208/go/./gcc/xgcc
-B/home/hp/derp/gcctop/pr71208/go/./gcc/
-B/home/hp/derp/gcctop/pr71208/p/mmix/bin/
-B/home/hp/derp/gcctop/pr71208/p/mmix/lib/ -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/include -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/sys-includesupports -c -o file.o...
(cached) yes
checking whether the /home/hp/derp/gcctop/pr71208/go/./gcc/xgcc
-B/home/hp/derp/gcctop/pr71208/go/./gcc/
-B/home/hp/derp/gcctop/pr71208/p/mmix/bin/
-B/home/hp/derp/gcctop/pr71208/p/mmix/lib/ -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/include -isystem
/home/hp/derp/gcctop/pr71208/p/mmix/sys-includelinker
(/home/hp/derp/gcctop/pr71208/go/./gcc/collect-ld) supports shared libraries...
yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
oops.

Thinking maybe --with-newlib is required "these days", I add that:

$ ~/derp/gcctop/pr71208/gcc-6.1.0/configure --prefix ~/derp/gcctop/pr71208/p
--target mmix --with-newlib
$ make all
checking for fenv.h... no
checking for complex.h... (cached) no
checking for complex.h... (cached) no
no
checking for ISO C99 support to TR1 in ... no
checking for fenv.h... (cached) no
no
checking for ISO C99 support to TR1 in ... no
checking for ISO C99 support to TR1 in ... no
no
no
checking stdbool.h usability... no
checking stdbool.h presence... yes
configure: WARNING: stdbool.h: present but cannot be compiled
configure: WARNING: stdbool.h: check for missing prerequisite headers?
configure: WARNING: stdbool.h: see the Autoconf documentation
configure: WARNING: stdbool.h: section "Present But Cannot Be Compiled"
configure: WARNING: stdbool.h: proceeding with the compiler's result
checking for stdbool.h... no
checking stdalign.h usability... no
checking stdalign.h presence... yes
configure: WARNING: stdalign.h: present but cannot be compiled
configure: WARNING: stdalign.h: check for missing prerequisite headers?
configure: WARNING: stdalign.h: see the Autoconf documentation
configure: WARNING: stdalign.h: section "Present But Cannot Be Compiled"
configure: WARNING: stdalign.h: proceeding with the compiler's result
checking for stdalign.h... no
checking for the value of EOF... configure: error: computing EOF failed
make[1]: *** [configure-target-libstdc++-v3] Error 1

(other attempts yielding same result pruned)

So, how did you manage to build and install gcc-6.1.0 for mmix in the first
place?  If you have local patches or work 

[Bug target/71208] [6 regression] mmix: C++ code fails to link

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson  ---
JFTR: I have a feeling there's a (non-build-machinery) target-specific bug here
too, one that trigs a binutils bug.  In any case, I have to build gcc for
myself to avoid a back-and-forth game of requests to include sufficient archive
and object files in the report (like I should have done regularly anyway, mea
culpa).

[Bug c++/71419] New: cortex-a9 IRQ

[hans.buchmann at fhnw dot ch]

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

Bug ID: 71419
   Summary: cortex-a9 IRQ
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hans.buchmann at fhnw dot ch
  Target Milestone: ---

Compiling the code:

extern void external();
 __attribute__ ((interrupt("IRQ"))) void _irq_() ;
 void _irq_()
 {
  external();
 }

with gcc 6.1.0 results in:

Disassembly of section .text:

 <_Z5_irq_v>:
   0:   e24ee004sub lr, lr, #4
   4:   e92d500fpush{r0, r1, r2, r3, ip, lr}
   8:   ebfebl  0 <_Z8externalv>
   c:   e8bd900fpop {r0, r1, r2, r3, ip, pc} < here

The instruction:

 e8bd900f   pop {r0, r1, r2, r3, ip, pc} 

compared to: 

 e8fd900f   ldm sp!, {r0, r1, r2, r3, ip, pc}^

dont copy the SPSR back into the CPSR

The call:

${TC}/bin/arm-none-eabi-g++ -O2 -mcpu=cortex-a9 \
-c -o irq.o ../src/irq.cc

The Compiler g++ -v

Using built-in specs.
COLLECT_GCC=../tc/bin/arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/home/buchmann/devel/gcc/target/arm/libexec/gcc/arm-none-eabi/6.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /home/buchmann/devel/gcc/dist/gcc-6.1/configure -v
--prefix=/home/buchmann/devel/gcc/target/arm --target=arm-none-eabi
--enable-languages=c,c++ --disable-threads --disable-nls --disable-__cxa_atexit
--with-as=/home/buchmann/devel/gcc/target/arm/arm-none-eabi/bin/as
--with-ld=/home/buchmann/devel/gcc/target/arm/arm-none-eabi/bin/ld
--with-newlib --with-sysroot --without-headers --disable-libssp --enable-lto
--disable-shared --enable-multilib
Thread model: single
gcc version 6.1.0 (GCC) 

Kind regards 

Hans Buchmann

[Bug c++/71420] New: "‘type’ is not a class type" error for address-of operator overloaded for enum type

[nekotekina at gmail dot com]

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

Bug ID: 71420
   Summary: "‘type’ is not a class type" error for address-of
operator overloaded for enum type
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nekotekina at gmail dot com
  Target Milestone: ---

I was not using gcc compiler directly (it happened for Travis build), sorry if
the information is misleading or inaccurate.

Code example (C++11):

namespace itype
{
enum type
{
unk = 0,

add,
sub,
//...
};

// Address-of operator for decoder<>
constexpr type operator &(type value)
{
return value;
}
}

// Irrelevant, only shows the meaning of the below template
struct interpreter
{
static void unk() { std::abort(); };

static void add();
static void sub();
//...
};

template
struct decoder
{
// Implementation omitted, low-relevant usage example:
static constexpr auto add = &D::add;
static constexpr auto sub = &D::sub;
};

decoder test1; // OK
decoder test2; // OK in Clang and MSVC

// Expected error: ‘itype::type’ is not a class type

int main()
{
return 0;
}

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
Created attachment 38646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38646&action=edit
tentative patch

(you can ignore the expr.c bit, it is just because bootstrap is currently
broken on some platforms)

Does it help?

We could probably also handle x*3 as x+x+x, but where to stop?

I don't understand why the optab test for LSHIFT_EXPR was using optab_vector,
as far as I understand we are creating vec<<3, so optab_scalar makes more
sense.

I gave priority to x+x over x<<1, not sure if that's right, it probably doesn't
matter much as one will probably be turned into the other in later passes.

[Bug bootstrap/71421] New: trunk bootstrap is broken

[segher at gcc dot gnu.org]

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

Bug ID: 71421
   Summary: trunk bootstrap is broken
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

/home/segher/src/gcc/gcc/expr.c: In member function 'virtual void
move_by_pieces_d::generate(rtx, rtx, machine_mode)':
/home/segher/src/gcc/gcc/expr.c:1146:60: error: unused parameter 'mode'
[-Werror=unused-parameter]
 move_by_pieces_d::generate (rtx op0, rtx op1, machine_mode mode)
^~~~

(PUSH_ROUNDING is not defined for all targets).

[Bug c++/49377] Template specialization attributes cause type mismatches when used

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-05
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Fixed in 6.1.0. I'm adding a testcase and closing the bug.

[Bug c++/49377] Template specialization attributes cause type mismatches when used

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun Jun  5 15:08:22 2016
New Revision: 237098

URL: https://gcc.gnu.org/viewcvs?rev=237098&root=gcc&view=rev
Log:
2016-06-05  Paolo Carlini  

PR c++/49377
* g++.dg/template/pr49377.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/pr49377.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/49377] Template specialization attributes cause type mismatches when used

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|rmorell at nvidia dot com  |
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Paolo Carlini  ---
Done.

[Bug c/71422] New: Total size of static objects is not limited

[ch3root at openwall dot com]

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

Bug ID: 71422
   Summary: Total size of static objects is not limited
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Shouldn't gcc loudly fail when it cannot lay static objects out without
wrapping around the end of the address space?
Otherwise the resulting binary can, for example, crash. Or silently give wrong
answer like in the example below.

Source code:

--
#include 
#include 

char a[SIZE_MAX / 2];
char b[SIZE_MAX / 2];
char c[SIZE_MAX / 2];

int main(int argc, char **argv)
{
  (void)argv;

  a[argc] = 123;
  printf("%d\n", b[argc]);

  printf("&a = %p\n", (void *)&a);
  printf("&b = %p\n", (void *)&b);
  printf("&c = %p\n", (void *)&c);
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 -m32 test.c && ./a.out
123
&a = 0x8049740
&b = 0x8049740
&c = 0x88049740
--

gcc version: gcc (GCC) 7.0.0 20160604 (experimental)

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jun  5 15:45:44 2016
New Revision: 237099

URL: https://gcc.gnu.org/viewcvs?rev=237099&root=gcc&view=rev
Log:
Backport from mainline
2016-06-01  Uros Bizjak  
Jocelyn Mayer  

PR target/67310
* config/i386/driver-i386.c (host_detect_local_cpu): Correctly
detect processor family for signature_CENTAUR_ebx.
: Pass c3, winchip2 or winchip-c6 for
signature_CENTAUR_ebx.
: Pass c3-2 for signature_CENTAUR_ebx.
: Pass x86-64 for has_longmode.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/driver-i386.c

[Bug c++/71420] "‘type’ is not a class type" error for address-of operator overloaded for enum type

[flashmozzg at gmail dot com]

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

flashmozzg at gmail dot com changed:

   What|Removed |Added

 CC||flashmozzg at gmail dot com

--- Comment #1 from flashmozzg at gmail dot com ---
There is even smaller example which compiles fine on Clang but fails in every
gcc:
https://godbolt.org/g/LTZZRc

#include 
#include 
using namespace std;

enum test {
A = 0
};

constexpr test operator &(test value)
{
return value;
}

template
void printt() {
cout << typeid(T).name() << endl;
}

int main() {
printt();

return 0;
}

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[uros at gcc dot gnu.org]

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

--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jun  5 15:47:50 2016
New Revision: 237100

URL: https://gcc.gnu.org/viewcvs?rev=237100&root=gcc&view=rev
Log:
Backport from mainline
2016-06-01  Uros Bizjak  
Jocelyn Mayer  

PR target/67310
* config/i386/driver-i386.c (host_detect_local_cpu): Correctly
detect processor family for signature_CENTAUR_ebx.
: Pass c3, winchip2 or winchip-c6 for
signature_CENTAUR_ebx.
: Pass c3-2 for signature_CENTAUR_ebx.
: Pass x86-64 for has_longmode.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/driver-i386.c

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[uros at gcc dot gnu.org]

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

--- Comment #22 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jun  5 15:52:01 2016
New Revision: 237101

URL: https://gcc.gnu.org/viewcvs?rev=237101&root=gcc&view=rev
Log:
Backport from mainline
2016-06-01  Uros Bizjak  
Jocelyn Mayer  

PR target/67310
* config/i386/driver-i386.c (host_detect_local_cpu): Correctly
detect processor family for signature_CENTAUR_ebx.
: Pass c3, winchip2 or winchip-c6 for
signature_CENTAUR_ebx.
: Pass c3-2 for signature_CENTAUR_ebx.
: Pass x86-64 for has_longmode.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/driver-i386.c

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug rtl-optimization/71423] New: wrong code at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 71423
   Summary: wrong code at -Os and above on x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -Os
and above in both 32-bit and 64-bit modes.

This is a regression from 5.3.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160604 (experimental) [trunk revision 237092] (GCC) 
$ 
$ gcc-trunk -O1 small.c
$ ./a.out
$ 
$ gcc-5.3 -Os small.c
$ ./a.out
$ 
$ gcc-6.1 -Os small.c
$ ./a.out
Aborted (core dumped)
$ 
$ gcc-trunk -Os small.c
$ ./a.out
Aborted (core dumped)
$ 


---


struct S1
{
  int f1:1;
};

volatile struct S1 b = { 0 };

int
main ()
{
  char c = b.f1;
  b.f1 = 1; 

  if (b.f1 > -1 || c)
__builtin_abort (); 

  return 0; 
}

[Bug tree-optimization/71423] [6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-05
  Component|rtl-optimization|tree-optimization
Summary|wrong code at -Os and above |[6/7 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
forwprop4 (already happens at -O2)

[Bug tree-optimization/71423] [6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
match.pd has transformations like (~X & Y) -> X < Y for types of precision 1.
It looks like those are only valid if the type is unsigned, the comparison
should be reversed (Y < X) if the type is signed. I didn't check if that's
actually causing this bug.

[Bug fortran/69659] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sun Jun  5 17:20:54 2016
New Revision: 237105

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

2016-06-05  Andre Vehreschild  

PR fortran/69659
* gfortran.dg/class_array_22.f03: New test.


gcc/fortran/ChangeLog:

2016-06-05  Andre Vehreschild  

PR fortran/69659
* trans-array.c (gfc_trans_dummy_array_bias): For class arrays use
the address of the _data component to reference the arrays data
component.


Added:
trunk/gcc/testsuite/gfortran.dg/class_array_22.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Marc Glisse  ---
[...]
> Does it help?

It does: I just completed a sparc-sun-solaris2.12 bootstrap and the
failures are gone.  Unfortunately, the patch introduced new new
regression:

+FAIL: gcc.dg/vect/vect-iv-9.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vect "vectorized 1 loops" 1

I'm attaching the dump.

Rainer

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Created attachment 38647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38647&action=edit
vect-iv-9.c.149t.vect

[Bug fortran/69659] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sun Jun  5 18:09:27 2016
New Revision: 237107

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

2016-06-05  Andre Vehreschild  

PR fortran/69659
* gfortran.dg/class_array_22.f03: New test.


gcc/fortran/ChangeLog:

2016-06-05  Andre Vehreschild  

PR fortran/69659
* trans-array.c (gfc_trans_dummy_array_bias): For class arrays use
the address of the _data component to reference the arrays data
component.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/class_array_22.f03
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-array.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/69659] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[vehre at gcc dot gnu.org]

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

--- Comment #11 from vehre at gcc dot gnu.org ---
Waiting one week for any regressions to occur before closing.

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> It does: I just completed a sparc-sun-solaris2.12 bootstrap and the
> failures are gone.  Unfortunately, the patch introduced new new
> regression:
> 
> +FAIL: gcc.dg/vect/vect-iv-9.c -flto -ffat-lto-objects  scan-tree-dump-times
> vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vect "vectorized 1
> loops" 1

That's actually progress, not a regression ;-)

We are now vectorizing more. We can either adjust the condition for
scan-tree-dump, or replace 2*i with 3*i (and 978 with the new value).

[Bug c++/71424] New: std::initializer_list

[glisse at gcc dot gnu.org]

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

Bug ID: 71424
   Summary: std::initializer_list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

This was posted by Peter Dimov in c++std-core-22683, and doesn't seem to have
found its way to our bugzilla.

#include 

void f( std::initializer_list list )
{
}

int main()
{
   f( { { 1.0, 2.0 }, { 3.0, 4.0 } } );
}

clang++ and EDG accept it, g++ rejects it with:

array must be initialized with a brace-enclosed initializer

Apparently the error message used to be

could not convert ‘{{1.0e+0, 2.0e+0}, {3.0e+0, 4.0e+0}}’ to
‘std::initializer_list’

[Bug c++/71425] New: GCC does not implement C++/WG21 DR 1399/1388

[schaub.johannes at googlemail dot com]

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

Bug ID: 71425
   Summary: GCC does not implement C++/WG21 DR 1399/1388
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schaub.johannes at googlemail dot com
  Target Milestone: ---

The following testcase should fail to compile because Args is not deduced
(stays empty), but surprisingly, GCC accept it

   #include 

   template
   T method(std::tuple, Args..., T, ...) {
  return T();
   }

   int main() {
   method(std::make_tuple(1, 1.0f, 1.0),
   1, 1.0f, 1.0, 1);
   }

Here, "Args..." in the "tuple" cannot be deduced because DR1388 says
that "Args" is never deduced, because it appears in a non-deduced context in
the second function parameter. GCC however seems to deduce it by the
tuple<...>, and then expands its value into the second function parameter. 

However, as Jason notes in DR1399, this is not sensible at all. T will have
been deduced by the first "1", rather than by the last "1". GCC will happily
accept the code if the last "1" is changed to "1.0", with T staying "int".

[Bug c++/71425] GCC does not implement C++/WG21 DR 1399/1388

[schaub.johannes at googlemail dot com]

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

--- Comment #1 from Johannes Schaub  ---
(This bug report is due to
https://stackoverflow.com/questions/37645347/clang-does-not-infer-template-argument-in-variadic-template-function-with-vararg)

[Bug c/71426] New: gcc ICE on x86_64-linux-gnu in get_parm_info, at c/c-decl.c:7059

[helloqirun at gmail dot com]

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

Bug ID: 71426
   Summary: gcc ICE on x86_64-linux-gnu in get_parm_info, at
c/c-decl.c:7059
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following invalid code causes an ICE when compiled with the current gcc
trunk on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It affects the current trunk, 4.X. But works for 5.X and 6.X.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160605 (experimental) [trunk revision 237097] (GCC)


$ gcc-trunk a.c
a.c:1:33: error: ‘ID1’ undeclared here (not in a function)
 signed * * ID0 ( inline ID1 [ + ID1 %  3.14 - ID1 ( ) ] ) ;
 ^~~
a.c:1:47: warning: implicit declaration of function ‘ID1’
[-Wimplicit-function-declaration]
 signed * * ID0 ( inline ID1 [ + ID1 %  3.14 - ID1 ( ) ] ) ;
   ^~~
a.c:1:25: warning: type defaults to ‘int’ in declaration of ‘ID1’
[-Wimplicit-int]
 signed * * ID0 ( inline ID1 [ + ID1 %  3.14 - ID1 ( ) ] ) ;
 ^~~
a.c:1:25: warning: parameter ‘ID1’ declared ‘inline’
a.c:1:1: internal compiler error: in get_parm_info, at c/c-decl.c:7059
 signed * * ID0 ( inline ID1 [ + ID1 %  3.14 - ID1 ( ) ] ) ;
 ^~
0x65d2dd get_parm_info(bool, tree_node*)
../../gcc/gcc/c/c-decl.c:7059
0x6c2160 c_parser_parms_list_declarator
../../gcc/gcc/c/c-parser.c:3756
0x6c22a0 c_parser_parms_declarator
../../gcc/gcc/c/c-parser.c:3672
0x6c4df9 c_parser_direct_declarator_inner
../../gcc/gcc/c/c-parser.c:3601
0x6c25d1 c_parser_declarator
../../gcc/gcc/c/c-parser.c:3362
0x6c25d1 c_parser_declarator
../../gcc/gcc/c/c-parser.c:3362
0x6c801a c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.c:1816
0x6d461d c_parser_external_declaration
../../gcc/gcc/c/c-parser.c:1549
0x6d5049 c_parser_translation_unit
../../gcc/gcc/c/c-parser.c:1430
0x6d5049 c_parse_file()
../../gcc/gcc/c/c-parser.c:17930
0x737922 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



$ cat a.c
signed * * ID0 ( inline ID1 [ + ID1 %  3.14 - ID1 ( ) ] ) ;

[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jun  5 19:49:59 2016
New Revision: 237108

URL: https://gcc.gnu.org/viewcvs?rev=237108&root=gcc&view=rev
Log:
2016-06-05  Jerry DeLisle  

PR fortran/71404
* io.c (match_io): For READ, commit in pending symbols in the
current statement before trying to match an expression so that
if the match fails and we undo symbols we dont toss good symbols.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c

[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0

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

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

--- Comment #12 from Andreas Schwab  ---
This breaks ada bootstrap on ia64, causing bootstrap comparison failure.

Bootstrap comparison failure!
gcc/ada/sem_ch13.o differs
make[1]: *** [compare] Error 1

[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|arm-linux-gnueabihf,|arm-*-*, ia64-*-*
   |arm-linux-gnueabi   |
Version|6.1.1   |7.0
 Blocks||52171
   Target Milestone|--- |7.0

--- Comment #1 from Andreas Schwab  ---
Also broken on ia64, caused by r237069.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171
[Bug 52171] memcmp/strcmp/strncmp can be optimized when the result is tested
for [in]equality with 0

[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jun  5 19:58:38 2016
New Revision: 237109

URL: https://gcc.gnu.org/viewcvs?rev=237109&root=gcc&view=rev
Log:
2016-06-05  Jerry DeLisle  

PR fortran/71404
* gfortran.dg/fmt_read_5.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_read_5.f
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Jerry DeLisle  ---
This should be fixed now.  Please confirm before closing this PR.

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #5)

> This looks like a dataflow infrastructure problem, not a target problem to
> me.

It is a target problem with invalid RTL sharing.

Invalid sharing is created by the code in Comment #4 when subregs are involved.
vec_extract_hi_v32qi pattern is generated in loop2_invariant pass when
misaligned V8SI move is generated, and later cprop3 pass propagates a register
to a subreg in (insn 197). The whole 

(subreg:V32QI (reg:V8SI 181) 0)

RTX is shared, and the pass updates both instances of (reg:V8SI 181) to
(reg:V8SI 175) in (insn 197) and (insn 198). However, since just renamed (reg
175) doesn't trigger rescan of (insn 198) in the substitution loop, we get:

rescanning insn with uid = 197.
GLOBAL COPY-PROP: Replacing reg 181 in insn 197 with reg 175
rescanning insn with uid = 199.
GLOBAL CONST-PROP: Replacing reg 182 in insn 199 with constant (const_int 1
[0x1])

And (insn 198) isn't even recognized...

Things get downhill from this point.

The solution is to avoid invalid sharing by copying RTXes when subregs are
created, as already proposed by the patch in Comment #4.

To answer my own question: the code, referred in the second part of Comment #4
(except V4SFmode part) is processing plain REG RTXes, and these don't need
copying.

I'm testing the patch that solves the failure and possible similar problem with
V4SFmode operands:

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 237110)
+++ config/i386/i386.c  (working copy)
@@ -19552,7 +19552,7 @@ ix86_avx256_split_vector_move_misalign (rtx op0, r
   m = adjust_address (op0, mode, 0);
   emit_insn (extract (m, op1, const0_rtx));
   m = adjust_address (op0, mode, 16);
-  emit_insn (extract (m, op1, const1_rtx));
+  emit_insn (extract (m, copy_rtx (op1), const1_rtx));
 }
   else
 gcc_unreachable ();
@@ -19724,7 +19724,7 @@ ix86_expand_vector_move_misalign (machine_mode mod
  m = adjust_address (op0, V2SFmode, 0);
  emit_insn (gen_sse_storelps (m, op1));
  m = adjust_address (op0, V2SFmode, 8);
- emit_insn (gen_sse_storehps (m, op1));
+ emit_insn (gen_sse_storehps (m, copy_rtx (op1)));
}
 }
   else
--cut here--

[Bug target/71389] [7 Regression] ICE on trunk gcc on ivybridge target (df_refs_verify)

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jun  5 22:55:35 2016
New Revision: 237111

URL: https://gcc.gnu.org/viewcvs?rev=237111&root=gcc&view=rev
Log:
PR target/71389
* config/i386/i386.c (ix86_avx256_split_vector_move_misalign):
Copy op1 RTX to avoid invalid sharing.
(ix86_expand_vector_move_misalign): Ditto.

testsuite/ChangeLog:

PR target/71389
* g++.dg/pr71389.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/pr71389.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Oof, I don't think I'll be able to reproduce an Ada failure on ARM. Can you
narrow the problem down a bit, identifying what the differences are?

[Bug tree-optimization/71428] New: [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[zsojka at seznam dot cz]

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

Bug ID: 71428
   Summary: [7 Regression] wrong code with -Os -fno-tree-forwprop
(breaks in the .bswap dump)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-tree-forwprop testcase.c -Wno-psabi
$ ./a.out 
Aborted

Diffing 6-branch and trunk assembly output shows:
@@ -7,10 +7,10 @@
 .LFB0:
.cfi_startproc
mov dx, WORD PTR [rsp+10]
-   or  WORD PTR [rsp+70], dx
mov rax, rdi
lea rsi, [rsp+8]
mov ecx, 16
+   mov WORD PTR [rsp+70], dx
rep movsd
ret
.cfi_endproc


The "or" seems to disappear in the .bswap dump in trunk.
6-branch .bswap doesn't perform any transformation, but trunk's one does.

[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 38649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38649&action=edit
reduced testcase

[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Target Milestone|--- |7.0

[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
I cannot upload any attachment to bugzilla (requests just time out), so here it
is as a plain text:
$ cat testcase.c
typedef unsigned short v64u16 __attribute__ ((vector_size (64)));

v64u16
foo (v64u16 p1)
{
  p1[31] |= p1[1];
  return p1;
}

int
main ()
{
  v64u16 x = foo ((v64u16){ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 });
//  __builtin_printf ("%04x\n", x[31]);
  if (x[31] != 1)
__builtin_abort();
  return 0;
}

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[shiva0217 at gmail dot com]

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

--- Comment #17 from Shiva Chen  ---
Hi, Richard

Thanks for the explanation :)

So the transformation (short)abs((int)short_var) -> abs (short_var)

should guard by TYPE_OVERFLOW_WRAPS 

because when TYPE_OVERFLOW_WRAPS is true, signed operation could wrap
around.(ABS_EXPR in gimple could wrap around and rtl abs already modulo)

Therefore, the transformation is valid when TYPE_OVERFLOW_WRAPS is true.

It seems the last update of Matthew's patch in
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00433.html
still make sense.

Why would it be dropped, or there're still something we should consider ?


If we implement ABSU_EXPR, when should transfer 
ABS_EXPR (x) -> (type of x) ABSU_EXPR (x) ?

Could we define like if (!TYPE_OVERFLOW_WRAPS) then transfer ABS_EXPR (x) ->
(type of x) ABSU_EXPR (x) in match.pd ?

How to expand (type of x) ABSU_EXPR (x) to rtl ?

Do we have to add a new naming pattern absu ?

[Bug driver/71429] New: Rename -W[no-]#pragma-messages to -W[no-]pragma-messages

[zeratul976 at hotmail dot com]

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

Bug ID: 71429
   Summary: Rename -W[no-]#pragma-messages to
-W[no-]pragma-messages
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeratul976 at hotmail dot com
  Target Milestone: ---

# is a special character that begins a comment in many scripting environments,
including makefiles. Escaping it is more trouble than it's worth.

Please stick to boring characters in flag names.

[Bug tree-optimization/71398] [7 Regression] ICE at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu (Segmentation fault, find_edge)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/71398] [7 Regression] ICE at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu (Segmentation fault, find_edge)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jun  6 06:55:19 2016
New Revision: 237117

URL: https://gcc.gnu.org/viewcvs?rev=237117&root=gcc&view=rev
Log:
2016-06-06  Richard Biener  

PR tree-optimization/71398
* tree-ssa-loop-ivcanon.c (unloop_loops): First unloop, then
remove edges.

* gcc.dg/torture/pr71398.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71398.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivcanon.c