Re: Design Considerations of GIMPLE Front End
On 05/18/2010 04:24 AM, Sandeep Soni wrote: On Tue, May 18, 2010 at 2:34 AM, Andrew Haley a...@redhat.com wrote: For example: A textual GIMPLE tuple for the statement a=b+c can be like GIMPLE_ASSIGNPLUS_EXPR,a,b,c (As demonstrated by the internal manual also). Is such a representation easy to parse? S-expressions are easier to parse and more compact, and are consistent with gcc's back end. Also, there are editors that already know how to edit and indent S-expressions. Thanks Andrew . Any thoughts on the 3rd point? Your suggestion for 3 is perfectly sensible, and is a good way to start. It's quite possible that, whatever you do, you'll find that the file structure will need to be changed, so it makes sense to do something as simple and straightforward as possible. If your code is well-factored it can be reorganized later. Andrew.
unrecognizable insn after adding clobbers
Hi,
I have for call_value a define_expand and define_insn that look like:
(define_expand call_value
[
(set (match_operand 0 )
(call (match_operand:QI 1 nonmemory_operand )
(match_operand:QI 2 immediate_operand )))
]
)
(define_insn *call_value
[
(set (match_operand 0 )
(call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
]
{
// CODE GEN deals with op0, 1 and 2.
})
This works, however I added a runtime option X which requires a more
complex generation of instructions, and requires 2 scratch registers
so I changed this define_insn into 2:
(define_insn *call_value
[
(set (match_operand 0 )
(call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
]
!TARGET_X
{
return target_call(operands); // deals with op0, 1 and 2.
})
(define_insn *call_value_complex
[
(set (match_operand 0 )
(call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
(clobber (match_scratch:QI 3 y,y))
(clobber (match_scratch:QI 4 y,y))
]
TARGET_X
{
return target_complex_call(operands); // deals with op0, 1, 2, 3, and 4.
})
This however causes an unrecognizable insn error during the compiler
runtime when I have TARGET_X defined.
I was expecting the clobbers not to influence the recognition but it
seems I was wrong.
What's the best way to solve this?
--
PMatos
Re: Design Considerations of GIMPLE Front End
On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote: 1. What should be the format of representation of the GIMPLE tuples in text? I liked Andrew's suggestion about S-expressions. It looks like a good balance between ease of parsing/writing. We can always tweak the format as we go. As for points 2 and 3, I'd suggest start documenting the grammar for types and sections on the wiki. That will expose some shortcomings early on before any code is written. Diego.
Re: Does `-fwhole-program' make sense when compiling shared libraries?
[ hmf. This one got lost to an smtp error when I sent it yesterday. It appears there's more or less agreement that at the moment you're supposed to manually annotate all external entry points if you want to use -fwhole-program on a library. On windows, where we often do that anyway, it looks like it would make a great deal of sense to infer externally_visible from dllexport. ] On 17/05/2010 19:26, Dave Korn wrote: On 17/05/2010 18:57, Toon Moene wrote: On 05/17/2010 08:08 PM, Dave Korn wrote: Hi! PR42904 is a bug where, when compiling a windows DLL using -fwhole-program, the compiler optimises away the entire library body, because there's no dependency chain related to 'main' to anchor it. Aren't shared library and whole program mutually exclusive concepts ? The mere fact that you are building a library means that it cannot be the whole program, and because a shared library cannot be determined to have being used by any fixed program, by definition cannot be the whole program. Or so I'd think. Well, indeed that is strictly the case, but a shared library is also a self-contained bundle of dependencies, and if all the externally visible functions were treated as roots like 'main', I would have thought -fwhole-program could usefully do its thing. So I wondered if anyone had thought about making it work. (I guess the PR should be treated as an enhancement request.) cheers, DaveK
Re: Design Considerations of GIMPLE Front End
Hi, On Tue, 18 May 2010, Diego Novillo wrote: On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote: 1. What should be the format of representation of the GIMPLE tuples in text? I liked Andrew's suggestion about S-expressions. I can see that for describing types, maybe. But isn't that artificially awkward for representing tuple instructions? I mean most instructions will look like (= i_1 (+ k_1 m_1)) or (= j_1 (call func arg1 arg2)) I don't see how that is much easier to parse compared to i_1 = k_1 + m_1 j_1 = func (arg1, arg2) The nice thing with tuples is that there's always only one operator, and hence no ambiguity in precedence that needs to be resolved or explicitely encoded via a list structure. Or is the format also intended to be able to represent GENERIC, i.e. deeply nested structures? Ciao, Michael.
Re: unrecognizable insn after adding clobbers
On 18/05/2010 13:01, Paulo J. Matos wrote:
I have for call_value a define_expand and define_insn that look like:
(define_expand call_value
[
(set (match_operand 0 )
(call (match_operand:QI 1 nonmemory_operand )
(match_operand:QI 2 immediate_operand )))
]
)
(define_insn *call_value
[
(set (match_operand 0 )
(call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
]
!TARGET_X
{
return target_call(operands); // deals with op0, 1 and 2.
})
(define_insn *call_value_complex
[
(set (match_operand 0 )
(call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
(clobber (match_scratch:QI 3 y,y))
(clobber (match_scratch:QI 4 y,y))
]
TARGET_X
{
return target_complex_call(operands); // deals with op0, 1, 2, 3, and 4.
})
This however causes an unrecognizable insn error during the compiler
runtime when I have TARGET_X defined.
I was expecting the clobbers not to influence the recognition but it
seems I was wrong.
Actually, IIUC the clobbers don't influence the recognition, that is
correct, so both those patterns look identical to the recognizer and
effectively only the first one will ever be matched by combine, then too late
the target condition kicks in and the second one pops up and goes oi, where's
my clobbers?. Or something like that.
I think what you need to do is explicitly (TARGET_X ? gen_call_value_complex
: gen_call_value); DONE in your expander.
cheers,
DaveK
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 09:59, Michael Matz m...@suse.de wrote: I don't see how that is much easier to parse compared to i_1 = k_1 + m_1 j_1 = func (arg1, arg2) Well, it would make the parser almost trivial to implement. But you have a point, the only structurally complex objects we need to parse are type declarations. Everything else should have very uniform syntax. The nice thing with tuples is that there's always only one operator, and hence no ambiguity in precedence that needs to be resolved or explicitely encoded via a list structure. That's true. Or is the format also intended to be able to represent GENERIC, i.e. deeply nested structures? No, just gimple. Diego.
Re: Does `-fwhole-program' make sense when compiling shared libraries?
[ hmf. This one got lost to an smtp error when I sent it yesterday. It appears there's more or less agreement that at the moment you're supposed to manually annotate all external entry points if you want to use -fwhole-program on a library. On windows, where we often do that anyway, it looks like it would make a great deal of sense to infer externally_visible from dllexport. ] dllexport is attribute and I think you can quite easilly make frontend hook to drop externally_visible attribute while handling it. This would indeed make sense. Honza
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 4:09 PM, Diego Novillo dnovi...@google.com wrote: On Tue, May 18, 2010 at 09:59, Michael Matz m...@suse.de wrote: I don't see how that is much easier to parse compared to i_1 = k_1 + m_1 j_1 = func (arg1, arg2) Well, it would make the parser almost trivial to implement. But you have a point, the only structurally complex objects we need to parse are type declarations. Everything else should have very uniform syntax. The nice thing with tuples is that there's always only one operator, and hence no ambiguity in precedence that needs to be resolved or explicitely encoded via a list structure. That's true. Or is the format also intended to be able to represent GENERIC, i.e. deeply nested structures? No, just gimple. IMHO, ideally we would have a syntax that is human readable and human writable. S-expressions are not as easy to read for me as something that resembles C. Related subject: Is it possible to have a formal grammar of some kind for, say, bison? It would be nice if we can generate different tools from one grammar, e.g. a GIMPLE front end, a syntax checker, maybe static analyzers, etc. If you make a reader that already constructs the gimple data structures, it will be harder to construct multiple tools on top of it that are independent of libbackend. Ciao! Steven
Re: unrecognizable insn after adding clobbers
On Tue, May 18, 2010 at 3:26 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: This however causes an unrecognizable insn error during the compiler runtime when I have TARGET_X defined. I was expecting the clobbers not to influence the recognition but it seems I was wrong. Actually, IIUC the clobbers don't influence the recognition, that is correct, so both those patterns look identical to the recognizer and effectively only the first one will ever be matched by combine, then too late the target condition kicks in and the second one pops up and goes oi, where's my clobbers?. Or something like that. Got it, thanks for the explanation. It makes sense. I think what you need to do is explicitly (TARGET_X ? gen_call_value_complex : gen_call_value); DONE in your expander. So I guess i need something like emit_call_insn(TARGET_X ? gen_call_value_complex(...) : gen_call_value(...)); DONE but what do I pass to the gen_* functions? I don't really have anything to pass to them at this point, I just want gcc to expand those. However if I pass no arguments it claims I haven't passed enough arguments. -- PMatos
Re: Design Considerations of GIMPLE Front End
On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote: Hi, On Tue, 18 May 2010, Diego Novillo wrote: On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote: 1. What should be the format of representation of the GIMPLE tuples in text? I liked Andrew's suggestion about S-expressions. I can see that for describing types, maybe. But isn't that artificially awkward for representing tuple instructions? I mean most instructions will look like (= i_1 (+ k_1 m_1)) or (= j_1 (call func arg1 arg2)) I don't see how that is much easier to parse compared to i_1 = k_1 + m_1 j_1 = func (arg1, arg2) My intuition might be that once a Gimple parser exists, most of its use would be writing various translators (e.g. external front-ends) to this syntax, so people might probably code more Gimple-syntax printers than Gimple-syntax parsers. Still, I prefer the Lispy S-expression syntax everywhere -including Gimple- because it is so simple to define and to implement, and because GCC MELT already have [almost] the infrastructure for it. However, I tend to think that the Gimple syntax would also [at least optionally] contain the location information, so it would be instead (= (@ foo.cobol 23 2) i_1 (+ k_1 m_1))) or even (= (@ foo.cobol 23 3) i_1 (+ (@ foo.cobol 23 5) k_1 m_1))) I am using, perhaps wrongly, @ as an operator giving the location information as a file name, line number, column number. I am not sure to have the syntax right (because I am not sure to remember what exactly has a location information). I believe a Gimple-syntax should provide the features (or hooks, or syntax) to convey all the Gimple information, and this includes the source file location. This is needed both for external (GPLv3+ or compatibly licensed) programs producing Gimple (such as an hypothetical Cobol frontend) and for external (GPLv3+ or compatibly licensed) programs consuming Gimple (like sophisticated static analyzers) or for external programs both consuming producing Gimple (e.g. an optimization implemented by an external program). Otherwise, what is the purpose of Gimple-syntax? Why making it if it does not contain all the information inside GCC? BTW, is it possible today to have a GCC plugin providing a front-end to GCC? [last time I looked, I believe the answer is no] Cheers.
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch bas...@starynkevitch.net wrote: On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote: Hi, On Tue, 18 May 2010, Diego Novillo wrote: On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote: 1. What should be the format of representation of the GIMPLE tuples in text? I liked Andrew's suggestion about S-expressions. I can see that for describing types, maybe. But isn't that artificially awkward for representing tuple instructions? I mean most instructions will look like (= i_1 (+ k_1 m_1)) or (= j_1 (call func arg1 arg2)) I don't see how that is much easier to parse compared to i_1 = k_1 + m_1 j_1 = func (arg1, arg2) My intuition might be that once a Gimple parser exists, most of its use would be writing various translators (e.g. external front-ends) to this syntax, so people might probably code more Gimple-syntax printers than Gimple-syntax parsers. Still, I prefer the Lispy S-expression syntax everywhere -including Gimple- because it is so simple to define and to implement, and because GCC MELT already have [almost] the infrastructure for it. However, I tend to think that the Gimple syntax would also [at least optionally] contain the location information, so it would be instead (= (@ foo.cobol 23 2) i_1 (+ k_1 m_1))) or even (= (@ foo.cobol 23 3) i_1 (+ (@ foo.cobol 23 5) k_1 m_1))) I am using, perhaps wrongly, @ as an operator giving the location information as a file name, line number, column number. I am not sure to have the syntax right (because I am not sure to remember what exactly has a location information). Yep, we also need to be able to specify the various flags on gimple statements and information such as alias info. At least if we eventually want to use this as a framework for real unit-testing. So I'm not too concerned about using s-expressions even for the statements. Richard.
Re: unrecognizable insn after adding clobbers
On 18/05/2010 15:24, Paulo J. Matos wrote: On Tue, May 18, 2010 at 3:26 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: This however causes an unrecognizable insn error during the compiler runtime when I have TARGET_X defined. I was expecting the clobbers not to influence the recognition but it seems I was wrong. Actually, IIUC the clobbers don't influence the recognition, that is correct, so both those patterns look identical to the recognizer and effectively only the first one will ever be matched by combine, then too late the target condition kicks in and the second one pops up and goes oi, where's my clobbers?. Or something like that. Got it, thanks for the explanation. It makes sense. I think what you need to do is explicitly (TARGET_X ? gen_call_value_complex : gen_call_value); DONE in your expander. So I guess i need something like emit_call_insn(TARGET_X ? gen_call_value_complex(...) : gen_call_value(...)); DONE but what do I pass to the gen_* functions? I don't really have anything to pass to them at this point, I just want gcc to expand those. However if I pass no arguments it claims I haven't passed enough arguments. They need the contents of the operands[] array passed to them, and you'll have to allocate the scratch registers (as pseudos) yourself, I guess (which of course means you can't generate these after reload, should you ever want to). Hmm, I'm not so sure of my answer now, maybe I'm forgetting something. I do remember having trouble trying to make an insn work with two variants that different only in clobbers before. cheers, DaveK
Re: Design Considerations of GIMPLE Front End
On 18/05/2010 15:17, Steven Bosscher wrote: IMHO, ideally we would have a syntax that is human readable and human writable. S-expressions are not as easy to read for me as something that resembles C. I'd like it that way too, but I acknowledge that it would be more work and it's not me who'd have to do that extra work... cheers, DaveK
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch bas...@starynkevitch.net wrote: BTW, is it possible today to have a GCC plugin providing a front-end to GCC? [last time I looked, I believe the answer is no] This is one of the reasons for my patches to better hide the middle-end details from the front ends. Ciao! Steven
Re: Design Considerations of GIMPLE Front End
On 05/18/2010 04:05 PM, Dave Korn wrote: On 18/05/2010 15:17, Steven Bosscher wrote: IMHO, ideally we would have a syntax that is human readable and human writable. S-expressions are not as easy to read for me as something that resembles C. I'd like it that way too, but I acknowledge that it would be more work and it's not me who'd have to do that extra work... Well, it can always be changed later, but there's a lot to be said for not spending time now writing a parser, and getting on with the project. It's a matter of taste anyway. Andrew.
Re: Design Considerations of GIMPLE Front End
[ apologies for the duplicate message. My previous reply was bounced by the ML. ] On Tue, May 18, 2010 at 10:52, Andrew Haley a...@redhat.com wrote: On 05/18/2010 04:05 PM, Dave Korn wrote: On 18/05/2010 15:17, Steven Bosscher wrote: IMHO, ideally we would have a syntax that is human readable and human writable. S-expressions are not as easy to read for me as something that resembles C. I'd like it that way too, but I acknowledge that it would be more work and it's not me who'd have to do that extra work... Well, it can always be changed later, but there's a lot to be said for not spending time now writing a parser, and getting on with the project. It's a matter of taste anyway. Yup. This shade of blue can be changed later. Sandi, let's start with the S-expression syntax for everything. Richard is correct in pointing out that even gimple expressions have metadata associated with them that will need to be represented. Diego.
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 8:33 PM, Diego Novillo dnovi...@google.com wrote: Yup. This shade of blue can be changed later. Sandi, let's start with the S-expression syntax for everything. Richard is correct in pointing out that even gimple expressions have metadata associated with them that will need to be represented. Yes. I will start editing the wiki page created to document the S-expression syntax and the grammar. This will be an ongoing process though, in parallel with my current work of getting familiar with the LTO code base, so might take some time earlier on. Diego. -- Cheers Sandy
Updating multilib support after a compiler is built
Hi, Is it possible to update the multilib combinations supported by GCC after it has been built? (I would like to build some libraries optimised for different CPUs variants, that aren't built by default). I tried doing this via a specs file, but something like the following fails: %rename multilib_matches old_multilib_matches *multilib_matches: mcpu=xyz mcpu=xyz;%(old_multilib_matches); with: multilib spec 'mcpu=xyz mcpu=xyz;%(old_multilib_matches);' is invalid So it looks like GCC isn't performing substitutions for the %s in multilib_matches specs. (The same seems to be true for the other multilib specs). Perhaps there's a simpler way? Cheers, Jon
Re: Updating multilib support after a compiler is built
On Tue, 2010-05-18 at 18:30 +0100, Jon Beniston wrote:
Is it possible to update the multilib combinations supported by GCC after it
has been built?
I don't know for sure, but I would guess and imagine that it is not
possible. The intuition is that multilib-ness is really a matter of
choosing the target system, and you certainly cannot use a compiled GCC
for a target which you did not configure the compiler for.
But perhaps I might be completely wrong (however, x86 x86-64 are quite
different beasts).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Updating multilib support after a compiler is built
Jon Beniston j...@beniston.com writes: Is it possible to update the multilib combinations supported by GCC after it has been built? I believe that all the multilib information can be read from the specs file, so, technically, yes. %rename multilib_matches old_multilib_matches *multilib_matches: mcpu=xyz mcpu=xyz;%(old_multilib_matches); with: multilib spec 'mcpu=xyz mcpu=xyz;%(old_multilib_matches);' is invalid So it looks like GCC isn't performing substitutions for the %s in multilib_matches specs. (The same seems to be true for the other multilib specs). Right, the multilib specs aren't written in the spec mini-language, so transformations like %() are not applied. You will have to write out the complete multilib description. Ian
useless stores generated when returning a struct -- bug?
I have a case where I think useless stores are being generated, but I
want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu
10.04, x86-64.
I have been experimenting with returning structs from functions instead
of passing pointers to out parameters. This seems like it should be
more optimizer-friendly because you can avoid taking addresses of local
variables, which prevents them from possibly being aliased.
However in this test case, gcc is generating four stores that appear to
be completely useless:
#include stdint.h
struct twoints { uint64_t a, b; } foo();
void bar(uint64_t a, uint64_t b);
void func() {
struct twoints s = foo();
bar(s.a, s.b);
}
$ gcc -Wall -c -o testbad.o -msse2 -O3 -fomit-frame-pointer testbad.c-
$ objdump -d -r -M intel testbad.o
testbad.o: file format elf64-x86-64
Disassembly of section .text:
func:
0: 48 83 ec 28 subrsp,0x28
4: 31 c0 xoreax,eax
6: e8 00 00 00 00 call b func+0xb
7: R_X86_64_PC32foo-0x4
b: 48 89 04 24 movQWORD PTR [rsp],rax
f: 48 89 54 24 08 movQWORD PTR [rsp+0x8],rdx
14: 48 89 d6movrsi,rdx
17: 48 89 44 24 10 movQWORD PTR [rsp+0x10],rax
1c: 48 89 54 24 18 movQWORD PTR [rsp+0x18],rdx
21: 48 89 c7movrdi,rax
24: 48 83 c4 28 addrsp,0x28
28: e9 00 00 00 00 jmp2d func+0x2d
29: R_X86_64_PC32 bar-0x4
Why is it storing rax and rdx to the stack twice? These stores are never
used AFAICS.
Josh
gcc help
How do i build gcc for linux?
Re: gcc help
On 05/18/2010 01:11 PM, packet wrote: How do i build gcc for linux? Oh the irony of the subject. This is better asked on the gcc-help mailing list. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Updating multilib support after a compiler is built
On Tue, 18 May 2010, Jon Beniston wrote: Hi, Is it possible to update the multilib combinations supported by GCC after it has been built? (I would like to build some libraries optimised for different CPUs variants, that aren't built by default). I tried doing this via a specs file, but something like the following fails: Even if you get modifications of specs to work (and some pieces such as --with-arch configuration are handled in different ways that may not be configurable that way), GCC's own libraries are nontrivial to build outside of building GCC itself - especially libgcc (libstdc++ is easier). The libgcc configuration uses information passed from the gcc/ directory because the toplevel libgcc transition is incomplete, including target macros from tm.h which is mainly a host header but also used for some things on the target. I certainly encourage cleaning up these things so that the libgcc build configuration can be properly contained within the libgcc/ directory and not depend on host tm.h headers. http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration If you only want to optimize some libraries but not others, GCC doesn't effectively support different multilibs having different sets of libraries either. My proposal http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html would have the effect of making it much easier to have different sets of libraries for each multilib. -- Joseph S. Myers jos...@codesourcery.com
disallow movm in a register class
Hi all, how can I disallow the mov operation for a register class. Can someone help me? Thanks, Egge
[PATCH, RFC] plugin to warn about surplus includes
Hi,
A couple of days ago i was asking:
does any frontend support some sort of noting that a user-header was
included but no decl of it was ever referenced (i.e. superfluous
#include) ?
I could not find an appropriate tool to diagnose them, so i was thinking
about a gcc plugin to do that.
Would some plugin like the attached be suitable to put into svn if
cleaned up a bit?
If so, where would they live?
Observations while thinking about all this:
- libcpp does not record LC_PSEUDO_ENTER (or something like that),
so pristine libcpp cannot detect duplicate includes, like iostream
in attached sample input.cc
- should figure out how to print a help-text for the plugin
Hints?
- should handle structs.
Thanks in advance for hints on the help-text printing or comments about
the overall idea of such a facility.
/* Dump superfluous, missing or duplicate includes.
*
* Copyright (C) 2010 Bernhard Reutner-Fischer
*/
/*
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
#include config.h
#include system.h
#include gcc-plugin.h
#include coretypes.h
#include tree.h
#include tree-iterator.h
#include tree-pass.h
#include intl.h
#include line-map.h
#include langhooks.h
#include target.h
#include toplev.h /* warning_at */
//#define info warning
#define info(...) /**/
typedef struct include_t {
struct include_t *next;
const char *filename;
source_location location;
} include_t;
static include_t *incs = NULL, *referenced = NULL;
static bool warn_missing;
static bool warn_surplus;
/* Add filename to the end of the include list. */
static void __attribute__ ((__nonnull__ (2)))
add_include (include_t **head, const char *filename, const source_location loc,
const bool mainfile)
{
include_t *tail, *elt;
if (filename == NULL)
gcc_unreachable ();
tail = *head;
while (1)
{
if (tail strcmp (tail-filename, filename) == 0)
{
const bool old_warn_system_headers = warn_system_headers;
warn_system_headers = 1; /* to please warning_at */
if (tail-location != loc mainfile warn_surplus)
warning_at (loc, 0, Duplicate include %s, filename);
warn_system_headers = old_warn_system_headers;
return; /* don't enter duplicate */
}
if (tail tail-next)
tail = tail-next;
else
break;
}
info (0, ADDING %s, filename);
elt = XNEW (include_t);
elt-filename = filename;
elt-location = loc;
elt-next = NULL;
if (tail)
tail-next = elt;
else
*head = elt;
}
/* Remove filename from the include list. */
static void __attribute__ ((__nonnull__ (2)))
remove_include (include_t **head, const char *filename)
{
bool seen;
if (filename == NULL)
gcc_unreachable ();
seen = false;
while (*head)
{
if (strcmp ((*head)-filename, filename) == 0)
{
include_t *delete = *head;
info (0, REMOVE %s, filename);
*head = (*head)-next;
XDELETE (delete);
seen = true;
break;
}
head = (*head)-next;
}
if (!seen warn_missing)
warning (0, Missing include %s, filename);
}
/* Callback function to invoke after GCC finishes parsing a struct. */
void
handle_struct (void *event_data, void *user_data)
{
tree type = (tree) event_data;
if (type == error_mark_node)
return;
warning (0, G_(Process struct %s),
IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type;
}
static void
fn_add_includes (tree fndecl, const bool mainfile)
{
tree decl, type;
const struct line_map *map;
map = linemap_lookup (line_table, DECL_SOURCE_LOCATION (fndecl));
if (!MAIN_FILE_P (map))
{
source_location loc = DECL_SOURCE_LOCATION (fndecl);
info (0,fn %s: %s, lang_hooks.decl_printable_name (fndecl, 3), LOCATION_FILE (DECL_SOURCE_LOCATION (fndecl)));
add_include (referenced, LOCATION_FILE (loc), loc, mainfile);
}
for (decl = DECL_ARGUMENTS (fndecl); decl; decl = TREE_CHAIN (decl))
{
map = linemap_lookup (line_table, DECL_SOURCE_LOCATION (decl));
if (!MAIN_FILE_P (map))
{
source_location loc = DECL_SOURCE_LOCATION (decl);
info (0,fn arg %s: %s, lang_hooks.decl_printable_name (decl, 3), LOCATION_FILE (DECL_SOURCE_LOCATION (decl)));
add_include (referenced,
LOCATION_FILE (loc),
loc,
false);
}
}
}
static void debug_location (location_t l)
{
fprintf (stderr, LOCATION_FILE=%s\n, LOCATION_FILE (l));
}
static void
operands_add_includes (tree decl, location_t decl_loc, const bool mainfile)
{
Re: [PATCH, RFC] plugin to warn about surplus includes
On 5/18/10, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, A couple of days ago i was asking: does any frontend support some sort of noting that a user-header was included but no decl of it was ever referenced (i.e. superfluous #include) ? I could not find an appropriate tool to diagnose them, so i was thinking about a gcc plugin to do that. *bows* Such a plugin would be very welcome for me at least. Ciao! Steven
gcc-4.4-20100518 is now available
Snapshot gcc-4.4-20100518 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100518/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 159545 You'll find: gcc-4.4-20100518.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100518.tar.bz2 C front end and core compiler gcc-ada-4.4-20100518.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100518.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100518.tar.bz2 C++ front end and runtime gcc-java-4.4-20100518.tar.bz2 Java front end and runtime gcc-objc-4.4-20100518.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100518.tar.bz2The GCC testsuite Diffs from 4.4-20100511 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [PATCH, RFC] plugin to warn about surplus includes
On 05/18/2010 05:53 PM, Steven Bosscher wrote: On 5/18/10, Bernhard Reutner-Fischerrep.dot@gmail.com wrote: Hi, A couple of days ago i was asking: does any frontend support some sort of noting that a user-header was included but no decl of it was ever referenced (i.e. superfluous #include) ? I could not find an appropriate tool to diagnose them, so i was thinking about a gcc plugin to do that. *bows* Such a plugin would be very welcome for me at least. Count me in those who would be interested. Would there be a way to exclude specific files? Say something like config.h that by convention you might want every file to include? Ciao! Steven --joel
Re: useless stores generated when returning a struct -- bug?
Joshua Haberman jhaber...@gmail.com writes: I have a case where I think useless stores are being generated, but I want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu 10.04, x86-64. I concur that this is a missed optimization bug. Ian
Re: disallow movm in a register class
Eggenmüller Bernd egg...@gmx.de writes: how can I disallow the mov operation for a register class. Can someone help me? Please do not start a new thread by replying to an existing message. That hides your message for all of us who use threaded e-mail readers. If there is some mode which can be stored in both register classes, then gcc requires that you provide a way to move values between those registers. So you can't really disallow it. You could disallow direct moves between the register classes if you like; you can do that by setting REGISTER_MOVE_COST for the modes and by providing secondary reloads to actually move the values. Ian
Re: useless stores generated when returning a struct -- bug?
Ian Lance Taylor iant at google.com writes: Joshua Haberman jhaberman at gmail.com writes: I have a case where I think useless stores are being generated, but I want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu 10.04, x86-64. I concur that this is a missed optimization bug. Thanks Ian. I'll file it as a bug. Josh
RM QA Session on May 27th
Several people have asked that there be a forum for asking questions of and providing feedback to the GCC RMs. Since this is of course a very widely distributed community, the best medium for this seems to be an IRC chat. To that end, I'll be hosting a 1-hour session on May 27th at 9:00 AM Pacific. I'm hoping that Jakub, Joseph, and Richard will also be able to participate. If anyone would like to volunteer to set up a channel and/or moderate the chat itself, please let me know. Otherwise, I'll do that. For those who do not find that a convenient time, please add questions to: http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A We'll try to give somewhat intelligent answers to those questions, as well as to those asked live. Thanks! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: RM QA Session on May 27th
On Tue, May 18, 2010 at 11:36 PM, Mark Mitchell m...@codesourcery.com wrote: Several people have asked that there be a forum for asking questions of and providing feedback to the GCC RMs. Since this is of course a very widely distributed community, the best medium for this seems to be an IRC chat. To that end, I'll be hosting a 1-hour session on May 27th at 9:00 AM Pacific. I'm hoping that Jakub, Joseph, and Richard will also be able to participate. If anyone would like to volunteer to set up a channel and/or moderate the chat itself, please let me know. Otherwise, I'll do that. For those who do not find that a convenient time, please add questions to: http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A We'll try to give somewhat intelligent answers to those questions, as well as to those asked live. Thanks! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 Can you just do it in #gcc on oftc?
Re: RM QA Session on May 27th
NightStrike wrote: If anyone would like to volunteer to set up a channel and/or moderate the chat itself, please let me know. Can you just do it in #gcc on oftc? That's certainly the fallback possibility. Though, for those not interested, it would interrupt whatever else is being discussed. It would also probably be better if it were a moderated discussion so that everyone doesn't talk at once. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
prerequisites page
I'm writing to report a discrepancy in http://gcc.gnu.org/install/prerequisites.html I just discovered that if gmp is boot strapped during gcc build and an older m4 exists, when gmp calls flex, it will fail during configure with: checking for flex... flex checking lex output file root... configure: error: cannot find output from flex; giving up I mention this because the prerequisites page specifies m4 as optional if you're just building gcc. m4 appears to have a minimal requirement if gmp is being boot strapped.
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 --- *** Bug 44187 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug c++/44187] Wrong code generated with -O2 and above
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 --- *** This bug has been marked as a duplicate of 44186 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44187
[Bug c/31367] Should not warn about use of deprecated type in deprecated struct
--- Comment #4 from ethouris at gmail dot com 2010-05-18 07:14 ---
No matter which entity is actually affected in the example above, 'foo' is a
type of field used inside the entity. In all these cases, deprecation warning
should not be reported for the field of type 'foo'. It should be reported only
when no part of the structure definition is deprecated.
The difference between deprecating only a typedef for a structure or the
structure itself, but not its typedef, should not be seen when it concerns one
integrated declaration (that is, when you deprecate any of these two, both
the typedef and the struct are deprecated). To only deprecate the typedef or
the struct, they should be declared separately - for example, bop4/bar4 should
be declared this way:
struct bar4
{
foo baz;
};
typedef struct bar4 bop4 __attribute__((deprecated));
So, in the examples for bop1-bop4, all of barN/bopN symbols should be
deprecation-attributed (and, simultaneously, in all these declarations the
deprecation warning should not be reported for 'baz' field declaration). For
this above declaration, the compiler should issue a warning about 'baz' field,
as the structure isn't deprecated and is using a deprecated type 'foo'; so
should be reported a warning about using struct bar4 (this structure is this
way implicitly deprecated) and bop4 (which is explicitly deprecated).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug middle-end/44185] [4.6 regression] New prefetch test failures
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-18 07:29 --- In general, with inlining, not a huge deal, although it can still occur when functons are short-circuited. For certain applicatons that are built with PIC, the IP-thunk, at the very least, should be padded since it's a guaranteed stall on every call. Help Dhrysyone -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44185
[Bug middle-end/44101] [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-18 07:41 --- I need the preprocessed file. Thanks in advance. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
[Bug lto/44184] asm goto does not work with LTO
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 08:10:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #4 from segher at gcc dot gnu dot org 2010-05-18 08:26 --- Confirmed with current 4.4 branch and mainline. -mabi=nospe -mno=spe doesn't make the problem go away; only changing -mcpu does. -- segher at gcc dot gnu dot org changed: What|Removed |Added CC||segher at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.4 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-18 08:26:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-18 09:09 --- Created an attachment (id=20693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view) latest version a few more tweaks. with this emutls is working for lto/whopr OMP is still broken and so will be tree-prof if it uses TLS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-18 09:25 --- Note however, that both the warning and the miscompilation do not happen with current 4_5-branch and mainline... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug c++/44188] New: Fails to produce DW_AT_typedef for typedef of anonymous struct
typedef struct
{
int i;
} AAA;
typedef struct BBB
{
int i;
} BBB;
int main(void) {
BBB bb;
AAA aa;
return 0;
}
produces
3a2: Abbrev Number: 9 (DW_TAG_variable)
a3 DW_AT_name: bb
a6 DW_AT_decl_file : 1
a7 DW_AT_decl_line : 13
a8 DW_AT_type: 0x66
ac DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32)
3af: Abbrev Number: 9 (DW_TAG_variable)
b0 DW_AT_name: aa
b3 DW_AT_decl_file : 1
b4 DW_AT_decl_line : 14
b5 DW_AT_type: 0x2d
b9 DW_AT_location: 2 byte block: 91 50
where
166: Abbrev Number: 6 (DW_TAG_typedef)
67 DW_AT_name: BBB
6b DW_AT_decl_file : 1
6c DW_AT_decl_line : 10
6d DW_AT_type: 0x4d
(good)
12d: Abbrev Number: 2 (DW_TAG_structure_type)
2e DW_AT_byte_size : 4
2f DW_AT_decl_file : 1
30 DW_AT_decl_line : 3
31 DW_AT_name: AAA
35 DW_AT_sibling : 0x46
(bad)
This seems to be because in gen_type_die_with_usage we arrive with a
type that has a non-typedef type-decl as its name.
--
Summary: Fails to produce DW_AT_typedef for typedef of anonymous
struct
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-18 09:36 --- Subject: Bug 41371 Author: jakub Date: Tue May 18 09:35:52 2010 New Revision: 159528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159528 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Add a few checks from rtx_equal_p inline. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-18 09:53 --- (In reply to comment #3) Note however, that both the warning and the miscompilation do not happen with current 4_5-branch and mainline... Which is because we see the must-alias and punt. After all this just invokes undefined behavior which includes works and does not work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug middle-end/44185] [4.6 regression] New prefetch test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44185
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-18 10:04 --- Confirmed. Assembly with 4.4 is equal -g vs. -g0 and different starting with 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.5.0 Known to work||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-05-18 10:04:30 date|| Summary|-fcompare-debug failure |[4.5/4.6 Regression] - |(length) with -O1 |fcompare-debug failure ||(length) with -O1 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug lto/44184] asm goto does not work with LTO
-- steven at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-pc-linux-gnu | GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|x86_64-pc-linux-gnu | Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-18 10:08 --- Ok ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #28 from siarhei dot siamashka at gmail dot com 2010-05-18 10:09 --- Thanks, this patch fixes bootstrap for powerpc/powerpc64. But still fails for arm on all the same gcc_assert() in another place. Should a new bug be filed about this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug target/42159] [4.4/4.5/4.6] app SIGABRTs after a trivial nested throw/stack unwinding
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:28 --- Confirmed on gcc version 4.5.1 20100506 (prerelease). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.4.1 4.4.2 |4.4.1 4.4.2 4.5.1 Known to work|4.5.0 | Last reconfirmed|-00-00 00:00:00 |2010-05-18 10:28:59 date|| Summary|[4.4 only] app compiled with|[4.4/4.5/4.6] app SIGABRTs |4.4.2 SIGABRTs after a |after a trivial nested |trivial nested throw/stack |throw/stack unwinding |unwinding | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
[Bug debug/43821] -feliminate-dwarf2-dups produces no debug symbols in executable warning from dsymutil
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:35 --- Doesn't happen for me with the 4.5 branch. (I don't have a current trunk compiler to compare with.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #9 from sfilippone at uniroma2 dot it 2010-05-18 10:41 --- (In reply to comment #8) (In reply to comment #7) Btw, after the recent patch for PR43969, this might well be fixed already ... Unfortunately, no, I still get the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #29 from jakub at gcc dot gnu dot org 2010-05-18 10:58 --- Please file a new PR for that, with preprocessed source and all other relevant info for reproduction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-18 11:26 --- The differences start during inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug target/44189] New: PIC compilation on ARM screws up DWARF lineinfo in function prologue
SVN revision: 159525
Configure line: ../gcc-svn/configure --prefix=/tmp/gcc-cross/gcc-svn-bin/
--target=arm-linux-gnueabi
--with-headers=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/include
--with-libs=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/lib/
--enable-threads=posix --enable-shared --enable-languages=c
Command line: arm-linux-gnueabi-gcc -fpic -Wall -g -O0 -S -o - -c test.c
No errors/warnings from the compiler.
Input program, test.c:
int ext_var;
void ext_fn(int x);
void bad(int x) {
ext_fn(ext_var);
}
The resulting assembly of the bad function:
bad:
.LFB0:
.file 1 test.c
.loc 1 4 0
.cfi_startproc
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
stmfd sp!, {fp, lr}
.LCFI0:
.cfi_def_cfa_offset 8
add fp, sp, #4
.cfi_offset 14, -4
.cfi_offset 11, -8
.LCFI1:
.cfi_def_cfa 11, 4
sub sp, sp, #8
.loc 1 5 0 -- should not be here
ldr r3, .L2
.LPIC0:
add r3, pc, r3
.loc 1 4 0 -- should not be here
str r0, [fp, #-8]
.loc 1 5 0
ldr r2, .L2+4
ldr r3, [r3, r2]
ldr r3, [r3, #0]
mov r0, r3
bl ext_fn(PLT)
.loc 1 6 0
sub sp, fp, #4
ldmfd sp!, {fp, pc}
I have marked the .loc directives that cause the problems for me, because of
those GDB stops too early (when the function parameters are not stored yet) and
because of this GDB command `bt' shows bad parameters for the top frame. The
`next' command is confused too, of course. Furthermore, objdump -S is also
confused, shows the function header twice:
bad:
int ext_var;
void ext_fn(int x);
void bad(int x) {
0: e92d4800push{fp, lr}
4: e28db004add fp, sp, #4
8: e24dd008sub sp, sp, #8
ext_fn(ext_var);
c: e59f3020ldr r3, [pc, #32] ; 34 bad+0x34
10: e08f3003add r3, pc, r3
int ext_var;
void ext_fn(int x);
void bad(int x) {
14: e50b0008str r0, [fp, #-8]
ext_fn(ext_var);
18: e59f2018ldr r2, [pc, #24] ; 38 bad+0x38
1c: e7933002ldr r3, [r3, r2]
20: e5933000ldr r3, [r3]
24: e1a3mov r0, r3
28: ebfebl 0 ext_fn
}
2c: e24bd004sub sp, fp, #4
30: e8bd8800pop {fp, pc}
34: 001c.word 0x001c
38: .word 0x
To my understanding, the issue is caused by the on-demand generation of the
pic register loading logic for the function prologue. That part of the
prologue gets line number info of the statement that causes the generation.
My quick fix is:
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 159525)
+++ gcc/config/arm/arm.c(working copy)
@@ -4897,13 +4897,23 @@
process. */
if (current_ir_type () != IR_GIMPLE || currently_expanding_to_rtl)
{
+ /* We want the PIC register loading instructions to have
+the same line number info as the function
+prologue. */
+ location_t saved_curr_loc = get_curr_insn_source_location ();
+ set_curr_insn_source_location (cfun-function_start_locus);
+
crtl-uses_pic_offset_table = 1;
start_sequence ();
arm_load_pic_register (0UL);
seq = get_insns ();
end_sequence ();
+
+ set_curr_insn_source_location (saved_curr_loc);
+
/* We can be called during expansion of PHI nodes, where
we can't yet emit instructions directly in the final
insn stream. Queue the insns on the entry edge, they will
This patch solves the issue for me.
This is the first time I try to do anything internally with GCC, so please
forgive my mistakes and show me the better way to fix the issue.
--
Summary: PIC compilation on ARM screws up DWARF lineinfo in
function prologue
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gergely+gccbug at risko dot hu
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44189
[Bug middle-end/44101] [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 11:55 --- Created an attachment (id=20694) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20694action=view) preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #10 from janus at gcc dot gnu dot org 2010-05-18 12:19 --- (In reply to comment #9) Btw, after the recent patch for PR43969, this might well be fixed already ... Unfortunately, no, I still get the ICE. Sure. Actually my comment was only targeted towards Tobias' ALLOCATED example, not the original ICE :) -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-18 12:24 --- (In reply to comment #8) If one adds b = ALLOCATED(x) one finds: Where do you add this? Add in bug14 of attachment 20491 before 'end subroutine': logical b b = allocated(a%a) However, this is now fixed. * * * There are other problems related to allocatable scalars, but I think those are tracked in PR 42647. For instance (again based on attachment 20491): use d_mat_mod implicit none type(d_sparse_mat), ALLOCATABLE :: x call bug14(x) ! OK around here contains subroutine bug14(a) type(d_sparse_mat), ALLOCATABLE, intent(out) :: a logical b ! ICE here b = allocated(a); if (b) call abort() ! OK here end subroutine bug14 end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug debug/43821] -feliminate-dwarf2-dups produces no debug symbols in executable warning from dsymutil
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-18 12:30 ---
it still fails for me on ppc and i686 4.6.0 r159518 and 159528 resp.
gcc version 4.5.1 20100518 (prerelease) [gcc-4_5-branch revision 159528] (GCC)
apollo:gcc-4-5-branch-build $ ./gcc/xgcc -B gcc -g -feliminate-dwarf2-dups
../tests/trivial-debug-sym.c
warning: no debug symbols in executable (-arch i386)
$ cat ../tests/trivial-debug-sym.c
int main (int ac, char *av[])
{
int a ;
return a + 1;
}
$ xcodebuild -version
Xcode 3.1.4
Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0
BuildVersion: 9M2809
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
$ dsymutil -v
@(#)PROGRAM:dsymutil PROJECT:dwarfutils-70
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-18 13:04 --- I guess this is related to the EH rewrite in 4.5. In particular, when building cfg for f2 in make_blocks on (gdb) p debug_gimple_stmt (stmt) S::f3 (this, D.2140); (gdb) p stmt_can_throw_internal (stmt) $47 = 0 '\000' (gdb) p stmt_could_throw_p (stmt) $48 = 1 '\001' (apparently cfun-eh-throw_stmt_table is NULL). This means a new bb isn't created right after the call and so j = 0; stmt can be after it. Later on this j = 0; is replaced with DEBUG j = j_* and for -g0 case with nothing. The only two calls for which add_stmt_to_eh_lp_fn is called before inlining are S::f2 (nc_1(D), D.2136); and S::~S (D.2136); in f, no stmts in f2 nor f3. During inlining of f2 into f copy_bb - maybe_duplicate_eh_stmt_fn - add_stmt_to_eh_lp_fn is called on S::f3 (nc_1(D), D.2158_8); and from that point the f3 call is considered stmt_can_throw_internal. As with -g the f3 call is followed by a DEBUG stmt (which is invalid after it started to be a throwing insn), that bb is split during copy_edges_for_bb, but the -g0 f3 call was the last, so no splitting happens. I wonder whether it is correct that stmt_can_throw_internal changes on a call during inlining. If it is always false or always true, then either no DEBUG stmts would appear after it or no splitting would happen after the call during inlining. If it is intended that stmt_can_throw_internal changes during inlining, then guess copy_edges_for_bb 1901 if (!gsi_end_p (si)) 1902/* Note that bb's predecessor edges aren't necessarily 1903 right at this point; split_block doesn't care. */ would need to skip over is_gimple_debug stmts for the test and if there are any, drop them (or something else, Alex?). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug lto/44184] asm goto does not work with LTO
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-18 13:52 --- Subject: Bug 44184 Author: steven Date: Tue May 18 13:51:50 2010 New Revision: 159531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159531 Log: gcc/ PR lto/44184 * lto-streamer-out.c (output_gimple_stmt): Output number of labels in a GIMPLE_ASM. * lto-streamer-in.c (input_gimple_stmt): Read number of labels in a GIMPLE_ASM. testsuite/ PR lto/44184 * gcc.dg/lto/20100518_0.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/20100518_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug lto/44184] asm goto does not work with LTO
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-18 14:07 --- Subject: Bug 44184 Author: steven Date: Tue May 18 14:06:31 2010 New Revision: 159532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159532 Log: gcc/ PR lto/44184 * lto-streamer-out.c (output_gimple_stmt): Output number of labels in a GIMPLE_ASM. * lto-streamer-in.c (input_gimple_stmt): Read number of labels in a GIMPLE_ASM. testsuite/ PR lto/44184 * gcc.dg/lto/20100518_0.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/lto/20100518_0.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/lto-streamer-in.c branches/gcc-4_5-branch/gcc/lto-streamer-out.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug lto/44184] asm goto does not work with LTO
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-18 14:08 --- Fixed for GCC 4.5.1 and later. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 --- (In reply to comment #10) Re-opening. It turns out that GCC fails to actually apply the dllexport attribute to TLS control vars. So solving the binutils problem allows auto-export of a TLS variable to work, but as auto-export gets disabled in the presence of any explicit dllexport directives, this isn't an effective solution. I believe the problem needs to be addressed in config/i386/winnt.c#i386_pe_encode_section_info() I have doubts about the approach in winnt.c, but well maybe I am wrong here. I investigated for this issue and see the real issue in declaration cloning in varasm.c's emutls_decl- function, which simply doesn't copy attributes of the delaration, which then leads to issues about name-decoration. Also the DECL_DLLIMPORT_P has to be copied here, too (for import). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #12 from davek at gcc dot gnu dot org 2010-05-18 14:29 --- (In reply to comment #11) I have doubts about the approach in winnt.c, but well maybe I am wrong here. I investigated for this issue and see the real issue in declaration cloning in varasm.c's emutls_decl- function, which simply doesn't copy attributes of the delaration, which then leads to issues about name-decoration. Also the DECL_DLLIMPORT_P has to be copied here, too (for import). Well, what I was thinking when I wrote that is that we could recognize the TARGET_EMUTLS_xxx_PREFIX in winnt.c, look up the original decl, and copy whatever necessary attributes over at that time. However it does look like the TARGET_EMUTLS_VAR_INIT hook might be what we're actually looking for here; I'll check the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #13 from davek at gcc dot gnu dot org 2010-05-18 14:33 --- (In reply to comment #12) TARGET_EMUTLS_VAR_INIT Nah, scratch that, it's not really sensible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-18 14:58
---
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable type
T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making
up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value as
obj1.
Yep. But an assignment is not a byte-copy and exactly the assignment is
what invokes the undefined behavior (not the subsequent access).
So,
struct X
{
char data[ sizeof( float ) ];
};
int main()
{
X x1;
new( x1.data ) float( 3.14f );
X x2 = x1;
GCC sees this as reading the float object you made live in x1.data via
an lvalue of type X and thus decides that the float object is unused
and removes it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
-- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 14:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-18 15:00
---
(In reply to comment #10)
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable
type T,
if two pointers to T point to distinct T objects obj1 and obj2, where
neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7)
making
up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value
as
obj1.
Yep. But an assignment is not a byte-copy and exactly the assignment is
what invokes the undefined behavior (not the subsequent access).
So,
struct X
{
char data[ sizeof( float ) ];
};
int main()
{
X x1;
new( x1.data ) float( 3.14f );
X x2 = x1;
GCC sees this as reading the float object you made live in x1.data via
an lvalue of type X and thus decides that the float object is unused
and removes it.
Oh, and
float is a trivially copyable type. Copying X results in copying the bytes
of
X::data (because the default copy constructor of a class does a memberwise
copy, and the default copy constructor of an array does an elementwise copy).
Therefore, the underlying bytes of the object of type float, initialized at
x1.data, are copied into x2.data, which then must, if interpreted as a float,
hold the same value as the original object.
is not what the C++ frontend does. It emits the assignment literally:
cleanup_point Unknown tree: expr_stmt
(void) (x2 = TARGET_EXPR D.21180, x1)
;
gimplified to
x2 = x1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-18 15:02 --- Making this a C++ frontend bug. The only way to avoid expanding the copy to a loop is by using memcpy which will then run into PR42834. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug lto/44143] [4.6 Regression] -fdump-tree-all for lto does not work as expected
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 --- Subject: Bug 44143 Author: rguenth Date: Tue May 18 15:11:01 2010 New Revision: 159536 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159536 Log: 2010-05-18 Richard Guenther rguent...@suse.de PR lto/44143 * lto-wrapper.c (verbose): New variable. Initialize from -v. (debug): Initialize from -save-temps. (collect_execute): Print command-line when verbose. (run_gcc): Always use COLLECT_GCC_OPTIONS. Use fork_execute for ltrans invocation. Produce -dumpbase flag again. (process_args): Remove. (main): Simplify. * collect2.c (maybe_run_lto_and_relink): Only pass object files to lto-wrapper. * gcc.c (LINK_COMMAND_SPEC): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/collect2.c trunk/gcc/gcc.c trunk/gcc/lto-wrapper.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
[Bug lto/44143] [4.6 Regression] -fdump-tree-all for lto does not work as expected
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 --- Fixed again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-05-18 15:18 ---
Hi Dave,
following patch solves the issue for me pretty well.
ChangeLog
* varasm.c (emutls_decl): Clone attributes for new decl.
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++ gcc/gcc/varasm.c2010-05-18 17:10:11.385445300 +0200
@@ -403,6 +403,8 @@ emutls_decl (tree decl)
int foo() { return i; }
__thread int i = 1;
in which I goes from external to locally defined and initialized. */
+ DECL_DLLIMPORT_P (to) = DECL_DLLIMPORT_P (decl);
+ DECL_ATTRIBUTES (to) = targetm.merge_decl_attributes (decl, to);
TREE_STATIC (to) = TREE_STATIC (decl);
TREE_USED (to) = TREE_USED (decl);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-18 15:26 --- (In reply to comment #14) Hi Dave, following patch solves the issue for me pretty well. That looks good to me to, although doing it in the middle-end makes me worry that some other target might /not/ be expecting attributes to be merged from one to the other! That's the slight advantage of doing it in the encode section hook, even though string-matching the symbols is a bit kludgey. I can't test it right now owing to parallel make check being thoroughly borked on cygwin :( Could be a few days before it gets fixed and I can do anything productive gcc-wise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-18 15:55 --- (In reply to comment #17) Created an attachment (id=20693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view) [edit] latest version a few more tweaks. with this emutls is working for lto/whopr actually, with that patch, lto is clean and whopr has reduced fails (still some symbols not getting through). OMP is still broken hmm. it's not quite that -- the working libgomp was *not* using emutls (but standard pthread calls). So the configury machinery is detecting that tls works on with the current patch :) -- it just doesn't work well enough ... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #16 from dominiq at lps dot ens dot fr 2010-05-18 16:28 --- You may be interested by pr 44132. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #19 from dominiq at lps dot ens dot fr 2010-05-18 16:55 --- This PR may have an overlap with pr44139. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
-- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-17 09:10:19 |2010-05-18 18:15:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- Comment #1 from vmakarov at redhat dot com 2010-05-18 19:06 --- It will be fixed by IRA without cover classes which I am working on. The code is planned to be included in gcc4.6. For older versions, it should be fixed in reload because I believe it is a hidden reload bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
[Bug target/44189] PIC compilation on ARM screws up DWARF lineinfo in function prologue
--- Comment #1 from gergely+gccbug at risko dot hu 2010-05-18 19:17 --- Added wrong-debug as a keyword. -- gergely+gccbug at risko dot hu changed: What|Removed |Added CC||gergely+gccbug at risko dot ||hu Keywords||wrong-debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44189
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-18 19:39 --- This happens on i386-pc-solaris2.11, too, but only with -flto and -fwhopr. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug middle-end/44185] [4.6 regression] New prefetch test failures
--- Comment #2 from changpeng dot fang at amd dot com 2010-05-18 19:39 --- I have a patch to fix the test cases: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01359.html For prefetch-6.c, patch http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00567.html applies the insn to prefetch ratio heuristic to loops with known trip count, and thus filtered one prefetch out. Add --param min-insn-to-prefetch-ratio=6 (default is 10) fixes the problem. For prefetch-7.c, patch http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00566.html does not generate prefetch if the loop is far from being sufficiently unrolled required by the prefetching. In this case, prefetching requires the loop to be unrolled 16 times, but the loop is not unrolled due to the parameter constraint. We remove --param max-unrolled-insns=1 to allow unrolling and thus generating prefetches. The movnti count is also adjusted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44185
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 19:42 --- Ian, you've introduced this testcase; could you have a look? -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug c/19541] need another option to support what -I- did just besides -iquote
--- Comment #15 from chris dot litchfield at gmail dot com 2010-05-18 19:48 --- This is still a huge issue. We would wish to inhibit use of the CURRENT Working directory to find include files. Basically FORCE every time a new include file is found with #include to start AGAIN from the begining of the Include Path system. using -iquote will simply cause the same problem where an include file that includes another include file will include that sub-include file even if you can pulled it away in a previous include path. Make files with VPATH or put Development paths first in lists are totally hosed by removing the -I- functionality. This is NOT an enhancement but a Priority 2 bug which there is NO WORKAROUND provided by removing a feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #4 from iains at gcc dot gnu dot org 2010-05-18 20:04 --- (In reply to comment #3) Ian, you've introduced this testcase; could you have a look? Yes.. working my way through .. I'm sure that it is problem with ObjC (and ObjC++, if you apply http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01039.html) -- iains at gcc dot gnu dot org changed: What|Removed |Added CC|developer at sandoe-|iains at gcc dot gnu dot org |acoustics dot co dot uk | AssignedTo|unassigned at gcc dot gnu |iains at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 20:04:17 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #13 from pluto at agmk dot net 2010-05-18 20:57 --- btw. the boost::optional uses char-based storage and cast storage - void* - some_type* via address() and get_object() methods. it looks like aliasing violation too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 --- If print *, (foo()) is changed to print *, foo() one gets: $ gfortran-svn pr41859.f90 pr41859.f90:17.19: print *, foo() ! -- ICE here! 1 Error: Data transfer element at (1) cannot have POINTER components Same for the second problem: $ gfortran-svn pr41859-c1.f90 pr41859-c1.f90:37.19: print *, foo() ! 1 Error: Data transfer element at (1) cannot have PRIVATE components -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 21:17:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) print *exp
$2 = {expr_type = EXPR_OP, ts = {type = BT_DERIVED, kind = 0, u = {derived =
0x8bc7ad8, cl = 0x8bc7ad8}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN},
rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where = {nextc = 0x8bfa9ec,
lb = 0x8bfa9b0}, inline_noncopying_intrinsic = 0, is_boz = 0, is_snan = 0,
error = 0,
user_operator = 0, representation = {length = 0, string = 0x0}, value =
{logical = 27, iokind = 27, integer = {{_mp_alloc = 27, _mp_size = 0, _mp_d =
0x8bb1450}}, real = {{
_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp = 146478160, _mpfr_d =
0x0}}, complex = {{re = {{_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp =
146478160, _mpfr_d = 0x0}}, im = {
{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0, op
= {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}, function
= {actual = 0x1b,
name = 0x0, isym = 0x8bb1450, esym = 0x0}, compcall = {actual = 0x1b,
name = 0x0, base_object = 0x8bb1450, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {
length = 27, string = 0x0}, constructor = 0x1b}}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns
--- Comment #4 from vmakarov at redhat dot com 2010-05-18 21:40 --- Thanks for reporting the problem. The problem has no effect on generated code whatever initialization is used. The code in question tries to get basic block for BARRIER which is wrong. Whatever it gets basic block for BARRIER the code will still work right. In any case, it is really annoying to see such valgrind diagnostic. Therefore I'll send a patch to fix it soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
[Bug libstdc++/44190] New: Debug vector resize does not update capacity
The assertion in the following testcase should /not/ fail, but does:
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include vector
#include cassert
int main()
{
std::vectorint v;
v.resize(10);
assert(v.size() = v.capacity());
}
--
Summary: Debug vector resize does not update capacity
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2010-05-18 21:45 --- Created an attachment (id=20695) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20695action=view) Trivial patch that fixes the problem. The problem was just a missing call to _M_update_guaranteed_capacity(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 21:50:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-18 21:51 --- Created an attachment (id=20696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20696action=view) Fifth draft patch - with test case New approach. The attached patch now also works with twisted modules (cf. test case in the attachment). However, it needs still some clean up as there are test suite failures. Additional tasks: (a) Check whether one can get rid of gfc_match_structure_constructor. (b) Add check to ensure that the generic name only contains functions and that the type name does not exist as specific function name. (c) Do general clean up, bug fixing, and add test cases. Regarding C489 [F2003] and C496 [F2008], see also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3580ffd988330d7 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20599|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p)! '()' are significant
end
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) p exp-expr_type
$11 = EXPR_OP
(gdb) p exp-ts.u.derived-name
$12 = 0xb7f47a08 ptype
(gdb) p exp-value.op
$13 = {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}
(gdb) p exp-value.op.op1-expr_type
$14 = EXPR_VARIABLE
(gdb) p exp-value.op.op1-ts.u.derived-name
$15 = 0xb7f47a08 ptype
No idea how to fix this, adding the obvious check and workaround for EXPR_OP
feels wrong. More likely, EXPR_OP should never have been passed down here?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
