[Bug c++/59031] vtable lookup not optimized away

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59031

--- Comment #1 from Paolo Carlini  ---
I recommend always sending patches to the mailing list.

[Bug c++/59030] [4.9 Regression] Caret diagnostic always points to the first line

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030

--- Comment #3 from Paolo Carlini  ---
Today I can't reproduce this. Please double check.

[Bug c++/59033] cannot control inherited constructors access

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59033

Paolo Carlini  changed:

   What|Removed |Added

Summary|cannot control inherited|cannot control inherited
   |constructors visibility |constructors access

--- Comment #1 from Paolo Carlini  ---
visibility is a term of art

[Bug target/59035] New: FAIL: gcc.dg/torture/c99-contract-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035

Bug ID: 59035
   Summary: FAIL: gcc.dg/torture/c99-contract-1.c  -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution
test
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
Target: ia64-*-*

Only fails with -flto.

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/torture/c99-contract-1.c -O2 -std=c99
-pedantic-errors
$ ./a.out
$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/torture/c99-contract-1.c -O2 -std=c99
-pedantic-errors -flto
$ ./a.out
Aborted

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Nov  7 09:58:05 2013
New Revision: 204501

URL: http://gcc.gnu.org/viewcvs?rev=204501&root=gcc&view=rev
Log:
Use Pmode with stack_pointer_rtx

gcc/

PR target/59034
* config/i386/i386.md (push peepholer/splitter): Use Pmode
with stack_pointer_rtx.

gcc/testsuite/

PR target/59034
* gcc.target/i386/pr59034-1.c: New test.
* gcc.target/i386/pr59034-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59034-1.c
trunk/gcc/testsuite/gcc.target/i386/pr59034-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Nov  7 10:05:07 2013
New Revision: 204502

URL: http://gcc.gnu.org/viewcvs?rev=204502&root=gcc&view=rev
Log:
Use Pmode with stack_pointer_rtx

gcc/

Backport from mainline
PR target/59034
* config/i386/i386.md (push peepholer/splitter): Use Pmode
with stack_pointer_rtx.

gcc/testsuite/


Backport from mainline
PR target/59034
* gcc.target/i386/pr59034-1.c: New test.
* gcc.target/i386/pr59034-2.c: Likewise.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59034-1.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59034-2.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-07
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.8.4
 Ever confirmed|0   |1

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[hjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Nov  7 10:09:49 2013
New Revision: 204503

URL: http://gcc.gnu.org/viewcvs?rev=204503&root=gcc&view=rev
Log:
Use Pmode with stack_pointer_rtx

Backport from mainline
PR target/59034
* config/i386/i386.md (push peepholer/splitter): Use Pmode
with stack_pointer_rtx.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/i386.md

[Bug c++/2778] -fdump-translation-unit [Simple patch supplied, needs review]

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2778

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.2, 4.9.0
 Resolution|--- |WORKSFORME

--- Comment #15 from Paolo Carlini  ---
Everything seems fine to me.

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029

--- Comment #3 from Jakub Jelinek  ---
(In reply to Yury Gribov from comment #2)
> Created attachment 31177 [details]
> Draft patch
> 
> Aha, looks like the ICE is caused by destination address being INTEGER_CST
> instead of ADDR_EXPR. Attached patch seems to fix this (tested on x86_64).
> 
> @Volker: could you add your testcase to Asan testsuite?

Patch preapproved with the testcase and correct ChangeLog, just add
/* { dg-do compile } */

int
foo ()
{
  return __sync_fetch_and_add ((int *) 0, 1);
}

to testsuite/c-c++-common/asan/pr59029.c ?

[Bug rtl-optimization/59036] New: [4.9 regression] Performance degradation after r204212 on 32-bit x86 targets.

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036

Bug ID: 59036
   Summary: [4.9 regression] Performance degradation after r204212
on 32-bit x86 targets.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

After patch to improve register preferencing in IRA and to *remove regmove*
pass we noticed performance degradation on several benchmarks from eembc2.0
suite in 32-bit mode for all x86 targets (such as atom, slm, hsw, etc.).
This can be reproduced with attached test-case - after fix 3 more instructions
are generated for innermost loop (compiled with -O2 -m32 -march=core-avx2
options):

  before fix
.L4:
movl12(%esp), %edx
addl$3, %ecx
movl4(%esp), %ebx
movl(%esp), %ebp
movl8(%esp), %esi
movzbl(%edx,%eax), %edi
movl16(%esp), %edx
movzbl(%ebx,%eax), %ebx
movzbl(%esi,%eax), %esi
addl$1, %eax
addl(%edx,%edi,4), %ebp
movzbl0(%ebp,%ebx), %edx
movl28(%esp), %ebp
movb%dl, -3(%ecx)
movl24(%esp), %edx
movl(%edx,%edi,4), %edx
movl(%esp), %edi
addl0(%ebp,%esi,4), %edx
leal(%edi,%ebx), %ebp
sarl$16, %edx
movzbl0(%ebp,%edx), %edx
movl20(%esp), %ebp
movb%dl, -2(%ecx)
movl0(%ebp,%esi,4), %edx
addl%edi, %edx
movzbl(%edx,%ebx), %edx
movb%dl, -1(%ecx)
cmpl80(%esp), %eax
jne.L4

  after fix
.L4:
movl8(%esp), %ebx
addl$3, %edx
movl12(%esp), %esi
movl4(%esp), %ecx
movzbl(%ebx,%eax), %ebx
movzbl(%esi,%eax), %esi
movzbl(%ecx,%eax), %ecx
addl$1, %eax
movb%bl, (%esp)
movl16(%esp), %ebx
movl(%ebx,%esi,4), %ebp
addl%edi, %ebp
movzbl0(%ebp,%ecx), %ebx
movzbl(%esp), %ebp
movb%bl, -3(%edx)
movl24(%esp), %ebx
movl%ebp, (%esp)
movl(%ebx,%esi,4), %esi
movl28(%esp), %ebx
addl(%ebx,%ebp,4), %esi
leal(%edi,%ecx), %ebp
sarl$16, %esi
movzbl0(%ebp,%esi), %ebx
movl20(%esp), %esi
movl(%esp), %ebp
movb%bl, -2(%edx)
movl%edi, %ebx
addl(%esi,%ebp,4), %ebx
movzbl(%ebx,%ecx), %ecx
movb%cl, -1(%edx)
cmpl80(%esp), %eax
jne.L4

[Bug rtl-optimization/59036] [4.9 regression] Performance degradation after r204212 on 32-bit x86 targets.

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 31178
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31178&action=edit
test-case to reproduce

test need to be compiled with -m32 option for any x86 targets.

[Bug c++/12277] Warn on dynamic casts with known NULL results.

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/10619] Error message for no matching function calls does not list explicitly-specified template arguments

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/16386] [ABI] attribute aligned,packed shifting [3.2/3.3/3.4]

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16386

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
I see the results per Comment #3 very consistent across the recent release
series and current ICC and clang too. I think we can close the bug.

[Bug c++/17314] Error message wrongly shows declared rather than inherited access

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314

Paolo Carlini  changed:

   What|Removed |Added

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

[Bug rtl-optimization/59036] [4.9 regression] Performance degradation after r204212 on 32-bit x86 targets.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 CC||vmakarov at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug target/59035] [4.9 Regression] FAIL: gcc.dg/torture/c99-contract-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|FAIL:   |[4.9 Regression] FAIL:
   |gcc.dg/torture/c99-contract |gcc.dg/torture/c99-contract
   |-1.c  -O2 -flto |-1.c  -O2 -flto
   |-fno-use-linker-plugin  |-fno-use-linker-plugin
   |-flto-partition=none|-flto-partition=none
   |execution test  |execution test

--- Comment #1 from Richard Biener  ---
I wonder whether fp-contract opts are properly transfered to LTO?

[Bug target/59034] [4.9 Regression] FAIL gcc.c-torture/compile/20031208-1.c

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59034

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/59031] [4.8/4.9 Regression] vtable lookup not optimized away

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59031

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.3
Summary|vtable lookup not optimized |[4.8/4.9 Regression] vtable
   |away|lookup not optimized away

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.3

[Bug c++/59030] [4.9 Regression] Caret diagnostic always points to the first line

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Appearantly got fixed meanwhile.

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

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014

Marek Polacek  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #6 from Marek Polacek  ---
  if (TREE_CODE (rhs_def_operand1) == SSA_NAME
  && ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs_def_operand1)
  && TREE_CODE (rhs_def_operand2) == INTEGER_CST
  && operand_equal_p (rhs_def_operand2,
  build_low_bits_mask (TREE_TYPE
(rhs_def_operand2),
   TYPE_PRECISION (lhs_type)),
   0))

in simplify_conversion_from_bitmask in tree-ssa-forwprop.c will need some
tweaking

[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
Summary|Revision 203979 causes  |[4.9 Regression] Revision
   |failure in CPU2006  |203979 causes failure in
   |benchmark 435.gromacs   |CPU2006 benchmark
   ||435.gromacs

[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025

--- Comment #3 from Jakub Jelinek  ---
Can you please narrow it down to a file and routine?  I guess I can look at it
afterwards using cross-compilers, the patch wasn't meant do any code generation
changes, only that sometimes a new stmt is created instead of reusing existing
one and the old one eventually removed later on, plus different SSA_NAME
versions may be used.  The only places where it should affect code generation
is if previously we kept invalid preserved range information (or we could have
wrong-debug) and something used that preserved range info, but in r203979 there
were still almost no get_range_info users.

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
Can you provide a test that should fail according to your interpretation? I
think you are misreading the code: is_signed delegates to a specialization of
__is_signed_helper. For this template we have a static branch into types where
is_arithmetic doesn't hold (This returns false_type unconditionally) and
another one where this holds. Only in the latter case further performs the
additional expression test.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-07
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin13.

Revision 204368 says

Author:kcc
Date:Mon Nov 4 21:33:31 2013 UTC (2 days, 14 hours ago)
Log Message:
libsanitizer merge from upstream r191666

** This may break gcc-asan on Mac, will follow up separately. **

The failures are of the kind:

==70739==AddressSanitizer CHECK failed:
../../../../_clean/libsanitizer/sanitizer_common/sanitizer_mac.cc:146
"((env_ptr)) != (0)" (0x0, 0x0)

[Bug c++/59033] cannot control inherited constructors access

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59033

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #2 from Daniel Krügler  ---
The wording in the standard is pretty clear (12.9 p4):

"A constructor so declared has the same access as the corresponding constructor
in X."

The gcc compiler (and clang as well) both behave according to this
specification.

A using declaration for a type is different: There can not be two (or more)
types of the same name within such a using declaration.

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[ygribov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029

--- Comment #4 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Thu Nov  7 12:04:45 2013
New Revision: 204508

URL: http://gcc.gnu.org/viewcvs?rev=204508&root=gcc&view=rev
Log:
Allow integer literals as addresses in instrumented builtins.

gcc/
PR sanitizer/59029
* gcc/asan.c (get_mem_refs_of_builtin_call): Allow
integer literals as addresses in instrumented builtins.

gcc-testsuite/
PR sanitizer/59029
* c-c++-common/asan/pr59029.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr59029.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029

--- Comment #5 from Jakub Jelinek  ---
(In reply to ygribov from comment #4)
> URL: http://gcc.gnu.org/viewcvs?rev=204508&root=gcc&view=rev
> Log:
> Allow integer literals as addresses in instrumented builtins.

Note, patches should still go to gcc-patches, even when you just say in subject
[committed] and in the description that it has been preapproved in the PR.
> gcc/
>   PR sanitizer/59029
>   * gcc/asan.c (get_mem_refs_of_builtin_call): Allow
>   integer literals as addresses in instrumented builtins.

The gcc/ prefix shouldn't be there.

[Bug c++/59033] cannot control inherited constructors access

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59033

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Closing then.

[Bug c++/59030] [4.9 Regression] Caret diagnostic always points to the first line

[reichelt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59030

--- Comment #5 from Volker Reichelt  ---
The offending patch got reverted:

http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg00212.html

[Bug middle-end/59037] New: ICE when accessing invalid element (nelts + 1) of vector

[matthew.leach at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037

Bug ID: 59037
   Summary: ICE when accessing invalid element (nelts + 1) of
vector
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.leach at arm dot com

Created attachment 31179
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31179&action=edit
Reduced test case for ICE

Output of ./gcc -v -save-temps -O3 ~/test.c

Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/work/gcc-trunk/gcc/install-native/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c
--prefix=/work/gcc-trunk/gcc/install-native
Thread model: posix
gcc version 4.9.0 20131107 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'

/work/gcc-trunk/gcc/install-native/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1
-E -quiet -v -imultilib . -imultiarch x86_64-linux-gnu /home/matlea01/test.c
-mtune=generic -march=x86-64 -O3 -fpch-preprocess -o test.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/work/gcc-trunk/gcc/install-native/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/work/gcc-trunk/gcc/install-native/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include
 /usr/local/include
 /work/gcc-trunk/gcc/install-native/include

/work/gcc-trunk/gcc/install-native/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'

/work/gcc-trunk/gcc/install-native/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1
-fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -march=x86-64
-auxbase test -O3 -version -o test.s
GNU C (GCC) version 4.9.0 20131107 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20131107 (experimental), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20131107 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.0 20131107 (experimental), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fa4fbb3b9b1dd7adc3db446e035da983
/home/matlea01/test.c: In function ‘main’:
/home/matlea01/test.c:9:1: internal compiler error: Segmentation fault
 }
 ^
0x9c944f crash_signal
../../gcc/toplev.c:334
0xab9259 tree_check
../../gcc/tree.h:2691
0xab9259 simplify_bitfield_ref
../../gcc/tree-ssa-forwprop.c:3049
0xabc104 ssa_forward_propagate_and_combine
../../gcc/tree-ssa-forwprop.c:3496
0xabc104 execute
../../gcc/tree-ssa-forwprop.c:3590
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.

[Bug tree-optimization/59038] New: [4.9 Regression] r204398 causes 186.crafty init.c to be miscompiled

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038

Bug ID: 59038
   Summary: [4.9 Regression] r204398 causes 186.crafty init.c to
be miscompiled
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

-fno-tree-loop-distribute-patterns fixes it.  Trying to reduce.

[Bug tree-optimization/59038] [4.9 Regression] r204398 causes 186.crafty init.c to be miscompiled

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug middle-end/59037] ICE when accessing invalid element (nelts + 1) of vector

[matthew.leach at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037

--- Comment #1 from Matthew Leach  ---
Having a quick dig around the code, I think fold-const.c:16718 looks
suspicious:

if (offset/part_widthi <= TYPE_VECTOR_SUBPARTS (op00type))

Likewise in cp/semantics.c:9122 and gimple-fold.c:3407.

Should this "<=" be a "<"?

[Bug middle-end/59037] ICE when accessing invalid element (nelts + 1) of vector

[jgreenhalgh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-07
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
Reproduced on aarch64-none-elf and arm-none-eabi.

[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029

--- Comment #6 from Yury Gribov  ---
(In reply to Jakub Jelinek from comment #5)
> Note, patches should still go to gcc-patches, even when you just say in
> subject
> [committed] and in the description that it has been preapproved in the PR.

Got it. Done.

> The gcc/ prefix shouldn't be there.

Right, my bad...

-Y

[Bug c++/58176] ICE in output_constant, at varasm.c:4658

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug other/59039] New: Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

Bug ID: 59039
   Summary: Undocumented __builtin_longjmp/__builtin_setjmp
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

cilk_fiber-unix.cpp has

#pragma GCC push_options
#pragma GCC optimize ("-O0")
NORETURN cilk_fiber_sysdep::run()
{

It fails when compiled with any optimization.  This function has
__builtin_setjmp and __builtin_longjmp within the same function.
When __builtin_longjmp is put in a separate function, optimization
works.  But there is no documentation on how __builtin_longjmp
and __builtin_setjmp should be used, like the jump buffer size
and fields as well as any limitation.

If it is true that __builtin_setjmp and __builtin_longjmp can't be
used within the same function, GCC should issue an error, at least
a warning.

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Marc Mutz from comment #0)
> 
>   templatebool = is_arithmetic<_Tp>::value>
^^

> struct __is_signed_helper
> : public false_type { };
> 
>   template
> struct __is_signed_helper<_Tp, true>
 
> : public integral_constant
> { };

This looks right to me.

[Bug tree-optimization/59038] [4.9 Regression] r204398 causes 186.crafty init.c to be miscompiled

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038

--- Comment #1 from Richard Biener  ---
extern void abort (void);

unsigned char first_ones_8bit[256];
unsigned char connected_passed[256];

int
main ()
{
  int i, j;
  for (i=0;i<256;i++){
  connected_passed[i]=0;
  first_ones_8bit[i]=0;
  for (j=7;j>0;j--){
  if ((i & (3<<(7-j))) == (3<<(7-j))){
  connected_passed[i]=j;
  break;
  }
  }
  }
  if (connected_passed[3] != 7)
abort ();
  return 0;
}

[Bug target/59040] New: [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

Bug ID: 59040
   Summary: [4.9 Regression] r203937 caused: FAIL:
gcc.dg/torture/memcpy-1.c  -O0  (internal compiler
error)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: areg.melikadamyan at gmail dot com, hubicka at gcc dot 
gnu.org
Target: i686

On x86, I got

/export/project/git/gcc-regression/master/203937/bld/gcc/xgcc
-B/export/project/git/gcc-regression/master/203937/bld/gcc/
/export/project/git/gcc-regression/gcc/gcc/testsuite/gcc.dg/torture/memcpy-1.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -m32 
-mtune=pentiumpro -minline-all-stringops -S
/export/project/git/gcc-regression/gcc/gcc/testsuite/gcc.dg/torture/memcpy-1.c:
In function \u2018my_memcpy\u2019:
/export/project/git/gcc-regression/gcc/gcc/testsuite/gcc.dg/torture/memcpy-1.c:8:20:
internal compiler error: in
expand_set_or_movmem_prologue_epilogue_by_misaligned_moves, at
config/i386/i386.c:22998
0xe26c7a expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
../../../../gcc/gcc/config/i386/i386.c:22998
0xe28568 ix86_expand_set_or_movmem
../../../../gcc/gcc/config/i386/i386.c:23646
0xe29175 ix86_expand_movmem(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*)
../../../../gcc/gcc/config/i386/i386.c:23909
0xf0392b gen_movmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*)
../../../../gcc/gcc/config/i386/i386.md:15440
0x9f6798 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*) const
../../../../gcc/gcc/recog.h:288
0x9f5feb maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../../../gcc/gcc/optabs.c:8227
0x9f6158 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../../../gcc/gcc/optabs.c:8247
0x7b77a3 emit_block_move_via_movmem
../../../../gcc/gcc/expr.c:1322
0x7b7123 emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long)
../../../../gcc/gcc/expr.c:1178
0x66b3de expand_builtin_memcpy
../../../../gcc/gcc/builtins.c:3138
0x673917 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../../../gcc/gcc/builtins.c:6099
0x7d5f99 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
../../../../gcc/gcc/expr.c:10208
0x6bb173 expand_call_stmt
../../../../gcc/gcc/cfgexpand.c:2183
0x6bb26d expand_gimple_stmt_1
../../../../gcc/gcc/cfgexpand.c:2221
0x6bb8ba expand_gimple_stmt
../../../../gcc/gcc/cfgexpand.c:2373
0x6bb9ae expand_gimple_tailcall
../../../../gcc/gcc/cfgexpand.c:2420
0x6c1c5c expand_gimple_basic_block
../../../../gcc/gcc/cfgexpand.c:4189
0x6c37ba gimple_expand_cfg
../../../../gcc/gcc/cfgexpand.c:4731
0x6c3e44 execute
../../../../gcc/gcc/cfgexpand.c:4945
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #1 from Igor Zamyatin  ---
Dup of 588​53

[Bug c++/56710] Using reserved double underscore variable name in a lambda causes internal compiler error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56710

--- Comment #3 from Jonathan Wakely  ---
That testcase shows this is an ice-on-valid-code bug.  Reduced:

struct Dummy {
  void getDummy() const { }
};

template
  void eachDummy(F closure) {
Dummy d;
closure(d);
  }

template
void iterateDummies(F closure) {
  eachDummy([&] (const Dummy& d) {
  return closure(d);
  });
}

int main() {
  iterateDummies([] (const Dummy& d) {
  d.getDummy();
  return true;
  });
}

[Bug target/59035] [4.9 Regression] FAIL: gcc.dg/torture/c99-contract-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035

--- Comment #2 from joseph at codesourcery dot com  ---
If -ffp-contract=off is set for any object (whether explicitly, or 
implicitly by an option such as -std=c99), the safe option for LTO would 
be to set -ffp-contract=off at link time as well.

[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

--- Comment #2 from H.J. Lu  ---
(In reply to Igor Zamyatin from comment #1)
> Dup of 588​53

There is no PR588​53.

[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

--- Comment #3 from Igor Zamyatin  ---
Hmm... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853

[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Dup.

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

[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
*** Bug 59040 has been marked as a duplicate of this bug. ***

[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

octoploid at yandex dot com changed:

   What|Removed |Added

 CC||octoploid at yandex dot com

--- Comment #5 from octoploid at yandex dot com ---
(In reply to H.J. Lu from comment #2)
> (In reply to Igor Zamyatin from comment #1)
> > Dup of 588​53
> 
> There is no PR588​53.

Looks like a bugzilla bug. (PR588​53 links to PR588​...)
When I search for 588​53 on gcc.gnu.org/bugzilla it expands to 
http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=588%E2%80%8B53&list_id=74236
instead of
http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=58853
(Where is that strange %E2%80%8B coming from?)

[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040

--- Comment #6 from octoploid at yandex dot com ---
(In reply to octoploid from comment #5)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Igor Zamyatin from comment #1)
> > > Dup of 588​53
> > 
> > There is no PR588​53.
> 
> Looks like a bugzilla bug. (PR588​53 links to PR588​...)
> When I search for 588​53 on gcc.gnu.org/bugzilla it expands to 
> http://gcc.gnu.org/bugzilla/buglist.
> cgi?quicksearch=588%E2%80%8B53&list_id=74236
> instead of
> http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=58853
> (Where is that strange %E2%80%8B coming from?)

No it's a copy and paste error, because
the number from Comment1 is messed up.
When I paste it into vim I get:
588<200b>53

[Bug target/58853] [4.9 regression] ICE in expand_set_or_movmem_prologue_epilogue_by_misaligned_moves

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853

--- Comment #6 from H.J. Lu  ---
This

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 53e04c4..dd8d943 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23766,6 +23766,7 @@ ix86_expand_set_or_movmem (rtx dst, rtx src, rtx
count_exp, rtx 
val_exp,
  also avoids redundant job when sizes are known precisely.  */
   misaligned_prologue_used = (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES
   && MAX (desired_align, epilogue_size_needed) <= 32
+  && desired_align <= epilogue_size_needed
   && ((desired_align > align && !align_bytes)
   || (!count && epilogue_size_needed > 1)));

avoids crash.

[Bug c++/58176] ICE in output_constant, at varasm.c:4658

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jason at gcc dot gnu.org   |
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug c++/58176] ICE in output_constant, at varasm.c:4658

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58176

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Nov  7 14:26:17 2013
New Revision: 204514

URL: http://gcc.gnu.org/viewcvs?rev=204514&root=gcc&view=rev
Log:
2013-11-07  Paolo Carlini  

PR c++/58176
* varasm.c (output_constant): Handle NULLPTR_TYPE.

/testsuite
2013-11-07  Paolo Carlini  

PR c++/58176
* g++.dg/cpp0x/nullptr30.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nullptr30.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug other/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #1 from Richard Biener  ---
__builtin_longjmp/setjmp are just longjmp(3) setjmp(3) with their constraints.
They should not be used directly but  should be.

The file looks scary.

[Bug other/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #2 from Richard Biener  ---
I suppose

// alloca() to force generation of frame pointer.  The argument to alloca
// is contrived to prevent the compiler from optimizing it away.  This
// code should never actually be executed.
int* dummy = (int*) alloca((sizeof(int) + (std::size_t) m_start_proc) &
0x1);
*dummy = 0xface;

is optimized away.  Try using volatile int *.

[Bug other/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-07
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> __builtin_longjmp/setjmp are just longjmp(3) setjmp(3) with their
> constraints.
> They should not be used directly but  should be.

That was my first impression. But I saw

[hjl@gnu-hsw-1 tmp]$ cat y.c
#include 

extern jmp_buf buf;

void
foo ()
{
  __builtin_setjmp (buf);
}

void
bar ()
{
  __builtin_longjmp (buf, 1);
}
[hjl@gnu-hsw-1 tmp]$ gcc -S -O2 y.c
[hjl@gnu-hsw-1 tmp]$ cat y.s
.file"y.c"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
movq%rsp, buf(%rip)
movq$.L2, buf+8(%rip)
movq%rsp, buf+16(%rip)
ret
.L2:
.L4:
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB1:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movqbuf+8(%rip), %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
movqbuf(%rip), %rbp
movqbuf+16(%rip), %rsp
jmp*%rax
.cfi_endproc
.LFE1:
.sizebar, .-bar

__builtin_longjmp/setjmp only save/restore BP, SP and PC on
x86, x32 and x86-64.

[Bug middle-end/59037] [4.8/4.9 Regression] ICE when accessing invalid element (nelts + 1) of vector

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||4.7.3
   Target Milestone|--- |4.8.3
Summary|ICE when accessing invalid  |[4.8/4.9 Regression] ICE
   |element (nelts + 1) of  |when accessing invalid
   |vector  |element (nelts + 1) of
   ||vector
  Known to fail||4.8.0, 4.8.2, 4.9.0

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
  Component|other   |c

--- Comment #4 from Richard Biener  ---
Ah, those are the builtins used for SJLJ and they get lowered to
setjmp_setup,dispatcher and longjmp.

Don't use __builtin_setjmp as I said, use setjmp.

I suppose these shouldn't have been made callable by user code?  Eric?

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #5 from Richard Biener  ---
But it seems cilk depends on implementation details of setjmp/longjmp which
looks bogus anyway.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #6 from H.J. Lu  ---
(In reply to Richard Biener from comment #4)
> Ah, those are the builtins used for SJLJ and they get lowered to
> setjmp_setup,dispatcher and longjmp.
> 
> Don't use __builtin_setjmp as I said, use setjmp.
> 
> I suppose these shouldn't have been made callable by user code?  Eric?

There are a few run-time testcases in gcc/testsuite, which
indicates that they work in user code and may have some
limitations.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #7 from Eric Botcazou  ---
> Ah, those are the builtins used for SJLJ and they get lowered to
> setjmp_setup,dispatcher and longjmp.

Right, they are the efficient version of setjmp/longjmp.

> I suppose these shouldn't have been made callable by user code?  Eric?

Yes, but it's probably too late to change that.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #8 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #7)
> > Ah, those are the builtins used for SJLJ and they get lowered to
> > setjmp_setup,dispatcher and longjmp.
> 
> Right, they are the efficient version of setjmp/longjmp.
>  

What restrictions do they have? Can they be used within the
same function? Can they be used within functions with parameters?

[Bug rtl-optimization/59036] [4.9 regression] Performance degradation after r204212 on 32-bit x86 targets.

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036

--- Comment #2 from Vladimir Makarov  ---
(In reply to Yuri Rumyantsev from comment #0)
> After patch to improve register preferencing in IRA and to *remove regmove*
> pass we noticed performance degradation on several benchmarks from eembc2.0
> suite in 32-bit mode for all x86 targets (such as atom, slm, hsw, etc.).
> This can be reproduced with attached test-case - after fix 3 more
> instructions are generated for innermost loop (compiled with -O2 -m32
> -march=core-avx2 options):
> 

I am just curious what is the overall score change?  Are there only performance
degradations?  Was something improved?

In general would you prefer to reverse this patch?  Because I am affraid, it
will be only solution for the PR.

I am asking this because very frequently heuristic based optimizations generate
something better and something worse.  That is their nature.

When I worked on this optimization I had to change about 15 tests from GCC
testsuites checking AVX and found that in every tests uneccessary register
shuffling moves were deleted after applying the patch.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #9 from Eric Botcazou  ---
> What restrictions do they have? Can they be used within the
> same function? Can they be used within functions with parameters?

The only restriction I know of is that they cannot be in the same function,
it's even enforced by the inliner:

  case BUILT_IN_LONGJMP:
/* We can't inline functions that call __builtin_longjmp at
   all.  The non-local goto machinery really requires the
   destination be in a different function.  If we allow the
   function calling __builtin_longjmp to be inlined into the
   function calling __builtin_setjmp, Things will Go Awry.  */
inline_forbidden_reason
  = G_("function %q+F can never be inlined because "
   "it uses setjmp-longjmp exception handling");

[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025

--- Comment #4 from Peter Bergner  ---
Pat was working on that.  He reported to me that he had gone through compiling
each file with the "bad" options and did not hit the error, so it seems it is
an interaction between multiple files and he was in the process of trying to
determine which set of files are buggy.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #10 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #9)
> > What restrictions do they have? Can they be used within the
> > same function? Can they be used within functions with parameters?
> 
> The only restriction I know of is that they cannot be in the same function,
> it's even enforced by the inliner:
> 
> case BUILT_IN_LONGJMP:
>   /* We can't inline functions that call __builtin_longjmp at
>  all.  The non-local goto machinery really requires the
>  destination be in a different function.  If we allow the
>  function calling __builtin_longjmp to be inlined into the
>  function calling __builtin_setjmp, Things will Go Awry.  */
>   inline_forbidden_reason
> = G_("function %q+F can never be inlined because "
>  "it uses setjmp-longjmp exception handling");

But gcc doesn't issue anything for this testcase:

[hjl@gnu-hsw-1 tmp]$ cat z.c
#include 

extern jmp_buf buf;

int
foo (int i)
{
  int j = i + 1;
  if (__builtin_setjmp (buf))
{
  j += 1;
  __builtin_longjmp (buf, 1);
}

  return j + i;
}
[hjl@gnu-hsw-1 tmp]$ gcc -S -O2 z.c -Wall
[hjl@gnu-hsw-1 tmp]$ 

For this testcase:

[hjl@gnu-hsw-1 tmp]$ cat i.c
#include 

extern jmp_buf buf;

int
foo (int i)
{
  int j = i + 1;
  if (!__builtin_setjmp (buf))
{
  j += 1;
}

  return j + i;
}
[hjl@gnu-hsw-1 tmp]$ gcc -O2 -S i.c
[hjl@gnu-hsw-1 tmp]$ cat i.s
.file"i.c"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
.L4:
.L2:
movq%rsp, buf(%rip)
movq$.L2, buf+8(%rip)
leal2(%rdi,%rdi), %eax
movq%rsp, buf+16(%rip)
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo

%rdi holds the function parameter 'i'.  But when __builtin_longjmp is
called, %rdi can have some random value.  GCC doesn't save %rdi first.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #11 from Andreas Schwab  ---
In the latter testcase foo doesn't call a function so there is never a need to
save anything.

[Bug target/59041] New: [4.8/4.9 Regression] Unnecessary vzeroupper generated

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59041

Bug ID: 59041
   Summary: [4.8/4.9 Regression] Unnecessary vzeroupper generated
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com

[hjl@gnu-6 gcc]$ cat /tmp/j.cc
#include 

extern jmp_buf buf;

struct xxx
{
  int foo ();
  int i;
};

static void __attribute__((noinline))
bar (jmp_buf buf)
{
  __builtin_longjmp (buf, 1);
}

int
xxx::foo ()
{
  int j = i + 1;
  if (!__builtin_setjmp (buf))
{
  j += 1;
  bar (buf);
}

  return j + i;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -mavx /tmp/j.cc
[hjl@gnu-6 gcc]$ cat j.s
.file"j.cc"
.section.text.unlikely,"ax",@progbits
.type_ZL3barP13__jmp_buf_tag.constprop.0, @function
_ZL3barP13__jmp_buf_tag.constprop.0:
.LFB2:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movqbuf+8(%rip), %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
movqbuf(%rip), %rbp
movqbuf+16(%rip), %rsp
jmp*%rax
.cfi_endproc
.LFE2:
.size_ZL3barP13__jmp_buf_tag.constprop.0,
.-_ZL3barP13__jmp_buf_tag.constprop.0
.text
.align 2
.p2align 4,,15
.globl_ZN3xxx3fooEv
.type_ZN3xxx3fooEv, @function
_ZN3xxx3fooEv:
.LFB1:
.cfi_startproc
pushq%r15
.cfi_def_cfa_offset 16
.cfi_offset 15, -16
pushq%r14
.cfi_def_cfa_offset 24
.cfi_offset 14, -24
pushq%r13
.cfi_def_cfa_offset 32
.cfi_offset 13, -32
pushq%r12
.cfi_def_cfa_offset 40
.cfi_offset 12, -40
pushq%rbp
.cfi_def_cfa_offset 48
.cfi_offset 6, -48
pushq%rbx
.cfi_def_cfa_offset 56
.cfi_offset 3, -56
subq$16, %rsp
.cfi_def_cfa_offset 72
movl(%rdi), %eax
movq$.L4, buf+8(%rip)
leaq16(%rsp), %rcx
movq%rdi, 8(%rsp)
movq%rsp, buf+16(%rip)
addl$2, %eax
movq%rcx, buf(%rip)
movl%eax, 4(%rsp)
call_ZL3barP13__jmp_buf_tag.constprop.0
.L7:
.p2align 4,,10
.p2align 3
.L4:
movq8(%rsp), %rdx
movl4(%rsp), %eax
addl(%rdx), %eax
vzeroupper   Unnecessary vzeroupper
addq$16, %rsp
.cfi_def_cfa_offset 56
popq%rbx
.cfi_def_cfa_offset 48
popq%rbp
.cfi_def_cfa_offset 40
popq%r12
.cfi_def_cfa_offset 32
popq%r13
.cfi_def_cfa_offset 24
popq%r14
.cfi_def_cfa_offset 16
popq%r15
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size_ZN3xxx3fooEv, .-_ZN3xxx3fooEv
.ident"GCC: (GNU) 4.9.0 20131106 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$

[Bug target/59041] [4.8/4.9 Regression] Unnecessary vzeroupper generated

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59041

--- Comment #1 from Uroš Bizjak  ---
This one is not unnecessary, it is emitted on purpose from generic
mode-switching code:

-- gcc/mode-switching.c --

  /* Pretend the mode is clobbered across abnormal edges.  */
  {
edge_iterator ei;
edge e;
FOR_EACH_EDGE (e, ei, bb->preds)
  if (e->flags & EDGE_COMPLEX)
break;
if (e)
  {
ptr = new_seginfo (no_mode, BB_HEAD (bb), bb->index, live_now);
add_seginfo (info + bb->index, ptr);
bitmap_clear_bit (transp[bb->index], j);
  }
  }

It is true that 4.7 didn't emit vzeroupper here, but I think that generic code
is correct, and this is actually an improvement.

[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019

--- Comment #3 from Jeffrey A. Law  ---
OK, making a conditional no-return call into an unconditional no-return call
would have the same problem.  Ugh.

The problem I see where is we're going to have to run some kind of cleanup pass
after each RTL pass that might make these transformations (cse, gcse, cprop,
combine and I'm sure others).  That seems quite heavyweight and bad from a
compile-time standpoint.

But I don't really see a way out.  I guess I'm hoping you have other
suggestions for how we can fix this.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #12 from Eric Botcazou  ---
> %rdi holds the function parameter 'i'.  But when __builtin_longjmp is
> called, %rdi can have some random value.  GCC doesn't save %rdi first.

No, __builtin_longjmp doesn't touch %rdi at all.  Don't worry too much, the
SJLJ mechanism of the C++ and Ada compilers has been piggybacked on this for a
couple of decades, this is quite robust.

[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019

--- Comment #4 from Eric Botcazou  ---
> The problem I see where is we're going to have to run some kind of cleanup
> pass after each RTL pass that might make these transformations (cse, gcse,
> cprop, combine and I'm sure others).  That seems quite heavyweight and bad
> from a compile-time standpoint.
> 
> But I don't really see a way out.  I guess I'm hoping you have other
> suggestions for how we can fix this.

Maybe declare trap_if instructions unconditionally control-flow altering?  They
are probably quite rare in practice, so perhaps this wouldn't really pessimize.

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[marc.mutz at kdab dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

Marc Mutz  changed:

   What|Removed |Added

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

--- Comment #3 from Marc Mutz  ---
See code posted in http://llvm.org/bugs/show_bug.cgi?id=17834
is_unsigned fails, !is_signed succeeds. MouseButton is an enum.

[Bug target/59041] [4.8/4.9 Regression] Unnecessary vzeroupper generated

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59041

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Not a bug.

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

--- Comment #4 from Daniel Krügler  ---
(In reply to Marc Mutz from comment #3)
> See code posted in http://llvm.org/bugs/show_bug.cgi?id=17834
> is_unsigned fails, !is_signed succeeds. MouseButton is an enum.

The assertion of the following code is required to hold according to the C++
library specification:

//---
#include 

enum MouseButton {};

static_assert(!std::is_signed::value, "");
//---

MouseButton is no arithmetic type therefore std::is_signed is required to
return false. If you are interested in the sign character of either the
underlying type or the promoted type of MouseButton, you have to perform
different tests, such as

static_assert(!std::is_signed::type>::value,
"");
static_assert(std::is_signed::value, "");

(The first result is currently unspecified by the standard)

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #13 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #12)
> No, __builtin_longjmp doesn't touch %rdi at all.  Don't worry too much, the
> SJLJ mechanism of the C++ and Ada compilers has been piggybacked on this for
> a couple of decades, this is quite robust.

This is good to hear.  What is each field?  I assume that
the first 3 fields are frame address, resume address and
stack address.  Are the same for all targets?  What are
the maximum number of fields?

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Closing again.

[Bug libstdc++/59042] New: Declaration of back_insert_iterator::value_type is incorrect

[cdodd at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042

Bug ID: 59042
   Summary: Declaration of back_insert_iterator::value_type is
incorrect
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cdodd at acm dot org

The declaration of std::back_insert_iterator::value_type is incorrect in the
header file.  The following small test program should compile without errors or
warnings, demonstrating the problem:

#include 
#include 
#include 

template
void output(OutputIterator &&iter, typename OutputIterator::value_type val)
{
*iter++ = val;
}

int main()
{
std::vectorvec;
output(back_inserter(vec), 10);
std::cout << vec.size() << std::endl;
return 0;
}

The fix is quite trivial -- just fix the declaration in the header file:

--- libstdc++-v3/include/bits/stl_iterator.h-orig2013-11-07
10:11:54.99111 -0800
+++ libstdc++-v3/include/bits/stl_iterator.h2013-11-07 10:05:40.414571676
-0800
@@ -400,7 +400,7 @@
   */
   template
 class back_insert_iterator
-: public iterator
+: public iterator
 {
 protected:
   _Container* container;


There are probably other places in the library that have similar problems
(front_insert_iterator)

[Bug libstdc++/59042] Declaration of back_insert_iterator::value_type is incorrect

[cdodd at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042

--- Comment #1 from Chris Dodd  ---
The other type traits of back_insert_iterator should probably not be void, as
well.

[Bug libstdc++/59027] std::is_signed does not include check for is_arithmetic

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027

--- Comment #6 from Jonathan Wakely  ---
(In reply to Marc Mutz from comment #0)
> According to N3797 Table 49, both is_signed and is_unsigned should evaluate
> to true_type only if the argument is_arithmetic, too. is_unsigned honours
> this, but is_signed doesn't:

Your own code shows this statement to be false. is_signed is false for your
enumeration type, as required. is_unsigned is also false, as required.

The text in your assertion is wrong:
static_assert(!std::is_signed::value, "Enum should be unsigned");

It is not true that enums should be unsigned, the traits say enums are neither
signed nor unsigned, and that's what GCC does, as required:

#include 
enum MouseButton { };
static_assert(!std::is_signed::value,
  "Enum should be not be signed");
static_assert(!std::is_unsigned::value,
  "Enum should not be unsigned");

[Bug libstdc++/59042] Declaration of back_insert_iterator::value_type is incorrect

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042

--- Comment #3 from Jonathan Wakely  ---
And in [back.insert.iterator] the standard explicitly requires this:

template 
class back_insert_iterator :
public iterator{

[Bug tree-optimization/56764] vect_prune_runtime_alias_test_list not smart enough

[congh at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764

Cong Hou  changed:

   What|Removed |Added

 CC||congh at google dot com

--- Comment #2 from Cong Hou  ---
I have made a patch on this issue. However, I don't think the example here is
proper. Say z1 == &(x[0][4]) (assume VF=4). Then after unrolling the loop for 4
times, there is still no data dependence that prevents vectorization.

I think a better example is like the one shown below:



__attribute__((noinline, noclone)) void
foo (float x[3][32], float y1, float y2, float y3, float *z1, float *z2, float
*z3)
{
  int i;
  for (i = 0; i < 16; i++)
{
  z1[i] = -y1 * x[0][i*2];
  z2[i] = -y2 * x[1][i*2];
  z3[i] = -y3 * x[2][i*2];
}
}


Here we have to make sure z1/z2/z3 does not alias with x across the whole range
being traversed. Then we could merge the alias checks between z1 and
&x[0][0:32]/&x[1][0:32]/&x[2][0:32] into one.

[Bug libstdc++/59042] Declaration of back_insert_iterator::value_type is incorrect

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042

--- Comment #2 from Jonathan Wakely  ---
Your code is not valid, you should be using typename
iterator_traits::value_type

[Bug libstdc++/59042] Declaration of back_insert_iterator::value_type is incorrect

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59042

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
As far as I can tell we conform exactly to the standard, the program is
ill-formed, even with the iterator_traits change.

[Bug tree-optimization/56764] vect_prune_runtime_alias_test_list not smart enough

[congh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764

--- Comment #3 from congh at gcc dot gnu.org ---
Author: congh
Date: Thu Nov  7 19:29:45 2013
New Revision: 204538

URL: http://gcc.gnu.org/viewcvs?rev=204538&root=gcc&view=rev
Log:
2013-11-07  Cong Hou  

PR tree-optimization/56764
* tree-vect-loop-manip.c (vect_create_cond_for_alias_checks):
  Combine alias checks if it is possible to amortize the runtime
  overhead.  Return the number of alias checks after merging.
  * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list):
Use the function vect_create_cond_for_alias_checks () to check
the number of alias checks.

2013-11-07  Cong Hou  

* gcc.dg/vect/vect-alias-check.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-loop-manip.c
trunk/gcc/tree-vectorizer.h

[Bug middle-end/59037] [4.8/4.9 Regression] ICE when accessing invalid element (nelts + 1) of vector

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037

--- Comment #3 from Marc Glisse  ---
(In reply to Matthew Leach from comment #1)
> Having a quick dig around the code, I think fold-const.c:16718 looks
> suspicious:
> 
> if (offset/part_widthi <= TYPE_VECTOR_SUBPARTS (op00type))
> 
> Likewise in cp/semantics.c:9122 and gimple-fold.c:3407.
> 
> Should this "<=" be a "<"?

Looks similar to something I had found suspicious in PR 53101 (comment 5),
though apparently that was in gimplify.c.

[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #11 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #2 from Dominique d'Humieres  ---
Note that the tests pass on x86_64-apple-darwin10 for both -m32 and -m64.

[Bug testsuite/59043] New: [4.9 Regression] FAIL: (gcc|++).dg/pubtypes* scan-assembler long.*Length of Public Type Names Info

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59043

Bug ID: 59043
   Summary: [4.9 Regression] FAIL: (gcc|++).dg/pubtypes*
scan-assembler long.*Length of Public Type Names Info
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: howarth at bromo dot med.uc.edu, iains at gcc dot gnu.org,
sterling at gcc dot gnu.org
  Host: *-apple-darwin*
Target: *-apple-darwin*
 Build: *-apple-darwin*

On *-apple-darwin* the tests g++.dg/pubtypes.C and gcc.dg/pubtypes-*.c fail
after revision 203936 because the string "Length of Public Names Info" has been
changed to "Pub Info Length" without adjusting the tests for darwin. The
following patch fixes the failures:

--- ../_clean/gcc/testsuite/g++.dg/pubtypes.C2009-11-25 18:16:31.0
+0100
+++ gcc/testsuite/g++.dg/pubtypes.C2013-10-24 13:54:59.0 +0200
@@ -2,7 +2,7 @@
 /* { dg-do compile { target *-*-darwin* } } */
 /* { dg-options "-O0 -gdwarf-2 -dA -fno-eliminate-unused-debug-types" } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+\(0x\)?\[0-9a-f]+\[
\t\n\]+\[#;@]+\[ \t\]+Length of Public Type Names Info" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+\(0x\)?\[0-9a-f]+\[
\t\n\]+\[#;@]+\[ \t\]+Pub Info Length" } } */
 /* { dg-final { scan-assembler "\"empty0\"+\[ \t\]+\[#;@]+\[ \t\]+external
name" } } */
 /* { dg-final { scan-assembler "\"A0\"+\[ \t\]+\[#;@]+\[ \t\]+external
name" } } */
 /* { dg-final { scan-assembler "\"B0\"+\[ \t\]+\[#;@]+\[ \t\]+external
name" } } */

--- ../_clean/gcc/testsuite/gcc.dg/pubtypes-1.c2009-11-25
18:15:40.0 +0100
+++ gcc/testsuite/gcc.dg/pubtypes-1.c2013-10-24 13:52:37.0 +0200
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA -fno-eliminate-unused-debug-types" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x\[0-9a-f]+\[ \t\]+\[#;]+\[
\t\]+Length of Public Type Names Info" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x\[0-9a-f]+\[ \t\]+\[#;]+\[
\t\]+Pub Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler "unused_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */

--- ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c2012-06-26
20:42:19.0 +0200
+++ gcc/testsuite/gcc.dg/pubtypes-2.c2013-10-24 13:53:05.0 +0200
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[
\t\]+Length of Public Type Names Info" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */

--- ../_clean/gcc/testsuite/gcc.dg/pubtypes-3.c2012-06-26
20:42:19.0 +0200
+++ gcc/testsuite/gcc.dg/pubtypes-3.c2013-10-24 13:53:33.0 +0200
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[
\t\]+Length of Public Type Names Info" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "\"list_name_type0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
--- ../_clean/gcc/testsuite/gcc.dg/pubtypes-4.c2012-06-26
20:42:19.0 +0200
+++ gcc/testsuite/gcc.dg/pubtypes-4.c2013-10-24 13:53:53.0 +0200
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x172+\[ \t\]+\[#;]+\[
\t\]+Length of Public Type Names Info" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x172+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "unused_struc

[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from janus at gcc dot gnu.org ---
Hi Paul,

> Are you going to apply your fix?

yes. Thanks for reminding (I almost forgot about this one). Taking your comment
as an 'ok' and considering that the patch is completely trivial, I will commit
it to trunk soon (and 4.8 afterwards).

Cheers,
Janus

[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471

--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Nov  7 22:39:15 2013
New Revision: 204547

URL: http://gcc.gnu.org/viewcvs?rev=204547&root=gcc&view=rev
Log:
2013-11-07  Janus Weil  

PR fortran/58471
* primary.c (gfc_expr_attr): Check for result symbol.

2013-11-07  Janus Weil  

PR fortran/58471
* gfortran.dg/constructor_9.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/constructor_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #14 from Eric Botcazou  ---
> This is good to hear.  What is each field?  I assume that
> the first 3 fields are frame address, resume address and
> stack address.  Are the same for all targets?  What are
> the maximum number of fields?

Everything is in the manual I think, otherwise certainly in the sources.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039

--- Comment #15 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #14)
> > This is good to hear.  What is each field?  I assume that
> > the first 3 fields are frame address, resume address and
> > stack address.  Are the same for all targets?  What are
> > the maximum number of fields?
> 
> Everything is in the manual I think, otherwise certainly in the sources.

I couldn't find anything in GCC manual.

[Bug c++/59044] New: Internal compiler error triggers when accessing a typedef in a specialized member class

[decaluwe.t at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044

Bug ID: 59044
   Summary: Internal compiler error triggers when accessing a
typedef in a specialized member class
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: decaluwe.t at gmail dot com

Created attachment 31180
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31180&action=edit
Preprocessor output

The following code triggers an internal compiler error when compiled with 'g++
bug.cpp' (the complete preprocessed file can be found in the attachment):

/*  bug.cpp --- */
template 
class C {
private:
template 
struct Implementation;
template 
struct Implementation<0, b> { typedef void Typedef; };
public:
typedef typename Implementation<0, 0>::Typedef Type;
};

template class C;
/*  */

The error message produced by g++ 4.8.1 (as found in the g++-4.8 package in the
Ubuntu 13.10 repo, see below for build information):

bug.cpp: In instantiation of ‘class C’:
bug.cpp:12:16:   required from here
bug.cpp:9:52: internal compiler error: in tsubst, at cp/pt.c:11313
 typedef typename Implementation<0, 0>::Typedef Type;
^

This bug is still present in the gcc-snapshot package. However the code
compiles fine in g++ 4.7.3 (as found in the g++-4.7 package).

Additional information:

GCC version: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) 
System type: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu

[Bug tree-optimization/56764] vect_prune_runtime_alias_test_list not smart enough

[congh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764

--- Comment #4 from congh at gcc dot gnu.org ---
Author: congh
Date: Fri Nov  8 02:08:05 2013
New Revision: 204557

URL: http://gcc.gnu.org/viewcvs?rev=204557&root=gcc&view=rev
Log:
2013-11-07  Cong Hou  

Backport from mainline
2013-11-07  Cong Hou  

PR tree-optimization/56764
* tree-vect-loop-manip.c (vect_create_cond_for_alias_checks):
  Combine alias checks if it is possible to amortize the runtime
  overhead.  Return the number of alias checks after merging.
  * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list):
Use the function vect_create_cond_for_alias_checks () to check
the number of alias checks.

2013-11-07  Cong Hou  

Backport from mainline
2013-11-07  Cong Hou  

* gcc.dg/vect/vect-alias-check.c: New.


Added:
branches/google/gcc-4_8/gcc/testsuite/gcc.dg/vect/vect-alias-check.c
Modified:
branches/google/gcc-4_8/gcc/ChangeLog
branches/google/gcc-4_8/gcc/testsuite/ChangeLog
branches/google/gcc-4_8/gcc/tree-vect-data-refs.c
branches/google/gcc-4_8/gcc/tree-vect-loop-manip.c
branches/google/gcc-4_8/gcc/tree-vectorizer.h

[Bug c++/18969] Invalid return statement diagnosed too late

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18969

--- Comment #3 from Manuel López-Ibáñez  ---
It works in clang:

test.cc:3:16: error: void function 'foo' should not return a value
[-Wreturn-type]
  void foo() { return 0; }
   ^  ~

[Bug c++/18969] Invalid return statement diagnosed too late

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18969

--- Comment #4 from Manuel López-Ibáñez  ---
Breakpoint 5, check_return_expr (retval=,
no_warning=0x7fffdf2f) at /home/manuel/test1/src/gcc/cp/typeck.c:8311

B =>if (processing_template_decl)
  {
current_function_returns_value = 1;
if (check_for_bare_parameter_packs (retval))
  retval = error_mark_node;
return retval;
  }

processing_template_decl is a big hammer here. We only should care about the
return type of the function or the type of the thing being returned. If those
are not dependent, then we should just give diagnostics. But we also need a way
to not repeat the diagnostics when instantiated.

It doesn't seem trivial to me.

[Bug middle-end/48110] __attribute__ ((optimize(...))) version of -Ofast

[mingjie.xing at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110

Mingjie Xing  changed:

   What|Removed |Added

 CC||mingjie.xing at gmail dot com

--- Comment #1 from Mingjie Xing  ---
The document says, "Numbers are assumed to be an optimization level. Strings
that begin with O are assumed to be an optimization option, while other options
are assumed to be used with a -f prefix."

So, it should be __attribute__ ((optimize("Ofast"))).