[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Ryan Mansfield from comment #18)
> (In reply to Jakub Jelinek from comment #17)
> > Can I ask for preprocessed source + options again?
> 
> $ cat ~/conftest.c
> void bar ();
> void clean (int *);
> void foo ()
> {
>   int i __attribute__ ((cleanup (clean)));
>   bar();  
> }
> 
> ryan@zoidberg:~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -B. -fexceptions
> ~/conftest.c 
> /home/ryan/conftest.c: In function 'foo':
> /home/ryan/conftest.c:7:1: internal compiler error: Segmentation fault
>  }
>  ^
> 0x95cbcf crash_signal
>   ../../gcc/toplev.c:337
> 0xbef5a6 arm_unwind_emit_sequence
>   ../../gcc/config/arm/arm.c:28729
> 0xbef5a6 arm_unwind_emit
>   ../../gcc/config/arm/arm.c:28970
> 0x708ede final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
>   ../../gcc/final.c:2978
> 0x709885 final(rtx_def*, _IO_FILE*, int)
>   ../../gcc/final.c:2024
> 0x709ca9 rest_of_handle_final
>   ../../gcc/final.c:4438
> 0x709ca9 execute
>   ../../gcc/final.c:4513
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

Sorry, can't reproduce.  Can you run it in the debugger
p debug_rtx (p)
up
p debug_rtx (insn)
?

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[kcc at gcc dot gnu.org]

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

--- Comment #58 from Kostya Serebryany  ---
FTR, here are the new numbers; except for 464.h264ref looks good.
clang r199888, gcc r207025
flags: -O2 -fsanitize=address
machine: Dell 3500 (Intel(R) Xeon(R) CPU W3690  @ 3.47GHz)

   clang  gccdiff
   400.perlbench,  1286.00,-1.00,-0.00
   401.bzip2,   857.00,   940.00, 1.10
 403.gcc,   621.00,   606.00, 0.98
 429.mcf,   578.00,   574.00, 0.99
   445.gobmk,   860.00,   850.00, 0.99
   456.hmmer,   880.00,  1149.00, 1.31
   458.sjeng,   992.00,   996.00, 1.00
  462.libquantum,   492.00,   483.00, 0.98
 464.h264ref,  1274.00,  3998.00, 3.14
 471.omnetpp,   566.00,   569.00, 1.01
   473.astar,   661.00,   647.00, 0.98
   483.xalancbmk,   478.00,   491.00, 1.03
433.milc,   620.00,   611.00, 0.99
444.namd,   601.00,   528.00, 0.88
  447.dealII,   624.00,   670.00, 1.07
  450.soplex,   366.00,   389.00, 1.06
  453.povray,   430.00,   374.00, 0.87
 470.lbm,   355.00,   452.00, 1.27
 482.sphinx3,   926.00,  1108.00, 1.20

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #59 from Markus Trippelsdorf  ---
(In reply to Kostya Serebryany from comment #58)
> FTR, here are the new numbers; except for 464.h264ref looks good.

Thanks. Lets close this bug then.

[Bug target/59952] -march=core-avx2 should not enable RTM

[thiago at kde dot org]

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

--- Comment #2 from Thiago Macieira  ---
The Ks and the Rs don't have it. The plain 4770 as well as 4770S do have it. I
guess we were too eager with TSX when the announcement came out 2 years ago: it
sounded like all Haswell would have it.

I don't see a #define for HLE, so that's probably fine to leave XACQUIRE and
XRELEASE generation enabled, though. Just make sure there are no uses of the
XTEST instruction unless RTM is also enabled or the CPU check was performed.

[Bug target/59952] -march=core-avx2 should not enable RTM

[mikpelinux at gmail dot com]

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

--- Comment #3 from Mikael Pettersson  ---
There are also Haswells that lack BMI2.  I updated our dynamic binary
instrumentation engine for AVX2 about a year ago, but while our Haswell box at
the time had AVX2 it didn't have BMI2 etc, causing Intel's MKL to refuse to
enter it AVX2 code paths.  So testing had to be limited to small assembly-coded
kernels.

[Bug c/59953] New: Improve the warning message for unsigned_expression >= 0UL

[chengniansun at gmail dot com]

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

Bug ID: 59953
   Summary: Improve the warning message for unsigned_expression >=
0UL
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

-Wtype-limits emits different messages for "unsigned_expression >= 0" and
"unsigned_expression >= 0UL". It would be nice if you could make the messages
more consistent. Moreover, the warning message for  "unsigned_expression >= 0"
is more informative than the other. 



$: cat type-limit-improve.c
extern unsigned g();
void f(unsigned u, unsigned long ul) {
  int b = g() >= 0;
  int c = g() >= 0UL;
}
$: gcc-trunk -c -Wtype-limits type-limit-improve.c
type-limit-improve.c: In function ‘f’:
type-limit-improve.c:3:12: warning: comparison of unsigned expression >= 0 is
always true [-Wtype-limits]
   int b = g() >= 0;
^
type-limit-improve.c:4:12: warning: comparison is always true due to limited
range of data type [-Wtype-limits]
   int c = g() >= 0UL;
^
$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/chengniansun/tools/gcc-trunk-binaries/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --prefix=/home/chengniansun/tools/gcc-trunk-binaries :
(reconfigured) ../gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --prefix=/home/chengniansun/tools/gcc-trunk-binaries
Thread model: posix
gcc version 4.9.0 20140123 (experimental) (GCC)

[Bug c++/59954] New: ice in execute with -Wall

[dcb314 at hotmail dot com]

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

Bug ID: 59954
   Summary: ice in execute with -Wall
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 31959
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31959&action=edit
C++ source code

I just compiled the attached code with gcc trunk dated 20140126 on a x86_64
box with flag -Wall and it said

g++: internal compiler error: Segmentation fault (program cc1plus)
0x40d21e execute
../../src/trunk/gcc/gcc.c:2841
0x40d499 do_spec_1
../../src/trunk/gcc/gcc.c:4641
0x410221 process_brace_body
../../src/trunk/gcc/gcc.c:5924
0x410221 handle_braces
../../src/trunk/gcc/gcc.c:5838
0x40dc22 do_spec_1
../../src/trunk/gcc/gcc.c:5295
0x410221 process_brace_body
../../src/trunk/gcc/gcc.c:5924
0x410221 handle_braces
../../src/trunk/gcc/gcc.c:5838
0x40dc22 do_spec_1
../../src/trunk/gcc/gcc.c:5295

[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap

[kcc at gcc dot gnu.org]

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

Kostya Serebryany  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |kcc at gcc dot gnu.org
   Target Milestone|4.9.0   |---

--- Comment #24 from Kostya Serebryany  ---
I increased the mmap granularity in sanitizer's allocator to 
allow our bot on ubuntu pre-14.04 to pass.
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_allocator.h?r1=200197&r2=200196&pathrev=200197
Feel free to apply the same change to GCC trunk. 

Once the kernel bug is fixed and the fix reaches ubuntu 14.04 tree 
we will likely revert this change. 
There is nothing else we can do on sanitizer side -- the kernel bug 
is significant (e.g. it makes gimp crash) and so such system is unusable
for many other purposes. 

Let's keep this bug open so that we don't forget to revert the workaround.

FTR, here is a program that detects the presence of a broken kernel:

#include 
#include 
#include 
#include 
#include 
int main() {
  char *p = (char*)0x6000;
  size_t i;
  for (i = 0; i < 10; i++) {
void *addr = p + i * 4096;
void *ret = mmap(addr, 4096, PROT_WRITE | PROT_READ,
 MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
if (addr != ret) {
  fprintf(stderr, "failed at iteration %zd\n", i);
  char command[100];
  snprintf(command, sizeof(command), "cat /proc/%d/maps | head -30",
getpid());
  system(command);
  return 1;
}
  }
}


On a broken kernel it will print something like this:

failed at iteration 65514
0040-00401000 r-xp  fc:00 20991316  /tmp/a.out
0060-00601000 r--p  fc:00 20991316  /tmp/a.out
00601000-00602000 rw-p 1000 fc:00 20991316  /tmp/a.out
6000-60001000 rw-p  00:00 0 
60001000-60002000 rw-p  00:00 0 
60002000-60003000 rw-p  00:00 0 
60003000-60004000 rw-p  00:00 0 
60004000-60005000 rw-p  00:00 0 
...

[Bug c++/59954] ice in execute with -Wall

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-27
 CC||dodji at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I think this is due to latest input.c changes.

[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from Jakub Jelinek  ---
*** Bug 59954 has been marked as a duplicate of this bug. ***

[Bug c++/59954] ice in execute with -Wall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jakub Jelinek  ---
IMHO a dup.

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

[Bug libstdc++/59529] fix experimental/string_view end-of-string edge cases

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

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

[Bug libstdc++/59530] Incorrect check on string_view operator[]

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

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

[Bug libstdc++/59531] string_view overrun in copy operation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

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

[Bug bootstrap/59951] bootstrap comparison failure with -O3 for a week

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce with current trunk:
../configure --enable-checking=yes --enable-languages=c,c++,fortran \
--disable-werror
BOOT_CFLAGS="-g -O3" make -j48
went past make compare just fine here (x86_64-linux).

[Bug c++/59955] New: G++ 4.8 internal compiler error: Segmentation fault on (re?)defining a struct template as function template, when inside a struct tempate

[wouter at voti dot nl]

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

Bug ID: 59955
   Summary: G++ 4.8 internal compiler error: Segmentation fault on
(re?)defining a struct template as function template,
when inside a struct tempate
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wouter at voti dot nl

Created attachment 31960
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31960&action=edit
then offending source file

The following code gives an 
   internal compiler error: Segmentation fault

template< int xyz >
struct wovo {

   template< int n >
   void us(){}

   template< int n >
   struct us< n > {};
};

using G++ 4.8 cross-compiler for ARM, running on Windows

"C:/Program Files (x86)/GNU Tools ARM Embedded/4.8
2013q4/bin/arm-none-eabi-g++" -fno-builtin -nostartfiles -fno-exceptions 
-mcpu=cortex-m0 -mthumb -fomit-frame-pointer -fno-threadsafe-statics
-fno-use-cxa-get-exception-ptr -I. -Ic:/bmptk/bmptk/bmptk/bmptk  -Ichips 
-Itargets -Ic:/bmptk/bmptk/bmptk/bmptk/stdlib
-Ic:/bmptk/bmptk/bmptk/bmptk/targets/cortex/cmsis
-Ic:/bmptk/bmptk/bmptk/bmptk/targets/cortex
-Ic:/bmptk/bmptk/bmptk/bmptk/targets/cortex/cmsis/11xx/inc -DLANGUAGE_CPP   
-DBMPTK_EMBEDDED_HEAP -DBMPTK_TARGET=db103 -DBMPTK_TARGET_db103
-DBMPTK_CHIP=lpc1114fn28 -DBMPTK_CHIP_lpc1114fn28 -DBMPTK_XTAL=1200
-DBMPTK_BAUDRATE=38400 -DBMPTK_VERSION=V02.00-work-in-progress-2013-11-11
-DBMPTK_TICKS_PER_US=6 -DBMPTK_GRAPHICS -Ic:/bmptk/bmptk/bmptk/bmptk  -Werror 
-fno-rtti -fno-exceptions  -std=c++11 -Wall  -Wno-unused-local-typedefs
-Wno-unused-function -fdata-sections -ffunction-sections -Os  -c -o main.o
main.cpp

[Bug c++/59955] G++ 4.8 internal compiler error: Segmentation fault on (re?)defining a struct template as function template, when inside a struct tempate

[wouter at voti dot nl]

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

Wouter van Ooijen  changed:

   What|Removed |Added

 Target||ARM
   Host||windows
Version|unknown |4.8.3

--- Comment #1 from Wouter van Ooijen  ---
-v retrun:

Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
Target: arm-none-eabi
Configured with: /home/build/work/GCC-4-8-build/src/gcc/configure
--build=i686-linux-gnu --host=i586-mingw32 --target=arm-none-eabi
--prefix=/home/build/work/GCC-4-8-build/install-mingw
--libexecdir=/home/build/work/GCC-4-8-build/install-mingw/lib
--infodir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/info
--mandir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/man
--htmldir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/html
--pdfdir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --disable-decimal-float --disable-libffi
--disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads
--disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib
--with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/home/build/work/GCC-4-8-build/install-mingw/arm-none-eabi
--with-libiconv-prefix=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-gmp=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-mpfr=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-mpc=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-isl=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-cloog=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-libelf=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Tools for ARM Embedded Processors'
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
(GNU Tools for ARM Embedded Processors)

[Bug c++/59916] [4.9 Regression] constructors and destructors can cause "control reaches end of non-void function" warnings with -Os

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  ---
Richard, is this a front-end issue?

Status on c++ bug 27557

[Matthew Krafczyk]

Hi, I'm trying to find out information on the current state of bug
27557 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557)

I've currently had not response from people monitoring the bugzilla.

Basically I'd like to know what still needs to be done to fix this
bug, since it is directly affecting me.

Thanks for any help.

[Bug c++/51219] [4.7/4.8/4.9 regression] ICE with empty bit-fields

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/37140] type inherited from base class not recognized

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from fabien at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #9)
> Fabien, any news on this - now that we are in Stage 3?

I have successfuly tested a patch, but wait a moment, I need to refine it a
bit.

[Bug c++/59956] New: internal compiler error: unexpected expression ‘P_S’ of kind template_parm_index

[chretien at lirmm dot fr]

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

Bug ID: 59956
   Summary: internal compiler error: unexpected expression ‘P_S’
of kind template_parm_index
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chretien at lirmm dot fr

Created attachment 31961
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31961&action=edit
repro code

I get the following internal compiler error with g++ 4.8.2 and the attached
repro code:

gcc_ice.cpp: In instantiation of ‘class Foo’:
gcc_ice.cpp:35:28:   required from here
gcc_ice.cpp:28:17: internal compiler error: unexpected expression ‘P_S’ of kind
template_parm_index
  friend void Bar::impl (const Foo& poly);
  ^

This was tested on Arch Linux (x86_64).

$ g++ --version
g++ (GCC) 4.8.2 20131219 (prerelease)

[Bug c/59957] New: ICE in read_line_num when re-#define-ing a -DVAR=...

[burnus at gcc dot gnu.org]

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

Bug ID: 59957
   Summary: ICE in read_line_num when re-#define-ing a -DVAR=...
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

Running

  gcc -c -DNDEBUG=1 test.c

on the following code will give an ICE:

  #ifndef DEBUG
  #define NDEBUG  /* Re-define NDEBUG - should warn but not ICE  */
  #endif
  #include 


will give an ICE with 4.9:


0xfa2248 read_line_num
../../gcc/input.c:603
0xfa2248 location_get_source_line(expanded_location, int*)
../../gcc/input.c:702
0xf9cf4b diagnostic_show_locus(diagnostic_context*, diagnostic_info const*)
../../gcc/diagnostic.c:304
0xf9df8b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:800
0x635024 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char
const*, __va_list_tag (*) [1])
../../gcc/c-family/c-common.c:9639
0xfac796 cpp_error_with_line(cpp_reader*, int, unsigned int, unsigned int, char
const*, ...)
../../libcpp/errors.c:163
0xfbc7ef _cpp_create_definition
../../libcpp/macro.c:3124

[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap

[kcc at gcc dot gnu.org]

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

Kostya Serebryany  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #25 from Kostya Serebryany  ---
Even with this workaround asan is almost unusable with the buggy kernel.
I suspect that when a process has too many mappings it gets too slow.
The machine where we have our clang-asan bootstrap gets very slow and
unreliable.

We have reverted the kernel on that bot 
(http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/)
and reverted the above workaround in llvm trunk.
http://llvm.org/viewvc/llvm-project?rev=200217&view=rev

The kernel fix went into Linus's tree for 3.14 last week,
and was tagged for stable backport. Nothing else we could do here.

[Bug c++/59956] internal compiler error: unexpected expression ‘P_S’ of kind template_parm_index

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-27
 CC||trippels at gcc dot gnu.org
   Target Milestone|--- |4.8.3
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.0

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

markus@x4 tmp % cat test.ii
template  struct A;
template  class B {
  template  friend void A::impl();
};
B<0> a;

markus@x4 tmp % g++ test.ii
test.ii: In instantiation of ‘class B<0>’:
test.ii:5:6:   required from here
test.ii:3:34: internal compiler error: unexpected expression ‘A_S’ of kind
template_parm_index
   template  friend void A::impl();
  ^
0x6e2af5 cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9784
0x6e5875 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:9804
0x6e854b maybe_constant_value(tree_node*)
../../gcc/gcc/cp/semantics.c:9914
0x5c6512 convert_nontype_argument
../../gcc/gcc/cp/pt.c:5671
0x5c6512 convert_template_argument
../../gcc/gcc/cp/pt.c:6477
0x5be4a0 coerce_template_parms
../../gcc/gcc/cp/pt.c:6851
0x5c8369 lookup_template_class_1
../../gcc/gcc/cp/pt.c:7422
0x5c8369 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:7720
0x5cdb73 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10023
0x5d2705 tsubst_decl
../../gcc/gcc/cp/pt.c:10401
0x5c025f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11349
0x5eed53 tsubst_friend_function
../../gcc/gcc/cp/pt.c:8211
0x5eed53 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9176
0x5eed53 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9262
0x680473 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:134
0x569418 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4719
0x5922c7 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4682
0x66c6fe cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16710
0x66e189 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11217
0x651463 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11098
Please submit a full bug report,

[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
(In reply to Kostya Serebryany from comment #25)
> Even with this workaround asan is almost unusable with the buggy kernel.
> I suspect that when a process has too many mappings it gets too slow.
> The machine where we have our clang-asan bootstrap gets very slow and
> unreliable.
> 
> We have reverted the kernel on that bot 
> (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/)
> and reverted the above workaround in llvm trunk.
> http://llvm.org/viewvc/llvm-project?rev=200217&view=rev
> 
> The kernel fix went into Linus's tree for 3.14 last week,
> and was tagged for stable backport. Nothing else we could do here.

Yeah, except perhaps putting your #c24 testcase into the kernel bug as comment
for others to have quicker test than gimp, and perhaps filing bugs in distro
bugzillas to have this fixed there quicker, best mentioning that testcase.
Though, for a portable testcase that:
  char *p = (char*)0x6000;
is clearly undesirable, you probably just want to mmap with NULL base address,
perhaps with PROT_NONE, a .5GB region, then munmap it and use the result as p
(if that hasn't failed).

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #6)
> Somewhat reminds me of PR 58007.

Unfortunately r207119 does not seem to fix it on the 4.7 branch. Apparently
it's a different problem after all ...

[Bug c/59958] New: alpha does not deal with non-aligned returns from malloc() when doing byte wise access

[martin at netbsd dot org]

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

Bug ID: 59958
   Summary: alpha does not deal with non-aligned returns from
malloc() when doing byte wise access
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org

Created attachment 31962
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31962&action=edit
generated assembler code (cc -O2 -S test.c)

On NetBSD/alpha a call to malloc requesting a two byte allocation may return a
pointer that is only 2-byte algined. We believe this to be within the C std
spec (as alignemnt is good enough for all complete objects fitting in the
allocated space).

However, gcc seems to assume return values from malloc to have higher
alignment.

This test program:

--8<--
#include 
#include 

int main(int argc, char **argv)
{
char *p;
size_t i;

for (i = 0; i < 24; i++) {
p = malloc(2);
printf("got %p\n", p);
p[0] = 'A'; p[1] = 0;
printf("stored string: %s\n", p);
}

return 0;
}
-->8--

shows the problem:

[..]
got 0x3fffdc02238
stored string: A
got 0x3fffdc0223a
pid 600 (a.out): unaligned access: va=0x3fffdc0223a pc=0x12bc4
ra=0x12bbc sp=0x1db08 op=ldl
pid 600 (a.out): unaligned access: va=0x3fffdc0223a pc=0x12be4
ra=0x12bbc sp=0x1db08 op=stl
stored string: A
got 0x3fffdc0223c
stored string: A
got 0x3fffdc0223e
pid 600 (a.out): unaligned access: va=0x3fffdc0223e pc=0x12bc4
ra=0x12bbc sp=0x1db08 op=ldl
pid 600 (a.out): unaligned access: va=0x3fffdc0223e pc=0x12be4
ra=0x12bbc sp=0x1db08 op=stl
stored string: A
got 0x3fffdc02240
[..]


This might be more of a problem with target alpha and the byte access code,
compiling the test program with -mbwx does help (but not all alpha CPUs support
that).

gcc version used:

> cc -v
Using built-in specs.
COLLECT_GCC=cc
Target: alpha--netbsd
Configured with: /usr/src7/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=alpha--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit
--with-mpc-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/mpc/lib/libmpc
--with-mpfr-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/mpfr/lib/libmpfr
--with-gmp-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/gmp/lib/libgmp
--with-mpc-include=/usr/src7/external/lgpl3/mpc/dist/src
--with-mpfr-include=/usr/src7/external/lgpl3/mpfr/dist/src
--with-gmp-include=/usr/src7/external/lgpl3/gmp/lib/libgmp/arch/alpha
--enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0. --host=alpha--netbsd
--with-sysroot=/var/obj/mknative/alpha/usr/src7/destdir.alpha
Thread model: posix
gcc version 4.8.3 (NetBSD nb1 20131213)

[Bug c/59957] libcpp: ICE in read_line_num when re-#define-ing a -DVAR=...

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|ICE in read_line_num when   |libcpp: ICE in
   |re-#define-ing a -DVAR=...  |read_line_num when
   ||re-#define-ing a -DVAR=...

--- Comment #1 from Tobias Burnus  ---
The asset in read_line_num is:
   gcc_assert (line_num > 0);

The caller is libcpp/macro.c's:

  if (warned && node->type == NT_MACRO && !(node->flags &
NODE_BUILTIN))
cpp_error_with_line (pfile, CPP_DL_NOTE,
 node->value.macro->line, 0,
 "this is the location of the previous definition");

where node->value.macro->line == 3 - that only gets converted into line 0 via
gcc/input.c's expand_location_to_spelling_point.

[Bug c/59957] libcpp: ICE in read_line_num when re-#define-ing a -DVAR=...

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Almost certainly a dup.

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

[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #8 from Marek Polacek  ---
*** Bug 59957 has been marked as a duplicate of this bug. ***

[Bug gcov-profile/58602] .gcno files not truncated at gcov_close

[laurent.alfonsi at st dot com]

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

--- Comment #8 from Laurent Aflonsi  ---
  Jeffrey,

As you asked for, I have performed much more testing on that fix.
I am far from having done as many tests as Jakub in 2004. In particular, I have
not been able to test on ppc/iaxx, because i don't have any available.

I have performed a profiledbootstrap in a loop all over the weekend on my
x86_64 with parallelized builds (-j 4, -j 5, ... -j 12). which represents 80
builds using various parallel schedules. All of them have finished
successfully. I have not observed any instabilities.
It has been also regtested gcc/g+/libstdc++, 7 times in a row without any
failure.

Thanks
Laurent

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Jan 27 13:57:39 2014
New Revision: 207129

URL: http://gcc.gnu.org/viewcvs?rev=207129&root=gcc&view=rev
Log:
Core DR 475
PR c++/41174
PR c++/59224
* libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions.
* libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception)
(__cxa_allocate_exception): Don't set it here.

Added:
trunk/gcc/testsuite/g++.dg/eh/uncaught4.C
Modified:
trunk/gcc/testsuite/g++.dg/eh/uncaught1.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_alloc.cc
trunk/libstdc++-v3/libsupc++/eh_throw.cc

[Bug libstdc++/41174] uncaught_exception always returns true

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Mon Jan 27 13:57:39 2014
New Revision: 207129

URL: http://gcc.gnu.org/viewcvs?rev=207129&root=gcc&view=rev
Log:
Core DR 475
PR c++/41174
PR c++/59224
* libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions.
* libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception)
(__cxa_allocate_exception): Don't set it here.

Added:
trunk/gcc/testsuite/g++.dg/eh/uncaught4.C
Modified:
trunk/gcc/testsuite/g++.dg/eh/uncaught1.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_alloc.cc
trunk/libstdc++-v3/libsupc++/eh_throw.cc

[Bug c++/58965] [4.8/4.9 Regression] [c++11] ICE with member initializer in static union

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Jan 27 13:58:42 2014
New Revision: 207130

URL: http://gcc.gnu.org/viewcvs?rev=207130&root=gcc&view=rev
Log:
PR c++/58965
* mangle.c (write_guarded_var_name): Handle null DECL_NAME.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/nsdmi-union3.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/mangle.c

[Bug libstdc++/41174] uncaught_exception always returns true

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
Author: jason
Date: Mon Jan 27 13:58:48 2014
New Revision: 207131

URL: http://gcc.gnu.org/viewcvs?rev=207131&root=gcc&view=rev
Log:
Core DR 475
PR c++/41174
PR c++/59224
* libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions.
* libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception)
(__cxa_allocate_exception): Don't set it here.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/eh/uncaught4.C
Modified:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/eh/uncaught1.C
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_alloc.cc
branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_throw.cc

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Jan 27 13:58:48 2014
New Revision: 207131

URL: http://gcc.gnu.org/viewcvs?rev=207131&root=gcc&view=rev
Log:
Core DR 475
PR c++/41174
PR c++/59224
* libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions.
* libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception)
(__cxa_allocate_exception): Don't set it here.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/eh/uncaught4.C
Modified:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/eh/uncaught1.C
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_alloc.cc
branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_throw.cc

[Bug c++/58965] [4.8/4.9 Regression] [c++11] ICE with member initializer in static union

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 4.8.3/4.9.

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.7.4   |4.8.3

--- Comment #5 from Jason Merrill  ---
Fixed for 4.8.3/4.9.  Not fixing on 4.7 branch.

[Bug libstdc++/41174] uncaught_exception always returns true

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.3

--- Comment #17 from Jason Merrill  ---
Fixed for 4.8.3/4.9.

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[jason at gcc dot gnu.org]

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

Bug 59224 depends on bug 41174, which changed state.

Bug 41174 Summary: uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174

   What|Removed |Added

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

[Bug fortran/59959] [Regression 4.9] LRA ICEs on a fortran case(Suspected to be similar to pr59915)

[belagod at gcc dot gnu.org]

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

--- Comment #1 from Tejas Belagod  ---
My aarch64-none-linux-gnu-gfortran is configrued with:

/src/gcc/configure --target=aarch64-none-linux-gnu --prefix=
--with-sysroot=/aarch64-none-linux-gnu/libc
--with-build-sysroot=/workdir/rhe5x86_64/aarch64-none-linux-gnu/install//aarch64-none-linux-gnu/libc
--enable-gnu-indirect-function --enable-shared --disable-libssp
--disable-libmudflap --with-plugin-ld=aarch64-none-linux-gnu-ld
--enable-checking=release --enable-languages=c,c++,fortran
--with-gmp=/workdir/rhe5x86_64/aarch64-none-linux-gnu/host-tools
--with-mpfr=/workdir/rhe5x86_64/aarch64-none-linux-gnu/host-tools
--with-mpc=/workdir/rhe5x86_64/aarch64-none-linux-gnu/host-tools
--with-isl=/workdir/rhe5x86_64/aarch64-none-linux-gnu/host-tools
--with-cloog=/workdir/rhe5x86_64/aarch64-none-linux-gnu/host-tools

[Bug c++/58812] [4.7/4.8/4.9 Regression] ICE initializing an r-value reference with an initializer list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-27
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/59959] [Regression 4.9] LRA ICEs on a fortran case(Suspected to be similar to pr59915)

[belagod at gcc dot gnu.org]

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

--- Comment #2 from Tejas Belagod  ---
Looks like the same LRA issues are causing libgomp.fortran tests to ICE:

/aarch64-none-linux-gnu/obj/gcc4/gcc/xgcc
-B/aarch64-none-linux-gnu/obj/gcc4/gcc/
src/gcc/libgomp/testsuite/libgomp.fortran/vla3.f90
-B/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp/
-B/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp/.libs
-I/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp
-Isrc/gcc/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret
-fdiagnostics-color=never -fopenmp
-fintrinsic-modules-path=/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp
-O0
-B/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp/../libgfortran/.libs
-L/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp/.libs
-L/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgomp/../libgfortran/.libs
-lgfortran -lm -o ./vla3.exe
src/gcc/libgomp/testsuite/libgomp.fortran/vla3.f90: In function 'foo':
src/gcc/libgomp/testsuite/libgomp.fortran/vla3.f90:165:0: internal compiler
error: Maximum number of LRA constraint passes is achieved (30)

0x8b8e32 lra_constraints(bool)
src/gcc/gcc/lra-constraints.c:3959
0x8a5d9a lra(_IO_FILE*)
src/gcc/gcc/lra.c:2339
0x86a8f6 do_reload
src/gcc/gcc/ira.c:5457
0x86a8f6 rest_of_handle_reload
src/gcc/gcc/ira.c:5598
0x86a8f6 execute
src/gcc/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
output is:
src/gcc/libgomp/testsuite/libgomp.fortran/vla3.f90: In function 'foo':
src/gcc/libgomp/testsuite/libgomp.fortran/vla3.f90:165:0: internal compiler
error: Maximum number of LRA constraint passes is achieved (30)

0x8b8e32 lra_constraints(bool)
src/gcc/gcc/lra-constraints.c:3959
0x8a5d9a lra(_IO_FILE*)
src/gcc/gcc/lra.c:2339
0x86a8f6 do_reload
src/gcc/gcc/ira.c:5457
0x86a8f6 rest_of_handle_reload
src/gcc/gcc/ira.c:5598
0x86a8f6 execute
src/gcc/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


NA->FAIL: libgomp.fortran/vla4.f90  -O0  (internal compiler error)
PASS->FAIL: libgomp.fortran/vla4.f90  -O0  (test for excess errors)
PASS->NA: libgomp.fortran/vla4.f90  -O0  execution test
NA->FAIL: libgomp.fortran/vla5.f90  -O0  (internal compiler error)
PASS->FAIL: libgomp.fortran/vla5.f90  -O0  (test for excess errors)
PASS->NA: libgomp.fortran/vla5.f90  -O0  execution test

[Bug c++/59097] [4.7/4.8/4.9 Regression] ICE with invalid statement expression as array size

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-27
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/59959] New: [Regression 4.9] LRA ICEs on a fortran case(Suspected to be similar to pr59915)

[belagod at gcc dot gnu.org]

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

Bug ID: 59959
   Summary: [Regression 4.9] LRA ICEs on a fortran case(Suspected
to be similar to pr59915)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belagod at gcc dot gnu.org

Hi,

On AArch64, I'm seeing a fortran regression that I get when I compile:

.../aarch64-none-linux-gnu/obj/gcc4/gcc/testsuite/gfortran3/../../gfortran
-B.../aarch64-none-linux-gnu/obj/gcc4/gcc/testsuite/gfortran3/../../
-B.../aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgfortran/
.../gcc/gcc/testsuite/gfortran.dg/namelist_70.f90 -fno-diagnostics-show-caret
-fdiagnostics-color=never -O0 -pedantic-errors
-B.../aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgfortran/.libs
-L.../aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgfortran/.libs
-L.../aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libgfortran/.libs
-lm -o ./namelist_70.exe

This is similar to PR59915, but the same fix does not seem to fix the fortran
regression.

.../gcc/gcc/testsuite/gfortran.dg/namelist_70.f90: In function 'test3':
.../gcc/gcc/testsuite/gfortran.dg/namelist_70.f90:338:0: internal compiler
error: Maximum number of LRA constraint passes is achieved (30)

0x8b7e42 lra_constraints(bool)
.../gcc/gcc/lra-constraints.c:3933
0x8a4f9a lra(_IO_FILE*)
.../gcc/gcc/lra.c:2339
0x869af6 do_reload
.../gcc/gcc/ira.c:5457
0x869af6 rest_of_handle_reload
.../gcc/gcc/ira.c:5598
0x869af6 execute
.../gcc/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug c++/58837] [4.7/4.8/4.9 Regression] [c++11] ICE using invalid condition in static_assert

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/58965] [4.8/4.9 Regression] [c++11] ICE with member initializer in static union

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
*** Bug 58701 has been marked as a duplicate of this bug. ***

[Bug c++/58616] [meta-bug] nsdmi

[jason at gcc dot gnu.org]

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

Bug 58616 depends on bug 58701, which changed state.

Bug 58701 Summary: [4.9 Regression] [c++11] ICE initializing member of static 
union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jason Merrill  ---
Duplicate.

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

[Bug c++/58651] [4.7/4.8/4.9 Regression] ICE with invalid initializer list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/58814] [4.7/4.8/4.9 Regression] ICE with volatile and attribute vector_size

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/59952] -march=core-avx2 should not enable RTM

[thiago at kde dot org]

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

--- Comment #4 from Thiago Macieira  ---
(In reply to Mikael Pettersson from comment #3)
> There are also Haswells that lack BMI2.  I updated our dynamic binary
> instrumentation engine for AVX2 about a year ago, but while our Haswell box
> at the time had AVX2 it didn't have BMI2 etc, causing Intel's MKL to refuse
> to enter it AVX2 code paths.  So testing had to be limited to small
> assembly-coded kernels.

Are you sure? Unfortunately, ark.intel.com does not list BMI instruction level.

[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #16 from Jeffrey A. Law  ---
Should be fixed by commit on trunk.  Bootstrap still fails in stage3 libjava,
but that's unrelated to this fix AFAICT.

[Bug c++/59231] [4.8/4.9 Regression] gcc misses [-Werror=sign-compare] when inside a template

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Paolo Carlini from comment #6)
> However, what Jason suggested at the time was "ANOTHER job for
> c_inhibit_evaluation_warning" (emphasis mine). In my mind that was important
> because I saw a clear consistency rationale in the fix. Before changing /
> reverting anything here, we should therefore audit all those uses and figure
> out which ones we want to remove and finally decide which replacement.
> Frankly, I'm not sure this is 4.9 material (whoever does the job ;)

Yes, I saw it as a consistency issue.  But now I think that was forcing
consistency between two importantly different cases: the purpose of
c_inhibit_evaluation_warning is to avoid warning about evaluation issues for
expressions that are not actually evaluated.  But a template instantiation is
not an unevaluated context, so it's a different case.  Furthermore, the
-Wtype-limits warning still makes sense even in unevaluated context, so it
shouldn't be conditional on that.

I agree that an audit is needed here; we might want to introduce a new counter
to indicate dependent context and suppress some warnings within templates.  I
think this could still go into 4.9 if there's time to take care of it soon.

[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds

[law at gcc dot gnu.org]

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

--- Comment #15 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 27 16:33:39 2014
New Revision: 207137

URL: http://gcc.gnu.org/viewcvs?rev=207137&root=gcc&view=rev
Log:
   PR bootstrap/59934
* expmed.h (expmed_mode_index): Rework so that analysis and optimziers
know when the MODE_PARTIAL_INT and MODE_VECTOR_INT cases can never be
reached.

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

[Bug c++/59960] New: accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1 and t2 have different template types

[gcc at abeckmann dot de]

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

Bug ID: 59960
   Summary: accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1
and t2 have different template types
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at abeckmann dot de

The following code is accepted by g++ in c++11 mode (tested 4.7, 4.8, 4.9):

= 8< =
#include 
#include 

template 
void f(T1 & t1, T2 & t2)
{
auto a1 = t1, a2 = t2;
std::cout << typeid(a1).name() << std::endl;
std::cout << typeid(a2).name() << std::endl;
}

int main ()
{
int i(23);
double d(42.);
f(i, d);
}
= >8 =
the output id generates is
- 8< -
i
d
- >8 -

But the standard says in [dcl.spec.auto] clause 7: If the list [...] contains
more than one declarator, the type of each declared variable is determined as
described above. If the type deduced [...] is not the same in each deduction,
the program is ill-formed.

clang fails compilation with

auto2.cpp:7:2: error: 'auto' deduced as 'int' in declaration of 'a1' and
deduced as 'double' in declaration of 'a2'
auto a1 = t1, a2 = t2;
^ ~~   ~~

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 31963
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31963&action=edit
gcc49-pr59920.patch

Ok, started hacking on this.  I think I have the tree-cfg.c side of the thing
pretty much ready (appart from removing make_abnormal_goto_edges), including
being friendly to OpenMP and even using the OpenMP restrictions to get smaller
AB edge coverage, but things to do still include:
1) tree-inline.c
2) expansion (ensure the right edges exists after expansion)
3) see how it will play together with __builtin_setjmp, hopefully just kill
   __builtin_setjmp_dispatcher altogether

[Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #7 from Marek Polacek  ---
Actually, this one still ICEs.

[Bug c++/58616] [meta-bug] nsdmi

[mpolacek at gcc dot gnu.org]

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

Bug 58616 depends on bug 58701, which changed state.

Bug 58701 Summary: [4.9 Regression] [c++11] ICE initializing member of static 
union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

[Bug c++/58632] [4.8/4.9 Regression] ICE reusing template parameter name as class name

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/58639] [4.7/4.8/4.9 Regression] ICE on self-referential struct member

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/59215] tsan: warning in shared_ptr_base.h

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 27 17:56:40 2014
New Revision: 207147

URL: http://gcc.gnu.org/viewcvs?rev=207147&root=gcc&view=rev
Log:
PR libstdc++/59215
* include/bits/shared_ptr_base.h
(_Sp_counted_base<_S_atomic>::_M_add_ref_lock()): Use relaxed atomic
load.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug libgcc/59936] undefined reference to gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
> Here is the message that i have received when writing the command "gcc 
> band-3c.for"

You should either compile your file with gfortran, or pass the gfortran
libraries: -lgfortran (may be also -lquadmath).

[Bug libstdc++/59215] tsan: warning in shared_ptr_base.h

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug testsuite/59897] FAIL: c-c++-common/asan/use-after-return-1.c -O* output pattern test, is 1: 0x2285020

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #7 from Dominique d'Humieres  ---
> Dominique, please check and close if it works for you.

Done! Thanks for the commit.

[Bug c++/59960] accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1 and t2 have different template types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-27
 Ever confirmed|0   |1

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-27
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
This is the same error as the test in pr43996 comment 0 or with the test:

  INTEGER, PARAMETER :: ISCLASS(1) = &
(/&
Z'FF80'& ! IEEE_NEGATIVE_INF
/)
print *, isclass
end

[Bug libgcc/59936] undefined reference to gfortran

[benyahia-nezha at hotmail dot fr]

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

--- Comment #2 from Benyahia.N  ---
Salam Dominique d'Humieres
 Thanks for your response, that's so kind of you,fortunately, i have solved
this problem only by using the command 'gfortran band-3c.for' unstead of 'gcc'
command which must be used only with the 'c' programs. That was so obvious but
it is things that can happen to everybody.

[Bug target/59952] -march=core-avx2 should not enable RTM

[mikpelinux at gmail dot com]

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

--- Comment #5 from Mikael Pettersson  ---
(In reply to Thiago Macieira from comment #4)
> (In reply to Mikael Pettersson from comment #3)
> > There are also Haswells that lack BMI2.  I updated our dynamic binary
> > instrumentation engine for AVX2 about a year ago, but while our Haswell box
> > at the time had AVX2 it didn't have BMI2 etc, causing Intel's MKL to refuse
> > to enter it AVX2 code paths.  So testing had to be limited to small
> > assembly-coded kernels.
> 
> Are you sure? Unfortunately, ark.intel.com does not list BMI instruction
> level.

Yes I'm sure.  According to my notes the processor was a 2.0 GHz 4c/8t
i7-4765T.  It may have been an engineering sample, this was at my previous job
and I can't access the machine any more.

[Bug c++/58606] [4.8/4.9 Regression] [c++11] ICE with specialization in variadic template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-27
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/59952] -march=core-avx2 should not enable RTM

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Prerelease samples shouldn't count, people using those just can avoid using
-march=haswell and use -march=ivybridge -mavx2 or similar instead.  Can anyone
from Intel verify if all released Haswell CPUs have BMI2 (and if there aren't
plans to ship Haswell CPUs without BMI2)?

[Bug c++/58504] [4.7/4.8/4.9 regression] ICE with type trait as default template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/59961] New: Use of size_t in leading term of computation with subtraction

[olaf at robots dot ox.ac.uk]

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

Bug ID: 59961
   Summary: Use of size_t in leading term of computation with
subtraction
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olaf at robots dot ox.ac.uk

The minimalistic example further down produces a very unexpected result and no
warnings at all. I understand that size_t s1 can not be negative. However, in
my example using "-s1*..." in the leading term of the computation therefore
seems to cause an overflow.

Quite curiously, a similar bug is caused when using "unsigned int" instead of
size_t, but no bugs are caused if using "unsigned short" or "unsigned char".
The bug also does not appear if the + and - terms are swapped. All of this is
on an x86_64 platform.

Even if may be correct in a very obscure way according to some C specification,
it would be very helpful to issue a warning with -Wall -Wextra



/* compile with gcc -Wall -Wextra testcase.c */

#include 

int main(int ac, char**dc)
{
ac = ac; dc = dc;

size_t s1 = 100;
size_t s2 = 200;
double d1 = 0.123;
double d2 = 0.234;

double result = -s1*d1 + s2*d2;

printf("%lf %lf\n", result, -100*0.123+200*0.234);

return 0;
}

[Bug target/59952] -march=core-avx2 should not enable RTM

[thiago at kde dot org]

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

--- Comment #7 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #6)
> Prerelease samples shouldn't count, people using those just can avoid using
> -march=haswell and use -march=ivybridge -mavx2 or similar instead.  Can
> anyone from Intel verify if all released Haswell CPUs have BMI2 (and if
> there aren't plans to ship Haswell CPUs without BMI2)?

Trying to get that confirmed internally.

[Bug target/59952] -march=core-avx2 should not enable RTM

[thiago at kde dot org]

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

--- Comment #8 from Thiago Macieira  ---
(In reply to Thiago Macieira from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Prerelease samples shouldn't count, people using those just can avoid using
> > -march=haswell and use -march=ivybridge -mavx2 or similar instead.  Can
> > anyone from Intel verify if all released Haswell CPUs have BMI2 (and if
> > there aren't plans to ship Haswell CPUs without BMI2)?
> 
> Trying to get that confirmed internally.

First info is that the i3-4000 series has BMI2:

 Family: Core i3
 Version: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz
 flags:   fsgsbase bmi1 avx2 smep bmi2 erms invpcid

The other information that I can give you is that compiling code with ICC 14
with -march=core-avx2 does generate SHRX, SARX, SHLX instructions. It has no
#define for either BMI1 or 2, though.

[Bug c/59958] alpha does not deal with non-aligned returns from malloc() when doing byte wise access

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
The response to C90 DR#075 said memory from malloc must be suitably 
aligned for all types, not just those fitting in space of the given size, 
and nothing relevant has changed in the malloc specification in C99/C11 so 
it's reasonable to assume this still applies (for standard types, that is, 
not types using C11 _Alignof).

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_075.html

[Bug c/59961] Use of size_t in leading term of computation with subtraction

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

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

--- Comment #1 from Andreas Schwab  ---
-100 is not the same as -s1.  The latter is SIZE_MAX + 1 - 100, a big number,
depending on the size of size_t.  If s1 is declared as unsigned short or
unsigned char, it will be promoted to int before any futher operation is
applied.

[Bug c++/59838] [4.7 Regression] ICE with an enum using an incomplete type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||cas43 at cs dot stanford.edu

--- Comment #12 from Jason Merrill  ---
*** Bug 57946 has been marked as a duplicate of this bug. ***

[Bug target/59952] -march=core-avx2 should not enable RTM

[kirill.yukhin at intel dot com]

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

--- Comment #9 from Yukhin Kirill  ---
(In reply to Jakub Jelinek from comment #6)
> Prerelease samples shouldn't count, people using those just can avoid using
> -march=haswell and use -march=ivybridge -mavx2 or similar instead.  Can
> anyone from Intel verify if all released Haswell CPUs have BMI2 (and if
> there aren't plans to ship Haswell CPUs without BMI2)?

I am checking and will get back to. I though all AVX2 parts had BMI1/2

[Bug c++/57946] [4.7/4.8/4.9 Regression] internal compiler error: Segmentation fault in int_fits_type_p

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jason Merrill  ---
Duplicate.

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

[Bug c++/54652] [4.7/4.8/4.9 Regression] ICE with -g

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/59956] internal compiler error: unexpected expression ‘P_S’ of kind template_parm_index

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Maybe a dup a PR58466?

[Bug libstdc++/59829] Calling vector::data() occurs undefined behavior when the vector is empty

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
proposed fix: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01719.html

[Bug target/59952] -march=core-avx2 should not enable RTM

[thiago at kde dot org]

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

--- Comment #10 from Thiago Macieira  ---
(In reply to Yukhin Kirill from comment #9)
> I am checking and will get back to. I though all AVX2 parts had BMI1/2

The evidence seems to support that. I did check with a few colleagues and we
couldn't come up with a case that didn't.

We found Haswell-based Celerons that don't have them, but those don't have AVX2
either -- they don't qualify for either part of "core-avx2".

[Bug c++/59823] [4.7/4.8/4.9 Regression] conversion operator to const X& causes copy-construction of temporary

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-01-27
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/59962] New: --with-build-config=bootstrap-asan doesn't work

[hjl.tools at gmail dot com]

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

Bug ID: 59962
   Summary: --with-build-config=bootstrap-asan doesn't work
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

When GCC is configured with --with-build-config=bootstrap-asan,
bootstrap fails with

/export/build/gnu/gcc-asan/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/gcc-asan/build-x86_64-linux/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-g -O2 -static-libstdc++
-static-libgcc  -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o
fixlib.o fixopts.o ../libiberty/libiberty.a
../libiberty/libiberty.a(regex.o): In function `byte_compile_range':
/export/gnu/import/git/gcc/libiberty/regex.c:4495: undefined reference to
`__asan_report_load1'
/export/gnu/import/git/gcc/libiberty/regex.c:4449: undefined reference to
`__asan_report_load8'
/export/gnu/import/git/gcc/libiberty/regex.c:4499: undefined reference to
`__asan_report_load1'
/export/gnu/import/git/gcc/libiberty/regex.c:4499: undefined reference to
`__asan_report_store1'
/export/gnu/import/git/gcc/libiberty/regex.c:4499: undefined reference to
`__asan_report_load1'
/export/gnu/import/git/gcc/libiberty/regex.c:4499: undefined reference to
`__asan_report_load1'
/export/gnu/import/git/gcc/libiberty/regex.c:4495: undefined reference to
`__asan_report_load1'
/export/gnu/import/git/gcc/libiberty/regex.c:4495: undefined reference to
`__asan_report_load1'
/export/gnu/import/git/gcc/libiberty/regex.c:4489: undefined reference to
`__asan_report_load1'
../libiberty/libiberty.a(regex.o): In function
`byte_common_op_match_null_string_p':
...

fixincl isn't compiled/linked with -fsanitize=address, but libiberty
it linked against is.  A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02467.html

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #16 from Jeffrey A. Law  ---
I haven't managed to reproduce this either.  Clearly Jakub and I are doing
something different that's preventing us from reproducing this problem.

I don't want to just go forward with the patch that checks that the denominator
is nonzero without knowing more about how/why it is zero.  Much like a NULL
pointer dereference, this specific failure may well be just the manifestation
of a problem elsewhere.

David, Markus -- can y'all reproduce on one of the gcc farm machines?  Or a VM
you can give me access to?   Or at least a core file and corresponding svn
revision for the GCC build you're using?

[Bug c/59961] Use of size_t in leading term of computation with subtraction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I don't think there is anything that should be warned about, there is nothing
surprising or unexpected on unsigned negation.

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
Nevermind, I've got it failing now.

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #18 from Jan Hubicka  ---
When caller frequency is 0, we do not really want to inline recursively.  I
will make a patch.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #20 from Mikael Morin  ---
Author: mikael
Date: Mon Jan 27 21:23:16 2014
New Revision: 207152

URL: http://gcc.gnu.org/viewcvs?rev=207152&root=gcc&view=rev
Log:
fortran/
PR fortran/58007
* module.c (skip_list): Don't use default argument value.
(load_derived_extensions, read_module): Update callers.


Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/module.c

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[law at redhat dot com]

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

--- Comment #19 from Jeffrey A. Law  ---
That part is pretty obvious.  What I wanted to look at is how we got there and
did it make any sense to be in that code with a caller frequency of zero.

[Bug preprocessor/58580] [4.8 Regression] preprocessor goes OOM with warning for zero literals

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #11 from Pat Haugen  ---
CPU2000 benchmark 253.perlbmk started failing to build for me starting with
revision 206957. Reduced down to following example.

[pthaugen@igoo 0001]$ cat junk.c
# define HAS_FGETPOS
[pthaugen@igoo 0001]$ /home/pthaugen/install/gcc/gcc_hunt/bin/gcc -c junk.c
-DHAS_FGETPOS
junk.c:1:0: warning: "HAS_FGETPOS" redefined [enabled by default]
 # define HAS_FGETPOS
 ^
:0:0: note: this is the location of the previous definition
junk.c:1:0: internal compiler error: Segmentation fault
 # define HAS_FGETPOS
 ^
0x10667507 crash_signal
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/toplev.c:337
0x10cab5b7 add_file_to_cache_tab
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/input.c:296
0x10cab5b7 lookup_or_add_file_to_cache_tab
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/input.c:330
0x10cab5b7 location_get_source_line(expanded_location, int*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/input.c:704
0x10ca5167 diagnostic_show_locus(diagnostic_context*, diagnostic_info const*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/diagnostic.c:304
0x10ca580b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/diagnostic.c:800
0x10156397 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char
const*, char**)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/c-family/c-common.c:9638
0x10cb85af cpp_diagnostic_with_line
/home/pthaugen/src/gcc/gcc_hunt/gcc/libcpp/errors.c:145
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[hubicka at ucw dot cz]

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

--- Comment #20 from Jan Hubicka  ---
> That part is pretty obvious.  What I wanted to look at is how we got there and
> did it make any sense to be in that code with a caller frequency of zero.

Recursive inliner will happily call the predicate on every recursive call it is
given.  Usually we do not get there, because in those cases we get
!cgraph_maybe_hot_edge_p

That predicate however can be convinced to return true even for calls with
0 frequency if profile feedback says there are stil many counts or if user
drops hot attribute on the outer function. (Theresa made this code to depends
on edge historgram and in some cases it may behave in funy ways).
So check is needed.

Question remains why this reproduces on testcase without profile feedback & hot
attribute.  I assume that because roundoff error We have A inlined in B with
call frequency 0 while A still have callees with non-zero frequency because it
contains a loop.  It is apparently what happens here, will double check.

[Bug target/52125] Problems with LO16 asm operands on MIPS

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #5 from Steve Ellcey  ---
The new test (gcc.target/mips/pr52125.c) is passing on my linux target
(mips-mti-linux-gnu) but failing for my elf target (mips-mti-elf).  The code
for the asm statement I get on elf is:

#APP
# 8 "pr52125.c" 1
%gp_rel(b)($28) %gp_rel(d)($28)
# 0 "" 2
#NO_APP

It looks like I can fix this by using -mno-gpopt.  Is this a reasonable
fix or does it break what we want to test?

[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---
Right, I'd been speculating that we were calling
want_inline_self_recursive_call_p for all self-recursive calls and that maybe
the hot edge or other heuristic was doing something unexpected.

Anyway, I'll let you run with it.  You'll be far more efficient than I nailing
this down.  I only started looking at it because it was one of the P1s with no
activity for the longest time.

jeff

[Bug target/52125] Problems with LO16 asm operands on MIPS

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Yeah, got the same thing in overnight mipsisa64-sde-elf testing but
hadn't had chance to look at it.

Adding -mno-gpopt is fine.

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #31963|0   |1
is obsolete||

--- Comment #8 from Jakub Jelinek  ---
Created attachment 31964
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31964&action=edit
gcc49-pr59920.patch

Updated patch.  Apparently we were dropping the abnormal edges during expansion
anyway, so there is nothing to do for RTL right now.  The patch results in some
Ada miscompares though, will debug tomorrow.

[Bug c/59961] Use of size_t in leading term of computation with subtraction

[olaf at robots dot ox.ac.uk]

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

--- Comment #3 from Olaf  ---
Well... naive me found it quite surprising and unexpected that the following
two lines produce grossly different results:

double result1 = -s1*d1 + s2*d2;
double result2 =  s2*d2 - s1*d1;

...but never mind.