[Bug c++/21764] visibility attributes on namespace scope
--- Comment #9 from geoffk at geoffk dot org 2005-11-18 19:39 ---
Subject: Re: visibility attributes on namespace scope
On 17/11/2005, at 10:15 PM, jason at redhat dot com wrote:
> --- Comment #8 from jason at redhat dot com 2005-11-18 06:15
> ---
> Subject: Re: visibility attributes on namespace scope
>
> bkoz at gcc dot gnu dot org wrote:
>> What do you mean, "less or equal visibility to their enclosing
>> scope?"
>
> Where default > protected > hidden > internal, if a class or namespace
> has a specified visibility, nested scopes should have the same
> visibility or something later in the above sequence.
Although this makes sense for classes, I'm not sure it does for
namespaces:
namespace foo __attribute__((visibility("hidden"))) {
void foo();
void bar() __attribute__((visibility("default")));
}
This seems reasonable to me; the attribute on the namespace is
setting a default, which is overridden on bar().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #28 from geoffk at geoffk dot org 2005-11-19 04:40 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 On 18/11/2005, at 6:42 PM, lucier at math dot purdue dot edu wrote: > --- Comment #27 from lucier at math dot purdue dot edu > 2005-11-19 02:42 --- > Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 > > I don't know what Apple's priorities are here, but it would be really > nice to get 64-bit dynamic libraries working on Darwin. (Or maybe > they do work, and I'm just running into a dark corner case here.) They do work. It appears to be a linker bug. You can work around it by adding explicit -L paths to GCC's library directories, which do not contain '../'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #3 from geoffk at geoffk dot org 2005-11-28 19:22 --- Subject: Re: aliases, including weakref, break alias analysis On 28/11/2005, at 10:40 AM, aoliva at gcc dot gnu dot org wrote: > --- Comment #2 from aoliva at gcc dot gnu dot org 2005-11-28 > 18:40 --- > I'd change the testcase s/weakref/alias/, so as to make it clear > that the error > has nothing to do with the newly-introduced weakref, but rather > with regular > aliases, that weakref builds upon. If you do that, it won't work on Darwin, because Darwin doesn't have aliases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #5 from geoffk at geoffk dot org 2005-11-30 01:01 --- Subject: Re: aliases, including weakref, break alias analysis On 29/11/2005, at 5:55 AM, aoliva at gcc dot gnu dot org wrote: > Make it a weak alias, then. A weak alias is still an alias and still not supported by Mach-O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug middle-end/25522] zero-initialized constants are place in .bss
--- Comment #4 from geoffk at geoffk dot org 2005-12-23 23:33 --- Subject: Re: New: zero-initialized constants are place in .bss "drepper at redhat dot com" <[EMAIL PROTECTED]> writes: > const struct foo f; > > The compiler will mark the variable f in .bss instead of, as the const > indicates, into .rodata. What happens if you use -fno-common? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25522
[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
--- Comment #5 from geoffk at geoffk dot org 2006-08-21 22:06 --- Subject: Re: [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c On 20/08/2006, at 9:32 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-21 > 04:32 --- > Geoff, > Do you have a testcase where you get better debug info from your > patch? > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01567.html It took me a while to find it, but here's an example: extern void x(); static void (*f)() = x; However, this patch is clearly not behaving the way I expected. I can reproduce the reported problem on powerpc-darwin when using 'gcc - O -gdwarf-2'. I'll work on a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28692
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #13 from geoffk at geoffk dot org 2006-09-02 05:31 --- Subject: Re: [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs On 01/09/2006, at 2:53 PM, mmitchel at gcc dot gnu dot org wrote: > --- Comment #11 from mmitchel at gcc dot gnu dot org > 2006-09-01 21:53 --- > Yet another problem showing problems with attributes on typedefs > for structure > types... The question I asked is "why doesn't this happen for 'const'"? That turned out to be a good question, because it leads to the better question of "what debugging output did you expect for this code, anyway"? It seems to me that __noalias__ is an interesting attribute that should be somehow reflected in the DWARF. That would require a GNU extension, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #13 from geoffk at geoffk dot org 2008-02-12 22:43 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785 On 12/02/2008, at 7:46 AM, hjl dot tools at gmail dot com wrote: > --- Comment #10 from hjl dot tools at gmail dot com 2008-02-12 > 15:46 --- > (In reply to comment #3) >> Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os >> as well as >> -O2 -mno-accumulate-outgoing-args. The difference between i686- >> linux and >> i686-darwin9 that matters here is that darwin defines >> STACK_BOUNDARY to 128, >> while linux to 4. >> > > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is > hardware related, not ABI related. They should set > PREFERRED_STACK_BOUNDARY > instead, which is set to 128 already. On stack alignment branch, we > introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs. If you do not align the stack at a 128-bit boundary, your program will crash. The hardware that it is related to is SSE2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #15 from geoffk at geoffk dot org 2008-02-13 05:54 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785 STACK_BOUNDARY >> > is more or less "natural" hardware stack boundary, which should be > the size of pointer. That is not what is documented and if you are proposing a change, I do not see how your proposal is useful. The distinguishing property of STACK_BOUNDARY is that the compiler is allowed to rely on the stack being aligned by it. There is no notion of "hardware" or "pointer" or "natural" involved; either the stack is always aligned on call boundaries or it is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #17 from geoffk at geoffk dot org 2008-02-13 07:50 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785 On 12/02/2008, at 10:41 PM, hjl dot tools at gmail dot com wrote: > --- Comment #16 from hjl dot tools at gmail dot com 2008-02-13 > 06:41 --- > (In reply to comment #15) >> Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c: >> 32: internal >> compiler error: in expand_call, at calls.c:2785 >> >> STACK_BOUNDARY >>>> >>> is more or less "natural" hardware stack boundary, which should be >>> the size of pointer. >> >> That is not what is documented and if you are proposing a change, I >> do >> not see how your proposal is useful. >> >> The distinguishing property of STACK_BOUNDARY is that the compiler is >> allowed to rely on the stack being aligned by it. There is no notion >> of "hardware" or "pointer" or "natural" involved; either the stack is >> always aligned on call boundaries or it is not. >> > > Here is our proposal: > > http://gcc.gnu.org/ml/gcc/2007-12/msg00567.html It is to be expected that this proposal usually has no effect on Darwin, because the problem it is trying to solve, of local variables that require alignment greater than the default, does not usually exist on Darwin. Under the definitions in your proposal, on Darwin, STACK_BOUNDARY should be 128, because 128 is the "minimum stack boundary" on Darwin, and this is also the value "preferred by hardware". There is a contradiction in your proposal in which it says that it is "preferred by hardware" but also the "minimum stack boundary"; on many x86 platforms, the hardware would really prefer 128 bits, but the ABI actually specifies a smaller value. I think your proposal would be more clear if it left the definition of STACK_BOUNDARY alone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #8 from geoffk at geoffk dot org 2008-03-01 04:05 ---
Subject: Re: static object mangling conflicts with extern object
On 29/02/2008, at 5:57 AM, mueller at gcc dot gnu dot org wrote:
> extern "C" void abort();
> extern "C" { static int i; }
> int *p = &i;
> int main()
> {
> int i;
> {
>extern int i;
>i = 1;
>*p = 2;
>if (i == 2)
> abort ();
> }
> return 0;
> }
>
> in this case, the "i" name should not be mangled, right?
It should be mangled, because there are still three different things
named 'i' declared in this program, and so the two that have assembler
names have to have different names, and I don't think we want to start
mangling non-static variable names.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug middle-end/23125] [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault
--- Additional Comments From geoffk at geoffk dot org 2005-09-10 20:34 --- Subject: Re: [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault On 09/09/2005, at 9:56 PM, pinskia at gcc dot gnu dot org wrote: > So it is little harder to fix than I had previous thought as there > is no way to know if user set the decl > name or if it was just the name of the decl. The front-ends have > to be fixed to call > set_user_assembler_name all the time and then make_decl_rtl needs > to be updated for that but I don't > have the time to test that patch. You should be able to tell if the user set the name because it will start with a '*'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23125
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From geoffk at geoffk dot org 2005-09-16 00:01
---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
On 15/09/2005, at 3:53 PM, joseph at codesourcery dot com wrote:
> Yes, "spelling" is meant in terms of the source code characters.
> The idea is to permit simple strcmp-like checking by the
> preprocessor.
Good, so that answers that question.
You raise a good point about GCC not having documentation for phase
1. I don't have time to write all of it, but I think I can write the
last part, about UCNs, so maybe together we can get it all done. My
proposed wording is:
@cite{The mapping between physical source file multibyte characters
and the source character set in translation phase 1 (C90 and C99
5.1.1.2).}
[CR/NL/CR-NL are turned into EOL markers, spaces are deleted between
backslash and the end of a line, it's converted to UTF-8 using iconv
based on -finput-charset---and what else?]
Then, any character sequence which would form a UCN in an identifier
in phase 3 of translation is converted into the corresponding UTF-8
sequence. Any backslash-newline combinations in the UCN are
preserved and placed after the UTF-8 sequence.
[note that there's no way for a user to tell whether a backslash-
newline combination is placed before, in the middle of, or after, the
UTF-8 sequence.]
...
@cite{Which additional multibyte characters may appear in identifiers
and their correspondence to universal character names (C99 6.4.2).}
UTF-8 character sequences may appear in identifiers, and they
correspond to the UCN that specifies that character. A UTF-8
sequence may appear only if the UCN that it corresponds to would be
permitted in the identifier at that point. At present, only those
UTF-8 sequences which were produced by the mapping from UCNs to UTF-8
sequences in translation phase 1 are permitted, but this is likely to
change in the future.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #79 from geoffk at geoffk dot org 2005-10-31 22:14 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 10:37 AM, ismail at uludag dot org dot tr wrote: > --- Comment #78 from ismail at uludag dot org dot tr > 2005-10-31 18:37 --- > Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? > Waiting for 4.2 > means that unpatched gcc's will suffer for more. > I don't think the problem is solved yet, is it? In addition to the question of whether the patch is actually safe for all architectures, there's also still the question of using standard library templates, like 'vector', on hidden types; this works now if you use - fvisibility=hidden, and it'd stop working if the patch was applied, so you'd just be trading one problem for another. Better I think to not make this change in 4.1, at least that can't introduce any regressions, and work on the problem for 4.2. However, maybe the problem would be much reduced if we marked some specific classes as not hidden: those which are thrown as exceptions. There are only a handful of them, so we could do that with just an attribute, and surely that would be safe. What do people think of that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #81 from geoffk at geoffk dot org 2005-10-31 23:29 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 2:45 PM, mueller at kde dot org wrote: > --- Comment #80 from mueller at kde dot org 2005-10-31 22:45 > --- > - not hiding a symbols is better than the resulting issues when > hiding a symbol > which should be exported. for example right now the function > static pointer > pointing to libstdc++'s memory allocator is hidden, which causes > STL usages > to just randomly crash when used across linking boundaries. > crashing is worse > than the performance penality by exported symbols > I wasn't thinking so much of the performance penalty, but rather of the ABI impact. Suddenly, your dynamic library, which you thought had carefully controlled exports (maybe it shouldn't export any C++ interfaces of its own at all), is exporting a global C++ type, 'std::vector', which could conflict with any similarly-named- but-different type anywhere in a program that uses the library. Performance is also a concern, of course. > - of course just exporting those classes that *should* be exported > would be > much more clever. I just thought if its so difficult to get a > brain-dead > simple patch that makes everything work not getting applied within > 6 months > then the stripped-down just-exporting-what-is-really needed (which > requires > a lot of in-depth knowledge and a lot of testing) would need more > something > like 6 years to get applied. > > Anyway, I volunteer to help reducing the amount of exported classes > if thats > what makes you apply the patch. The current brute-force export-all > patch > fixes everything and is dead simple compared to such a "only export > what > is needed patch". > Well (after re-reading what the bug was originally about): - You'll notice that the bug is about things which are not defined in this library, which can't possibly include the things I'm concerned about above, since every part of std::vector must be defined in this library since nothing else knows about 'mytype'. So it's certainly possible to fix it. - But, I'm not sure that the front-end supports everything you'll need to mark all the right pieces. For instance, ctype has to be hidden, but ctype has to be not hidden. It would probably be easier to teach the front-end that "if I'm instantiating something, the resulting thing must have the most restrictive visibility of any of its parameters" than it would be to go around trying to put attributes on each little method. - If that's too hard to do in time for 4.1, we could at least fix the related problems for non-x86-64 systems, which have to do with the classes thrown as exceptions; it's not useful to compile them with hidden visibility, since they're passed between libraries. (They're mostly in libsupc++.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #84 from geoffk at geoffk dot org 2005-11-01 04:30 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 7:59 PM, bkoz at gcc dot gnu dot org wrote: > Geoff, it's not as simple as just marking throwable types, all > typeinfo, etc. > I'm performing an audit, but it's stuff like local statics as well. > Right, I wasn't trying to say that just marking the throwable types would be a complete solution (for anyone), just that it was easy, clearly correct as far as it went, and it would reduce the problem. > This has to be done very carefully for a C++ library, which isn't > as clearly defined as C libraries that are already using this > feature (but that don't have to deal with vague linkage.) > Plus, we don't really know what it should mean yet. For instance, if everything is compiled with visibility hidden, and dylib A throws "vector", should that be catchable in dylib B? I can think of good arguments for "yes", "no", and "undefined", which I guess means that "undefined" should win. --- Comment #85 from geoffk at geoffk dot org 2005-11-01 04:30 --- Created an attachment (id=10094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10094&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug pch/10591] Members of anonymous namespaces should be 'static'
--- Additional Comments From geoffk at geoffk dot org 2005-08-01 04:31 --- Subject: Re: Members of anonymous namespaces should be 'static' On 31/07/2005, at 7:24 PM, cpence at gmail dot com wrote: > Three months later, any movement on this bug? How is the PCH code > in the 4.0 > branch? PCH support would be a godsend to people supporting large C > ++ projects > on GCC. There aren't any particular plans I know of to work on this bug, although I'd be happy to hear of some. As far as I know PCH works fine in the 4.0 branch (but this bug isn't fixed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #17 from geoffk at geoffk dot org 2007-10-30 18:31 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 9:53 AM, gcc at magfr dot user dot lysator dot liu dot se wrote: >>> If that is the case, what should typeid(reference to base of >>> anonymous class >>> instance) in another module return? >> >> The same thing it does now, which I believe is the typeinfo of the >> base class. > > I follows the standard, so if base is polymorphic it returns the > typeinfo > object for the actual type and if if base is nonpolymorphic it > returns the > typeinfo object for base. > > Could the requirements be aligned? I believe that the compiler now does what the standard says and can continue to do so whether the typeinfo is local or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #18 from geoffk at geoffk dot org 2007-10-30 18:35 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 11:07 AM, rguenth at gcc dot gnu dot org wrote: > --- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-30 > 18:07 --- > Geoff, your patch changed the typeinfo symbols for anonymous > namespaces from > having weak linkage to non-weak linkage. This caused the > regression. Do you > argue this change was deliberate and is the right thing? Why do you > think so? > Can you please restore the old behavior which is also that of other > compilers > for the linux targets? No, it changed the typeinfo symbols from being externally visible and having weak linkage, to not being externally visible in which case the weak-ness does not matter. The change is correct and necessary. You cannot access an anonymous namespace from outside the translation unit it is defined in, so the associated symbols do not need to be externally visible, and the change is correct. It is necessary if you do not use random strings in the symbol names, because otherwise the symbols will conflict. It does not matter what other compilers do, this is not an ABI issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #21 from geoffk at geoffk dot org 2007-10-30 19:04 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 11:44 AM, rguenther at suse dot de wrote: > I see. So where is the bug here? We obviously see application builds > fail because of this. Well, perhaps you could look at the linker error message and see whether it is correct? As I said, I don't understand it, it reads to me like "ld refuses to link your program for no good reason". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #23 from geoffk at geoffk dot org 2007-10-30 19:32 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote: > The problem is "typeinfo for (anonymous namespace)::t" in .rodata > section > references "typeinfo name for (anonymous namespace)::t" in a comdat > section. > When the comdat section is discarded, we got a problem. Why is the comdat section being discarded when something is referencing it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #27 from geoffk at geoffk dot org 2007-11-03 07:21 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 9:03 PM, amodra at bigpond dot net dot au wrote: > --- Comment #26 from amodra at bigpond dot net dot au > 2007-10-31 04:03 --- > I believe the linker is correct to reject relocations against local > symbols in > discarded sections. The reason being that the linker allows > linkonce (and > comdat group) section contents to differ between two files, so that > for > example, two files may be compiled with different optimisations yet > still link > correctly. Since the contents may differ, the location of symbols > within the > section may also differ between files. Using the value of > "local_sym + offset" > in one file (in the discarded section) may point to an entirely > wrong location > in the other file (in the kept section). In this case, though, the contents of the linkonce section will never actually differ; and I believe in this case the offset is zero, so even if they did differ it would not matter. Perhaps a zero offset should be special-cased? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #30 from geoffk at geoffk dot org 2007-11-04 07:50 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote: > Local symbols should only be referenced within the same comdat group > or the linkonce section. Otherwise, it is a compiler bug. How do you represent, in ELF, a string which should be present in the executable only once, but which need not have a globally visible name? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #32 from geoffk at geoffk dot org 2007-11-05 00:14 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 6:40 AM, hjl at lucon dot org wrote: > --- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 > --- > (In reply to comment #30) >> Subject: Re: [4.3 Regression] typeinfo name referenced in ... >> defined in >> discarded section >> >> On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote: >> >>> Local symbols should only be referenced within the same comdat group >>> or the linkonce section. Otherwise, it is a compiler bug. >> >> How do you represent, in ELF, a string which should be present in the >> executable only once, but which need not have a globally visible >> name? >> > > You can put it in a comdat group. But you should only reference it > from the > same comdat group. A comdat group is a set of sections which have the > same signature. What if you want to reference this string from somewhere that should never be discarded, like a global variable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #35 from geoffk at geoffk dot org 2007-11-05 02:47 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 4:22 PM, hjl at lucon dot org wrote: > --- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 > --- > (In reply to comment #32) >> >> What if you want to reference this string from somewhere that should >> never be discarded, like a global variable? >> > > Since the string is local, that global variable is defined in > the same file as the string. You should put the global variable > in a section which belongs to the same comdat group as the local > string. - What if the global variable references two or more strings? - Won't this cause the global variable to be discarded if anyone defines a different global variable which also references the same string? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #39 from geoffk at geoffk dot org 2007-11-05 03:33 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote: >> - Won't this cause the global variable to be discarded if anyone >> defines a different global variable which also references the same >> string? > > The comdat group should have both global variables defined. I'm talking about static char * some_variable = "hi there"; and in some other file static char * some_variable = "hi there"; the compiler does not know that there are two files containing 'some_variable', and they have to be different variables (someone might change one of them and the other should not change if that happens), but the two "hi there" strings should be shared. How should the compiler represent this in ELF? --- Comment #40 from geoffk at geoffk dot org 2007-11-05 03:33 --- Created an attachment (id=14485) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14485&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #93 from geoffk at geoffk dot org 2006-04-04 00:23 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 03/04/2006, at 4:57 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #92 from pinskia at gcc dot gnu dot org 2006-04-03 > 23:57 --- > Both PR 27000 and bug 26984 are reasons why push/pop will fail > currently. It's probably OK if the visibility you're pushing is 'default'. At least, it's no worse to push default than it would be to not push anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata
--- Additional Comments From geoffk at geoffk dot org 2005-05-30 15:37 --- Subject: Re: [4.1 Regression] Powerpc atomic builtins missing PPC405 errata On 29/05/2005, at 6:40 PM, dje at gcc dot gnu dot org wrote: > This is a regression because libstdc++ previously worked correctly > on PPC405 and > now it does not. That would be due to this patch: 2005-05-25 Paolo Carlini <[EMAIL PROTECTED]> * config/cpu/alpha/atomicity.h: Use the builtins for atomic memory operations. * config/cpu/powerpc/atomicity.h: Likewise. * config/cpu/ia64/atomicity.h: Do not include ia64intrin.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21760
[Bug pch/105403] [Bug] Buffer overflow can happen when reading pchf_data from file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105403 Geoff Keating changed: What|Removed |Added CC||geoffk at geoffk dot org --- Comment #1 from Geoff Keating --- A PCH file is a trusted input, so this really shouldn’t happen, and there are surely many other ways to trigger arbitrary code execution if you can craft one. However a sanity check would do no harm, this code is not performance relevant.
