Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
Hi, I had a question about interpretation of FDE's CIE_pointer field (for .debug_frame) The spec say (from dwarf4 version although it really doesn't matter): 2. CIE_pointer (4 or 8 bytes, see Section 7.4) A constant offset into the .debug_frame section that denotes the CIE that is associated with this FDE. Does offset above mean offset from current location (in FDE) to CIE or does it mean offset from start of .debug_frame to the CIE. Per Ian Lance Taylor's blog, and if I'm interpreting it correctly, (http://www.airs.com/blog/archives/460) it seems to be latter. However the example given in spec it seems to have a direct reference to CIE Address Value Comment - fde 40 ... fde+4 cie CIE_pointer-- This is direct reference to CIE (not relative) The context is ARC GNU toolchain form Synopsys. ARC gcc 4.8 is currently generating something like this: .section.debug_frame,,@progbits .Lframe0: .4byte@.LECIE0-@.LSCIE0-- CIE .LSCIE0: .4byte0x .LECIE0: ... .LSFDE0: .4byte@.LEFDE0-@.LASFDE0 -- FDE .LASFDE0: .4byte@.Lframe0-- CIE pointer - direct reference to CI (not offset from start of .debug_frame) This direct reference to start of CIE is causing objdump to reference invalid CIE and hence print invalid CFI - although the CFI itself is valid since the code_factor and such are seeded from a bogus CIE. 0060 0014 80e0c000 FDE cie=48b25ff8 pc=80a680d4..80a6810a ... ^^ Looking at gcc 4.8 source : gcc/dwarf2out.c : It seems to hint that the CIE_pointer needs to be relative to .debug_frame (just as I think) + if (for_eh) +dw2_asm_output_delta (4, l1, section_start_label, FDE CIE offset); + else +dw2_asm_output_offset (DWARF_OFFSET_SIZE, section_start_label, + debug_frame_section, FDE CIE offset); However to not generate a direct reference, most targets need to implement ASM_OUTPUT_DWARF_OFFSET which is not really the case. So the questions are 1. Is the current encoding of CIE_pointer in FDE correct 2. If yes, then objdump/readelf are at fault ? 2. If not, why do most targets don't implement the above macro. -Vineet
Re: Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
On Mon, Jun 24, 2013 at 12:06:27PM +0530, Vineet Gupta wrote: I had a question about interpretation of FDE's CIE_pointer field (for .debug_frame) The spec say (from dwarf4 version although it really doesn't matter): 2. CIE_pointer (4 or 8 bytes, see Section 7.4) A constant offset into the .debug_frame section that denotes the CIE that is associated with this FDE. Does offset above mean offset from current location (in FDE) to CIE or does it mean offset from start of .debug_frame to the CIE. Per Ian Lance Taylor's blog, and if I'm interpreting it correctly, (http://www.airs.com/blog/archives/460) it seems to be latter. CIE_pointer in .debug_frame is relative to the start of the .debug_frame section. In .eh_frame section it is encoded based on the selected encoding, often relative to the start of the CIE_pointer. ... .LSFDE0: .4byte@.LEFDE0-@.LASFDE0 -- FDE .LASFDE0: .4byte@.Lframe0-- CIE pointer - direct reference to CI (not offset from start of .debug_frame) This looks fine. This direct reference to start of CIE is causing objdump to reference invalid CIE and hence print invalid CFI - although the CFI itself is valid since the code_factor and such are seeded from a bogus CIE. 0060 0014 80e0c000 FDE cie=48b25ff8 pc=80a680d4..80a6810a ... ^^ The 48b25ff8 looks wrong though, it would really surprise me if .debug_frame section was more than 1GB big. So perhaps your assembler or linker don't handle it properly? Looking at gcc 4.8 source : gcc/dwarf2out.c : It seems to hint that the CIE_pointer needs to be relative to .debug_frame (just as I think) + if (for_eh) +dw2_asm_output_delta (4, l1, section_start_label, FDE CIE offset); + else +dw2_asm_output_offset (DWARF_OFFSET_SIZE, section_start_label, + debug_frame_section, FDE CIE offset); However to not generate a direct reference, most targets need to implement ASM_OUTPUT_DWARF_OFFSET which is not really the case. ASM_OUTPUT_DWARF_OFFSET is there just for targets where the normal way doesn't produce desired result. Jakub
Re: Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
On 06/24/2013 12:33 PM, Jakub Jelinek wrote: On Mon, Jun 24, 2013 at 12:06:27PM +0530, Vineet Gupta wrote: I had a question about interpretation of FDE's CIE_pointer field (for .debug_frame) The spec say (from dwarf4 version although it really doesn't matter): 2. CIE_pointer (4 or 8 bytes, see Section 7.4) A constant offset into the .debug_frame section that denotes the CIE that is associated with this FDE. Does offset above mean offset from current location (in FDE) to CIE or does it mean offset from start of .debug_frame to the CIE. Per Ian Lance Taylor's blog, and if I'm interpreting it correctly, (http://www.airs.com/blog/archives/460) it seems to be latter. CIE_pointer in .debug_frame is relative to the start of the .debug_frame section. In .eh_frame section it is encoded based on the selected encoding, often relative to the start of the CIE_pointer. ... .LSFDE0: .4byte@.LEFDE0-@.LASFDE0 -- FDE .LASFDE0: .4byte@.Lframe0-- CIE pointer - direct reference to CI (not offset from start of .debug_frame) This looks fine. Pardon me if I sound dense (not really my area of expertise), wowever, the 2nd word in FDE above (@.Lframe0) is a direct reference to start of .debbug_frame shouldn't it be something like @.Lframe0 - @.Lframe0 i.e. zero. Or do you think asseblmer/linker need to interpret it like that. This direct reference to start of CIE is causing objdump to reference invalid CIE and hence print invalid CFI - although the CFI itself is valid since the code_factor and such are seeded from a bogus CIE. 0060 0014 80e0c000 FDE cie=48b25ff8 pc=80a680d4..80a6810a ... ^^ The 48b25ff8 looks wrong though, it would really surprise me if .debug_frame section was more than 1GB big. So perhaps your assembler or linker don't handle it properly? Exactly, although this is Linux kernel image which is linked at start of untranslated address space i.e. 0x8000_ onwards. The point however is that cie value above should read zero - not 0x8abcdefg since it is relative to start of .debug_frame -Vineet
Re: Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
On Mon, Jun 24, 2013 at 12:43:15PM +0530, Vineet Gupta wrote: Pardon me if I sound dense (not really my area of expertise), wowever, the 2nd word in FDE above (@.Lframe0) is a direct reference to start of .debbug_frame shouldn't it be something like @.Lframe0 - @.Lframe0 i.e. zero. Or do you think asseblmer/linker need to interpret it like that. On most targets, .debug_* sections are placed at address 0, so absolute relocations are the same as relocations relative to the start of the section. Note, in any case, it is always supposed to be start of the .debug_frame section, not start of the contribution of the current translation unit to the .debug_frame section. So if you have two compilation units, one has 250 bytes in .debug_frame section and second has some CIE at offset 0, after linking FDEs from the second CU would use CIE_pointer 250, not 0. So, either .debug_* sections are placed at address 0 and then absolute relocations will do the trick, or you need some kind of section relative relocation (e.g. ia64 has it I think). This isn't specific just to .debug_frame, e.g. DW_FORM_strp/DW_FORM_sec_offset encoded values in .debug_info or .debug_abbrev offsets in .debug_info CU header, DW_OP_call_ref arguments, .debug_aranges/.debug_pubtypes/.debug_pubnames offsets to .debug_info all have these requirements. Jakub
Re: Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
On 06/24/2013 12:58 PM, Jakub Jelinek wrote: On most targets, .debug_* sections are placed at address 0, so absolute relocations are the same as relocations relative to the start of the section. [snipped] So, either .debug_* sections are placed at address 0 and then absolute relocations will do the trick, or you need some kind of section relative relocation (e.g. ia64 has it I think). This isn't specific just to .debug_frame, e.g. DW_FORM_strp/DW_FORM_sec_offset encoded values in .debug_info or .debug_abbrev offsets in .debug_info CU header, DW_OP_call_ref arguments, .debug_aranges/.debug_pubtypes/.debug_pubnames offsets to .debug_info all have these requirements. Jakub Aha, I see what's happening. For historical reasons, ARC Linux kernel stack unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being non allocatable it would default to address zero hence the orig absolute relocations would work for most ports. However in our case we force it allocatable in kernel builds and thus it is relocated to 0x8abcdefg, thus the usage of absolute relocations ends up generating the invalid reference. Thus it seems we do need the special section relative reference. Thanks a bunch for clarifying. --Vineet
objdump for gimple [lto]
Hello, I see this item in http://gcc.gnu.org/wiki/LinkTimeOptimization : 7. Browsing/dumping tools for LTO files Is there anything already out there, even if half-baked? I am having trouble understanding a problem in LTO and I think the bug is in the writing of trees into the object file but can't find a way to know this unless I have something like an objdump for gimple. If there's no tool out there to straightforwardly know this, what's the best approach to find out if there's a problem written in the LTO stream? Cheers, Paulo Matos
Re: GCC talks at the GNU Hackers Meeting?
Hello Iain. I'm adding ghm-discuss in Cc. I think we shouldn't follow up on gcc@ any more at this point. Let's not bother the hardworking compiler masters :-). On 2013-06-24 at 01:15, Iain Buclaw wrote: I did a similar such talk at DConf 2013 with my GCC front-end for the D programming language (GDC). Not sure if would be relevant a GCC conference, but I could think about some of the challenges I've faced. :o) I for one would be very interested. Well, the conference is about GNU in general, so many people will not be particularly familiar with GCC internals. I, for example, have some knowledge about the general architecture but don't actually know the API, and have never attempted any non-trivial modification to the GCC source base. Some people will be more familiar than me, others even less; but I don't think that it's a serious problem if a few talks are less accessible than others. I like Einstein's phrase as simple as possible, but not simpler. If needed we can make a GCC session or an advanced session, and schedule all such talks close together for the public's sake. Your talk could follow Philip's, I suppose, since if I understood correctly Philips wanted to talk about frontends in general, and you more specifically about the frontend of D. What do you think, Philip? We can certainly have both talks, but I think it would be better if we tried not to say the same things twice. In any case, I would be interested in attending this - just to get a better feel of the community, as a definite future goal would be to get the D front-end merged into GCC proper as an officially supported language. Of course, welcome. I've registered you and added your talk to the web page. Please register to ghm-discuss at https://lists.gnu.org/mailman/listinfo/ghm-discuss . Philip, I'm waiting for your confirmation before adding you to the official page as well; we can write to be confirmed if you want. Thanks, -- Luca Saiu Home page: http://ageinghacker.net GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://marionnet.org
[libgomp] MEMMODEL_* constants and OMP_STACKSIZE: a few questions/proposals
Hi, I’ve recently started to work on libgomp with the goal of proposing a new way of handling queues of tasks based on the work done by a PhD student. While working on libgomp’s code I noticed two things that puzzled me: - The code uses gcc’s atomic builtins but doesn’t use the __ATOMIC_* constants to select the desired memory model for the operation. Instead it uses the MEMMODEL_* constants defined in libgomp.h. Is there a good reason for that? I’d be very tempted to (possibly) “fix” it with the attached patch. - When using the OMP_STACKSIZE environment variable to select the stack size of the threads, it only applies to the threads created by pthread_create and has no effect on the main thread of the process. This behaviour looks compliant with version 3.1 of the spec: “OMP_STACKSIZE sets the stacksize-var ICV that specifies the size of the stack for threads created by the OpenMP implementation” but I was wondering if it was the best thing to do? I discovered this when playing with the UTS benchmark of the BOTS benchmark suite which can require quite big stacks for some input datasets. It uses OMP_STACKSIZE to set its requirements but that doesn’t prevent a task with stack requirements bigger than the default size to be scheduled on the main thread of the process, leading the application to crash because of a stack overflow. Should the application be setting itself the size of its main thread’s stack? Shouldn’t something be done in the compiler/runtime to handle this? That wouldn’t be not compliant with the spec and much more intuitive to the programmer: “I can expect that every thread will have OMP_STACKSIZE worth of stack”. I should hopefully write again soon with some more useful patches and proposals. In the meantime, thank you for your answers. Regards, Kévin 0001-Don-t-redefine-an-equivalent-to-the-__ATOMIC_-consta.patch Description: Binary data
Re: GCC talks at the GNU Hackers Meeting?
On 24 June 2013 17:02, Luca Saiu posit...@gnu.org wrote: Hello Iain. I'm adding ghm-discuss in Cc. I think we shouldn't follow up on gcc@ any more at this point. Let's not bother the hardworking compiler masters :-). On 2013-06-24 at 01:15, Iain Buclaw wrote: I did a similar such talk at DConf 2013 with my GCC front-end for the D programming language (GDC). Not sure if would be relevant a GCC conference, but I could think about some of the challenges I've faced. :o) I for one would be very interested. Well, the conference is about GNU in general, so many people will not be particularly familiar with GCC internals. I, for example, have some knowledge about the general architecture but don't actually know the API, and have never attempted any non-trivial modification to the GCC source base. Some people will be more familiar than me, others even less; but I don't think that it's a serious problem if a few talks are less accessible than others. I like Einstein's phrase as simple as possible, but not simpler. If needed we can make a GCC session or an advanced session, and schedule all such talks close together for the public's sake. Your talk could follow Philip's, I suppose, since if I understood correctly Philips wanted to talk about frontends in general, and you more specifically about the frontend of D. What do you think, Philip? We can certainly have both talks, but I think it would be better if we tried not to say the same things twice. My talk at Dconf2013 can be bulleted into the following: - What is GDC? - A brief history of porting the D language to GCC. - D language and library support, including current challenges being faced. - Introduction to GCC, in particular an overview of the compilation process from GENERIC down to RTL and how things tie in with the D front end. - Taking advantage of the GCC backend. What features of GCC are leveraged by the D front end (eg: builtin functions, extended assembler) - Future goals and architecture support. In any case, I would be interested in attending this - just to get a better feel of the community, as a definite future goal would be to get the D front-end merged into GCC proper as an officially supported language. Of course, welcome. I've registered you and added your talk to the web page. Please register to ghm-discuss at https://lists.gnu.org/mailman/listinfo/ghm-discuss . Have registered myself. I'll have to confirm my availability. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: GCC talks at the GNU Hackers Meeting?
On 2013-06-24 at 19:14, Iain Buclaw wrote: My talk at Dconf2013 can be bulleted into the following: - What is GDC? - A brief history of porting the D language to GCC. - D language and library support, including current challenges being faced. - Introduction to GCC, in particular an overview of the compilation process from GENERIC down to RTL and how things tie in with the D front end. - Taking advantage of the GCC backend. What features of GCC are leveraged by the D front end (eg: builtin functions, extended assembler) - Future goals and architecture support. Cool for me. If we have Philip's talk as well then part of your fourth point might become redundant, but it's quite small fraction of the talk. Of course you can reuse slides. We all do :-). Have registered myself. I'll have to confirm my availability. Oh, sorry. I'm marking your name as to be confirmed then. Thanks, -- Luca Saiu Home page: http://ageinghacker.net GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://marionnet.org
Re: GCC talks at the GNU Hackers Meeting?
On 24 June 2013 18:38, Luca Saiu posit...@gnu.org wrote: On 2013-06-24 at 19:14, Iain Buclaw wrote: My talk at Dconf2013 can be bulleted into the following: - What is GDC? - A brief history of porting the D language to GCC. - D language and library support, including current challenges being faced. - Introduction to GCC, in particular an overview of the compilation process from GENERIC down to RTL and how things tie in with the D front end. - Taking advantage of the GCC backend. What features of GCC are leveraged by the D front end (eg: builtin functions, extended assembler) - Future goals and architecture support. Cool for me. If we have Philip's talk as well then part of your fourth point might become redundant, but it's quite small fraction of the talk. Of course you can reuse slides. We all do :-). As I said, I can rehash some of what was gone over and perhaps focus more on challenges of representing the D language within GCC. (Eg: Delegates, Thunks, TLS symbols and D runtime...) Have registered myself. I'll have to confirm my availability. Oh, sorry. I'm marking your name as to be confirmed then. No problem mate, I'll let you know as soon as possible. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
On 06/24/2013 12:37 AM, Vineet Gupta wrote: Aha, I see what's happening. For historical reasons, ARC Linux kernel stack unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being non allocatable it would default to address zero hence the orig absolute relocations would work for most ports. However in our case we force it allocatable in kernel builds and thus it is relocated to 0x8abcdefg, thus the usage of absolute relocations ends up generating the invalid reference. Thus it seems we do need the special section relative reference. Thanks a bunch for clarifying. It seems like it would be easier to change the kernel to use .eh_frame rather than adding relocation types and changing the tool chain... r~
Re: Interpretation of DWARF FDE-CIE_pointer field for .debug_frame
On 06/25/2013 12:35 AM, Richard Henderson wrote: On 06/24/2013 12:37 AM, Vineet Gupta wrote: Aha, I see what's happening. For historical reasons, ARC Linux kernel stack unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being non allocatable it would default to address zero hence the orig absolute relocations would work for most ports. However in our case we force it allocatable in kernel builds and thus it is relocated to 0x8abcdefg, thus the usage of absolute relocations ends up generating the invalid reference. Thus it seems we do need the special section relative reference. Thanks a bunch for clarifying. It seems like it would be easier to change the kernel to use .eh_frame rather than adding relocation types and changing the tool chain... Yes that is what we concluded as well. Although the current issue manifests only as objdump/readelf splat with kernel binary - the unwinder itself in kernel works OK. But .eh_frame is what others do so we might as well follow suite given that ARC gcc 4.8 now has started generating one. -Vineet
Re: Question about conds attribute for *thumb2_alusi3_short
On 13/6/24 下午11:43, Tom de Vries wrote: Richard, I've noticed that f.i. *thumb2_alusi3_short has no explicit setting of the conds attribute, which means the value of the conds attribute for this insn is nocond: ... (define_insn *thumb2_alusi3_short [(set (match_operand:SI 0 s_register_operand =l) (match_operator:SI 3 thumb_16bit_operator [(match_operand:SI 1 s_register_operand 0) (match_operand:SI 2 s_register_operand l)])) (clobber (reg:CC CC_REGNUM))] TARGET_THUMB2 reload_completed GET_CODE(operands[3]) != PLUS GET_CODE(operands[3]) != MINUS %I3%!\\t%0, %1, %2 [(set_attr predicable yes) (set_attr length 2)] ) ... AFAIU, this insn is either: - conditional, and does not modify cc, or - unconditional, and sets cc. So the clobber of CC in the RTL conservatively describes both cases. It seems to me the logical conds setting for the conditional case is nocond, set (or perhaps clob) for the unconditional case. So, is this a more accurate value of conds for this insn: ... (set (attr conds) (if_then_else (match_test GET_CODE (PATTERN (insn)) == COND_EXEC) (const_string nocond) (const_string set)))] ... ? Is there a generic need to have this attribute accurate for all insns? Following this thread that Tom pointed to me earlier in internal discussion: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00723.html If the short-CC-clobbered form is selected very late now, I think this pattern simply is (or should) not be used for the conditional (within IT-block) case. It should simply be set to clob. Predicable might be set to no as well... Chung-Lin
[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Version|unknown |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- .
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Janne Blomqvist from comment #13) I believe a lot of progress has been made indeed. However, the fundamental(?) issue of module sizes growing exponentially with deep module hierarchies still remains. The solution to that is to not include transitive dependencies, which in turn would require a module cache for good performance. Whether that is worth doing, and who is willing and able to do it, is unclear. note that there could also be disadvantages for that solution. For example, dependencies for a given .F would be more difficult to find (i.e. not just the USE statements). I'm not sure what implications that would have e.g. for 'smart' recompilation (i.e. based on time stamps of .mod). The module cache would also not work very well for the (common, I guess) case of having a single module per file, and all USE statements on top. It might thus be that the current state is the sweet spot.
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Was marked as ASSIGNED, but actually Not yet assigned to anyone. Set to NEW.
[Bug fortran/47267] array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Was marked as ASSIGNED, but actually Not yet assigned to anyone. Set to NEW.
[Bug fortran/25708] [F95] Module loading is not good at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr --- Was marked as ASSIGNED, but actually Not yet assigned to anyone. Set to NEW.
Re: confirm unsubscribe from gcc-bugs@gcc.gnu.org
On 2013-06-24 09:11, gcc-bugs-h...@gcc.gnu.org wrote: Hi! This is the ezmlm program. I'm managing the gcc-bugs@gcc.gnu.org mailing list. To confirm that you would like joop.boo...@boonen.org removed from the gcc-bugs mailing list, please send an empty reply to this address: gcc-bugs-uc.1372057878.ilaghhpkihfgnfkidodi-joop.boonen=boonen@gcc.gnu.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, m...@xdd.ff.com receives messages with return path: gcc-bugs-return-number-mary=xdd.ff@gcc.gnu.org. Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to gcc-bugs-requ...@gcc.gnu.org and put the entire address listed above into the Subject: line. --- Administrative commands for the gcc-bugs list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: gcc-bugs-subscr...@gcc.gnu.org To remove your address from the list, send a message to: gcc-bugs-unsubscr...@gcc.gnu.org Send mail to the following for info and FAQ for this list: gcc-bugs-i...@gcc.gnu.org gcc-bugs-...@gcc.gnu.org Similar addresses exist for the digest list: gcc-bugs-digest-subscr...@gcc.gnu.org gcc-bugs-digest-unsubscr...@gcc.gnu.org To get messages 123 through 145 (a maximum of 100 per request), mail: gcc-bugs-get.123_...@gcc.gnu.org To get an index with subject and author for messages 123-456 , mail: gcc-bugs-index.123_...@gcc.gnu.org They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: gcc-bugs-thread.12...@gcc.gnu.org The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example john@host.domain, just add a hyphen and your address (with '=' instead of '@') after the command word: gcc-bugs-subscribe-john=host.dom...@gcc.gnu.org To stop subscription for this address, mail: gcc-bugs-unsubscribe-john=host.dom...@gcc.gnu.org In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at gcc-bugs-ow...@gcc.gnu.org. Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: anonym...@sourceware.org Received: (qmail 28832 invoked by uid 48); 24 Jun 2013 07:11:18 - Message-ID: 20130624071118.28829.qm...@sourceware.org From: anonym...@sourceware.org Date: Mon, 24 Jun 2013 07:11:18 + To: gcc-bugs-unsubscribe-joop.boonen=boonen@sourceware.org User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
[Bug c++/57693] New: The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693
Bug ID: 57693
Summary: The program logically failed in case of used int b +=
b++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad94009277 at gmail dot com
Steps to reproduce:
1. Write the following source cod and compile it:
#include iostream
using namespace std;
int main(){
int d = 7;
int c = 7;
int b = c;
b += b++;
d += d++;
cout c = c endl;
cout d = d endl;
return 0;
}
2. Run the appropriate generated executable file.
Actual result:
It's printed:
c = 8
d = 15
Expected result:
It should be printed:
c = 15
d = 15
Please note that there are different assemble codes for used operators:
1) d += d++
movl -4(%rbp), %eax // Copies value of d to register %eax
addl %eax, %eax // Adds %eax to %eax, remembers the value in %eax
movl %eax, -4(%rbp) // Moves %eax to d (d = 14)
addl $1, -4(%rbp) // Increments the value of d (d = 15)
2) b += b++
movl -12(%rbp), %eax // Moves the value of b to %eax
movl -12(%rbp), %edx // Moves the value of b to %edx
leal (%rax,%rdx), %edx // Adds %rax to %rdx and stores result in %edx (%rax and
%rdx are equal to 7, so after this operation %edx is 14)
movl %edx, -12(%rbp) // Moves %edx to d (d = 14)
addl $1, %eax // Increments the value of %eax (%eax = 8).
movl %eax, -12(%rbp) // Moves %eax to d (d = 8)
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Both: b += b++; And d += d++; are undefined what value b and d is going to be as there are no sequence point intbetween the two assignments. They could be: temp = b; b++; b += temp; or b++; b+=b;
[Bug c++/57694] New: [c++11] constexpr constructor do not work with const address of own member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694
Bug ID: 57694
Summary: [c++11] constexpr constructor do not work with const
address of own member
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lts-rudolph at gmx dot de
The following code results in
error: field initializer is not constant
class A
{
private:
int a;
const int* const aptr;
public:
constexpr A( int _a):
a(_a)
, aptr( a) // why aptr could not be initialized?
{}
};
class Data { } d1;
class B
{
private:
Data* dptr1;
public:
constexpr B(Data* _p): dptr1( _p) {}
};
class Use
{
static constexpr A a{2}; // fail! error: field initializer is not
constant
static constexpr B b{d1}; // works
};
[Bug c++/57694] [c++11] constexpr constructor do not work with const address of own member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 --- Comment #2 from Vladimir vlad94009277 at gmail dot com --- (In reply to Andrew Pinski from comment #1) Both: b += b++; And d += d++; are undefined what value b and d is going to be as there are no sequence point intbetween the two assignments. They could be: temp = b; b++; b += temp; or b++; b+=b; I tried this issue on version 4.8.1 and it works successfully. It seems the bug was already fixed.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #13) The file /usr/include/stdc-predef.h is from glibc (v2.17 on Arch) and is specifically mentioned as being preincluded in http://gcc.gnu.org/gcc-4.8/porting_to.html. In fact, using -ffreestanding solves the issue. So when you use -ffreestanding, is stdc-predef.h still included? You could put a break in push_command_line_include and check if -include foo.h still includes stdc-predef.h and whether it shows also the problem. If the file is included but there is no bug, then my guess is that the code executed before or after the pre-include stdc-predef.h is missing something for the -imacros case. If it shows the bug, then the code for pre-including stuff must be wrong somehow, perhaps cpp_push_default_include is doing something wrong when compared to cpp_push_include.
[Bug c++/57695] New: [c++11] generalized attributes with avr __progmem__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695
Bug ID: 57695
Summary: [c++11] generalized attributes with avr __progmem__
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lts-rudolph at gmx dot de
The two statements:
extern const X x __attribute__ ((__progmem__)) = { 1 }; // works as expected
extern const X x [[__progmem__]] = { 1 };// warning broken
code
See the following description to get working example.
The following code compiles as expected with avr-g++ 4.8.1: (code must split in
different translation units to see any result, because the optimizer will
remove all effects while inlining the instructions)
x.h:
struct X
{
uint8_t a;
};
x.cpp:
extern const X x __attribute__ ((__progmem__)) = { 1 };
main.cpp:
#include x.h
extern const X x __attribute__ (( __progmem__ ));
int main()
{
PORTB = pgm_read_byte( (x.a));
return 0;
}
results in (objdump -d):
001a x:
1a: 01 00 ..
...
2e: ea e1 ldi r30, 0x1A ; 26
30: f0 e0 ldi r31, 0x00 ; 0
32: c8 95 lpm
the result is fine.
Using generalized attributes do NOT work:
extern const X x [[__progmem__]] = { 1 };
this results in a warning x.cpp:8:32: warning: 'progmem' attribute directive
ignored [-Wattributes] and the code is broken because the var x is stored to
ram instead of flash.
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- You are not listening, the only bug here is in your testcase, not in the compiler.
[Bug c++/57695] [c++11] generalized attributes with avr __progmem__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Probably because you should be using [[gnu::progmem]] or [[gnu::__progmem__]].
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jun 24 08:43:55 2013 New Revision: 200361 URL: http://gcc.gnu.org/viewcvs?rev=200361root=gccview=rev Log: 2013-06-24 Steven G. Kargl s...@troutmask.apl.washington.edu Francois-Xavier Coudert fxcoud...@gcc.gnu.org Dominique d'Humieres domi...@lps.ens.fr PR fortran/52413 * simplify.c (gfc_simplify_fraction): Fix the sign of negative values. 2013-06-24 Francois-Xavier Coudert fxcoud...@gcc.gnu.org Dominique d'Humieres domi...@lps.ens.fr PR fortran/52413 * gfortran.dg/fraction.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/fraction.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the trunk (GCC 4.9). Thanks for the report!
[Bug c++/57695] [c++11] generalized attributes with avr __progmem__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695 Klaus Rudolph lts-rudolph at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Klaus Rudolph lts-rudolph at gmx dot de --- @Jakub: [[gnu::__progmem__]] works! [[gnu::progmem]] fails. Thanks a lot!
[Bug c++/57693] The program logically failed in case of used int b += b++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57693 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Both: b += b++; And d += d++; are undefined what value b and d is going to be as there are no sequence point intbetween the two assignments. They could be: temp = b; b++; b += temp; or b++; b+=b; Please, could we make more use of the FAQ? http://gcc.gnu.org/wiki/FAQ#undefinedbut If you think the answer does not provide enough information, just extend the answer there. (it could mention some example, and -Wsequence-points). Otherwise, we have the same back and forth over and over again to the frustration of users and the time waste of developers: what is UB? but my program worked before! but my program works without optimizations! but I know how it should work! can't gcc be consistent? but UB should not affect my problem! I think this should not be UB!
[Bug fortran/57696] New: Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 Bug ID: 57696 Summary: Defined assignment for components not used when those are ALLOCATABLE 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: pault at gcc dot gnu.org The following prints 42 42 with gfortran and 42 20 with crayftn. Thus, gfortran does not use defined assignment - but it should. Note: If right%foo is not allocated, the code segfaults with crayftn. module m0 implicit none type component integer :: i = 42 contains procedure :: assign0 generic :: assignment(=) = assign0 end type type parent type(component), allocatable :: foo end type contains elemental subroutine assign0(lhs,rhs) class(component), intent(INout) :: lhs class(component), intent(in) :: rhs lhs%i = 20 end subroutine end module program main use m0 implicit none type(parent) :: left, right allocate(right%foo) print *, right%foo left = right print *, left%foo end
[Bug rtl-optimization/57518] [4.8/4.9 Regression] Redundant insn generated in LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.0 |4.8.2 Summary|[4.9 Regression] Redundant |[4.8/4.9 Regression] |insn generated in LRA |Redundant insn generated in ||LRA Known to fail||4.8.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Not sure if we want to backport such change though.
[Bug tree-optimization/57488] [4.9 regression] loop terminates early at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jun 24 10:22:22 2013 New Revision: 200363 URL: http://gcc.gnu.org/viewcvs?rev=200363root=gccview=rev Log: 2013-06-24 Richard Biener rguent...@suse.de PR tree-optimization/57488 * tree-ssa-pre.c (insert): Clear NEW sets before each iteration. * gcc.dg/torture/pr57488.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57488.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug fortran/57696] Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- From Fortran 2008, 7.2.1.3 Interpretation of intrinsic assignments, paragraph 13 (excerpt): For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated. (2) If the component of the value of expr is allocated, the corresponding component of the variable is allocated with the same dynamic type and type parameters as the component of the value of expr. If it is an array, it is allocated with the same bounds. The value of the component of the value of expr is then assigned to the corresponding component of the variable using defined assignment if the declared type of the component has a type-bound defined assignment consistent with the component, and intrinsic assignment for the dynamic type of that component otherwise.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #26 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #25) Created attachment 30346 [details] conti This patch creates references where the referring node is the old one, not the newly created clone. I think that create_specialized_node should traverse aggvals and create the references. Hopefully I can prepare a patch doing that in the course of this afternoon (but of course feel free to make one yourself if you are faster).
[Bug go/57689] [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 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 Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Oops.
[Bug tree-optimization/57685] [4.8/4.9 Regression] GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-24 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.2 Summary|GCC stuck in an infinite|[4.8/4.9 Regression] GCC |loop|stuck in an infinite loop Ever confirmed|0 |1 Known to fail||4.8.1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug rtl-optimization/57676] [4.8/4.9 Regression] ICE: Maximum number of LRA constraint passes is achieved (30)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57676 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Keywords||ra Last reconfirmed||2013-06-24 CC||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE: Maximum number of LRA |[4.8/4.9 Regression] ICE: |constraint passes is|Maximum number of LRA |achieved (30) |constraint passes is ||achieved (30) Target Milestone|--- |4.8.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/323] optimized code gives strange floating point results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||oliverst at online dot de --- Comment #191 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 57669 has been marked as a duplicate of this bug. ***
[Bug target/57669] Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 323 ***
[Bug fortran/57696] Defined assignment for components not used when those are ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57696 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug other/57668] Regression in vectorizing memcpy pattern.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57668 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. memcpy_byte.c:2: note: Completely unroll loop 14 times the new unrolling code unrolls the epilogue loop completely: Estimating sizes for loop 3 BB: 8, after_exit: 0 size: 0 i.0_40 = (sizetype) i_38; size: 1 _41 = s_7(D) + i.0_40; size: 1 _42 = d_9(D) + i.0_40; size: 1 _43 = *_42; size: 1 *_41 = _43; size: 1 i_45 = i_38 + 1; size: 2 if (i_45 _16) Exit condition will be eliminated in last copy. BB: 9, after_exit: 1 size: 7-0, last_iteration: 7-2 Loop size: 7 Estimated size after unrolling: 68 And loop distribution fails to detect the memcpy clone, too.
[Bug debug/57664] [4.8/4.9 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57664 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/57661] [4.9 Regression] ICE: SIGSEGV in verify_ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57661 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, we are missing the SSA_NAME_DEF_STMT for _18.
[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jun 24 11:14:31 2013 New Revision: 200364 URL: http://gcc.gnu.org/viewcvs?rev=200364root=gccview=rev Log: 2013-06-24 Richard Biener rguent...@suse.de PR testsuite/57686 * gcc.dg/torture/pr57584.c: Remove target specific bits. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr57584.c
[Bug fortran/57697] New: Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697
Bug ID: 57697
Summary: Segfault with defined assignment for components during
intrinsic assignment
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
Found with ForTrilinos's ForTrilinos_ADT_3D_Burgers_6th_Pade example.
For the code:
function new_scalar_field(initial,comm) result(this)
...
if (.not. allocated(map)) then
map = Epetra_Map(NumGlobalElements,NumMyElements,IndexBase,comm)
gfortran generates the code:
static struct epetra_map * _F.DA104 = 0B;
static struct universal _F.DA105;
...
if (map == 0B)
{
{
static integer(kind=4) C.5077 = 1;
static integer(kind=4) C.5076 = 4096;
if (_F.DA104 != 0B) goto L.249;
_F.DA104 = (struct epetra_map *) __builtin_malloc (56);
L.249:;
*_F.DA104 = create_linear (C.5076, nummyelements, C.5077,
(struct __class_fepetra_comm_Epetra_comm *) comm);
}
_F.DA105 = map-epetra_blockmap.universal;
if (map != 0B) goto L.251;
map = (struct epetra_map *) __builtin_malloc (56);
L.251:;
*map = *_F.DA104;
Note that the assignment to _F.DA105 dereferences map, which is known to be
NULL!
[Bug tree-optimization/57698] New: rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Bug ID: 57698 Summary: rev.200179 causes many errors (inlining failures) when building Firefox Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: markus at trippelsdorf dot de I cannot build Firefox anymore with trunk because of inline errors, e.g.: /home/markus/mozilla-central/js/src/jsapi.h: In function ‘js::regexp_exec(JSContext*, unsigned int, JS::Value*)’: /home/markus/mozilla-central/js/src/builtin/RegExp.cpp:307:1: error: inlining failed in call to always_inline ‘IsRegExp(JS::Value const)’: indirect function call with a yet undetermined callee IsRegExp(const Value v) ^ In file included from /home/markus/mozilla-central/js/src/jsprvtd.h:24:0, from /home/markus/mozilla-central/js/src/builtin/RegExp.h:10, from /home/markus/mozilla-central/js/src/builtin/RegExp.cpp:7: /home/markus/mozilla-central/js/src/jsapi.h:706:5: error: called from here if (Test(thisv)) IMO that is to aggressive (and will affect many projects). Wouldn't a simple warning be enough?
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|RESOLVED|NEW Version|4.7.0 |4.8.1 Resolution|FIXED |--- --- Comment #16 from dominik.stras...@onespin-solutions.com --- The situation is much improved in 4.8.1, but still not usable for me in bigger configurations: time ./a.out 1 real0m0.907s user0m0.904s sys0m0.003s time ./a.out 2 real0m3.713s user0m3.708s sys 0m0.001s time ./a.out 4 real 0m13.820s user0m13.812s sys 0m0.001s time ./a.out 8 real0m56.759s user0m56.729s sys0m0.001s Still O(n^2). (I modified the test program to use argv[1] as loop counter. W/o _GLIBCXX_DEBUG: time ./a.out 1 real0m0.008s user0m0.006s sys0m0.002s ./a.out 2 real0m0.013s user0m0.008s sys0m0.004s ./a.out 4 real0m0.013s user0m0.013s sys0m0.000s ./a.out 8 real0m0.026s user0m0.024s sys0m0.002s Which shows O(n) behavior.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #17 from dominik.stras...@onespin-solutions.com --- Created attachment 30350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30350action=edit New testcase
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This doesn't make any sense to me.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Attachment #27332|0 |1 is obsolete|| Attachment #30350|0 |1 is obsolete|| --- Comment #18 from dominik.stras...@onespin-solutions.com --- Created attachment 30351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30351action=edit Really new testcase
[Bug fortran/57639] [OOP] ICE with polymorphism (and illegal code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57639 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- (In reply to janus from comment #4) The following patch fixes both variants: ... and regtests cleanly. Confirmed.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com --- I'm not going to work on this anyway, but really I'm not at all sure that debug-mode is by design made for bigger configurations, thus makes sense to give high priority to this kind of issue. Unless of course users actively contribute improvements.
[Bug tree-optimization/57656] [4.7/4.8/4.9 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30352 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30352action=edit patch Fails at -O0 -fstrict-overflow as we fold int t = 1 - (a - b) / c; into int t = (b - a) / c + 1; The change in r117969 exposed a bug in negate_expr_p, namely that we cannot negate (a - b) / c as (b - a) / c because that associates the negate with the division which exposes possible undefined overflow in -(a - b) that is not there in the original expression for c != +-1. This is a bit a problem with the negate_expr_p specification - the API doesn't specify whether we are removing an existing negate or whether we are adding one. This case removes one from the division and adds it to the subtraction. -(a - b) - (b - a) is ok, but (a - b) - -(b - a) is not - the API doesn't really distinguish these two cases but in the MINUS_EXPR case clearly implements -(a - b) - (b - a). Testing the attached.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- I think this is due to a horrible hack in the front end which adds implicit extern C blocks around system headers, and a side-effect is that function prototypes of the form 'T f()' are treated as 'T f(...)' as in C, not 'T f(void)' as C++ requires. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982#c40 for another case where this bit us. This is a terrible terrible hack IMHO, and should be disabled in libstdc++ headers, because when we write void(*)() we damn well mean it, we don't mean something different. Having to use void(*)(void) is an abomination.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com --- And we already analyzed the issue and figured out that further improvements aren't part of it (See Comment 6 and 9).
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Yes it is, a huge abomination, I had no idea we had something like that. Then, I don't know, I don't think it's going away any time soon, probably we should bite the bullet and add those void with a big comment for the time being?
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- ... by the way, I'm *very* surprised that nobody noticed this over the years: the freestanding atexit is declared like this in cstdlib in 4.0.0!?!
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- I'm adding Jakub in CC.
[Bug c++/57699] New: Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
Bug ID: 57699
Summary: Disable empty parameter list misinterpretation in
libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
In cp/parser.c the function cp_parser_parameter_declaration_clause has:
else if (token-type == CPP_CLOSE_PAREN)
/* There are no parameters. */
{
#ifndef NO_IMPLICIT_EXTERN_C
if (in_system_header current_class_type == NULL
current_lang_name == lang_name_c)
return NULL_TREE;
else
#endif
return void_list_node;
}
This means that on implicit extern C systems (ones not known to have C++
compatible libc headers) we interpret void(*)() as void(*)(...)
This might be necessary to properly handle libc headers on those systems, but
should not be enabled for libstdc++ headers (or more generally, any headers
actually written in C++) because when we write void(*)() in C++ we damn well
mean what we wrote, we shouldn't have to say void(*)(void)
This has caused problems more than once in libstdc++, where correct C++ code in
an explicit extern C block is misinterpreted by the front end, because
libstdc++ headers are system headers (due to the #pragma we use) and we
sometimes have to declare functions in extern C blocks. The problems are not
found immediately because they only happen on less-tested targets such as AIX
and eCos:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982#c40
It would be nice to have some way to mark libstdc++ headers to prevent the code
above returning NULL_TREE.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #21 from dominik.stras...@onespin-solutions.com --- How can I help ? My goal is to run our entire regression test suite with STL debugging switched on as this is great for quality assurance. Having fought several problems, this now seems to be my final obstacle. After one year I now have a fix in a GCC release but unfortunately still no cigar. If you point me to sth. where I can look at I will happily try to contribute.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- I've opened PR 57699 -- it would be nice not to have to write (void) in our headers.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com --- Get in touch with Francois and work on further improvements with him.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #4) ... by the way, I'm *very* surprised that nobody noticed this over the years: the freestanding atexit is declared like this in cstdlib in 4.0.0!?! It only matters on some less-well-tested targets, because NO_IMPLICIT_EXTERN_C is defined for sane targets. It might also not matter if the system headers declare: int atexit(void (*)(void)); as GNU Libc does, because then the function is declared portably for both C and C++. Presumably the eCos headers either don't declare atexit or declare it without an abominable (void) parameter list.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Of course. Since, AFAIK, we already had the sensible () with no void in like 2005, communities outside GCC must have workarounds in place, can wait a bit more. Let's mark the C++ front-end issue as blocking this one.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Jonathan Wakely from comment #7) (In reply to Paolo Carlini from comment #4) ... by the way, I'm *very* surprised that nobody noticed this over the years: the freestanding atexit is declared like this in cstdlib in 4.0.0!?! It only matters on some less-well-tested targets, because NO_IMPLICIT_EXTERN_C is defined for sane targets. It might also not matter if the system headers declare: int atexit(void (*)(void)); as GNU Libc does, because then the function is declared portably for both C and C++. Presumably the eCos headers either don't declare atexit or declare it without an abominable (void) parameter list. the eCos stdlib.h declares it the right way: stdlib.h:/* Type of function used by atexit() */ stdlib.h:typedef void (*__atexit_fn_t)( void ); stdlib.h:atexit( __atexit_fn_t /* func_to_register */ ); but because the cstdlib has this guard block it declares every thing by itself: #if !_GLIBCXX_HOSTED // The C standard does not require a freestanding implementation to // provide stdlib.h. However, the C++ standard does still require // cstdlib -- but only the functionality mentioned in // [lib.support.start.term].
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Uhm. I can't say to understand all the details of this wrt the various targets and the front-end, but given that C++11 *spells out* in 18.5 those damn void, I suppose we could do that in our implementation and be done with it. Jon, what do you think?
[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Jun 24 12:40:17 2013 New Revision: 200368 URL: http://gcc.gnu.org/viewcvs?rev=200368root=gccview=rev Log: 2013-06-24 Martin Jambor mjam...@suse.cz PR tree-optimization/57539 * cgraphclones.c (cgraph_clone_node): Add parameter new_inlined_to, set global.inlined_to of the new node to it. All callers changed. * ipa-inline-transform.c (clone_inlined_nodes): New variable inlining_into, pass it to cgraph_clone_node. * ipa-prop.c (ipa_propagate_indirect_call_infos): Do not call ipa_free_edge_args_substructures. (ipa_edge_duplication_hook): Only add edges from inlined nodes to rdesc linked list. Do not assert rdesc edges have inlined caller. Assert we have found an rdesc in the rdesc list. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphclones.c trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-prop.c trunk/gcc/lto-cgraph.c
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Jun 24 12:51:43 2013 New Revision: 200369 URL: http://gcc.gnu.org/viewcvs?rev=200369root=gccview=rev Log: 2013-06-24 Martin Jambor mjam...@suse.cz PR tree-optimization/57358 * ipa-prop.c (ipa_func_spec_opts_forbid_analysis_p): New function. (ipa_compute_jump_functions_for_edge): Bail out if it returns true. (ipa_analyze_params_uses): Generate pessimistic info when true. testsuite * gcc.dg/ipa/pr57358.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr57358.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, that will fix it right now. In the longer term it would be nice to get a FE change.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Sure, if we close this the C++ front-end issue remains open. I will commit the tweak to c_std and c_global, mainline only.
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Jun 24 12:57:52 2013 New Revision: 200370 URL: http://gcc.gnu.org/viewcvs?rev=200370root=gccview=rev Log: 2013-06-24 Martin Jambor mjam...@suse.cz PR tree-optimization/57358 * ipa-prop.c (parm_ref_data_preserved_p): Always return true when not optimizing. testsuite/ * gcc.dg/ipa/pr57358.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/ipa/pr57358.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/ipa-prop.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Created attachment 30353 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30353action=edit Test case
[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 30353 [details] Test case Should not this go to PR57696?
[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Should not this go to PR57696? No. The examples are similar, but they expose rather different bugs. PR57696 has already a test case and the problem there is that no defined assignment is done for an allocatable component. - Wrong code as the defined assignment is not invoked. This PR (and attachment 30353) is about an unallocated allocatable LHS, where for a component defined assignment is used. - Wrong code as it segfaults at run time.
[Bug libstdc++/57691] freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug tree-optimization/57521] [4.7/4.8/4.9 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It's if-conversion (we do not vectorize anything here). The predicates are inserted correctly but the wrong ones are being used for the predication. That is because the predecessor edge we chose in find_phi_replacement_condition is not fallthru and thus the predicate we chose is bogus. It seems to assume that critical edges are split. I have a patch.
[Bug other/57700] New: doc: improperly named node about Diagnostic Messages Formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57700 Bug ID: 57700 Summary: doc: improperly named node about Diagnostic Messages Formatting Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: akim.demaille at gmail dot com The node about Options to Control Diagnostic Messages Formatting seems to be named Language Independent Options (or something is wrong with the structure of Texinfo doc in there). See http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html and look at the title of the page. Of course the TOC is wrong etc. (And FWIW, there appears to be no appropriate Component in the bug tracker for documentation issues).
[Bug other/57700] doc: improperly named node about Diagnostic Messages Formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57700 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Akim Demaille from comment #0) See http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html and look at the title of the page. Of course the TOC is wrong etc. The URL should be http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html (And FWIW, there appears to be no appropriate Component in the bug tracker for documentation issues). Because documentation bugs should be assigned to the relevant component so the relevant maintainers can fix it, e.g. libstdc++ docs bugs get assigned to libstdc++. There's a documentation keyword instead.
[Bug tree-optimization/57701] New: Incorrect optimisation of inlined function with inline assembly when cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701 Bug ID: 57701 Summary: Incorrect optimisation of inlined function with inline assembly when cross-compiling Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sqweek at gmail dot com Created attachment 30354 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30354action=edit Standalone source file for reproducing gcc version 4.8.1 (GCC) My system is x86_64-unknown-linux-gnu, but I'm cross-compiling to x86 (-m32) Configured with: /build/gcc-multilib/src/gcc-4.8.1/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --enable-multilib --disable-libssp --disable-werror --enable-checking=release I'm running the gcc-multilib binary from archlinux, which slightly modifies the stock gcc build - it doesn't run fixinc.sh and adds -O2 to some configure tests. I suspect they are not important, but in the interest of full disclosure the details available in the prepare() function at https://projects.archlinux.org/svntogit/community.git/tree/repos/multilib-x86_64/PKGBUILD?h=packages/gcc-multilib The problem: I've attached a program (which I've tried to make smaller but failed to reproduce the problem) that runs fine when compiled with no flags, but fails when compiled with -O. -O2 also fails, but -O3 works again *shrug*. Build commands: gcc -m32 fpe.c -o fpe #produces a working binary gcc -m32 -O fpe.c -o fpe-O #produces the failing binary Anyway, the code uses inline assembly to setup the floating point unit, then calculates 0./0. The expected result is a NaN, but when compiled with -O the FPU gets setup differently and we get a SIGFPE instead. I'm pretty new at assembler, but I *think* I've ruled that out as the cause, I've been stepping through the instructions in gdb and the results from the inline assembly sections appear to be the same. The value returned from getFPcontrol() seems to be where the differences begun.
[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You do not properly specify the side-effects of the asms so the compiler assumes it can freely re-order things as it likes.
[Bug libitm/57643] libitm.c/reentrant.c hangs on POWER8 with HTM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- This was confirmed fixed (on Power and S390) with Torvald's two patches: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01132.html (revision 200250) http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01188.html (revision 200251)
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #27 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30355 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30355action=edit Proposed patch I'd suggest this (yet untested) patch.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- I saw this too. There is always_inline (force_inline in the source) function taking always_inline as a callback and we don't work hard enough to inline all of them. I am not sure if GCC is missing some indirect call inlining or it is bug in firefox. Concerning error/warning We generally output error when always_inline is not inlined for some reason, so it seems bit odd to error sometimes and warn at other times. We also may just have disregard_inline_limits attribute for uses like this. Honza
[Bug tree-optimization/57702] New: Reassoc missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57702
Bug ID: 57702
Summary: Reassoc missed optimizations
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
On:
int f1 (int x, int y) { x += y; return x + 3 * y; }
unsigned int f2 (unsigned int x, unsigned int y) { x += y; return x + 3 * y; }
int f3 (int x, int y) { x += 7 * y; return x + 12 * y; }
unsigned int f4 (unsigned int x, unsigned int y) { x += 7 * y; return x + 12 *
y; }
reassoc optimizes only the f4 function into x += 19 * y; at the tree level, and
at the RTL level combiner happens to optimize it except for f3, which has more
insns than f4. I don't see why not optimizing this even for signed types would
be problematic, as long as the multiplication is performed in the same signed
type and all terms have the same sign (with different sizes the optimization
could remove undefined overflow, but I don't see how it could introduce it).
When things are vectorized the RTL optimizations will hardly help though.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 --- Comment #5 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #4) ... So I think that the code in comment #0 is not legal. Then, should not this PR closed as INVALID? Yes, close as INVALID. -- For the record: NAG Fortran Compiler Release 5.3.1(928) says SOMETHING is not permitted in an initialisation expression and xlf 14.01..0003 complains: Variable something_array was declared as array of type ADJUSTABLE. This type of array is not permitted in a main program. Only pgi 13.4-0 accepts it, but I believe that it shouldn't.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Yes, close as INVALID. Hence closed.
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Bud, What was the purpose of this construct? What is the valid way to replace it?
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- 1. you should never touch memory that lies outside the struct. 2. if you have to generate multiple accesses you should generate code as if volatile was not used at all. 3. if -mno-unaligned-access is given you should not use accesses that are larger than the struct's __attribute__((alignment(x))) 4. otherwise if unaligned accesses are allowed, you may generate an unaligned ldr/str instruction. Note: please do not use ldmia/stmia with unaligned addresses, because that does still segfault even in ARMv7. (that may be handled by a Linux IRQ but not for other O/S like eCos)
[Bug fortran/42607] add information about how to compile a module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- What should we do with this PR?
[Bug lto/57703] New: Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Bug ID: 57703 Summary: Assembler function definition moved to a different ltrans then call Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin.liska at gmail dot com SandboxSyscall calls SyscallAsm that is an assembler function defined in the same file: syscall.cc. dump grep: grep SyscallAsm *: out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm out/Release/nacl_helper.ltrans0.s:.type SyscallAsm, @function out/Release/nacl_helper.ltrans0.s:SyscallAsm:.cfi_startproc out/Release/nacl_helper.ltrans0.s:9:.size SyscallAsm, 9b-SyscallAsm out/Release/nacl_helper.ltrans1.s:call SyscallAsm out/Release/nacl_helper.ltrans1.045i.cp:call SyscallAsm Linker error: nacl_helper.ltrans1.ltrans.o: In function `playground2::SandboxSyscall(int, long, long, long, long, long, long)': nacl_helper.ltrans1.o:(.text+0x4503): undefined reference to `SyscallAsm' /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: nacl_helper.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `SyscallAsm' can not be used when making a shared object; recompile with -fPIC /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: final link failed: Bad value collect2: error: ld returned 1 exit status Dumps link: https://docs.google.com/file/d/0B0pisUJ80pO1eFltWU9NUUZkaGM/edit?usp=sharing When compiled with --param lto-partitions=1 no problem is encountered.
[Bug fortran/51535] Optimization problem with -finit-real=snan at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I can reproduce it with gfortran 4.7.3 and '-O2 -ffpe-trap=zero,overflow,invalid -finit-real=snan -mfpmath=387', but not with 4.8.1 nor trunk. Could this PR be closed as FIXED?
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since I don't access to a box (linux or not) allowing -static, I cannot reproduce the segmentation fault. Is the array test in comment #0 still failing?
[Bug fortran/52328] Wrong line in warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52328 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Works for me too from 4.4 to trunk (4.9): write (*,*) HELLO WORLD 1 Warning: Nonconforming tab character at (1) Closing as WORKSFORME. Please reopen if I am wrong.
[Bug middle-end/57670] Member-pointer calls should not be redirected to builtin_unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57670 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg01403.htm ||l --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- The subject of the email should have been Do not turn member pointer CALLS to builtin_unreachable but nevertheless I have submitted a fix to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01403.html
