[Bug c/64748] OpenACC: is not a variable error with deviceptr()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64748 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- ??? threadprivate? That doesn't look even remotely similar to the deviceptr clause, threadprivate in OpenMP is a declarative clause you put on variables to turn them into TLS vars.
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- So fixed?
[Bug middle-end/65003] [5 Regression] -fsection-anchors ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65003 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34713 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34713action=edit gcc5-pr65003.patch Untested fix. If the assert ever triggers, I guess we'll need to do something smarter in the cgraph area. Note that symbols that are aliases from the beginning aren't a problem here, the only problem is if a symbol has RTL created too early (in this case because of notice_global_symbol) and then IPA or whatever turns it into an alias to some other symbol.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #2 from Ian Lance Taylor ian at airs dot com --- From a cursory look the problem is that the regexp expects line 66 but the actual output is line 65. Looking at the code line 66 seems correct. However if the code is built with optimization it's easy to imagine this being not quite correct for one reason or another. Probably the test should be loosened.
[Bug sanitizer/65000] ICE in in expand_builtin_eh_common, at except.c:2072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-10 Ever confirmed|0 |1 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Note that if I remove the IFN_UBSAN_NULL case or the IFN_UBSAN_OBJECT_SIZE case in call_may_clobber_ref_p_1, the ICE disappears.
[Bug middle-end/65003] New: [5 Regression] -fsection-anchors ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65003
Bug ID: 65003
Summary: [5 Regression] -fsection-anchors ICE
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target: armv7hl-linux-gnuaebi
struct A
{
void operator= (A );
A ();
};
struct B
{
A b;
};
struct C
{
virtual bool foo (int , bool) const;
};
struct D : virtual C
{
bool foo (int , bool) const;
B e;
};
struct F : D
{
F (int , const int , const A );
bool foo (int , bool) const;
};
bool D::foo (int , bool) const {}
F::F (int , const int , const A ) {}
bool F::foo (int , bool) const {}
ICEs on armv7hl-linux-gnuaebi, with -O2 -fpic. I believe the bug has been
introduced with r211045, but haven't verified it.
[Bug middle-end/65003] [5 Regression] -fsection-anchors ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65003
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-10
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
snode = symtab_node::get (decl);
if (snode-alias)
{
rtx target = DECL_RTL (snode-ultimate_alias_target ()-decl);
place_block_symbol (target);
SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
return;
}
is of course bogus, DECL_RTL is very unlikely a SYMBOL_REF, it should be a MEM
with SYMBOL_REF as operand. The question is if we can assert that. If that
wouldn't be the case, I guess the optimizers would need to prevent creation of
the alias.
[Bug fortran/57822] I/O: (g0) wrongly prints E+0000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) Note that the output of this test on powerpc-apple-darwin9 r220529 is 3 38 .6919E-0001 so it seems that the test will fail on powerpc* using the IBM REAL(16). Can you try a round up on that to see what it does?
[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #16 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Is anyone working on this one?
[Bug middle-end/65003] [5 Regression] -fsection-anchors ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65003 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug libstdc++/64936] regex, ECMA treated as posix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64936 pierreblavy at yahoo dot fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from pierreblavy at yahoo dot fr --- Hi, I seems to be a duplicate of the bug you've cited. I've missed it. *** This bug has been marked as a duplicate of bug 61424 ***
[Bug ipa/64963] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org --- In theory the kernel could mark __init functions with noclone. But I think sticky behavior would be better. That's the behavior that the kernel expects. There isn't any code as far as I know that would expect only a single function per section.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Just noticed that all function offsets in the stack traces are broken. On s390x, only even offsets are valid, but all the numbers are odd, e.g. pprof_test.allocatePersistent1K+0x23 ^
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 --- Comment #8 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Feb 10 14:49:07 2015 New Revision: 220585 URL: https://gcc.gnu.org/viewcvs?rev=220585root=gccview=rev Log: cap frequency in make_forwarder_block In the testcase the block with problematic frequency has to incoming edges. Each edge has probability 1. The first edge's source bb has frequency 873/1, and the second has a frequency of 9409/1. So at least one of those is slightly high probably from some sort of rounding issue related to fixed point, but in any case make_forwarder_block should not create basic blocks with frequency greater than BB_FREQ_MAX. gcc/ PR tree-optimization/64326 * cfghooks.c (make_forwarder_block): Cap frequency of created basic block. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64326.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c
[Bug c/64748] OpenACC: is not a variable error with deviceptr()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64748
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #3)
(In reply to Jakub Jelinek from comment #2)
??? threadprivate? That doesn't look even remotely similar to the deviceptr
clause, threadprivate in OpenMP is a declarative clause you put on variables
to turn them into TLS vars.
I'm sorry that I didn't correctly memorize this OpenMP construct. So,
considering:
void f(int *a)
{
#pragma omp threadprivate (a)
}
..., the error that GCC emits is actually correct:
$ build-gcc/gcc/xgcc -Bbuild-gcc/gcc/ ../t.c -fopenmp
../t.c: In function 'f':
../t.c:3:27: error: 'a' is not a variable
#pragma omp threadprivate (a)
^
Of course. You can't make a parameter threadprivate, nor you can make an
automatic variable threadprivate.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com --- These entries looks screwed to me: -- snip -- 32: 1024 [32: 1024] @ ... #0x8000c44b ...allocatePersistent1K ... mprof_test.go:43 #0x8000c595 ...TestMemoryProfiler ... mprof_test.go:65 ... 0: 0 [1: 32] @ ... #0x8000c3b7 ...allocateTransient2M ... mprof_test.go:30 #0x8000c58f ...TestMemoryProfiler ... mprof_test.go:64 ... -- snip -- In line 64 there's a call to allocateTransient1M(), not to allocateTransient2M() as the stack trace claims, and likewise line 65 calls allocateTransient2M() and not allocatePersistent1K(). On top of that, the output for line 66 is missing completely.
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from tbsaunde at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) So fixed? yes, just didn't get back to this tab yet
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com --- The stack traces in gdb look good: line 64: #0 __go_new (td=td@entry=0x8010c8e8 __go_td_S1_xAN5_uint81024ee, size=size@entry=1024) at ../../../libgo/runtime/go-new.c:14 #1 0x8000c32c in pprof_test.allocateTransient1M () at mprof_test.go:21 #2 0x8000c58a in runtime_pprof_test.TestMemoryProfiler ( t=0xc2088502d0) at mprof_test.go:64 line 65: #0 __go_make_slice1 (td=td@entry=0x80109848 __go_td_AN5_uint8e, len=len@entry=2097152) at ../../../libgo/runtime/go-make-slice.c:74 #1 0x8000c3a8 in pprof_test.allocateTransient2M () at mprof_test.go:30 #2 0x8000c590 in runtime_pprof_test.TestMemoryProfiler ( t=0xc2088502d0) at mprof_test.go:65 line 66: #0 __go_new (td=td@entry=0x8010cc18 __go_tdn_runtime_pprof_test.Obj32, size=size@entry=32) at ../../../libgo/runtime/go-new.c:14 #1 0x8000c44c in pprof_test.allocatePersistent1K () at mprof_test.go:43 #2 0x8000c596 in runtime_pprof_test.TestMemoryProfiler ( t=0xc2088502d0) at mprof_test.go:66
[Bug tree-optimization/65002] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65002 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems estimate_function_body_sizes, in particular the ipa_load_from_parm_agg, assumes that the function has SSA form properly updated, but since the bounded pointers stuff changes that is not necessarily true. Normally that is fixed up now during fixup_cfg pass, but this call happens before that. Perhaps we need to update ssa form for the function if it hasn't been updated yet before we call these?
[Bug ipa/64963] [5 Regression] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|IPA Cloning/Splitting does |[5 Regression] IPA |not copy function section |Cloning/Splitting does not |attributes resulting in |copy function section |kernel miscompilation |attributes resulting in ||kernel miscompilation --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, though it seems we've actually been using the user section for the clones in the past, it is just Honza's r211363/r211365 changes (or so, r211350 works, r211400 doesn't), that broke this. So in that case it is a regression and supposedly cloning should ensure the section name is copied (which has been done automatically in the past because it was part of the FUNCTION_DECL that was copied and modified, but after moving that out into cgraph that doesn't happen anymore).
[Bug target/65010] New: ppc backend generates unnecessary signed extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
Bug ID: 65010
Summary: ppc backend generates unnecessary signed extension
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
I use ppc gcc to compile following code with option -O2
unsigned long c2l(unsigned char* p)
{
unsigned long res = *p + *(p+1);
return res;
}
long c2sl(signed char* p)
{
long res = *p + *(p+1);
return res;
}
Trunk gcc generates:
c2l:
lbz 10,0(3)
lbz 9,1(3)
add 3,10,9
extsw 3,3
blr
c2sl:
lbz 9,1(3)
lbz 10,0(3)
extsb 9,9
extsb 3,10
add 3,3,9
extsw 3,3
blr
The extsw instructions in both functions are unnecessary since it can't change
the value in return register.
[Bug lto/65012] New: [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012 Bug ID: 65012 Summary: [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with a test rebuild and trunk 20150205, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-gcc5-vivid.html no details yet. can other distros confirm? seems to work on x86 and x86_64.
[Bug c++/65011] New: misleading error message for target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65011
Bug ID: 65011
Summary: misleading error message for target attribute
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
The target attribute named default is handled special and this causes a
problem in error reporting. If I have code like this:
__attribute__((target(sse2,avx2)))
void foo(double *__restrict r, const double *__restrict a, const double
*__restrict b, double f)
{
for (unsigned i = 0; i 128; ++i)
r[i] = a[i] * f + b[i];
}
the compiler doesn't complain even though it ignores one of the parameters of
the target attribute. That's a question for another day.
The problem is that replacing one of the strings with default causes a
problem:
$ cat u.cc
__attribute__((target(default,avx2)))
void foo(double *__restrict r, const double *__restrict a, const double
*__restrict b, double f)
{
for (unsigned i = 0; i 128; ++i)
r[i] = a[i] * f + b[i];
}
$ local-gcc -c -O3 u.cc
u.cc:10:96: error: attribute(target(default)) is unknown
void foo(double *__restrict r, const double *__restrict a, const double
*__restrict b, double f)
^
Of course default is known. But it is not parsed in
ix86_valid_target_attribute_inner_p. It seems (haven't verified it) that the
caller checks for default being the entire string and if this is not the case
defers parsing to ix86_valid_target_attribute_inner_p.
[Bug lto/65012] [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- /bin/bash ./libtool --tag=CC --mode=link gcc -pipe -Wall -Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security -Wformat -nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclarati on-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmi ssing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlen gth-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow -Wdate-time -Wnested-ex terns -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -ffunction-sections -fdata-s ections -fstack-protector -fstack-protector-strong -fPIE --param=ssp-buffer-size=4 -flto -ffat-lto-objects -g -O3 -fstack-p rotector-strong -Wformat -Werror=format-security -Wl,--as-needed -Wl,--no-undefined -Wl,--gc-sections -Wl,-z,relro -Wl,-z,now -pie -Wl,-Bsymbolic-functions -Wl,-z,relro -o test-watchdog src/test/test-watchdog.o libsystemd-shared.la -ldl lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-5/README.Bugs for instructions. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug fortran/57822] I/O: (g0) wrongly prints E+0000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Wed Feb 11 04:29:06 2015 New Revision: 220606 URL: https://gcc.gnu.org/viewcvs?rev=220606root=gccview=rev Log: 2015-02-10 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/57822 * io/write_float.def (output_float): Apply fix of previous patch to correctly calculate the exponent number of digits and take care of wide character output. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 --- Comment #12 from manuel.reimer at gmx dot de --- (In reply to Richard Earnshaw from comment #11) We don't have your hardware and we don't have the full code to your application, so we aren't going to be able to help you debug this. The hardware is basically something like a reference application for the STM32F103 available for a few bucks on ebay: http://www.ebay.com/itm/400608858461 The software is just the bootloader, I will need to flash new software directly via USB: https://github.com/tormodvolden/maple-bootloader/tree/unify_platforms To take this any further you'll need to show us why you think the compiler has mis-optimized your code. I won't be able to. I'm just a hobby programmer trying to help with this project: https://github.com/j1rie/IRMP_STM32/ with the goal to create a cheap USB based infrared remote control receiver. I'm able to compile the code, flash the binary and up to now I was able to provide the required information in this bug report. I don't understand in detail what the C code does and I don't know anything about how compilers and their optimization work.
[Bug c++/64994] [5 Regression] Firefox build error: ICE: in cxx_eval_call_expression, at cp/constexpr.c:1353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-10 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Confirmed, also happens for me at x86_64-linux build.
[Bug target/55926] Internal compiler error with static volatile pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55926 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- So as I can't reproduce this, and neither we had new comments on this bug, nor duplicate, I will close it. So I will close this bug.
[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 manuel.reimer at gmx dot de changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #14 from manuel.reimer at gmx dot de --- You are a bit fast with closing bugs, aren't you? I think you should give me at least a chance to get feedback on my git bisect result, I'll be able to present in a few minutes. I took me a few hours to track this down and maybe the affected commit at least makes it possible that someone can give me a hint what else I could try to find the real reason for the problem?
[Bug target/18649] terminate called after throwing - IOT/Abort trap (core dumped)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- So waited long enough for a reply of PPC maintainer. I assume it is fixed too.
[Bug c++/61838] ICE on Windows with ctors defined outside class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61838 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- This issue got fixed for 5.0. As it is unlikely thing get back-merged to 4.9, I close this bug
[Bug sanitizer/65004] Compare debug failure with -fno-sanitize-recover -fsanitize=address -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65004 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-10 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug sanitizer/64670] -fsanitize=vptr leads to undefined reference to `typeinfo for class'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jason Merrill from comment #10) Having #pragma implementation in LogListener.cc is sufficient: The real-world LogListener.o has (full output as it is short): ... V typeinfo for LogListener So why are you getting an undefined reference? Because log.o has due to the vptr sanitizer: U typeinfo for LogListener
[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #13 from Richard Earnshaw rearnsha at gcc dot gnu.org --- gcc developers are volunteers. Sorry, but they're not going to go around buying random bits of hardware to search for problems that may not even be bugs in the compiler. In the absense of any concrete information, I'm closing this as invalid. If you can provide more details as to exactly how the code has been mis-compiled, then please feel free to re-open and append that information.
[Bug bootstrap/56645] libgcc /configure identifies non-existing /lib/cpp as preprocessor on Mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56645 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, closing this. Can't reproduce. Don't hesitate to open new bug with more detailed information for reproducing, if this issue still exists
[Bug lto/50351] An internal compiler error when building gcc4.6 using -flto -fuse-linker-plugin on Win7 mingw64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- No reply. Seems to be solved. So I close this bug
[Bug sanitizer/64670] -fsanitize=vptr leads to undefined reference to `typeinfo for class'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #9) In the real code, one has something like the following, which I tried to mimic in the test case. If I understood your comment correctly, I should use in log.c not only 'implementation log.h' but additionally(?) 'implementation LogListener.h' - i.e. using 'pragma implementation' for LogListener.h's classes only in LogListener.h is not sufficient? Having #pragma implementation in LogListener.cc is sufficient: The real-world LogListener.o has (full output as it is short): ... V typeinfo for LogListener So why are you getting an undefined reference?
[Bug ipa/64982] [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug ipa/64963] [5 Regression] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Yeah, we was copying section as long as it was part of decl more or less by accident than by design. I suppose keeping section (or not clonning at all) makes sense. What about inlining across functions with user sections?
[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing .../xgcc -dumpspecs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, I don't assume so. I stay in contact to reporter and didn't got this issue reported anymore. So I close it. Please don't hesitate to open a new bug with more details to reproduce, if issue still exists.
[Bug c++/64994] [5 Regression] Firefox build error: ICE: in cxx_eval_call_expression, at cp/constexpr.c:1353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Feb 10 17:20:01 2015 New Revision: 220589 URL: https://gcc.gnu.org/viewcvs?rev=220589root=gccview=rev Log: PR c++/64994 * constexpr.c (cxx_eval_call_expression): Walk the clone list. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/57775] default argument for template parameter error for friend definition in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-10 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Also happens with trunk on GNU/Linux. Related to bug 60605.
[Bug sanitizer/65000] ICE in in expand_builtin_eh_common, at except.c:2072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, what seems to happen is that we have at the end of ehcleanup2:
After removal of unreachable regions:
Eh tree:
1 cleanup land:{5,L29},{4,L30}
7 must_not_throw
2 cleanup land:{3,L24}
3 cleanup land:{2,L20}
4 cleanup land:{1,L19}
...
L19:
MEM[(struct basic_streambuf *)this_3(D) + 8B]._vptr.basic_streambuf =
MEM[(void *)_ZTV15basic_streambuf + 16B];
resx 4
L20:
...
Then resx lowering pass lowers this into:
...
L19:
MEM[(struct basic_streambuf *)this_3(D) + 8B]._vptr.basic_streambuf =
MEM[(void *)_ZTV15basic_streambuf + 16B];
__builtin_eh_copy_values (3, 4);
L20:
...
and finally remove_unreachable_handlers called during optimize pass removes the
EH 3 region (supposedly because the EH 4 cleanup now falls thru into the L20
landing pad?). And during expansion we ICE when trying to expand the
__builtin_eh_copy_values call, as the region 3 has been removed as unreachable.
So, shall remove_unreachable_handlers consider __builtin_eh_copy_values as
uses, something else? Richard, any ideas?
[Bug ipa/64982] [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Tue Feb 10 16:38:31 2015 New Revision: 220587 URL: https://gcc.gnu.org/viewcvs?rev=220587root=gccview=rev Log: PR ipa/64982 * cgraphunit.c (cgraph_node::expand_thunk): Look for stdarg thunks. * method.c (use_thunk): Do not check for stdarg thunks. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c
[Bug ada/64985] segfault on address of record with reverse Scalar Storage Order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed, but please do _not_ use this pragma, it's essentially untested and is guaranteed to be a disaster performance-wise... This comment is only for the configuration pragma, the regular form is OK.
[Bug c++/64961] nested template implementation crossing namespace fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64961 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- No it isn't the same. Foo1 is a public member of bar::Bar ([class]/2 For purposes of access checking, the injected-class-name is treated as if it were a public member name.) Ba is a protected member of bar::Bar.
[Bug sanitizer/64670] -fsanitize=vptr leads to undefined reference to `typeinfo for class'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org --- Close as INVALID. The LogListener.o was missing for one make target - and I kept looking at the wrong one. Misreading the description of V also didn't help ([...] When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error.) Sorry for wasting everyone's time :-(
[Bug c++/64994] [5 Regression] Firefox build error: ICE: in cxx_eval_call_expression, at cp/constexpr.c:1353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug ipa/64963] [5 Regression] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- I think we should try to keep older gcc behavior, unless there is a strong reason to change that.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #6 from Ian Lance Taylor ian at airs dot com --- The odd addresses are most likely a symptom of the libbacktrace library. It should probably be considered a bug. I'm guessing that it's because of the --pc in the static function unwind in libbacktrace/backtrace.c.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #16 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, this issue seems to be fixed. I close this bug. Please don't hesitate to open new bug for it, iff issue still exists.
[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 manuel.reimer at gmx dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from manuel.reimer at gmx dot de --- This is what git bisect ended with. Maybe someone can at least have a look at this. Feel free to close again if this really doesn't help at all. $ git bisect bad9eec20bfd5806dd0380e07dbc0f03409ce3d4efb is the first bad commit commit 9eec20bfd5806dd0380e07dbc0f03409ce3d4efb Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Mar 26 09:14:59 2013 + 2013-03-26 Richard Biener rguent...@suse.de * emit-rtl.c (set_mem_attributes_minus_bitpos): Remove alignment computations and rely on get_object_alignment_1 for the !TYPE_P case. Commonize DECL/COMPONENT_REF handling in the ARRAY_REF path. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197095 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 f4fa27b8adaec983566fb9cb72d1165d10c86048 a13a68729d60b22dd6c45edb3ef7c3c52b3a2f41 Mgcc
[Bug sanitizer/64670] -fsanitize=vptr leads to undefined reference to `typeinfo for class'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #11) Because log.o has due to the vptr sanitizer: U typeinfo for LogListener And why isn't that reference satisfied by the definition in LogListener.o?
[Bug target/63293] [AArch64] can read from deallocated stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293 --- Comment #6 from collison at gcc dot gnu.org --- Author: collison Date: Tue Feb 10 08:17:09 2015 New Revision: 220574 URL: https://gcc.gnu.org/viewcvs?rev=220574root=gccview=rev Log: 2015-02-10 Michael Collison michael.colli...@linaro.org Backport from trunk r217091. 2014-11-04 Jiong Wang jiong.w...@arm.com 2014-11-04 Wilco Dijkstra wilco.dijks...@arm.com PR target/63293 * config/aarch64/aarch64.c (aarch64_expand_epiloue): Add barriers before stack adjustment. Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.c
[Bug target/64909] [4.8/4.9/5 Regression] Missed vectorization with bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P2 Status|WAITING |NEW Component|middle-end |target Known to work||4.7.4 Target Milestone|6.0 |4.8.5 Summary|Missed vectorization|[4.8/4.9/5 Regression] ||Missed vectorization with ||bdver1 Known to fail||4.8.3, 4.9.2, 5.0 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed with -march=bdver1. A cost model issue: t.c:6:3: note: Cost model analysis: Vector inside of loop cost: 24 Vector prologue cost: 0 Vector epilogue cost: 336 Scalar iteration cost: 14 Scalar outside cost: 0 Vector outside cost: 336 prologue iterations: 0 epilogue iterations: 4 Calculated minimum iters for profitability: 30 t.c:6:3: note: Runtime profitability threshold = 29 t.c:6:3: note: Static estimate profitability threshold = 29 t.c:6:3: note: not vectorized: vectorization not profitable. the vector epilogue cost looks odd to me. Without -march=bdver1 I get 12.
[Bug rtl-optimization/63676] [5.0 regression] vshuf-v16hi.c ICE on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63676 --- Comment #3 from collison at gcc dot gnu.org --- Author: collison Date: Tue Feb 10 08:05:35 2015 New Revision: 220572 URL: https://gcc.gnu.org/viewcvs?rev=220572root=gccview=rev Log: 2015-02-10 Michael Collison michael.colli...@linaro.org Backport from trunk r217215. 2014-11-07 Jiong Wang jiong.w...@arm.com 2014-11-07 Richard Biener rguent...@suse.de PR tree-optimization/63676 * gimple-fold.c (fold_gimple_assign): Do not fold node when TREE_CLOBBER_P be true. Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/gimple-fold.c
[Bug c++/64995] [5 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64995 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-10 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Bisecting...
[Bug c++/64995] New: [5 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64995
Bug ID: 64995
Summary: [5 Regression] ICE in vn_reference_insert_pieces, at
tree-ssa-sccvn.c:2341
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
seen with trunk 20150210 on x86_64-linux-gnu
$ g++ -c -g -O2 World.cc
World.cc: In function 'void passTime()':
World.cc:23:6: internal compiler error: in vn_reference_insert_pieces, at
tree-ssa-sccvn.c:2341
void passTime() {
^
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat World.cc
extern C double acos(double);
class A {
public:
double mY, mZ;
A(double, double);
double m_fn1(A *);
int *m_fn2();
};
double a;
A *b;
A::A(double, double) : mY(), mZ() {}
double A::m_fn1(A *) { return mY * mZ; }
inline int *A::m_fn2() {
mZ = 0;
double c = m_fn1(this);
a = acos(c);
double d = m_fn1(b);
acos(d);
}
void passTime() {
A e(0, 1);
e.m_fn2();
}
[Bug target/64909] [4.8/4.9/5 Regression] Missed vectorization with bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- We call Breakpoint 6, ix86_add_stmt_cost (data=0x21f34b0, count=56, kind=scalar_stmt, stmt_info=0x0, misalign=0, where=vect_epilogue) which is because we estimate epilogue cost to # of peeled iterations times scalar iteration cost (4 * 14). The way we do that, if (*peel_iters_epilogue) retval += record_stmt_cost (epilogue_cost_vec, *peel_iters_epilogue * scalar_single_iter_cost, scalar_stmt, NULL, 0, vect_epilogue); is slightly off (we record 4 * 14 scalar stmts but for that we'd need to use scalar_single_iter_num_stmts, not their cost, but well - scalar stmt cost is 1 even for bdver1). So the issue is that scalar iteration cost is somehow very high for bdver1 (14) compared to generic (3). It looks like bdver1 uses scaled costs (not based on 1): 6,/* scalar_stmt_cost. */ 4,/* scalar load_cost. */ 4,/* scalar_store_cost. */ 6,/* vec_stmt_cost. */ 0,/* vec_to_scalar_cost. */ 2,/* scalar_to_vec_cost. */ 4,/* vec_align_load_cost. */ 4,/* vec_unalign_load_cost. */ 4,/* vec_store_cost. */ 2,/* cond_taken_branch_cost. */ 1,/* cond_not_taken_branch_cost. and thus runs into the aforementioned issue.
[Bug sanitizer/64670] -fsanitize=vptr leads to undefined reference to `typeinfo for class'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670
--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #8)
(In reply to Tobias Burnus from comment #5)
Updated test case (part 1/2): [main file] compile with g++ -fsanitize=vptr
so the #pragma implementation doesn't match. If I change it to be test2.h
I get the typeinfo for LogListener.
I have to admit that I am lost - is there a good explanation of #pragma
implementation/interface somewhere?
In the real code, one has something like the following, which I tried to mimic
in the test case. If I understood your comment correctly, I should use in
log.c not only 'implementation log.h' but additionally(?) 'implementation
LogListener.h' - i.e. using 'pragma implementation' for LogListener.h's
classes only in LogListener.h is not sufficient?
- LogListener.h --
// Complete file except for ... bits and #include lines.
#pragma interface
class LogListener
{
public:
virtual ~LogListener() {}
virtual void listen( const Cstring input) = 0;
// virtual ... = 0; // some more
}
class AccumulatingLogListener : public LogListener {...};
- LogListener.cc --
// matches approx. attachment 34628
// As it is short, that's really the complete file
#pragma implementation
#include LogListener.h
void AccumulatingLogListener::listen( const Cstring input) {
m_buffer += input;
}
- log.h --
#pragma interface
class LogListener;
class Log_Handler {};
- log.c --
// matches approx. attachment 34627
#pragma implementation log.h
#include log.h
#include LogListener.h
// implementation of Log_Handler, which causes -fsanitize=vptr to access
// typeinfo for name LogListener, which is U.
The real-world LogListener.o has (full output as it is short):
006d t
_GLOBAL__sub_D_00099_0__ZN23AccumulatingLogListener6listenERK7Cstring
0082 t
_GLOBAL__sub_I_00099_1__ZN23AccumulatingLogListener6listenERK7Cstring
W LogListener::LogListener()
W LogListener::LogListener()
W LogListener::~LogListener()
W LogListener::~LogListener()
W LogListener::~LogListener()
T AccumulatingLogListener::listen(Cstring const)
W AccumulatingLogListener::AccumulatingLogListener(int)
W AccumulatingLogListener::AccumulatingLogListener(int)
W AccumulatingLogListener::~AccumulatingLogListener()
W AccumulatingLogListener::~AccumulatingLogListener()
W AccumulatingLogListener::~AccumulatingLogListener()
W AccumulatingLogListener::getContent() const
W AccumulatingLogListener::eatsMessages() const
W AccumulatingLogListener::isAccumulatingLogListerner() const
V typeinfo for LogListener
V typeinfo for AccumulatingLogListener
V typeinfo name for LogListener
V typeinfo name for AccumulatingLogListener
V vtable for LogListener
V vtable for AccumulatingLogListener
[Bug tree-optimization/64590] Firefox 34 triggers GCC AVX bug (segfault: XPCCallContext::GetJSContext (this=0xfffc7fffe3e23980))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64590 Dâniel Fraga fragabr at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Dâniel Fraga fragabr at gmail dot com --- I'm marking this as INVALID, since the following patch fixes the problem in Firefox: https://hg.mozilla.org/integration/mozilla-inbound/rev/b266a69f1947 Thanks.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Rainer Emrich rai...@emrich-ebersheim.de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #25 from Rainer Emrich rai...@emrich-ebersheim.de --- (In reply to Jeffrey A. Law from comment #24) Fixed by Trevor's patch to the trunk. We have a configure check for ftw.h and if it's not found we disable things that are dependent on ftw. The issue described in comment 8 isn't solved at all!
[Bug c++/64995] [5 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64995 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r218515.
[Bug sanitizer/64984] [5 Regression] ICE in check_noexcept_t with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34710 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34710action=edit gcc5-pr64984.patch Untested fix.
[Bug ipa/64988] [5 Regression] ICE: verify_cgraph_node failed: Alias and target's comdat groups differs with -fdeclone-ctor-dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64988 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0
[Bug c++/64994] [5 Regression] Firefox build error: ICE: in cxx_eval_call_expression, at cp/constexpr.c:1353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Target Milestone|--- |5.0
[Bug tree-optimization/64995] [5 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64995 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Component|c++ |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug rtl-optimization/64990] [4.8/4.9/5 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64990 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-* Priority|P3 |P2
[Bug ipa/64963] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963
James Greenhalgh jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64-none-elf|aarch64-none-elf,
||x86_64-unknown-linux-gnu
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-10
Ever confirmed|0 |1
--- Comment #2 from James Greenhalgh jgreenhalgh at gcc dot gnu.org ---
Adding x86_64 to the list of targets, as this is going to be a problem for
everybody.
build-x86/install/bin/gcc test.c -O3 -c
readelf -S test.o
There are 12 section headers, starting at offset 0x128:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
0012 AX 0 0 16
[ 2] .data PROGBITS 0052
WA 0 0 1
[ 3] .bss NOBITS 0052
WA 0 0 1
[ 4] .text.unlikelyPROGBITS 0052
AX 0 0 1
[ 5] .comment PROGBITS 0052
002a 0001 MS 0 0 1
[ 6] .note.GNU-stack PROGBITS 007c
0 0 1
[ 7] .eh_frame PROGBITS 0080
0040 A 0 0 8
[ 8] .rela.eh_frameRELA 0550
0030 0018 10 7 8
[ 9] .shstrtab STRTAB 00c0
0063 0 0 1
[10] .symtab SYMTAB 0428
0108 0018 1110 8
[11] .strtab STRTAB 0530
001b 0 0 1
$ build-x86/install/bin/gcc test.c -O0 -c
$ readelf -S test.o
There are 13 section headers, starting at offset 0x158:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
0017 AX 0 0 1
[ 2] .rela.textRELA 05b0
0018 0018 11 1 8
[ 3] .data PROGBITS 0057
WA 0 0 1
[ 4] .bss NOBITS 0057
WA 0 0 1
[ 5] test_section PROGBITS 0057
0013 AX 0 0 1
[ 6] .comment PROGBITS 006a
002a 0001 MS 0 0 1
[ 7] .note.GNU-stack PROGBITS 0094
0 0 1
[ 8] .eh_frame PROGBITS 0098
0058 A 0 0 8
[ 9] .rela.eh_frameRELA 05c8
0030 0018 11 8 8
[10] .shstrtab STRTAB 00f0
0066 0 0 1
[11] .symtab SYMTAB 0498
0108 0018 1210 8
[12] .strtab STRTAB 05a0
000f 0 0 1
[Bug sanitizer/64996] UBsan check optimized out by -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64996 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Since the variable is unused, we get rid of it, and then DCE removes the ubsan check. I don't think it is a bug. Adding asm ( : +g (i)); after the decrement makes the runtime error appear again.
[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-10 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- That is simply because you declared b volatile and thus b may be zero HERE. Not sure what you are expecting?
[Bug fortran/57822] I/O: (g0) wrongly prints E+0000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Something such as
! { dg-do run }
! PR58722
program testit
use ISO_FORTRAN_ENV
implicit none
integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
character(50) :: astring
integer :: i, l, n
n = 0
do i=1,size(real_kinds)
if (i == 1) then
write(astring, '(g0)') 1.0/real(10.0, kind=j(1))
else if (i == 2) then
write(astring, '(g0)') 1.0/real(10.0, kind=j(2))
else if (i == 3) then
write(astring, '(g0)') 1.0/real(10.0, kind=j(3))
else if (i == 4) then
write(astring, '(g0)') 1.0/real(10.0, kind=j(4))
end if
l = index(astring, 'E')
if (l /= 0) then
print *, i, l, trim(astring)
n = n + l
end if
end do
if (n /= 0) call abort
end program
should do the trick.
Note that the output of this test on powerpc-apple-darwin9 r220529 is
3 38 .6919E-0001
so it seems that the test will fail on powerpc* using the IBM REAL(16).
[Bug target/63652] [AArch64_be] vzip/vuzp tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63652 --- Comment #2 from clyon at gcc dot gnu.org --- I saw them pass at r219958, but fail again at r219959 as reported here: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02204.html
[Bug sanitizer/64996] New: UBsan check optimized out by -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64996
Bug ID: 64996
Summary: UBsan check optimized out by -O
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sami.liedes at iki dot fi
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
Consider this program:
#include limits.h
int main() {
int i=INT_MIN;
i--;
}
When compiled with -fsanitize=undefined -O0, ub is correctly detected:
$ gcc -fsanitize=undefined ub.c -o ub ./ub
ub.c:4:10: runtime error: signed integer overflow: -2147483648 + -1 cannot be
represented in type 'int'
When compiled with -O, the entire check is optimized out, even if the program
still clearly exhibits ub:
$ gcc -fsanitize=undefined ub.c -o ub -O ./ub
$ gcc -fsanitize=undefined ub.c -o ub.s -O -S
$ cat ub.s
.file ub.c
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
rep ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident GCC: (Debian 4.9.2-10) 4.9.2
.section.note.GNU-stack,,@progbits
$
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org --- Instead of the #undef mkdir you'd IMHO better just use (mkdir) (filename) in the second case. Anyway, if you've posted your patch to gcc-patches, you should be pinging it until it is reviewed. Kai, can you please have a look?
[Bug target/64997] [AArch64] Illegal EON on SIMD registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64997 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-10 Assignee|unassigned at gcc dot gnu.org |alalaw01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from alalaw01 at gcc dot gnu.org --- Results from split condition of xor_one_cmpl pattern using 'which_alternative' variable, which is not defined in split phase.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #30 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, this patch slipped under my radar. It would be good if you - Rainer - would have pinged on it. As far as I recalled I awaited at that time a full patch by Rong on this subject. (See comment #16 and after that). Nevertheless patch looks ok. I will give it some testing and will apply it after that. The change to undef mkdir in libgcc's part of the patch looks to me being the real patch. The patch in gcc's part is more cosmetic part getting rid of this (also mentioned to Rong too) wrong _WIN32 check.
[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-10 Ever confirmed|0 |1 --- Comment #11 from Richard Earnshaw rearnsha at gcc dot gnu.org --- (In reply to manuel.reimer from comment #0) So something is wrong with the optimization. Not necessarily. Your program may have a bug in it: many bugs are only shown up by higher levels of optimization. We don't have your hardware and we don't have the full code to your application, so we aren't going to be able to help you debug this. To take this any further you'll need to show us why you think the compiler has mis-optimized your code. I think that's a more useful approach than trying to identify the change in GCC that causes the code to fail.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #31 from Rainer Emrich rai...@emrich-ebersheim.de --- (In reply to Kai Tietz from comment #30) Yes, this patch slipped under my radar. It would be good if you - Rainer - would have pinged on it. As far as I recalled I awaited at that time a full patch by Rong on this subject. (See comment #16 and after that). Sorry, I had not much time the last few month. Nevertheless patch looks ok. I will give it some testing and will apply it after that. The change to undef mkdir in libgcc's part of the patch looks to me being the real patch. The patch in gcc's part is more cosmetic part getting rid of this (also mentioned to Rong too) wrong _WIN32 check. This part is necessary because otherwise the definition of the mkdir macro in system.h expects 2 arguments what isn't satisfied.
[Bug tree-optimization/64909] [4.8/4.9/5 Regression] Missed vectorization with bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Feb 10 11:48:47 2015 New Revision: 220580 URL: https://gcc.gnu.org/viewcvs?rev=220580root=gccview=rev Log: 2015-02-10 Richard Biener rguent...@suse.de PR tree-optimization/64909 * tree-vect-loop.c (vect_estimate_min_profitable_iters): Properly pass a scalar-stmt count estimate to the cost model. * tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost): Likewise. * gcc.dg/vect/costmodel/x86_64/costmodel-pr64909.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr64909.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/64909] [4.8/4.9 Regression] Missed vectorization with bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] Missed |Missed vectorization with |vectorization with bdver1 |bdver1 | Known to fail|5.0 | Severity|enhancement |normal --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar (for the SLP case please open another bugreport or amend the existing double - int convert one).
[Bug ipa/64988] [5 Regression] ICE: verify_cgraph_node failed: Alias and target's comdat groups differs with -fdeclone-ctor-dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64988 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-10 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r219696.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #27 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #26) Instead of the #undef mkdir you'd IMHO better just use (mkdir) (filename) in the second case. Anyway, if you've posted your patch to gcc-patches, you should be pinging it until it is reviewed. Kai, can you please have a look? Sure, I will have a look. Was this patch sent to ML? If so I am sorry for not noticing it. Could you please ping it?
[Bug ipa/64963] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- I'm not so sure that putting the clones into the same section si the right thing. The clone is by definition a local compiler generated function, it might not be desirable in the user defined section, which could have all kinds of weird handling on it. If the kernel can't grok some functions being cloned, I'd say it should just use noclone attribute on those.
[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64967 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I was wondering if anyone even still uses --enable-symvers=gnu-versioned-namespace I don't think it is worthwhile to support the dual ABI with the versioned namespace, since using the versioned namespace already means you don't care about ABI compatibility. One option would be to force --disable-libstdcxx-dual-abi when gnu-versioned-namespace is used so that none of the new code and features are available, another option would be to change the versioned namespace from __7 to __8 and unconditionally enable the new ABI so that all the features are available but without any backward compatibility.
[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64967 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-10 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/64994] [5 Regression] Firefox build error: ICE: in cxx_eval_call_expression, at cp/constexpr.c:1353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64994
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 test % cat nsGfxScrollFrame.ii
class TimeStamp {
public:
constexpr TimeStamp() : mValue() {}
int mValue;
};
class A {
class B;
A(bool);
};
class C {
TimeStamp mFadeBeginTime;
};
class A::B {
public:
B(int) {}
TimeStamp mPrevEventTime[1];
};
A::A(bool) {
new C;
B(0);
}
markus@x4 test % g++ -c --std=c++11 nsGfxScrollFrame.ii
nsGfxScrollFrame.ii: In constructor ‘A::B::B(int)’:
nsGfxScrollFrame.ii:16:10: in constexpr expansion of ‘TimeStamp()’
nsGfxScrollFrame.ii:16:10: internal compiler error: in
cxx_eval_call_expression, at cp/constexpr.c:1353
Reverting r220544 fixes the issue.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #29 from Rainer Emrich rai...@emrich-ebersheim.de --- Am 10.02.2015 12:12, schrieb jakub at gcc dot gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-patches/2014-09/msg02137.html ? Yes, that's it.
[Bug target/64997] New: [AArch64] Illegal EON on SIMD registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64997
Bug ID: 64997
Summary: [AArch64] Illegal EON on SIMD registers
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Testcase:
#include arm_neon.h
#define force_simd(V1) asm volatile (mov %d0, %1.d[0] \
: =w(V1) \
: w(V1) \
: /* No clobbers */)
int foo(int64x1_t val4, int64x1_t val6, int64x1_t val7)
{
int64x1_t val5 = vbic_s64 (val4,
veor_s64 (val6,
vsri_n_s64 (val6, val7, 13)));
force_simd (val5);
return vget_lane_s64 (val5, 0) == 0 ? 1 : 0;
}
generates an illegal assembly instruction (eon v1, v3, v1 -- EON works only on
General-Purpose Registers) at -O1 and higher.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-patches/2014-09/msg02137.html ?
[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64967 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Or drop the gnu-versioned-namespace support altogether. Anyway, if you don't, bumping it to _8 and always using the new ABI sounds like a good plan to me.
[Bug driver/64998] New: -shared -static-libasan does not actually link libasan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64998
Bug ID: 64998
Summary: -shared -static-libasan does not actually link libasan
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.gr...@ix-n.net
It was my expectation that I could statically link libasan into a shared object
with:
$ cat t.c
void foo(char* x) { x[4] = 1; }
$ gcc -fsanitize=address t.c -shared -fPIC -static-libasan
However, it seems that -lasan is never passed to the linker and I end up with
lots of unresolved symbols:
$ readelf -s a.out | grep asan
9: 0 NOTYPE GLOBAL DEFAULT UND __asan_init_v3
10: 0 NOTYPE GLOBAL DEFAULT UND __asan_report_store1
51: 0 NOTYPE GLOBAL DEFAULT UND __asan_init_v3
52: 0 NOTYPE GLOBAL DEFAULT UND __asan_report_store1
$ gcc -fsanitize=address t.c -shared -fPIC -static-libasan
-Wl,-Bstatic,-lasan,-Bdynamic
seems to produce the expected output.
[Bug ipa/64963] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963 --- Comment #4 from James Greenhalgh jgreenhalgh at gcc dot gnu.org --- The warning message given by the kernel build is: WARNING: net/ipv4/built-in.o(.text.unlikely+0x10c): Section mismatch in reference from the function ip_auto_config.part.6() to the function .init.text:ic_is_init_dev() The function ip_auto_config.part.6() references the function __init ic_is_init_dev(). This is often because ip_auto_config.part.6 lacks a __init annotation or the annotation of ic_is_init_dev is wrong. So we've ended up keeping around code for longer than was intended by cloning it out of the init section. If the implication is that code destined for user-defined sections might be unsafe to clone, then surely we should turn off cloning for functions annotated with __attribute__ ((section (foo))) ?
[Bug go/64999] New: s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 Bug ID: 64999 Summary: s390x libgo test failure in TestMemoryProfiler Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com CC: cmang at google dot com With the current trunk I get a test failure in the runtime/pprof test. I'll start investigating what's going on now but wanted to report it beforehand. Any hints on debugging this? -- $ make -k check-go RUNTESTFLAGS=go-test.exp ... --- FAIL: TestMemoryProfiler (0.16s) testing.go:278: The entry did not match: 32: 1024 \[32: 1024\] @ 0x[0-9,a-f x]+ #0x[0-9,a-f]+pprof_test\.allocatePersistent1K\+0x[0-9,a-f]+ .*/mprof_test\.go:43 #0x[0-9,a-f]+ runtime_pprof_test\.TestMemoryProfiler\+0x[0-9,a-f]+.*/mprof_test\.go:66 Profile: heap profile: 37: 3544 [3111: 4229640] @ heap/2 1: 1408 [1: 1408] @ 0x800250a9 0x800250a9 0x8001e5c7 0x8001e5c7 0x80021d3f 0x8001bf73 0x8001d54b 0x800069b1 0x3fff74ac92b 0x80006a15 #0x8001bf73mcommoninit+0x93 ../../../libgo/runtime/proc.c:739 #0x8001d54bruntime_schedinit+0x8b ../../../libgo/runtime/proc.c:459 #0x800069b1main+0x31../../../libgo/runtime/go-main.c:40 #0x3fff74ac92b #0x80006a15 1: 1024 [1024: 1048576] @ 0x800250a9 0x800250a9 0x8001163f 0x80011687 0x8000c551 0x800ad279 0x8001e229 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 32: 1024 [32: 1024] @ 0x800250a9 0x800250a9 0x8000c44b 0x8000c595 0x800ad279 0x8001e229 #0x8000c44bpprof_test.allocatePersistent1K+0x23 /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:43 #0x8000c595runtime_pprof_test.TestMemoryProfiler+0x11d /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:65 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 1: 64 [1: 64] @ 0x800250a9 0x800250a9 0x8001134d 0x8000c533 0x800ad279 0x8001e229 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 1: 16 [1: 16] @ 0x800250a9 0x800250a9 0x8000c4df 0x800ad279 0x8001e229 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 1: 8 [1: 8] @ 0x800250a9 0x800250a9 0x8000c50f 0x800ad279 0x8001e229 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 0: 0 [0: 0] @ 0x800250a9 0x800250a9 0x8000c5bb 0x800ad279 0x8001e229 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 0: 0 [1: 32] @ 0x800250a9 0x800250a9 0x8000c3b7 0x8000c58f 0x800ad279 0x8001e229 #0x8000c3b7pprof_test.allocateTransient2M+0x47 /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:30 #0x8000c58fruntime_pprof_test.TestMemoryProfiler+0x117 /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:64 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 0: 0 [1: 2097152] @ 0x800250a9 0x800250a9 0x8001163f 0x80011687 0x8000c3a7 0x8000c58f 0x800ad279 0x8001e229 #0x8000c3a7pprof_test.allocateTransient2M+0x37 /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:30 #0x8000c58fruntime_pprof_test.TestMemoryProfiler+0x117 /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:64 #0x800ad279testing.$thunk15+0xc9 ../../../libgo/go/testing/testing.go:555 #0x8001e229kickoff+0x41 ../../../libgo/runtime/proc.c:235 0: 0 [1024: 1048576] @ 0x800250a9 0x800250a9 0x8000c32b 0x8000c589 0x800ad279 0x8001e229 #0x8000c32bpprof_test.allocateTransient1M+0x23 /home/vogt/src/git/gcc/build-go/s390x-ibm-linux-gnu/libgo/gotest81795/test/mprof_test.go:21 #0x8000c589
[Bug c++/64936] regex, ECMA treated as posix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64936 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-10 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Please read https://gcc.gnu.org/bugs/ -- your testcase is incomplete and you didn't provide the requested information. Did you search for existing bugs and determine this is not a duplicate of PR61424?
[Bug libstdc++/64913] basic_string fails to use custom allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64913 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- And indeed if you fix the allocator (either by defining a correct my_allocator::rebind, or declaring it as private so std::allocator::rebind isn't found) then it compiles OK.
[Bug target/63347] [5 regression] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #13 from Bernd Schmidt bernds at gcc dot gnu.org --- Ugh, I see. I think the old method of just advancing should work with c6x - IIRC SCHED_GROUP_P isn't used there.
[Bug c++/64961] nested template implementation crossing namespace fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64961 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Clang gives exactly the same error.
[Bug tree-optimization/64995] [5 Regression] ICE in vn_reference_insert_pieces, at tree-ssa-sccvn.c:2341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64995 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Feb 10 13:37:54 2015 New Revision: 220581 URL: https://gcc.gnu.org/viewcvs?rev=220581root=gccview=rev Log: 2015-02-10 Richard Biener rguent...@suse.de PR tree-optimization/64995 * tree-ssa-sccvn.c (set_ssa_val_to): Assert that the value we use is final. (visit_reference_op_store): Always valueize op. (visit_use): Properly valueize vuses. * g++.dg/torture/pr64995.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr64995.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug c++/64961] nested template implementation crossing namespace fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64961 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- And I think the code is invalid. If you want to define the function, don't use a protected access path.
