[Bug target/53425] No warnings are given for -mno-sse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53425 jbeulich at novell dot com changed: What|Removed |Added CC||jbeulich at novell dot com --- Comment #4 from jbeulich at novell dot com --- I don't think this is quite right for 32-bit: For one, MMX types should be handled separately in that case. And there are now two warnings for both MMX and SSE types, i.e. the new one is redundant with the ones generated by function_arg_32(). I believe all that's needed is adding TARGET_64BIT to the conditional in type_natural_mode().
[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Actually, seems the 3 argument Intel intrinsic is _bextr_u{32,64}, while the
GCC
intrinsic is __bextr_u{32,64}, so guess the two can coexist, we just need to
add the 3 argument one.
[Bug fortran/57633] New: I/O: Problem with formatted read: reading an incomplete record under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633 Bug ID: 57633 Summary: I/O: Problem with formatted read: reading an incomplete record under Windows Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jb at gcc dot gnu.org, jvdelisle at gcc dot gnu.org The following seems to be a Windows only problem as I cannot reproduce it under Linux. See https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/mtERtiPKqu0 testcase.txt file: line1,1, line2 Produces the following output line11 0 Expected: line11 line25 Comment by BAF: I can confirm these result with the exact same program under mingw32 gfortran 4.8.0 20130302 (experimental) [trunk revision 196403]. To eliminate the concern about the end of line/record character for the second line of the file, I added a third line, so that the data file is now line1,1, line2 line3 The output remains the same, i.e. line11 0 Very strange. If I change the second read statement to be be read(11,*)s1 (i.e., change the formatted read to a list directed form), the output changes to what would be expected in either case line11 line25 Seems like the bug is related to the formatted read. Test program: program teststuff implicit none integer::a character(len=10)::s1 open(11,file=testcase.txt) read(11,*)s1,a write(*,*)s1,a read(11,(a))s1 write(*,*)s1, len_trim(s1) end program teststuff
[Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|I/O: Problem with formatted |I/O: Problem with formatted |read: reading an incomplete |read: reading CR-LF files |record under Windows|(\r\n) --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- I can reproduce the issue using the following test file: printf line1,1,\r\nline2\r\nline3 testcase.txt It works if one has \n instead of \r\n
[Bug tree-optimization/57634] New: Missed vectorization for a fixed point multiplication reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57634
Bug ID: 57634
Summary: Missed vectorization for a fixed point
multiplication reduction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
I the following code the loop in red does not vectorize becauseof
note: reduction: not commutative/associative: s_12 = (unsigned int) _11;
if I use unsigned long long everywhere as in redl the reason becomes
reduction: not commutative/associative: s_10 = temp_9 23;
the multiplication in itself vectorize… (for unsigned!)
compiled as
c++ -std=c++11 -march=corei7-avx -mavx2 -Ofast -S FixedF.cc
-ftree-vectorizer-verbose=2 -Wall
with gcc version 4.9.0 20130607 (experimental) [trunk revision 199812] (GCC)
inline
unsigned int mult(unsigned int a, unsigned int b) {
typedef unsigned long long ull; // (to support )
// a and b are of the form 1.m with m of Q bits as int is therefore max
2^(Q+2)-1. a*b is therefore 2^(2*(Q+2))
constexpr int Q = 23;
constexpr unsigned long long K = (1 (Q-1));
ull temp = (ull)(a) * (ull)(b); // result type is operand's type
// Rounding; mid values are rounded up
temp += K;
// Correct by dividing by base
return (temp Q);
}
inline
unsigned long long multL(unsigned long long a, unsigned long long b) {
typedef unsigned long long ull; // (to support )
// a and b are of the form 1.m with m of Q bits. As int is therefore max
2^(Q+2)-1. a*b is therefore 2^(2*(Q+2))
constexpr int Q = 23;
constexpr unsigned long long K = (1 (Q-1));
ull temp = (ull)(a) * (ull)(b);
// Rounding; mid values are rounded up
temp += K;
// Correct by dividing by base
return (temp Q);
}
unsigned int a[1024];
unsigned int b[1024];
unsigned int c[1024];
unsigned long long al[1024];
unsigned long long bl[1024];
unsigned long long cl[1024];
void foo() {
for (int i=0;i!=1204;++i)
c[i] = mult(a[i],b[i]);
}
unsigned int red() {
unsigned int s=1;
for (int i=0;i!=1204;++i)
s = mult(s,b[i]);
return s;
}
unsigned long long redL() {
unsigned long long s=1;
for (int i=0;i!=1204;++i)
s = multL(s,b[i]);
return s;
}
unsigned int prod() {
unsigned int s=1;
for (int i=0;i!=1204;++i)
s = s*b[i];
return s;
}
[Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Another comment, which I missed to pass on from the original report: It is crucial that the first line ends with a comma; without comma it works.
[Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-17 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug c/57635] New: gcc hanging while compiling huge files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635 Bug ID: 57635 Summary: gcc hanging while compiling huge files Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vijunag at gmail dot com to gcc Hello, I recently upgraded my compiler to 4.7.2 and I'm trying to compile a huge file containing as much as 92840 lines and gcc is taking an eternity to compile. (more than 18 hours) I see via top command that CC1 is consuming 100 percent CPU. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14848 vinag 25 0 485m 413m 8196 R 99.9 0.4 64:41.24 cc1 I tried to attach to CC1 in gdb and below are few snapshots of it under gdb snapshot 1 Program received signal SIGINT, Interrupt. 0x0052f775 in find_base_term () (gdb) bt #0 0x0052f775 in find_base_term () #1 0x0052f924 in find_base_term () #2 0x0052fa45 in base_alias_check () #3 0x00531823 in true_dependence_1 () #4 0x00531a31 in canon_true_dependence () #5 0x005acf58 in cselib_invalidate_mem () #6 0x005ad14c in cselib_invalidate_rtx () #7 0x005ad170 in cselib_invalidate_rtx_note_stores () #8 0x00816458 in note_stores () #9 0x005ad935 in cselib_record_sets () #10 0x005add94 in cselib_process_insn () #11 0x00a4b78a in vt_initialize () #12 0x00a4beda in variable_tracking_main_1 () #13 0x00a4be47 in variable_tracking_main () #14 0x007a6b89 in execute_one_pass () #15 0x007a6ef8 in execute_pass_list () #16 0x007a6f16 in execute_pass_list () #17 0x007a6f16 in execute_pass_list () #18 0x008ddc76 in tree_rest_of_compilation () #19 0x005a0a28 in cgraph_expand_function () #20 0x005a0be4 in cgraph_expand_all_functions () #21 0x005a14f0 in cgraph_optimize () #22 0x0059f498 in cgraph_finalize_compilation_unit () #23 0x0049d927 in c_write_global_declarations () #24 0x0087865e in compile_file () #25 0x0087a8e7 in do_compile () #26 0x0087aa34 in toplev_main () #27 0x0052a17f in main () (gdb) c Continuing. snapshot2 (gdb) bt #0 0x0052f7ea in find_base_term () #1 0x0052f924 in find_base_term () #2 0x0052f7cf in find_base_term () #3 0x0052f924 in find_base_term () #4 0x0052fa45 in base_alias_check () #5 0x00531823 in true_dependence_1 () #6 0x00531a31 in canon_true_dependence () #7 0x005acf58 in cselib_invalidate_mem () #8 0x005ad14c in cselib_invalidate_rtx () #9 0x005ad170 in cselib_invalidate_rtx_note_stores () #10 0x00816458 in note_stores () #11 0x005ad935 in cselib_record_sets () #12 0x005add94 in cselib_process_insn () #13 0x00a4b78a in vt_initialize () #14 0x00a4beda in variable_tracking_main_1 () #15 0x00a4be47 in variable_tracking_main () #16 0x007a6b89 in execute_one_pass () #17 0x007a6ef8 in execute_pass_list () #18 0x007a6f16 in execute_pass_list () #19 0x007a6f16 in execute_pass_list () #20 0x008ddc76 in tree_rest_of_compilation () #21 0x005a0a28 in cgraph_expand_function () #22 0x005a0be4 in cgraph_expand_all_functions () #23 0x005a14f0 in cgraph_optimize () #24 0x0059f498 in cgraph_finalize_compilation_unit () #25 0x0049d927 in c_write_global_declarations () #26 0x0087865e in compile_file () #27 0x0087a8e7 in do_compile () #28 0x0087aa34 in toplev_main () #29 0x0052a17f in main () I'm little bit surprised because same file I was able to compile with my older gcc compiler 3.3. i686-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=~/tools/bintools/linux-x86/gcc/201302221200/bin/i686-pc-linux-gnu-gcc-wrapped COLLECT_LTO_WRAPPER=~/tools/bintools/linux-x86/gcc/201302221200/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../../gcc/configure --build=amd64-pc-linux-gnu --host=amd64-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++ --prefix=~tools/bintools/linux-x86/gcc/201302221200 --enable-shared --with-headers=/tmp/201302221200/new_header/ --disable-libquadmath --disable-libgomp --disable-libssp --disable-libmudflap --disable-libitm --with-fast-fixincludes --enable-threads --site=starent --with-gnu-as --with-gnu-ld Thread model: posix gcc version 4.7.2 (GCC) i586-pc-linux-gnu-gcc -c ternary.c i586-pc-linux-gnu-gcc -v Reading specs from ~/tools/bintools/linux-x86/gcc/200608191248/lib/gcc-lib/i586-pc-linux-gnu/3.3.6/specs Configured with: ../../gcc/configure --build=i686-linux --host=i686-linux --target=i586-pc-linux-gnu --enable-languages=c,c++
[Bug c/57630] Error should include -std=c11 and friends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-17 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Created attachment 30315 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30315action=edit pr57630.patch That's true, so maybe something like the attached.
[Bug c/57635] gcc hanging while compiling huge files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635 --- Comment #1 from vijay Nag vijunag at gmail dot com --- Let me know if you will need any additional information. It is also difficult to isolate one single huge file from my project to attach it here. It will be great if you can suggest me to proceed in some direction to debug this issue.
[Bug c/57630] Error should include -std=c11 and friends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Attachment #30315|0 |1 is obsolete|| --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Created attachment 30316 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30316action=edit pr57630.patch Actually, this one.
[Bug target/57636] New: cr16: ICE while building libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636 Bug ID: 57636 Summary: cr16: ICE while building libgcc Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stefan at astylos dot dk Target: cr16-none-elf # ./configure --target cr16-none-elf # make all-gcc all-target-libgcc' ... make[4]: Entering directory `/home/ssorensen/sources/gcc-build/cr16-none-elf/far-pic/libgcc' # If this is the top-level multilib, build all the other # multilibs. /home/ssorensen/sources/gcc-build/./gcc/xgcc -B/home/ssorensen/sources/gcc-build/./gcc/ -B/usr/local/cr16-none-elf/bin/ -B/usr/local/cr16-none-elf/lib/ -isystem /usr/local/cr16-none-elf/include -isystem /usr/local/cr16-none-elf/sys-include-g -O2 -fPIC -mcr16cplus -mdata-model=far -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _udivmoddi4.o -MT _udivmoddi4.o -MD -MP -MF _udivmoddi4.dep -DL_udivmoddi4 -c ../../../../gcc/libgcc/libgcc2.c \ -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc/libgcc/libgcc2.c: In function ‘__udivmoddi4’: ../../../../gcc/libgcc/libgcc2.c:1112:1: internal compiler error: in variable_post_merge_new_vals, at var-tracking.c:4430 } ^ 0x8d514b variable_post_merge_new_vals ../../gcc/gcc/var-tracking.c:4428 0x9e5cf7 htab_traverse_noresize ../../gcc/libiberty/hashtab.c:784 0x8d8511 dataflow_post_merge_adjust ../../gcc/gcc/var-tracking.c:4540 0x8d8511 vt_find_locations ../../gcc/gcc/var-tracking.c:6965 0x8de854 variable_tracking_main_1 ../../gcc/gcc/var-tracking.c:10166 0x8de854 variable_tracking_main() ../../gcc/gcc/var-tracking.c:10212 Removing either the -g or the -O2 from the compile command avoids the ICE. It was introduced in trunk@188870: 2012-06-21 Alexandre Oliva aol...@redhat.com PR debug/53671 PR debug/49888 * var-tracking.c (vt_initialize): Record initial offset between arg pointer and stack pointer.
[Bug c/57630] Error should include -std=c11 and friends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630 --- Comment #3 from lailavrazda1979 at gmail dot com --- Looks good to me.
[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This happens on Linux too. The issue is that per C++11 (see 18.6) operator new is declared in new as: void* operator new(size_t mem); (1) and as such is internally pre-declared in decl.c:cxx_init_decl_processing. Then, if I understand correctly, when the parser sees in user code: void* operator new(size_t mem) throw(std::bad_alloc); it thinks, Ok the user is just redeclaring (1), it simply ignores the exception specifier. Then the additional declaration in user code is seen inconsistent with the former one (it becomes clear that the exception specifier was dropped the first time). We (used to) have a completely similar, dual, issue in C++98 for this user code: void* operator new(std::size_t mem); void* operator new(std::size_t mem); and I'm not sure whether and how we want to do better. Note that changing in C++11 the user code to: void* operator new(std::size_t mem); void* operator new(std::size_t mem); is perfectly fine.
[Bug target/57637] New: Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 Bug ID: 57637 Summary: Miscompare on 178.galgel in SPEC2000 on arm Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: bernds at codesourcery dot com, zhenqiang.chen at linaro dot org Target: armv7l-unknown-linux-gnueabihf We're getting a miscompare on the 178.galgel benchmark in SPEC2000 on armv7l-unknown-linux-gnueabihf, on a Cortex-A15. The .mis file just says 'galgel.out' short. Bisection shows it started with r199439. 2013-05-30 Bernd Schmidt ber...@codesourcery.com Zhenqiang Chen zhenqiang.c...@linaro.org config/arm/arm-protos.h: Add and update function protos. config/arm/arm.c (use_simple_return_p): New added. (thumb2_expand_return): Check simple_return flag. config/arm/arm.md: Add simple_return and conditional simple_return. config/arm/iterators.md: Add iterator for return and simple_return. The compiler was configured: --with-cpu=cortex-a15 --with-fpu=neon-vfpv4 --with-mode=thumb --with-float=hard --enable-languages=c,c++,fortran The flags for the benchmark are -ffixed-form -mthumb -mcpu=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=hard -O3. It works with -O1, fails at -O2 and -O3
[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-06-17
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |4.8.2
Ever confirmed|0 |1
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Interesting because we do fold the call and end up with
f (int i)
{
int _3;
bb 2:
_3 = 0;
if (_3 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
error ();
bb 4:
return;
where the zero does not end up being propagated into the conditional
at any point further down into the compilation ... (TER is disabled
which is what usually saves us here).
A simple solution is to exchange pass_fold_builtins and pass_dce in
pass_all_optimizations_g.
[Bug lto/57613] [LTO] error multiple definition symbol for local symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-17 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I don't think it works that way, hidden visibility makes it non-exported from the dynamic object but it's still visible inside the object. You probably want to mark it local instead?
[Bug c++/53184] Unnecessary anonymous namespace warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- I've just come across a case where an option to disable that warning would be handy: We have a foo.cc file defining some classes in an anon namespace. A unit test does #include foo.cc so it can test the implementation details, which makes GCC (quite rightly) think it's a header file. In this case no other translation unit is going to include the header and so there will be no ODR violation, but we can't disable the warning so have to resort to macros to give the namespace a name when used in this way, which means the test isn't testing the real code.
[Bug c++/53184] Unnecessary anonymous namespace warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Somebody could suggest an appropriate name for the warning. Then a patchlet would be easy to do and also easy to approve I think (naming warnings is in general a sensible idea)
[Bug c++/53184] Unnecessary anonymous namespace warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- ... and of course a clearer wording for the warning itself.
[Bug bootstrap/53394] Stage2 does not pass CFLAGS or LDFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53394 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- No feedback in over a year
[Bug c++/16128] Diagnostic of missing argument list within functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16128 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|gcc-bugs at gcc dot gnu.org| Resolution|--- |FIXED Assignee|giovannibajo at libero dot it |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Redundant error messages about semicolons fixed in 4.9.0.
[Bug fortran/49802] [F2003, F2008] Wrong code with VALUE, F2008: VALUE with arrays/DIMENSION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-17 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test in comment #3 (with (*) changed to (10)) aborts because the test if (str /= abcdefghij) call abort() fails (str==123456789). Is it expected? I also confirm that compiling the test in comment #5 gives an ICE pr49802_2.f90:6:0: internal compiler error: in fold_convert_loc, at fold-const.c:2075 if (present(str)) print *, str
[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Waiting.
[Bug fortran/51610] [OOP] Class container does not properly handle POINTER and TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Waiting.
[Bug fortran/55895] multiple type-bound procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55895 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- No answer since five months. Closing as INVALID. Please reopen if I am wrong.
[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- The original testcase (in Comment #0) is fixed in 4.8.1 and mainline as duplicate of PR56794.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- (gdb) p debug_tree (fn-decl) function_decl 0x77045f00 soap_getindependent type function_type 0x77042e70 type integer_type 0x76f155e8 int public SI size integer_cst 0x76f190a0 constant 32 unit size integer_cst 0x76f190c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76f155e8 precision 32 min integer_cst 0x76f19040 -2147483648 max integer_cst 0x76f19060 2147483647 pointer_to_this pointer_type 0x76f1d2a0 QI size integer_cst 0x76f04ee0 constant 8 unit size integer_cst 0x76f04f00 constant 1 align 8 symtab 0 alias set 0 canonical type 0x77042dc8 public static QI file a.i line 5 col 1 align 8 context translation_unit_decl 0x77049000 D.2387 initial block 0x7704d000 result result_decl 0x77047438 D.2391 type integer_type 0x76f155e8 int ignored SI file a.i line 5 col 1 size integer_cst 0x76f190a0 32 unit size integer_cst 0x76f190c0 4 align 32 context function_decl 0x77045b00 soap_getindependent struct-function 0x76f10140 $1 = void (gdb) p debug_tree (gimple_label_label (stmt)) label_decl 0x7704e000 D.2393 type void_type 0x76f15bd0 void VOID align 8 symtab 0 alias set -1 canonical type 0x76f15bd0 pointer_to_this pointer_type 0x76f15c78 ignored VOID file a.i line 8 col 1 align 1 context function_decl 0x77045b00 soap_getindependent $2 = void (gdb) p debug_tree ((tree)0x77045b00) function_decl 0x77045b00 soap_getindependent type function_type 0x77042e70 type integer_type 0x76f155e8 int public SI size integer_cst 0x76f190a0 constant 32 unit size integer_cst 0x76f190c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76f155e8 precision 32 min integer_cst 0x76f19040 -2147483648 max integer_cst 0x76f19060 2147483647 pointer_to_this pointer_type 0x76f1d2a0 QI size integer_cst 0x76f04ee0 constant 8 unit size integer_cst 0x76f04f00 constant 1 align 8 symtab 0 alias set 0 canonical type 0x77042dc8 static QI file b.i line 2 col 1 align 8 context translation_unit_decl 0x76f20f18 D.2381 result result_decl 0x77047168 D.2382 type integer_type 0x76f155e8 int ignored SI file b.i line 2 col 1 size integer_cst 0x76f190a0 32 unit size integer_cst 0x76f190c0 4 align 32 context function_decl 0x77045b00 soap_getindependent $3 = void (gdb) p debug_symtab_node (symtab_get_node ((tree)0x77045b00)) soap_getindependent/2 (soap_getindependent) @0x76f0d980 Type: function definition analyzed Visibility: force_output prevailing_def_ironly next sharing asm name: 6 References: Referring: Read from file: libx.a Availability: available Function flags: Called by: Calls: $6 = void (gdb) p debug_symtab_node (symtab_get_node (fn-decl)) soap_getindependent/6 (soap_getindependent) @0x76f0de40 Type: function definition analyzed Visibility: force_output externally_visible prevailing_def_ironly public previous sharing asm name: 2 References: Referring: Read from file: libx.a Availability: available Function flags: body Called by: Calls: so the problem seems to be that while reading body of the static function soap_getindependent we manage to mess the context with global function in the other file. I am not terribly familiar on how LTO sections are mapped...
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #182 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, after a while I should update the stats here. Richard's new tree merging patch makes libxul linking a lot faster and less memory consuming. Peak memory usage (in TOP) is now just bellow 10GB, with bit of incremental improvmenets I hope to get bellow 8GB again soon. Bulid time is real19m0.355s user56m20.459s sys 2m17.533s GGC memory usage after stream in 4938399k Execution times (seconds) phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 1399 kB ( 0%) ggc phase opt and generate : 72.86 (12%) usr 0.90 ( 3%) sys 75.25 (11%) wall 270952 kB ( 7%) ggc phase stream in : 274.88 (44%) usr 9.01 (26%) sys 294.99 (43%) wall 3478515 kB (93%) ggc phase stream out: 282.18 (45%) usr 24.40 (71%) sys 308.42 (45%) wall 7162 kB ( 0%) ggc garbage collection : 12.99 ( 2%) usr 0.01 ( 0%) sys 13.00 ( 2%) wall 0 kB ( 0%) ggc callgraph optimization : 1.95 ( 0%) usr 0.00 ( 0%) sys 1.95 ( 0%) wall 32 kB ( 0%) ggc ipa cp : 9.82 ( 2%) usr 0.39 ( 1%) sys 10.26 ( 2%) wall 418482 kB (11%) ggc ipa inlining heuristics : 39.30 ( 6%) usr 1.12 ( 3%) sys 41.52 ( 6%) wall 1353294 kB (36%) ggc ipa lto gimple in : 0.45 ( 0%) usr 0.15 ( 0%) sys 0.62 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple out : 18.24 ( 3%) usr 1.50 ( 4%) sys 19.86 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl in : 200.68 (32%) usr 5.85 (17%) sys 216.44 (32%) wall 3887175 kB (103%) ggc ipa lto decl out: 256.24 (41%) usr 13.44 (39%) sys 271.24 (40%) wall 0 kB ( 0%) ggc ipa lto cgraph I/O : 7.20 ( 1%) usr 1.61 ( 5%) sys 8.83 ( 1%) wall 2134157 kB (57%) ggc ipa lto decl merge : 27.71 ( 4%) usr 0.01 ( 0%) sys 27.72 ( 4%) wall 8270 kB ( 0%) ggc ipa lto cgraph merge: 17.31 ( 3%) usr 0.07 ( 0%) sys 17.39 ( 3%) wall 142240 kB ( 4%) ggc whopr wpa : 8.82 ( 1%) usr 0.04 ( 0%) sys 8.89 ( 1%) wall 7165 kB ( 0%) ggc whopr wpa I/O : 1.63 ( 0%) usr 9.43 (27%) sys 11.19 ( 2%) wall 0 kB ( 0%) ggc whopr partitioning : 3.21 ( 1%) usr 0.04 ( 0%) sys 3.25 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 5.56 ( 1%) usr 0.04 ( 0%) sys 5.81 ( 1%) wall 0 kB ( 0%) ggc ipa profile : 1.83 ( 0%) usr 0.02 ( 0%) sys 1.86 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 6.07 ( 1%) usr 0.18 ( 1%) sys 6.26 ( 1%) wall 0 kB ( 0%) ggc inline parameters : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 14 kB ( 0%) ggc tree copy propagation : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree PTA: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree SSA rewrite: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 27 kB ( 0%) ggc tree SSA other : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CCP: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc dominance computation : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc varconst: 0.14 ( 0%) usr 0.12 ( 0%) sys 0.24 ( 0%) wall 0 kB ( 0%) ggc unaccounted todo: 10.69 ( 2%) usr 0.29 ( 1%) sys 11.10 ( 2%) wall 0 kB ( 0%) ggc TOTAL : 629.9334.31 678.67 3758029 kB Memory usage seems about the same with -g. Honza
[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- For comment #1, it looks like there is something wrong in instantiation_dependent_expression_p: when finish_decltype_type calls it for arr it returns false, where it seems obvious that it should be true. This static_assert succeeds: static_assert(sizeof(arr) == sizeof(int) * sizeof...(Args), complete type);
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-06-17
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org ---
I am testing
Index: lto-symtab.c
===
--- lto-symtab.c(revision 200151)
+++ lto-symtab.c(working copy)
@@ -523,7 +523,8 @@ lto_symtab_merge_decls (void)
FOR_EACH_SYMBOL (node)
if (lto_symtab_symbol_p (node)
-node-symbol.next_sharing_asm_name)
+(node-symbol.next_sharing_asm_name
+ || node-symbol.previous_sharing_asm_name))
{
symtab_node n;
@@ -639,6 +640,7 @@ lto_symtab_prevailing_decl (tree decl)
ret = symtab_node_for_asm (DECL_ASSEMBLER_NAME (decl));
if (!ret)
return decl;
+ gcc_checking_assert (TREE_PUBLIC (ret-symbol.decl) !DECL_EXTERNAL
(ret-symbol.decl));
return ret-symbol.decl;
}
[Bug fortran/53950] [4.7/4.8/4.9 Regression] 1.5 times slowdown from 4.4.0 to 4.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53950 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW Summary|1.5 times slowdown from |[4.7/4.8/4.9 Regression] |4.4.0 to 4.7.0 |1.5 times slowdown from ||4.4.0 to 4.7.0 with -m32 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- On a Core2Duo 2.5Ghz under x86_64-apple-darwin10, I get -m64 -m32 4.9.01.9743720 2.2397862 4.8.12.0542710 2.2539010 4.7.31.9538360 2.2104399 4.6.41.9587610 2.1613581 4.5.42.0137279 2.3153970 4.4.71.9963471 1.9965631 Note that with 4.8 and trunk, I had to change slightly the code otherwise the loop is optimized out.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #183 from Jan Hubicka hubicka at gcc dot gnu.org --- type merging stats [WPA] read 43156894 SCCs of average size 2.270660 [WPA] 97994652 tree bodies read in total [WPA] tree SCC table: size 8388593, 3830511 elements, collision ratio: 0.684487 [WPA] tree SCC max chain length 88 (size 1) [WPA] Compared 19139975 SCCs, 344923 collisions (0.018021) [WPA] Merged 19067050 SCCs [WPA] Merged 58757829 tree bodies [WPA] Merged 11951381 types [WPA] 4357267 types prevailed (13278034 associated trees) [WPA] Old merging code merges an additional 2026163 types of which 140937 are in the same SCC with their prevailing variant (12389865 and 6362266 associated trees) [WPA] GIMPLE canonical type table: size 131071, 77910 elements, 4357402 searches, 1095104 collisions (ratio: 0.251320) [WPA] GIMPLE canonical type hash table: size 8388593, 4357346 elements, 15252531 searches, 11817317 collisions (ratio: 0.774777) [WPA] # of input files: 4918 [WPA] # of input cgraph nodes: 0 [WPA] # of function bodies: 0 [WPA] # of output files: 0 [WPA] # of output symtab nodes: 0 [WPA] # of output tree pickle references: 0 [WPA] # of output tree bodies: 0 [WPA] # callgraph partitions: 0 [WPA] Compression: 1311851796 input bytes, 4153897270 uncompressed bytes (ratio: 3.166438) [WPA] Size of mmap'd section decls: 1311851796 bytes [LTRANS] read 314277 SCCs of average size 6.082532 [LTRANS] 1911600 tree bodies read in total [LTRANS] GIMPLE canonical type table: size 16381, 9653 elements, 453967 searches, 24697 collisions (ratio: 0.054403) [LTRANS] GIMPLE canonical type hash table: size 1048573, 453913 elements, 1562009 searches, 1517260 collisions (ratio: 0.971352) [LTRANS] # of input files: 1 [LTRANS] # of input cgraph nodes: 0 [LTRANS] # of function bodies: 0
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #5 from Alan Hourihane alanh at fairlite dot co.uk --- any news ?
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #13 from Harald Anlauf anlauf at gmx dot de --- Hi Ryo! (In reply to Ryo Furue from comment #10) (In reply to Dominique d'Humieres from comment #7) AFAICT the option -fno-range-check is what you are looking for. Thanks! That's exactly it. But, I'm curious. The following code still fails to compile even with -fno-range-check : program try real, parameter:: a = -1.0 if (a 0) then write(*,*) sqrt(a) end if end program try $ gfortran -fno-range-check tmp.f90 tmp.f90:4.20: write(*,*) sqrt(a) 1 Error: Argument of SQRT at (1) has a negative value $ Is this an inconsistency in the implementation of -no-range-check ? I would be nice if there were an option to demote this type of error to a warning. I would also prefer if gfortran behaved as you suggested. Other compilers appear to generate warnings only, or no comment. After all, the code path in question never gets executed. I am afraid that the Fortran standard document does not give much help here and may allow gfortran's behavior. Nevertheless I recommend to ask in comp.lang.fortran where you'll probably get a better explanation. Cheers, Ryo
[Bug c++/57638] New: warning container: 'integer_cst’ not supported by dump_type#type error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Bug ID: 57638
Summary: warning container: 'integer_cst’ not supported by
dump_type#type error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at bubblescope dot net
The following code (notice the function takes a long long, the template takes
an int. This code is invalid)
templateint x
struct S {};
templatelong long i
void g(Si);
void f()
{
S1000 t;
g(t);
}
Produces the warning (in svn head and 4.7.0)
t.cc: In function ‘void f()’:
t.cc:11:8: error: no matching function for call to ‘g(S1000)’
g(t);
^
t.cc:11:8: note: candidate is:
t.cc:6:6: note: templatelong long int i void g(Si)
void g(Si);
^
t.cc:6:6: note: template argument deduction/substitution failed:
t.cc:11:8: note: mismatched types ‘long long int’ and ‘#‘integer_cst’ not
supported by dump_type#type error’
g(t);
^
t.cc:11:8: note: ‘S1000’ is not derived from ‘Si’
[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- There exists a related core language issue for this: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#967 Originally it was submitted when these function had an exception specification, but in C++11 the situation is different. Nonetheless I believe that this issue might influence whether this will turn out to be a gcc bug or not.
[Bug fortran/57639] New: ICE with polymorphism (and illegal code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57639 Bug ID: 57639 Summary: ICE with polymorphism (and illegal code) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Bug encountered with a snapshot of todays (June 17, 2013) trunk. The example compiles ok with 'allocatable' attribute specified (and the related allocate statement used) for variables t1 and t2. However if the allocatable attribute is omitted, (and allocate statement removed), gfortran gives a correct error message and then ICEs. module class_mod implicit none contains function compare (a, b) class(*), intent(in), allocatable :: a, b logical :: compare compare = SAME_TYPE_AS (a, b) end function end module program unlimited_test use class_mod implicit none type wws integer :: a, b end type ! When t1 and t2 are given the 'allocatable' attribute, ! and the allocate statement is used, this example compiles ! and runs correctly. However if the 'allocatable' attribute ! and the allocate statement are removed, the compiler issues ! the correct error message and then ICEs. class(*) :: t1, t2 ! allocate (wws::t1, t2) print *, 'main: compare = ', compare (t1, t2) end program wws@w6ws-4:~/fortran/f2008$ gfortran --version GNU Fortran (GCC) 4.9.0 20130617 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING wws@w6ws-4:~/fortran/f2008$ gfortran -c unlimited_test.f90 unlimited_test.f90:29.16: class(*) :: t1, t2 1 Error: CLASS variable 't1' at (1) must be dummy, allocatable or pointer unlimited_test.f90:29.20: class(*) :: t1, t2 1 Error: CLASS variable 't2' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault 0x96fcaf crash_signal ../../gcc-trunk/gcc/toplev.c:333 0x53a009 compare_parameter ../../gcc-trunk/gcc/fortran/interface.c:1982 0x53a009 compare_actual_formal ../../gcc-trunk/gcc/fortran/interface.c:2567 0x53ad33 gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*) ../../gcc-trunk/gcc/fortran/interface.c:3269 0x585fe0 resolve_specific_f0 ../../gcc-trunk/gcc/fortran/resolve.c:2612 0x585fe0 resolve_specific_f ../../gcc-trunk/gcc/fortran/resolve.c:2637 0x585fe0 resolve_function ../../gcc-trunk/gcc/fortran/resolve.c:2905 0x585fe0 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:6083 0x58bd2b resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9685 0x58ba7b gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:8998 0x58bd09 resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9675 0x58e8be resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14464 0x57fe82 gfc_resolve ../../gcc-trunk/gcc/fortran/resolve.c:14492 0x5749aa resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4442 0x5749aa gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4691 0x5b0a45 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. wws@w6ws-4:~/fortran/f2008$
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #14 from Ryo Furue furue at hawaii dot edu --- (In reply to Steve Kargl from comment #11) Overall, I think this kind of thing is better be a warning and that at least the compiler should allow the user to run such a code as this. The result of the run may be a disaster but it's the user's responsibility. To refuse to compile these codes is too much patronizing on the part of the compiler. I think that it is better to issue an error. The fact that you think so doesn't prevent you from giving gfortran an option to demote it to a warning, does it? because that would please both camps. Other users (at least two of us) think a warning is better. And I gave an example where a warning is better suited to the purpose at hand. gfortran does not support the IEEE 2003 standard. No one has stepped up to the plate. Here's your chance to make gfortran doe whatever you think the standard mandates. I'm not saying gfortran should implement the IEEE 2003 standard. I was just wondering whether the extension of replacing 1.0/0.0 with Inf now (-fno-range-check does that) would become more in harmony with the IEEE 2003 standard when gfortran implements it in the future. If so, replacing 1.0/0.0 with Inf as a default behavior (with a warming message) may be a better choice now. I was just wondering. I may be wrong. That may be a bad extension now. Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #15 from Ryo Furue furue at hawaii dot edu --- (In reply to Harald Anlauf from comment #13) Hi Harald, Thanks for your message. I would also prefer if gfortran behaved as you suggested. Other compilers appear to generate warnings only, or no comment. After all, the code path in question never gets executed. I am afraid that the Fortran standard document does not give much help here and may allow gfortran's behavior. I'm pretty sure that the Fortran standard allows gfortran's behavior. I'm not arguing that it's a violation of the standard. I'm just asking for an option to change the behavior (which would also within the standard). The question is what is the best way to deal with illegal bits of code. There, there are a number of choices all within the standard. For example, with this program try real:: a(10) = 1.0/0.0 write(10) a end program try the compiler is allowed to do anything and there is no single answer as to what's best. In some circumstances, to stop compiling with an error message is the best way (gfortran's default behavior); in some circumstances, to replace the constant expression with the IEEE +Infinity value and let the code pass (-fno-range-check) is a better choice. I certainly would write such a code as the above to get a binary array of Infinities. (It's a quick-n-dirty way but it works in practice.) In other circumstances, the compiler can send en email message to the writer of such a code, pointing out the stupidity of it :-) Cheers, Ryo
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #7 from Martin Liška marxin.liska at gmail dot com --- I've updated to latest gcc, all previous bugs are irrelevant: I mixed different -Ox cflags and chromium build system is full of hacks (they use gold as a primary linker, but bfd is used for some stuff, I used just bfd in my compilation). gcc --version: gcc (GCC) 4.9.0 20130617 (experimental) I finally reached WPA stage of LTO, memory usage was about 8GB for ld and 11 GB for lto1. lto1 was running for about 20 minutes and following error occured: lto1: error: ELF section name out of range lto1: internal compiler error: Segmentation fault 0x85e0bf crash_signal ../../gcc/toplev.c:333 0xd7f0dd htab_delete ../../libiberty/hashtab.c:419 0x50a41c lto_file_read ../../gcc/lto/lto.c:2824 0x50a41c read_cgraph_and_symbols ../../gcc/lto/lto.c:3401 0x50a41c lto_main() ../../gcc/lto/lto.c:3834 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: g++ returned 1 exit status /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: lto-wrapper failed collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. Do you have any ideas?
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #16 from Ryo Furue furue at hawaii dot edu --- (In reply to Steve Kargl from comment #12) On Sun, Jun 16, 2013 at 11:33:49PM +, furue at hawaii dot edu wrote: Is this an inconsistency in the implementation of -no-range-check ? No. Then, what's the counterpart of -fno-range-check that takes care of such cases as sqrt? To repeat the code: real, parameter:: a = -1.0 if (a 0) write(*,*) sqrt(a) With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN and let the code pass. Or is it better to extend -fno-range-check to cover these cases, too? Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #17 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Mon, Jun 17, 2013 at 10:07:32PM +, furue at hawaii dot edu wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #16 from Ryo Furue furue at hawaii dot edu --- (In reply to Steve Kargl from comment #12) On Sun, Jun 16, 2013 at 11:33:49PM +, furue at hawaii dot edu wrote: Is this an inconsistency in the implementation of -no-range-check ? No. Then, what's the counterpart of -fno-range-check that takes care of such cases as sqrt? To repeat the code: real, parameter:: a = -1.0 if (a 0) write(*,*) sqrt(a) With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN and let the code pass. Why not replace it with 0 instead of NaN? Afterall, the real part of the imaginary number i (or j if you're an electrical engineer) is 0? 13.7.159 SQRT(X) Argument. X shall be of type real or complex. Unless X is complex, its value shall be greater than or equal to zero. Those shall be phrases are fair strong statements. Yeah, I get it. You don't like the choice that gfortran made 10+ years ago.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added CC||marxin.liska at gmail dot com --- Comment #7 from Martin Liška marxin.liska at gmail dot com --- gcc --version: gcc (GCC) 4.9.0 20130617 (experimental) lto1: internal compiler error: in lto_symtab_prevailing_decl, at lto-symtab.c:644 0x783c63 lto_symtab_prevailing_decl(tree_node*) ../../gcc/lto-symtab.c:644 0x50afe4 lto_fixup_prevailing_decls ../../gcc/lto/lto.c:3220 0x50afe4 lto_fixup_decls ../../gcc/lto/lto.c:3284 0x50afe4 read_cgraph_and_symbols ../../gcc/lto/lto.c:3490 0x50afe4 lto_main() ../../gcc/lto/lto.c:3834 Dump (--save-temps --dump-ipa-all): https://docs.google.com/file/d/0B0pisUJ80pO1X2w0eXgteHlvNDQ/edit?usp=sharing
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 --- Comment #8 from Martin Liška marxin.liska at gmail dot com --- Sorry, comment was not added to related linker kernel bug 57483.
[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483 --- Comment #1 from Martin Liška marxin.liska at gmail dot com --- gcc --version: gcc (GCC) 4.9.0 20130617 (experimental) lto1: internal compiler error: in lto_symtab_prevailing_decl, at lto-symtab.c:644 0x783c63 lto_symtab_prevailing_decl(tree_node*) ../../gcc/lto-symtab.c:644 0x50afe4 lto_fixup_prevailing_decls ../../gcc/lto/lto.c:3220 0x50afe4 lto_fixup_decls ../../gcc/lto/lto.c:3284 0x50afe4 read_cgraph_and_symbols ../../gcc/lto/lto.c:3490 0x50afe4 lto_main() ../../gcc/lto/lto.c:3834 Dump (--save-temps --dump-ipa-all): https://docs.google.com/file/d/0B0pisUJ80pO1X2w0eXgteHlvNDQ/edit?usp=sharing
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #9 from Martin Liška marxin.liska at gmail dot com ---
Simple error case:
/tmp/x.c
char dnet_ntoa();
int main() {
dnet_ntoa()
; return 0; }
gcc -flto /tmp/x.c
Result:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab.c:644
0x500719 lto_fixup_state
../../gcc/lto/lto.c:3257
0x50ab48 lto_fixup_decls
../../gcc/lto/lto.c:3290
0x50ab48 read_cgraph_and_symbols
../../gcc/lto/lto.c:3490
0x50ab48 lto_main()
../../gcc/lto/lto.c:3834
Should return for: gcc /tmp/x.c
/tmp/ccZU5rdy.o: In function `main':
x.c:(.text+0xa): undefined reference to `dnet_ntoa'
collect2: error: ld returned 1 exit status
[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 --- Comment #3 from Bas Vodde b...@odd-e.com --- Thanks for the comments. I understand the problems in implementing a compiler, when this is also unclear in the language itself. Whatever is decided related to this, it would probably be a good idea to give a better error message. Right now, the error message is telling the user that the operator new *with* an exception specifier doesn't have one and that they are different, even though the two lines are exactly the same. It is a bit confusing. It would be good though to solve this in a way that both works with C++11 and C++03 as it came up when compiling a piece of code that is used by multiple compilers and by both language versions.
[Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- We need to audit all places where '\n' is used and make sure we are taking care of the '\r' properly in read.c , etc. Then review what were are doing when we get a premature end of record. Maybe we are skipping a code path related to read buffers, like fbuf.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #18 from Ryo Furue furue at hawaii dot edu --- (In reply to Steve Kargl from comment #17) real, parameter:: a = -1.0 if (a 0) write(*,*) sqrt(a) With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN and let the code pass. Why not replace it with 0 instead of NaN? I think that would be another good choice. I'm not insisting on NaN at all. sqrt(-1.0) is undefined within real numbers, so NaN is one valid choice. But, as you say, it's defined in complex numbers, so converting it to zero is another valid choice. A third valid choice is to convert it to complex number (0.0,-1.0). I'm not saying which is the most valid. I just think NaN is the most sensible choice NOW, if we disregard the history of the Fortran language. (I guess the IEEE standard says that NaN is the result, but I'm not sure at all.) Yeah, I get it. You don't like the choice that gfortran made 10+ years ago. Not quite. Whether I like it or not doesn't matter. All I'm saying is that adding an option to convert those invalid numbers according to the IEEE rule (or in the absence of the IEEE rule for particular conversions, to some sensible numbers) and let the code pass would be a useful extension to gfortran NOW. Since it's a useful extension with little harm, that is a good addition to gfortran to enhance its usefulness, I think. Before signing off, I'd like to apologize for my submitting this as a bug. Through this conversation, I quickly realized I was wrong in thinking it is a bug. I should have submitted it as a wish, so that some of the developers might consider it as a future extension. Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #19 from Ryo Furue furue at hawaii dot edu --- (In reply to Ryo Furue from comment #18) Sorry again. I made English error. Yeah, I get it. You don't like the choice that gfortran made 10+ years ago. Not quite. I meant, You are not quite right in thinking that I don't like your choice. English is my second language and the use of not occasionally trips me up. Cheers, Ryo
[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #2 from Vladimir Makarov vmakarov at redhat dot com --- Andreas, thanks for checking it and doing the analysis. I'll try to make a patch fixing this on this week.
[Bug c++/57640] New: Explicit call of system literal operator complains about leading underscore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57640 Bug ID: 57640 Summary: Explicit call of system literal operator complains about leading underscore. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: 3dw4rd at verizon dot net Since we added literal operators to the standard library I noticed that if you explicitly call a std literal operator --- #include chrono using namespace std::literals::chrono_literals; auto blooper = operator min(45.0L); --- you get --- blooper.cc:5:27: warning: literal operator suffixes not preceded by ‘_’ are reserved for future standardization [enabled by default] auto blooper = operator min(45.0L); --- The definition in the system header doesn't trigger this but the explicit call in user code does. Mot fatal, and won't be commonly hit butI'd like to fix it.
[Bug c++/57640] Explicit call of system literal operator complains about leading underscore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57640 --- Comment #1 from Ed Smith-Rowland 3dw4rd at verizon dot net --- Created attachment 30317 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30317action=edit Add declarator_p to checks to trigger warning. Testing this fully but I think this tiny patch will do. gcc/cp: 2013-06-18 Ed Smith-Rowland 3dw...@verizon.net PR c++/57640 * parser.c (cp_parser_unqualified_id): Add declarator_p to checks to trigger warning, (cp_literal_operator_id): Remove bogus TODO comment. gcc/testsuite: 2013-06-18 Ed Smith-Rowland 3dw...@verizon.net PR c++/57640 * g++.dg/cpp1y/pr57640.C: New.
