Re: debug strings output order is arbitrary
On Sun, Mar 16, 2014 at 3:58 AM, Martin Uecker uec...@eecs.berkeley.edu wrote: Hi list, the strings in the .debug_str section are output in an arbitrary order. Could this be changed? The function 'output_indirect_strings' in 'gcc/dwarf2out.c' uses htab_traverse which then outputs the string in the order they appear in the hash table. Instead, it would be nicer to output them based on their labels (which are assigned based on the order of creation). This would minimize differences between builds with slightly different build environments, e.g. directory. Can you propose a patch? Note that at creation time only the string itself is known, so sorting after the string may be another possibility. Richard.
Re: [gsoc 2014] moving fold-const patterns to gimple
On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni bilbotheelffri...@gmail.com wrote: In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand constructor instead of OP_EXPR ? Indeed - I have committed the fix. Thanks, Richard. This caused segfault for patterns when simplification operand was only c_expr (patch attached). * genmatch.c (c_expr::c_expr): use OP_C_EXPR instead of OP_EXPR in call to operand constructor.
Re: builtin function - novops
On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane hariharan@gmail.com wrote: Hello, This question is similar to one raised by bingfeng here http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html In our private port based on GCC 4.8.1, i want to define a builtin function for multiply and accumulate. The function uses the input parameters and modifies the accumulator. The accumulator can be read using special builtin functions. If i had __builtin_mac (s-x[0], s-x[1]); __builtin_mac (s-x[0] + 5, s-x[1] + 5); I want s-x[0,1] to be loaded once and used for both invocations. I can not use either pure or constant since that will eliminate these functions. I tried using novops within builtin declaration in the port, but that doesn't seem to do the trick either. What attribute should i be using in this scenario? There isn't (and there can't be) a magic attribute that will make the compiler know that implicit dependency between those builtins. The only implicit dependency we have is global memory which means no attribute is the correct attribute to use. The other variant is to make the dependency explicit - which is hard as mac already has an output and a call can at most have one. There are several possible work-arounds - add a 2nd output via a address argument SPECIAL_DECL and add a fn spec attribute to the builtin that tells the alias machinery about the fns behavior (doesn't work - fn spec can't make the function otherwise const, something we'd need to fix) - do the above but special-case the builtins in the alias disambiguators to only consider memory dependences on that 2nd fake output - model the builtins not as builtins but as inline asm which can have multiple outputs Richard. Thanks and regards Hari
RE: builtin function - novops
In our case, we make MAC register explicit by defining a new type of register (data type). To use your mac instruction, you must have a first instruction to only write to the mac register. In the following mac builtins, the mac register can be both input/output and therefore dependency is respected and your builtins won't be optimized away. This is useful especially if you have multiple mac registers and requires gcc to do register allocation. Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 17 March 2014 09:12 To: Hariharan Sandanagobalane Cc: Bingfeng Mei; Andrew Haley; GCC Development Subject: Re: builtin function - novops On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane hariharan@gmail.com wrote: Hello, This question is similar to one raised by bingfeng here http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html In our private port based on GCC 4.8.1, i want to define a builtin function for multiply and accumulate. The function uses the input parameters and modifies the accumulator. The accumulator can be read using special builtin functions. If i had __builtin_mac (s-x[0], s-x[1]); __builtin_mac (s-x[0] + 5, s-x[1] + 5); I want s-x[0,1] to be loaded once and used for both invocations. I can not use either pure or constant since that will eliminate these functions. I tried using novops within builtin declaration in the port, but that doesn't seem to do the trick either. What attribute should i be using in this scenario? There isn't (and there can't be) a magic attribute that will make the compiler know that implicit dependency between those builtins. The only implicit dependency we have is global memory which means no attribute is the correct attribute to use. The other variant is to make the dependency explicit - which is hard as mac already has an output and a call can at most have one. There are several possible work-arounds - add a 2nd output via a address argument SPECIAL_DECL and add a fn spec attribute to the builtin that tells the alias machinery about the fns behavior (doesn't work - fn spec can't make the function otherwise const, something we'd need to fix) - do the above but special-case the builtins in the alias disambiguators to only consider memory dependences on that 2nd fake output - model the builtins not as builtins but as inline asm which can have multiple outputs Richard. Thanks and regards Hari
jump_table_data and active_insn_p
Why is jump_table_data an active_insn?
int
active_insn_p (const_rtx insn)
{
return (CALL_P (insn) || JUMP_P (insn)
|| JUMP_TABLE_DATA_P (insn) /* FIXME */
|| (NONJUMP_INSN_P (insn)
(! reload_completed
|| (GET_CODE (PATTERN (insn)) != USE
GET_CODE (PATTERN (insn)) != CLOBBER;
}
It is clear that someone [Steven Bosscher] thought it needs fixing but what's
the problem with just removing it from the OR-expression?
Cheers,
Paulo Matos
Re: Integration of ISL code generator into Graphite
Hi, First, I fully agree that integration of the ISL code generator into Graphite will be an important step forward for Graphite development. Regarding the implementation I have a question - why a new AST-like representation is needed ? It is not possible to generate the code directly from the ISL AST (with possible addition of new attributes/transformations) ? Regards, Mircea - Original Message - From: Roman Gareev gareevro...@gmail.com To: gcc@gcc.gnu.org Cc: Tobias Grosser tob...@grosser.es, Albert Cohen albert.co...@inria.fr, Mircea Namolaru mircea.namol...@inria.fr Sent: Friday, March 14, 2014 9:18:40 PM Subject: Integration of ISL code generator into Graphite Dear gcc contributors, I am going to try to participate in Google Summer of Code 2014. My project is Integration of ISL code generator into Graphite. My proposal can be found at on the following link https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing. I would be very grateful for your comments, feedback and ideas about its improvement. P.S. Sorry for the copy of this message, the previous one was declined by the MAILER-DAEMON. - Roman Gareev
RedHat patch not found in mainline gcc
At the company where I work, we have a large program using Boost Python (1.54). We do our product builds for RHEL 5 and recently started building using gcc 4.8 from RedHat devtoolset 2 for performance. This works well, except for one system where it would deterministically crash. I traced it to an old version of libgcc, and specifically this patch, which RedHat applied to its 5.5 release in 2009: http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/b5e52bbfb4bb11a6cbed452927fba979/files/118. I built libgcc myself with and without the patch, with the program crashing reliably without the patch, and no crash with the patch applied. Unfortunately, gdb does not show a meaningful stack trace, at least not the old version from RHEL 5. When trying to find out a bit more about the patch, I was rather surprised to see that (1) it is not applied to the mainline gcc code and (2) it still applies cleanly. Since I don't have a good stack trace, I cannot even try to build a suitable reproducer at the moment. Is there a good reason for not having it in mainline gcc? I suppose it got lost or forgotten somehow, and that it would be good to have it applied.
Re: Integration of ISL code generator into Graphite
Hi Mircea, thank you for your comment! I wanted to say, that this AST-like representation is an ISL AST containing only loops, conditions, and statements (basic blocks). It will be differ from a CLooG AST in representation of AST and, possibly, additional options of ISL AST generation. I'll try to eliminate this ambiguity in an improved version of the proposal. 2014-03-17 21:47 GMT+06:00 Mircea Namolaru mircea.namol...@inria.fr: Hi, First, I fully agree that integration of the ISL code generator into Graphite will be an important step forward for Graphite development. Regarding the implementation I have a question - why a new AST-like representation is needed ? It is not possible to generate the code directly from the ISL AST (with possible addition of new attributes/transformations) ? Regards, Mircea - Original Message - From: Roman Gareev gareevro...@gmail.com To: gcc@gcc.gnu.org Cc: Tobias Grosser tob...@grosser.es, Albert Cohen albert.co...@inria.fr, Mircea Namolaru mircea.namol...@inria.fr Sent: Friday, March 14, 2014 9:18:40 PM Subject: Integration of ISL code generator into Graphite Dear gcc contributors, I am going to try to participate in Google Summer of Code 2014. My project is Integration of ISL code generator into Graphite. My proposal can be found at on the following link https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing. I would be very grateful for your comments, feedback and ideas about its improvement. P.S. Sorry for the copy of this message, the previous one was declined by the MAILER-DAEMON. - Roman Gareev -- Cheers, Roman Gareev.
Re: debug strings output order is arbitrary
Am Mon, 17 Mar 2014 09:44:53 +0100 schrieb Richard Biener richard.guent...@gmail.com: On Sun, Mar 16, 2014 at 3:58 AM, Martin Uecker uec...@eecs.berkeley.edu wrote: Hi list, the strings in the .debug_str section are output in an arbitrary order. Could this be changed? The function 'output_indirect_strings' in 'gcc/dwarf2out.c' uses htab_traverse which then outputs the string in the order they appear in the hash table. Instead, it would be nicer to output them based on their labels (which are assigned based on the order of creation). This would minimize differences between builds with slightly different build environments, e.g. directory. Can you propose a patch? Note that at creation time only the string itself is known, so sorting after the string may be another possibility. I will propose a patch. Sorting at the end would be easiest, but one could also keep track of the order. Is this performance critical? Also it seems there is other stuff which is output/indexed in hash table order, maybe this should be changed to. Martin
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes: With these defaults, the closest supported ABI is used for each architecture based on the --with-o32-fp build option. The only one I really care about is the middle one as it makes full use of the O32 FPXX ABI without a user needing to account for arch restrictions. Note that --with-* options just insert a canned -mfoo=bar option under certain conditions, with those conditions being the same regardless of bar. So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32- fp=64 should insert -mfp64, etc. The rules should therefore be the same for both -mfp and --with-o32-fp. Should: mips-*-gcc -march=mips1 -mfpxx generate -mfp32 code too? It seems counter-intuitive to me. I suppose it depends on what you want -mfpxx to mean. Do you want it to mean use the new ABI that is link-compatible with both -mfp32 and - mfp64 or do you want it to mean I don't care what the FR setting is; pick whatever seems best but be as flexible as possible? I'd assumed the former, in which case using it with an architecture that doesn't support it should be an error. In the end I do just want fpxx to mean use the new ABI that is link-compatible. I think I have managed to confuse this discussion by not understanding/separating vendor specific specs from generic option handling as you explain later in your email. I only really wish to allow a vendor specific config to infer a suitable default fp option from -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit arch). Well, for avoidance of doubt, --with has priority over the vendor-specific choices, so really this comes down to what happens when no -mfp and --with-o32-fp options are used. If you want to go for tha latter meaning then I think we should be careful to distinguish it from cases where we really are talking about the new ABI variant. E.g. an ELF file has to commit to one of the three modes: you shouldn't have to look at the ELF's architecture setting in order to interpret the FP setting correctly. And IMO the assembly code needs to commit to a specific mode too. What do you think should happen for: .module fp=xx .module arch=mips_n Should the output be FR=X or FR=1? Well, even defining fpxx as simply being another abi variant there are some issues. The current .set arch= options set fp32 for 32-bit architectures and fp64 for 64-bit architectures which means we do have to come up with some definition of how fpxx interacts with this. My current implementation is that, for .set arch, the fp option is only changed if the existing setting is incompatible with the new arch. So carrying that logic to .module means that in the case above then the output would be FPXX. Other examples would then be: .module fp=xx .module arch=mips_n FPXX .module fp=32 .module arch=mips_n FP64 .module fp=xx .module arch=mips2 FPXX .module fp=64 .module arch=mips2 FP32 (existing behaviour for .set) .module fp=xx .module arch=mips1 FP32 .module fp=64 .module arch=mips1 FP32 (existing behaviour for .set) This is weird though for the same reasons as you point out. You have to know the arch to know what happens to the FP mode. If we just continued with 32-bit arch setting fp=32 and 64-bit setting fp=64 then we have a problem with something like mips_n where fp=32 would be invalid. I really don't know what is best here! The .set mips handling of gp and fp is really there for local changes to the architecture in a .set push/pop or .set mipsN/mips0. (And IMO we the way we do it is a bit of a misfeature, but we have to keep it that way for compatibility.) I don't think it should apply to .module though. Ideally .module should work in the same way as passing the associated command-line option. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: With these defaults, the closest supported ABI is used for each architecture based on the --with-o32-fp build option. The only one I really care about is the middle one as it makes full use of the O32 FPXX ABI without a user needing to account for arch restrictions. Note that --with-* options just insert a canned -mfoo=bar option under certain conditions, with those conditions being the same regardless of bar. So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32- fp=64 should insert -mfp64, etc. The rules should therefore be the same for both -mfp and --with-o32- fp. Should: mips-*-gcc -march=mips1 -mfpxx generate -mfp32 code too? It seems counter-intuitive to me. I suppose it depends on what you want -mfpxx to mean. Do you want it to mean use the new ABI that is link-compatible with both -mfp32 and - mfp64 or do you want it to mean I don't care what the FR setting is; pick whatever seems best but be as flexible as possible? I'd assumed the former, in which case using it with an architecture that doesn't support it should be an error. In the end I do just want fpxx to mean use the new ABI that is link-compatible. I think I have managed to confuse this discussion by not understanding/separating vendor specific specs from generic option handling as you explain later in your email. I only really wish to allow a vendor specific config to infer a suitable default fp option from -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit arch). Well, for avoidance of doubt, --with has priority over the vendor- specific choices, so really this comes down to what happens when no -mfp and --with-o32-fp options are used. Yes that is what I understood. If you want to go for tha latter meaning then I think we should be careful to distinguish it from cases where we really are talking about the new ABI variant. E.g. an ELF file has to commit to one of the three modes: you shouldn't have to look at the ELF's architecture setting in order to interpret the FP setting correctly. And IMO the assembly code needs to commit to a specific mode too. What do you think should happen for: .module fp=xx .module arch=mips_n Should the output be FR=X or FR=1? Well, even defining fpxx as simply being another abi variant there are some issues. The current .set arch= options set fp32 for 32-bit architectures and fp64 for 64-bit architectures which means we do have to come up with some definition of how fpxx interacts with this. My current implementation is that, for .set arch, the fp option is only changed if the existing setting is incompatible with the new arch. So carrying that logic to .module means that in the case above then the output would be FPXX. Other examples would then be: .module fp=xx .module arch=mips_n FPXX .module fp=32 .module arch=mips_n FP64 .module fp=xx .module arch=mips2 FPXX .module fp=64 .module arch=mips2 FP32 (existing behaviour for .set) .module fp=xx .module arch=mips1 FP32 .module fp=64 .module arch=mips1 FP32 (existing behaviour for .set) This is weird though for the same reasons as you point out. You have to know the arch to know what happens to the FP mode. If we just continued with 32-bit arch setting fp=32 and 64-bit setting fp=64 then we have a problem with something like mips_n where fp=32 would be invalid. I really don't know what is best here! The .set mips handling of gp and fp is really there for local changes to the architecture in a .set push/pop or .set mipsN/mips0. (And IMO we the way we do it is a bit of a misfeature, but we have to keep it that way for compatibility.) I don't think it should apply to .module though. Ideally .module should work in the same way as passing the associated command-line option. As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Regards, Matthew
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||jakub at gcc dot gnu.org
Component|c++ |target
Target Milestone|--- |4.7.4
Summary|[4.9/4.8 regression]: |[4.7/4.8/4.9 regression]:
|cc1plus crashes compiling a |cc1plus crashes compiling a
|method with a huge struct |method with a huge struct
|as argument |as argument
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Kai Tietz from comment #3)
Issue is that copy_rtx gets feed with invalid insn.
No, it is fed completely valid insn, but just the note creation hasn't been
adjusted for the r163679 change.
(In reply to Mikael Pettersson from comment #4)
Started with r171890.
With an improved C testcase actually with r163679.
struct S { char c[65536]; };
__attribute__((ms_abi, thiscall)) void
foo (void *x, struct S y)
{
}
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32367 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32367action=edit gcc49-pr60516.patch Untested fix.
[Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #2) Please symbolize the output. How? asan_symbolize.py doesn't parse this output. If I run addr2line on the first few symbols by hand I get: Stack: sigaction.c:? gsignal+0x0034 :? abort+0x0147 :? /home/markus/gcc/libgcc/unwind-pe.h:257 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:415 dl_iterate_phdr+0x0134 :? _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 /home/markus/gcc/libgcc/unwind-dw2.c:1182 _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 crtstuff.c:? crtstuff.c:? __asan_report_error+0x083A ??:? __interceptor_setlocale+0x0155 ??:? Also, does this happen with the clang version of AddressSanitizer? Clang trunk cannot build Firefox with -fsanitize=address, because I get asan related linker errors.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #3) (In reply to Kostya Serebryany from comment #2) Please symbolize the output. How? asan_symbolize.py doesn't parse this output. If I run addr2line on the first few symbols by hand I get: Update the version of addr2line you are using first. Basically a newer addr2line will understand dwarf4 that GCC outputs.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org --- Clang trunk cannot build Firefox with -fsanitize=address, because I get asan related linker errors. To the best of my knowledge, firefox is routinely built by several different teams using clang+asan. Please report a separate bug at code.google.com/p/address-sanitizer/
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org --- _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 /home/markus/gcc/libgcc/unwind-dw2.c:1182 _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 Interesting. asan detects a bug and starts reporting it, then if crashes inside the slow unwinder. Try the fast unwinder? ASAN_OPTIONS=fast_unwind_on_fatal=1
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #5) Clang trunk cannot build Firefox with -fsanitize=address, because I get asan related linker errors. To the best of my knowledge, firefox is routinely built by several different teams using clang+asan. Please report a separate bug at code.google.com/p/address-sanitizer/ (In reply to Andrew Pinski from comment #4) (In reply to Markus Trippelsdorf from comment #3) (In reply to Kostya Serebryany from comment #2) Please symbolize the output. How? asan_symbolize.py doesn't parse this output. If I run addr2line on the first few symbols by hand I get: Update the version of addr2line you are using first. Basically a newer addr2line will understand dwarf4 that GCC outputs. I use the latest version, but gcc and glibc was build without debugging information.
[Bug middle-end/60546] [4.8 and 4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- -fno-strict-aliasing fixes the issue So there might be an aliasing issue in the code.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #5) Clang trunk cannot build Firefox with -fsanitize=address, because I get asan related linker errors. To the best of my knowledge, firefox is routinely built by several different teams using clang+asan. Please report a separate bug at code.google.com/p/address-sanitizer/ Sorry, but I don't have a google account and refuse to create one.
[Bug bootstrap/60050] Build failure on MinGW64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- This bug was fixed on mingw-w64's side. It isn't a gcc-bug. Btw gcc 4.6 isn't under maintenance anymore.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #6) _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 /home/markus/gcc/libgcc/unwind-dw2.c:1182 _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 Interesting. asan detects a bug and starts reporting it, then if crashes inside the slow unwinder. Try the fast unwinder? ASAN_OPTIONS=fast_unwind_on_fatal=1 Thanks, this works fine: markus@x4 tmp % ASAN_OPTIONS=fast_unwind_on_fatal=1 /var/tmp/moz-build-dir/dist/bin/firefox = ==10632==ERROR: AddressSanitizer: heap-use-after-free on address 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 READ of size 2 at 0x6021ec50 thread T0 #0 0x7f3e30645dbc in setlocale (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x3cdbc) #1 0x7f3e1d643400 in qtSettingsInit (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x20400) #2 0x7f3e1d637472 in qtcurve_rc_style_init (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x14472) 0x6021ec50 is located 0 bytes inside of 12-byte region [0x6021ec50,0x6021ec5c) freed by thread T0 here: #0 0x7f3e30667d37 in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x5ed37) #1 0x7f3e2fc0b6c2 in setlocale (/lib/libc.so.6+0x2a6c2) #2 0x7f3e30645cdb in setlocale (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x3ccdb) #3 0x7f3e1d641dc2 in qtSettingsInit (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x1edc2) #4 0x7f3e1d637472 in qtcurve_rc_style_init (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x14472) previously allocated by thread T0 here: #0 0x7f3e30667f6f in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x5ef6f) #1 0x7f3e2fc64639 in __GI___strdup (/lib/libc.so.6+0x83639) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 setlocale Shadow bytes around the buggy address: 0x0c047fffbd30: fa fa 00 00 fa fa 00 00 fa fa fd fd fa fa 00 00 0x0c047fffbd40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fd 0x0c047fffbd50: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00 fa 0x0c047fffbd60: fa fa 00 00 fa fa 06 fa fa fa 00 04 fa fa fd fd 0x0c047fffbd70: fa fa 00 04 fa fa 00 04 fa fa fd fd fa fa 00 04 =0x0c047fffbd80: fa fa 00 04 fa fa fd fd fa fa[fd]fd fa fa 00 04 0x0c047fffbd90: fa fa fd fd fa fa 00 04 fa fa 00 04 fa fa fd fd 0x0c047fffbda0: fa fa 00 04 fa fa 00 04 fa fa fd fd fa fa 00 04 0x0c047fffbdb0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fffbdc0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fffbdd0: fa fa 00 fa fa fa 00 07 fa fa 00 fa fa fa fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==10632==ABORTING The strange thing is that I cannot reproduce the issue above anymore. Without ASAN_OPTIONS=fast_unwind_on_fatal=1 I now get: = ==10801==ERROR: AddressSanitizer: heap-use-after-free on address 0x6021ec50 at pc 0x7fc97d727dbd bp 0x7fff3cd0d460 sp 0x7fff3cd0d438 READ of size 2 at 0x6021ec50 thread T0 #0 0x7fc97d727dbc in setlocale (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x3cdbc) #1 0x7fc96a725400 in qtSettingsInit (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x20400) #2 0x7fc96a719472 in qtcurve_rc_style_init (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x14472) #3 0x7fc97040da17 in g_type_create_instance (/usr/lib/libgobject-2.0.so.0+0x31a17) #4 0x7fc9703f1562 in g_object_new_internal (/usr/lib/libgobject-2.0.so.0+0x15562) #5 0x7fc9703f327c in g_object_newv (/usr/lib/libgobject-2.0.so.0+0x1727c) #6 0x7fc9703f3a0b in g_object_new (/usr/lib/libgobject-2.0.so.0+0x17a0b) #7 0x7fc96a720afb in theme_create_rc_style (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x1bafb) #8 0x7fc96ffe6b1d in gtk_rc_parse_any (/usr/lib/libgtk-x11-2.0.so.0+0x17cb1d) #9 0x7fc96ffe731c in gtk_rc_context_parse_one_file (/usr/lib/libgtk-x11-2.0.so.0+0x17d31c) #10 0x7fc96ffe7584 in gtk_rc_context_parse_file (/usr/lib/libgtk-x11-2.0.so.0+0x17d584) #11 0x7fc96ffe6246 in gtk_rc_parse_any (/usr/lib/libgtk-x11-2.0.so.0+0x17c246) #12 0x7fc96ffe731c in gtk_rc_context_parse_one_file (/usr/lib/libgtk-x11-2.0.so.0+0x17d31c) #13 0x7fc96ffe7584 in
[Bug other/60548] [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60548 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Severity|normal |minor
[Bug other/60547] libcilkrts/runtime/record-replay.cpp: 2 * possible problems in calls to scanf ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60547 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Severity|normal |minor
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-17
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
Confirmed. expand_omp_simd has for this case:
6837 /* If not -fno-tree-loop-vectorize, hint that we want to vectorize
6838 the loop. */
6839 if ((flag_tree_loop_vectorize
6840|| (!global_options_set.x_flag_tree_loop_vectorize
6841 !global_options_set.x_flag_tree_vectorize))
6842loop-safelen 1)
6843 {
6844 loop-force_vect = true;
6845 cfun-has_force_vect_loops = true;
6846 }
but gate_tree_loop_vectorize isn't called at all, because gate_tree_loop
returns false. So maybe:
--- gcc/tree-ssa-loop.c
+++ gcc/tree-ssa-loop.c
@@ -47,7 +47,7 @@ along with GCC; see the file COPYING3. If not see
static bool
gate_tree_loop (void)
{
- return flag_tree_loop_optimize != 0;
+ return flag_tree_loop_optimize != 0 || cfun-has_force_vect_loops;
}
namespace {
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
Thanks for the patch. I am about to do a full-regression test for it. This
will take some time.
Quick test has shown that issue isn't 'thiscall' specific at all. stdcall, and
fastcall calling-convention do have the same issues. So I would suggest to add
these two testcases to the patch, too.
/* PR target/60516 */
/* { dg-do compile } */
/* { dg-options -O2 } */
struct S { char c[65536]; };
__attribute__((ms_abi, thiscall)) void
foo (void *x, struct S y)
{
}
/* PR target/60516 */
/* { dg-do compile } */
/* { dg-options -O2 } */
struct S { char c[65536]; };
__attribute__((ms_abi, fastcall)) void
foo (void *x, void *xx, struct S y)
{
}
[Bug other/60548] [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60548 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This file is never compiled so it is very minor.
[Bug other/60547] libcilkrts/runtime/record-replay.cpp: 2 * possible problems in calls to scanf ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60547 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This code is never used unless you turn on the code manually.
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #26 from rguenther at suse dot de rguenther at suse dot de --- On Sat, 15 Mar 2014, linux at carewolf dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #25 from Allan Jensen linux at carewolf dot com --- Will it be backported to 4.8? Yes.
[Bug middle-end/60546] [4.8 and 4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- But it might be related to bug 60429.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org --- ==10632==ERROR: AddressSanitizer: heap-use-after-free on address 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 READ of size 2 at 0x6021ec50 thread T0 #0 0x7f3e30645dbc in setlocale So, sounds like a real use-after-free in firefox
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #11 from Kostya Serebryany kcc at gcc dot gnu.org --- Sorry, but I don't have a google account and refuse to create one. You can login to our bug tracker with any existing e-mail, or you can contact us via address-saniti...@googlegroups.com or you can file a bug using the llvm bug tracker
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Bernd Edlinger from comment #6) that would be r208419 and r208150 Reverting r208150 + r208419 and rebuilding from scratch eliminated all acats regressions.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #12 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #11) Sorry, but I don't have a google account and refuse to create one. You can login to our bug tracker with any existing e-mail, or you can contact us via address-saniti...@googlegroups.com or you can file a bug using the llvm bug tracker OK, sorry. I didn't know that. (In reply to Kostya Serebryany from comment #10) ==10632==ERROR: AddressSanitizer: heap-use-after-free on address 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 READ of size 2 at 0x6021ec50 thread T0 #0 0x7f3e30645dbc in setlocale So, sounds like a real use-after-free in firefox No. It's a bug in libqtcurve (a QT/GTK theme). When I switch to a different theme I hit the real Firefox bug that I was after: https://bugzilla.mozilla.org/show_bug.cgi?id=983995 What about the allocating memory until the OOM killer hits issue? Do you think this is an asan bug?
[Bug fortran/60549] New: [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Bug ID: 60549 Summary: [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Follow up to PR 55207 and to r208590; see http://gcc.gnu.org/ml/fortran/2014-03/msg00108.html Since r208590, the execution time of Polyhedron's fatigue.f90 doubled from ~1.4s to ~2.9s. I have not closely looked at fatigue.f90, however, I believe that this is due to the following: Fatigue's main program has internal procedures, which access variables defined in the main program. As static variables usually global variables, GCC does not a good job at optimizing static variables - even if it could in case they are defined within one function only. Possible solution: Small variables [of the MAIN program only!] should be (again) created on the stack - possibly even (new!) when they do have an explicitly set SAVE attribute. I think that's especially relevant for integer and real variables. I think it is impossible to see the difference from within the program; the only exception are __attribute__((destructor)) - thus, if one wants to play safe is to exclude those with TARGET attribute.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||dominiq at lps dot ens.fr, ||janus at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #13 from Kostya Serebryany kcc at gcc dot gnu.org --- What about the allocating memory until the OOM killer hits issue? Do you think this is an asan bug? Dunno. File a bug with more details if you think it's a bug. I guess you can close this one.
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- No, instead we should treat !flag_tree_loop_optimize the same as we treat explicit -fno-tree-vectorize in omp-low.c (there are two spots).
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Rich Felker from comment #6) On Sun, Mar 16, 2014 at 11:32:21PM +, olegendo at gcc dot gnu.org wrote: If it's OK for a temporary mode switch to clobber other FPSCR bits (such as in the PR = single mode above), it should also be OK to load the FPSCR value from a thread local variable inside the thread-control-block: mov.l @(disp, gbr),r0 // r0 = address to fpscr value for a // particular mode setting lds.l @r0+,fpscr // mode switch IMO this is an ugly hack that shouldn't be taken. It has lots of complex interactions with other things: signal handlers, the ucontext.h functions, fenv, pthread, etc. Could you please elaborate on the problems you see there? that could probably be achieved correctly if somebody wanted to spend the effort on it, but it would be ugly and SH-specific and honestly we already have a shortage of people willing to spend time fixing SH problems without introducing even more work. I failed to mention, that the idea with TLS variables was meant to be a separate option. If implemented in the compiler it would need to be turned on explicitly, similar to the option '-matomic-model=soft-tcb,gbr-offset=your offset here'. Thus, if a libc/kernel/whatever doesn't want to make use of it, it won't have to. This would require that any FPSCR setting change is also propagated to the TLS variables. E.g. setting the rounding mode would have to update FPSCR mode values in all such TLS variables. I guess that it would be useful to be able to select an FPSCR value for at least all combinations of FR and SZ bit settings, in other words having a TLS __fpscr_values array with 4 entries. However, it would make things such as toggling FPSCR.FR via frchg inefficient due to the required updates of the TLS variables. Other setting changes such as denorm or rounding mode are probably not so critical. If I'm not mistaken, the toggle approach will be efficient without this TLS hack once it's implemented, right? No. The toggle approach is only efficient on SH4A. Other SH FPUs don't implement the fpchg instruction and require sts-lds fpscr sequences, regardless of toggling or explicitly setting the PR mode. I don't think it makes sense to introduce a hack for just a short-term mitigation of the performance regression. If you think the short-term fix for this issue is too costly, the proper solution is probably to add a -m option to turn it back off (using the old __fpscr_values approach). This was not meant to be a short-term mitigation. In fact figuring out whether FPSCR bits can be clobbered during a PR mode switch or not is already not so simple. If at all, it would be an additional optimization opportunity after everything else is in place. Keeping the 'global __fpscr_values' approach as an option could be useful for thread model = single, or for bare-metal applications where the rounding mode etc is never changed from the default and FP status bits are never read back by application code.
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #32367|0 |1 is obsolete|| --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32368 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32368action=edit gcc49-pr60516.patch Ok, testcase adjusted.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-17 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since r208590, the execution time of Polyhedron's fatigue.f90 doubled from ~1.4s to ~2.9s. To make the things clear, these timings were obtained after applying the patch at http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html I have a few very short (invalid) tests which are optimized differently before and after r208590. I can post some of them if there is an interest.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Indeed once such variables have their address taken (trivially happens in fortran) we have a hard time disambiguating them. You might want to try (the imperfect) -fipa-pta, even though that pessimizes code in some cases.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Closing.
[Bug testsuite/58851] FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 --- Comment #14 from Andreas Schwab schwab at gcc dot gnu.org --- Author: schwab Date: Mon Mar 17 09:23:15 2014 New Revision: 208612 URL: http://gcc.gnu.org/viewcvs?rev=208612root=gccview=rev Log: PR testsuite/58851 * gfortran.dg/unlimited_polymorphic_13.f90: Properly compute storage size. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_13.f90
[Bug fortran/58793] Wrong value for _vtab for intrinsic types with CLASS(*): storage_size of class(*) gives wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58793 Bug 58793 depends on bug 58851, which changed state. Bug 58851 Summary: FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug testsuite/58851] FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Andreas Schwab sch...@linux-m68k.org --- .
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- You might want to try (the imperfect) -fipa-pta, even though that pessimizes code in some cases. It does not change the run time for fatigue.f90.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) You might want to try (the imperfect) -fipa-pta, even though that pessimizes code in some cases. It does not change the run time for fatigue.f90. And what exact change do you get with a mere http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html patch, against same version without it (e.g. both without the SAVE for MAIN__ change, or both with that change)?
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, even when it is Firefox/whatever bug, the question is why do you get a crash in libgcc_s.so.1. Is that because your libgcc is too old to handle the gcc 4.9 emitted unwind info? Note, I'm not aware of any such changes in the last few years, so it would need to be very old, or -flto generating invalid unwind info or something. Can you make sure you are using libgcc_s.so.1 built by gcc trunk with debug info and see where exactly it crashes?
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Summary|[4.8 and 4.9] O2 asan |[4.8/4.9] O2 asan enable |enable generates wrong |generates wrong insns |insns | --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It's not fixed by the fix for PR60429. But 1.cpp: In member function ‘unsigned int WTF::StringImpl::hashSlowCase() const’: 1.cpp:26260:1: warning: no return statement in function returning non-void [-Wreturn-type] } ^ so at least there's sth fishy going on (fixing it with an obvious change doesn't fix the abort). Note that valgrind reports the error without -fsanitize=address, for -O2 but not for -Os. -fno-tree-loop-im fixes this so it might be a duplicate of PR??? as loop invariant motion can cause the read of uninitialized memory when applying store-motion.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #16 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #15) Well, even when it is Firefox/whatever bug, the question is why do you get a crash in libgcc_s.so.1. Is that because your libgcc is too old to handle the gcc 4.9 emitted unwind info? Note, I'm not aware of any such changes in the last few years, so it would need to be very old, or -flto generating invalid unwind info or something. Can you make sure you are using libgcc_s.so.1 built by gcc trunk with debug info and see where exactly it crashes? You're right: x4 ~ # ll /lib/libgcc_s.so.1 -rw-r--r-- 1 root root 546544 Dec 3 2012 /lib/libgcc_s.so.1 So it's pretty old. I will install a new version and see what happens.
[Bug tree-optimization/60537] Loop header copying code bloat for simple loops that don't benefit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60537
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-17
Summary|Loop optimization code |Loop header copying code
|bloat for simple loops |bloat for simple loops that
||don't benefit
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
For -O2 we do this to enable loop optimizations which almost all require
do { } while style loops. This canonicalization can sometimes peel an
entire iteration as you can see here, and this canonicalization is
not done at -Os unless the loop is determined as hot (so with -Os
and profile-feedback some loops may get this treatment).
It's hard to undo this transform but that's what would be needed here ...
(or make more passes deal with number-of-iterations == n or zero)
[Bug sanitizer/60535] [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/57425] [4.8 Regression] RTL alias analysis unprepared to handle stack slot sharing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57425 --- Comment #18 from Mikael Pettersson mikpelinux at gmail dot com --- Bill, the backport patch has now been approved: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00792.html
[Bug fortran/60550] New: ICE on factory design pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550 Bug ID: 60550 Summary: ICE on factory design pattern Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pogos77 at hotmail dot com Created attachment 32369 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32369action=edit The test case for the design pattern: factory pattern. I want to select different benchmark problems in an optimization field. The attached program cannot compile due to an ICE. The error is ice2014.f90: In function ‘create_problem’: ice2014.f90:350:0: internal compiler error: in fold_convert_loc, at fold-const.c:1994 ALLOCATE(self%problemPtr, SOURCE=FRosenbrock(self%problemID, ndim, self%problemName)) ^ The gfortran version is gcc version 4.9.0 20140313 (experimental) [trunk revision 208526] (GCC) Thanking you for your prompt response.
[Bug c++/60551] New: __attribute__((used)) is ignored for 'static' function declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60551
Bug ID: 60551
Summary: __attribute__((used)) is ignored for 'static' function
declarations
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
// a.cc:
// I plan to implement it in only one .cc module
// and not this one, thus I don't need external visibility.
static void friendly_accessor (void) __attribute__((used));
struct Something
{
friend void friendly_accessor (void);
void f (void);
};
// somewhere in b.cc 'friendly_accessor (void);' is implemented
// and used in 'Something::f()'
When compiling 'a.cc' I haven't managed to silence gcc on -Wall:
a.cc:7:17: warning: 'void friendly_accessor()' declared 'static' but never
defined [-Wunused-function]
friend void friendly_accessor (void);
^
If i'll add a definition right after declaration the warning will go away:
static void friendly_accessor (void) {}
Looks like a declaration tracking bug. It's a gcc-4.8.2 on amd64.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32370 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32370action=edit patch to fix store motion issue Fixing that doesn't fix it (or my fix doesn't work ;)).
[Bug target/60539] [SH] builtin string functions ignore loop and label alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #1 from chrbr at gcc dot gnu.org --- yes or not, it's not really ignored, it's the prob_likely value tuning. Setting it to REG_BR_PROB_BASE restores the loop align but also impacts code ordering for the byte-at-a-time code chunk that becomes less likely. so we get worse: movr4,r0 tst#3,r0 movr4,r1 bt.L10 .L6: mov.b@r1+,r2 tstr2,r2 bf.L6 movr1,r0 rts subcr4,r0 .align 1 .L10: mov#0,r3 .L4: mov.l@r1+,r2 cmp/strr3,r2 bf.L4 bra.L6 add#-4,r1 The problem is that .L14 is reached both from the word-at-atime paths and byte-at-atime paths... and I was not able to find the proper tuning value to favor boths given than the word loop iteration number is probably small (strings are generally not so big) and that the byte loop number of iterations is less than 4, so introducing a .align here can be a cost. I did try to introduce a UNSPECV_ALIGN here but without measuring any speed improvement (or any small negative impact) on my board. Anyway any interesting benchmarking tuning here is interesting, or even find a pathological case here welcome,
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Sergei Trofimovich slyfox at inbox dot ru changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #6 from Sergei Trofimovich slyfox at inbox dot ru --- I was about to fill the bug about -Weverything to enable all the warnings you have. All those things I've got from 'gcc --help=warnings': -Wdelete-non-virtual-dtor -Wsuggest-attribute=noreturn -Wsuggest-attribute=format -Wredundant-decls ... (+around of 20 of this kind) But I'd like to see them (and new cool ones!) just with gcc upgrade and a run on -Weverything on a project (as I do with clang). Thanks!
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #5 from linzj manjian2006 at gmail dot com --- Well,valgind do detect invalid memory usage.That's not an asan problem then. Since it effects from 4.8,does that mean 4.8 is not secure any more?
[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32371 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32371action=edit Fix
[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org --- The fix uses the store-data-race avoiding path which keeps a flag per moved mem-ref whether it was stored to. With that I can avoid loading from the ref before the loop if there are no loads in the loop itself. But it reveals that we possibly use too many flags (we don't try combining them - some simple analysis should be able to improve that).
[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 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 #23 from Richard Biener rguenth at gcc dot gnu.org --- Mine, but not for 4.9.
[Bug target/60539] [SH] builtin string functions ignore loop and label alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539 --- Comment #2 from chrbr at gcc dot gnu.org --- note also that instead of merging the 3 max remaining bytes after the world-at-time loop with the byte-at-a-time loop I had a version that unrolled the 3 of them of we have 2 different path (word,bytes) instead of 3 (words, words+byte remaining, bytes). But the additional CF complexity was not beneficial in average for my set of benchmarks compared to a simple version with the remaining bytes falling thru the byte-at-atime loop
[Bug sanitizer/60535] [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-17
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase (-flto -fsanitize=undefined -O2):
struct A { int c; };
A *a;
int b = a-c;
int
main ()
{
}
[Bug sanitizer/60535] [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Yeah, that is the reason why we run ubsan tests with dg-skip-if { *-*-* } {
-flto } { }. I don't think it's a regression, it never worked.
[Bug other/60552] New: integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Bug ID: 60552 Summary: integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min^ Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: addepalli.prasad at tcs dot com When I am trying to build a cpp file with the gcc compiler. I am getting the below errors: /include/c++/4.4.3/bits/locale_facets.tcc,line 453: warning #61-D: integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^ detected during: instantiation of std::num_get _CharT, _InIter ::iter_type std::num_get _CharT, _InIter ::_M_extract_int(std::num_get _CharT, _InIter ::iter_type, std::num_get _CharT, _InIter ::iter_type, std::ios_base , std::ios_base::iostate , _ValueT ) const [with _CharT=char, _InIter=std::istreambuf_iterator std::basic_streambuf char, std::char_traits char ::char_type, std::basic_streambuf char, std::char_traits char ::traits_type , _ValueT=long] at line 2168 of /proj/DTE_releases/9.63.0.1/cade/cade_B_tools_gcc-ppc/Linux /i686/bin/../lib/gcc/powerpc-eabi/4.4.3/../../../../powerpc- eabi/include/c++/4.4.3/bits/locale_facets.h instantiation of std::num_get _CharT, _InIter ::iter_type std::num_get _CharT, _InIter ::do_get(std::num_get _CharT, _InIter ::iter_type, std::num_get _CharT, _InIter ::iter_type, std::ios_base , std::ios_base::iostate , long ) const [with _CharT=char, _InIter=std::istreambuf_iterator std::basic_streambuf char, std::char_traits char ::char_type, std::basic_streambuf char, std::char_traits char ::traits_type ] /include/c++/4.4.3/ext/numeric_traits.h: In copy constructor '__gnu_cxx::__numeric_traits_Value::__numeric_traits(const __gnu_cxx::__numeric_traits_Value)': powerpc-eabi/include/c++/4.4.3/ext/numeric_traits.h:126: error: '_Tp' was not declared in this scope include/c++/4.4.3/ext/numeric_traits.h:126: error: '_Tp' was not declared in this scope accum1.cpp: In function 'int accum1_test(int, char**)': accum1.cpp:17: warning: comparison between signed and unsigned integer expressions accum1.cpp: At global scope: accum1.cpp:25: error: specialization of 'char* std::allocator_Alloc::_att_tmpl_text() const [with _Tp = char]' after instantiation accum1.cpp:27: error: specialization of 'char* std::allocator_Alloc::_att_tmpl_text() const [with _Tp = wchar_t]' after instantiation accum1.cpp:32: error: specialization of 'char* std::basic_string_CharT, _Traits, _Alloc::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' after instantiation accum1.cpp:33: error: specialization of 'char* std::collate_CharT::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:37: error: specialization of 'char* std::collate_byname_CharT::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:38: error: specialization of 'char* std::basic_streambuf_CharT, _Traits::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traitschar]' after instantiation accum1.cpp:39: error: specialization of 'char* std::numpunct_CharT::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:44: error: specialization of 'char* std::numpunct_byname_CharT::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:45: error: specialization of 'char* std::num_get_CharT, _InIter::_att_tmpl_text() const [with _CharT = char, _InIter = std::istreambuf_iteratorchar, std::char_traitschar ]' after instantiation accum1.cpp:46: error: specialization of 'char* std::num_put_CharT, _OutIter::_att_tmpl_text() const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' after instantiation accum1.cpp:47: error: specialization of 'char* std::basic_ios_CharT, _Traits::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traitschar]' after instantiation accum1.cpp:48: error: specialization of 'char* std::basic_ostream_CharT, _Traits::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traitschar]' after instantiation accum1.cpp:49: error: no member function '_att_tmpl_text' declared in 'std::basic_ostreamchar, std::char_traitschar ::sentry' accum1.cpp:50: error: specialization of 'char* std::basic_istream_CharT, _Traits::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traitschar]' after instantiation
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- And what exact change do you get with a mere http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html patch, against same version without it (e.g. both without the SAVE for MAIN__ change, or both with that change)? With the patch, the timing when compiling with '-Ofast -fwhole-program' is between 1.40 to 1.45s before r208590 and above 3s after it. The later timing is unaffected by the addition of -fipa-pta. I did not test the effect of -fipa-pta before r208590 and I have no access to the machine before this evening.
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- Did regression-test for 32-bit mingw for C, C++, and Fortran. No new regressions occurred. So patch is from my POV ok for trunk and branches
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) And what exact change do you get with a mere http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html patch, against same version without it (e.g. both without the SAVE for MAIN__ change, or both with that change)? With the patch, the timing when compiling with '-Ofast -fwhole-program' is between 1.40 to 1.45s before r208590 and above 3s after it. The later timing is unaffected by the addition of -fipa-pta. I did not test the effect of -fipa-pta before r208590 and I have no access to the machine before this evening. I meant whether my (and Honza's and Tobias') patch actually fixed PR58721 on the benchmark or not (i.e. what were the timings without the http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html patch?).
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- You haven't provided the requested information requested at http://gcc.gnu.org/bugs/ - please read that before reporting bugs. /include/c++/4.4.3/bits/locale_facets.tcc,line 453: warning #61-D: integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^ This is not an error from GCC 4.4.3, are you sure that's what you're using? GCC 4.4.3 has been unsupported for several years, please either update to a newer release or report this to the vendor you got your compiler from.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Meanwhile -fno-tree-dse also fixes this but it only prevents mayhem downstream (Jakub bisected this to a revision that exposed the issue, r158047). You have to disable both tree DSE passes btw, thus it points to a pass running after DSE2. It's not -fhoist-adjacent-loads, not RTL PRE nor RTL loop invariant motion or the scheduler.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
--- Comment #8 from chrbr at gcc dot gnu.org ---
Hi Oleg,
I posted a patch in 2006
(http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01562.html) to support mode
flipping fpchg instruction for the sh4a. it is in used in our current (4.8)
production compiler without issue since then.
I didn't insist a lot pushing it since too sh4a specific, but I'd be happy to
port it to the 4.10 branch and repost if there is enough interest.
Cheers
a code like
float
foo(float a)
{
return a+2;
}
compiles into:
mova.L2,r0
fmov.s @r0+,fr0
fpchg
faddfr5,fr0
rts
fpchg
instead of:
mov.l .L2,r1
mova.L3,r0
fmov.s @r0+,fr0
lds.l @r1+,fpscr
add #-4,r1
add #4,r1
faddfr5,fr0
rts
lds.l @r1+,fpscr
.L4:
.align 2
.L2:
.long ___fpscr_values
.L3:
.long 1073741824
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Looks like TBAA violations to me:
struct QualifiedNameComponents c;
short unsigned int _316;
short unsigned int _317;
bb 53:
# data_157 = PHI data_329(53), c(52)
_316 = MEM[base: data_157, offset: 2B];
_317 = MEM[base: data_157, offset: 0B];
... hashing ...
data_329 = data_157 + 4;
if (data_329 != MEM[(void *)c + 12B])
goto bb 53;
else
goto bb 54;
so you hash the QualifiedNameComponents pointers, not its strings. And
you do it by reading the pointers as 'unsigned short'. Probably via
templatesize_t length static inline unsigned hashMemory(const void* data)
{
typedef int dummylength_must_be_a_multible_of_four [(!(length % 4)) ? 1
: -1];
return computeHashUChar(static_castconst UChar*(data), length /
sizeof(UChar));
}
which introduces the violation. It should not use 'short' hashing but
hashing of 'char'.
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Sivaprasad addepalli.prasad at tcs dot com changed: What|Removed |Added Severity|normal |major
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 --- Comment #2 from Sivaprasad addepalli.prasad at tcs dot com --- with GCC 4.6.3 also, we are facing same problems.
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #5 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 32372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32372action=edit tentative patch for tentative reloads In this case, reload already knows that it has to re-do the reloads, but it goes ahead anyway and computes reloads registers for this iteration. Unfortunately, when find_reload_regs fails, it then calls spill_failure, giving a hard error for a reload that we don't need in the first place. The patch in this attachment passes down something_changed from reload as tentative to select_reload_regs and then on to find_reload_regs to not worry about the failure. Also, in reload, I made it not 'goto failure' in that case.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #8 from linzj manjian2006 at gmail dot com --- I don't think it can be mark as resolved-invalid that fast.This code is used by WebKit for a long time and no one would say this is an illegal algorithm.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #9 from linzj manjian2006 at gmail dot com --- If this is an illegal expression, it should be reported at compile time,not generating a wrong code.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9 Regression] Link |Link failure with -flto and |failure with -flto and |-fsanitize=undefined |-fsanitize=undefined| Severity|normal |enhancement
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Mar 17 13:08:41 2014 New Revision: 208615 URL: http://gcc.gnu.org/viewcvs?rev=208615root=gccview=rev Log: 2014-03-17 Richard Biener rguent...@suse.de Backport from mainline 2014-03-11 Richard Biener rguent...@suse.de PR tree-optimization/60429 PR tree-optimization/60485 * tree-ssa-structalias.c (set_union_with_increment): Properly take into account all fields that overlap the shifted vars. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (get_constraint_for_ptr_offset): Likewise. * gcc.dg/pr60485-1.c: New testcase. * gcc.dg/pr60485-2.c: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/60485] field-sensitive points-to confused by pointer offsetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Mar 17 13:08:41 2014 New Revision: 208615 URL: http://gcc.gnu.org/viewcvs?rev=208615root=gccview=rev Log: 2014-03-17 Richard Biener rguent...@suse.de Backport from mainline 2014-03-11 Richard Biener rguent...@suse.de PR tree-optimization/60429 PR tree-optimization/60485 * tree-ssa-structalias.c (set_union_with_increment): Properly take into account all fields that overlap the shifted vars. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (get_constraint_for_ptr_offset): Likewise. * gcc.dg/pr60485-1.c: New testcase. * gcc.dg/pr60485-2.c: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-structalias.c
[Bug middle-end/60429] [4.7 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.3, 4.9.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] |Miscompilation (aliasing) |Miscompilation (aliasing) |with -finline-functions |with -finline-functions Known to fail||4.7.3, 4.8.2 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org --- Also fixed on the 4.8 branch.
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits_ValueT::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-17 Ever confirmed|0 |1 Severity|major |normal --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- 4.6.3 is also unsupported, and you still haven't read http://gcc.gnu.org/bugs/
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 linzj manjian2006 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #10 from linzj manjian2006 at gmail dot com --- add __attribute__((noinline)) to computeHash resolves this bug.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- That doesn't make this bug valid.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Although it seems that (1)-(5) in #3 are interesting points, they are almost optimizations. I guess that programs with frequent FP mode switchings are simply rare in real world and would be a bit special or even pathological in the first place. I like the idea of mode switching without __fpscr_values even if it requires more instructions on SH4. Now SH4 is a fairy old core and is not for heavy FP computations anyway. I think that it won't impact the real working set. It looks to me that Christian's patch is the way to go.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 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 32373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32373action=edit gcc49-pr60535.patch Untested fix. There are 3 remaining tests I haven't removed the dg-skip-if for yet: c-c++-common/ubsan/null-4.c c-c++-common/ubsan/overflow-int128.c These 2 fail because with -flto we get unknown type names instead of say complex double or int128_t (if I remember it well). Dunno if there is anything that can be done about it though. g++.dg/ubsan/pr59437.C This one shows a bug either in the -fvtable-* verification stuff, or in cgraph, but doesn't look related to ubsan: ==27993== Invalid write of size 8 ==27993==at 0x89AEEC: bitmap_initialize_stat(bitmap_head*, bitmap_obstack*) (bitmap.h:277) ==27993==by 0x89BA7C: bitmap_obstack_alloc_stat(bitmap_obstack*) (bitmap.c:376) ==27993==by 0xDCB7B2: mark_def_dom_walker::mark_def_dom_walker(cdi_direction) (tree-into-ssa.c:2234) ==27993==by 0xDCBA80: rewrite_into_ssa() (tree-into-ssa.c:2331) ==27993==by 0xDCBD70: (anonymous namespace)::pass_build_ssa::execute() (tree-into-ssa.c:2403) ==27993==by 0xC56F9D: execute_one_pass(opt_pass*) (passes.c:2229) ==27993==by 0xC571B6: execute_pass_list(opt_pass*) (passes.c:2282) ==27993==by 0xC4B58E: gcc::pass_manager::execute_early_local_passes() (passes.c:135) ==27993==by 0x92BCA4: cgraph_process_new_functions() (cgraphunit.c:338) ==27993==by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993==by 0xD42091: compile_file() (toplev.c:562) ==27993== Address 0xbc0cdf0 is 96 bytes inside a block of size 4,064 free'd ==27993==at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27993==by 0x3C5FA84857: obstack_free (in /usr/lib64/libc-2.18.so) ==27993==by 0x89B901: bitmap_obstack_release(bitmap_obstack*) (bitmap.c:358) ==27993==by 0x92C95C: analyze_function(cgraph_node*) (cgraphunit.c:665) ==27993==by 0x92BC0B: cgraph_process_new_functions() (cgraphunit.c:334) ==27993==by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993==by 0xD42091: compile_file() (toplev.c:562) ==27993==by 0xD441E9: do_compile() (toplev.c:1914) ==27993==by 0xD44354: toplev_main(int, char**) (toplev.c:1990) ==27993==by 0x14BD71B: main (main.c:36) Apparently this is related to the default obstack freeing and use after free, either vtable*.c calls cgraph at a pointer where it is not supposed to (or needs to conditionalize it on cgraph_state), or cgraph doesn't handle nesting properly.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) Created attachment 32373 [details] gcc49-pr60535.patch Untested fix. There are 3 remaining tests I haven't removed the dg-skip-if for yet: c-c++-common/ubsan/null-4.c c-c++-common/ubsan/overflow-int128.c These 2 fail because with -flto we get unknown type names instead of say complex double or int128_t (if I remember it well). Dunno if there is anything that can be done about it though. You need to amend lto/lto-lang.c:lto_init with more NAME_TYPEs (basically cover all global trees with a name we'd use for LTO - which would be matching the C frontend).
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Mar 17 14:15:51 2014 New Revision: 208616 URL: http://gcc.gnu.org/viewcvs?rev=208616root=gccview=rev Log: PR middle-end/60534 * omp-low.c (omp_max_vf): Treat -fno-tree-loop-optimize the same as -fno-tree-loop-vectorize. (expand_omp_simd): Likewise. testsuite/ * gcc.dg/gomp/pr60534.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr60534.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #9) Although it seems that (1)-(5) in #3 are interesting points, they are almost optimizations. Yep. Those are not necessary to get the functionality (of not using __fpscr_values). I guess that programs with frequent FP mode switchings are simply rare in real world and would be a bit special or even pathological in the first place. I like the idea of mode switching without __fpscr_values even if it requires more instructions on SH4. Now SH4 is a fairy old core and is not for heavy FP computations anyway. I think that it won't impact the real working set. It looks to me that Christian's patch is the way to go. Yep. However, when the patch was proposed there were some objections regarding the modifications in lcm.c (if I'm not mistaken). We could try again. The reason why I brought up (1)-(5) in #3 was that if one of them is eventually implemented (e.g. reorder calculation insns) the changes to lcm.c might not be required and could be avoided. Depending on the implementation of such optimization, the mode switch information might have to be obtained/maintained in a different way. However, I at the moment I have no concrete ideas/plans. If Christian's patch is accepted, that's cool, too.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #12 from linzj manjian2006 at gmail dot com --- Alright,should I change the algorithm to avoid this bug?
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 17 Mar 2014, manjian2006 at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #12 from linzj manjian2006 at gmail dot com --- Alright,should I change the algorithm to avoid this bug? Of course, what else ...
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #14 from linzj manjian2006 at gmail dot com --- Well,but I have not figured out what goes wrong in the hashing algorithm. Would you point it out.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) g++.dg/ubsan/pr59437.C This one shows a bug either in the -fvtable-* verification stuff, or in cgraph, but doesn't look related to ubsan: ==27993== Invalid write of size 8 ==27993==at 0x89AEEC: bitmap_initialize_stat(bitmap_head*, bitmap_obstack*) (bitmap.h:277) ==27993==by 0x89BA7C: bitmap_obstack_alloc_stat(bitmap_obstack*) (bitmap.c:376) ==27993==by 0xDCB7B2: mark_def_dom_walker::mark_def_dom_walker(cdi_direction) (tree-into-ssa.c:2234) ==27993==by 0xDCBA80: rewrite_into_ssa() (tree-into-ssa.c:2331) ==27993==by 0xDCBD70: (anonymous namespace)::pass_build_ssa::execute() (tree-into-ssa.c:2403) ==27993==by 0xC56F9D: execute_one_pass(opt_pass*) (passes.c:2229) ==27993==by 0xC571B6: execute_pass_list(opt_pass*) (passes.c:2282) ==27993==by 0xC4B58E: gcc::pass_manager::execute_early_local_passes() (passes.c:135) ==27993==by 0x92BCA4: cgraph_process_new_functions() (cgraphunit.c:338) ==27993==by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993==by 0xD42091: compile_file() (toplev.c:562) ==27993== Address 0xbc0cdf0 is 96 bytes inside a block of size 4,064 free'd ==27993==at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27993==by 0x3C5FA84857: obstack_free (in /usr/lib64/libc-2.18.so) ==27993==by 0x89B901: bitmap_obstack_release(bitmap_obstack*) (bitmap.c:358) ==27993==by 0x92C95C: analyze_function(cgraph_node*) (cgraphunit.c:665) ==27993==by 0x92BC0B: cgraph_process_new_functions() (cgraphunit.c:334) ==27993==by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993==by 0xD42091: compile_file() (toplev.c:562) ==27993==by 0xD441E9: do_compile() (toplev.c:1914) ==27993==by 0xD44354: toplev_main(int, char**) (toplev.c:1990) ==27993==by 0x14BD71B: main (main.c:36) Apparently this is related to the default obstack freeing and use after free, either vtable*.c calls cgraph at a pointer where it is not supposed to (or needs to conditionalize it on cgraph_state), or cgraph doesn't handle nesting properly. I think this is PR59441.
[Bug lto/59441] ICE in bitmap_element_allocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59441 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-17 Ever confirmed|0 |1
[Bug tree-optimization/57303] [4.7 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Mar 17 14:38:55 2014 New Revision: 208618 URL: http://gcc.gnu.org/viewcvs?rev=208618root=gccview=rev Log: 2014-03-17 Richard Biener rguent...@suse.de Backport from mainline 2013-05-21 Richard Biener rguent...@suse.de PR tree-optimization/57303 * tree-ssa-sink.c (statement_sink_location): Properly handle self-assignments. * gcc.dg/torture/pr57303.c: New testcase. 2013-12-02 Richard Biener rguent...@suse.de PR tree-optimization/59139 * tree-ssa-loop-niter.c (chain_of_csts_start): Properly match code in get_val_for. (get_val_for): Use gcc_checking_asserts. * gcc.dg/torture/pr59139.c: New testcase. 2014-02-14 Richard Biener rguent...@suse.de PR tree-optimization/60183 * tree-ssa-phiprop.c (propagate_with_phi): Avoid speculating loads. (tree_ssa_phiprop): Calculate and free post-dominators. * gcc.dg/torture/pr60183.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57303.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr59139.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr60183.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_7-branch/gcc/tree-ssa-phiprop.c branches/gcc-4_7-branch/gcc/tree-ssa-sink.c
