[Bug c/27153] function result is dereferenced error
--- Comment #11 from joseph at codesourcery dot com 2006-04-18 11:17 --- Subject: Re: function result is dereferenced error On Tue, 18 Apr 2006, falk at debian dot org wrote: > Uhm, this has nothing to do at all with evaluation order. Evaluation > order of arguments is unspecified (not undefined, which wouldn't make a > lot of sense), but that is in fact irrelevant here, it could lead to, > say, 3 1 2, but not 1 1 1. > > The actual problem is that val is modified more than once without an > intervening sequence point, which makes the behavior undefined. No, this testcase is unspecified, not undefined. There are intervening sequence points at the start and end of each call to function, and function calls do not overlap (DR#087); each call to func suspends the execution of main until func returns. However, the evaluation of the arguments to printf may overlap and the order is unspecified, so there are many possible outputs from the program (but "3 2 1" and "3 1 1", for example, are not possible). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug preprocessor/27195] hex and oct constants are converted to wrong type
--- Comment #3 from joseph at codesourcery dot com 2006-04-18 11:22 --- Subject: Re: hex and oct constants are converted to wrong type On Tue, 18 Apr 2006, rguenth at gcc dot gnu dot org wrote: > 6.10.1/3 > > The resulting tokens > compose the controlling constant expression which is evaluated according to > the > rules of > 6.6, except that all signed integer types and all unsigned integer types act > as > if they have > the same representation as, respectively, the types intmax_t and uintmax_t > defined > in the header . I recommend quoting the current standard as amended by TC2, which makes this specific case even clearer in response to DR#265: The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. For the purposes of this token conversion and evaluation, all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header .142) 142) Thus, on an implementation where INT_MAX is 0x7FFF and UINT_MAX is 0x, the constant 0x8000 is signed and positive within a #if expression even though it would be unsigned in translation phase 7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27195
[Bug c/27153] function result is dereferenced error
--- Comment #13 from joseph at codesourcery dot com 2006-04-18 12:57 --- Subject: Re: function result is dereferenced error On Tue, 18 Apr 2006, falk at debian dot org wrote: > > However, the evaluation of the > > arguments to printf may overlap and the order is unspecified, so there are > > many possible outputs from the program (but "3 2 1" and "3 1 1", for > > example, are not possible). > > I don't understand why is "3 2 1" is not possible. How about "1 1 1"? Is > this a bug in gcc after all? "1 1 1" is possible: first evaluate func(3), then func(2), then func(1), then do all the dereferences. To get "3 2 1", the initial "3" requires func(3) to be evaluated between the evaluation of func(1) and its dereference, so func(3) is evaluated after func(1); but likewise the final "1" requires func(1) to be evaluated after func(3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug c/27214] The C frontend introduces undefined pointer overflow
--- Comment #7 from joseph at codesourcery dot com 2006-04-19 17:15 --- Subject: Re: The C frontend introduces undefined pointer overflow On Wed, 19 Apr 2006, rakdver at gcc dot gnu dot org wrote: > Andrew, please do not mark PRs as invalid until the people involved in the > discussion do not agree on the common interpretation of the standard. This bug is about the interpretation of GCC's internal representation, not that of the standard. Valid pointer offsets range from -SIZE_MAX to +SIZE_MAX - thus they require one bit more than pointers to store. An internal representation not allowing for this range of offsets is problematic. (As for the C language issues, subtraction of two pointers involves undefined behavior if the result is outside the range PTRDIFF_MIN to PTRDIFF_MAX, but you can still have an array using more than half of memory as long as you don't subtract pointers to elements too far apart. You could also have an array using almost all of memory, and subtract elements at opposite ends, as long as the element size is not 1; only the final result needs to be in range. Such subtraction of pointers more than half of memory apart is not however an important case, and probably not one it's feasible to get right efficiently.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
[Bug c++/16376] Bit-field promotions
--- Comment #4 from joseph at codesourcery dot com 2006-04-23 22:22 ---
Subject: Re: Bit-field promotions
On Sun, 23 Apr 2006, mmitchel at gcc dot gnu dot org wrote:
> However, my patch was not intended to fix this bug, and only does so by
> accident. In particular, the last lines of decay_conversion convert the
> expression to the TYPE_MAIN_VARIANT of the limited-precision type, rather than
> to the TYPE_MAIN_VARIANT of the declared type of the bitfield, as I had
> intended, although the original conversion from limited-precision type to
> declared type is present in the expression by this point.
>
> I am not sure if that original conversion is actually required, given that the
> testsuite is passing with the code in its current state. In earlier forms of
> the patch, it was definitely required; otherwise, for example, bitfields of
> enumeration type did not have the correct type elsewhere in the compiler. It
> may be that because of the changes I made to the conversion machinery in
> call.c, this is no longer a problem.
The sort of case where you need to convert to the declared type is
#include
struct S {
unsigned long a : 33, b : 33;
} s = { 1UL << 32, 1UL << 32 };
int
main(void)
{
if (s.a + s.b != (1UL << 33))
abort();
}
(supposing 32-bit int, 64-bit long). But given that C++ doesn't define
LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS, even if the addition is done on
the reduced types that might not reliably cause the test to fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16376
[Bug target/27034] [4.2 Regression] gcc.dg/20021014-1.c (test for excess errors) fails
--- Comment #4 from joseph at codesourcery dot com 2006-05-03 00:12 --- Subject: Re: [4.2 Regression] gcc.dg/20021014-1.c (test for excess errors) fails On Tue, 2 May 2006, sje at cup dot hp dot com wrote: > I am not seeing this failure in my recent builds, should I go ahead and close > this defect? This failure has indeed gone away at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27034
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- Comment #3 from joseph at codesourcery dot com 2006-05-19 16:35 --- Subject: Re: New: float to int conversion doesn't raise invalid exception On Fri, 19 May 2006, janis at gcc dot gnu dot org wrote: > GCC claims to follow C99 Annex F when converting a floating value to an > integer It doesn't (in that it doesn't define __STDC_IEC_559__). But it should aim to do so (provided the user doesn't specify options such as -fno-trapping-math in this case). > A possibly-related issue is that this macro is defined in a header file > provided by glibc, not by GCC. That's a bug in the combination of glibc and GCC, requiring cooperation between them to fix. The macro must be defined from the start of the translation unit without any headers needing to be included; the same also applies to __STDC_ISO_10646__ which is definitely a property of the library. My suggested solution is still as at <http://gcc.gnu.org/ml/gcc/2004-05/msg01019.html>: an implicitly included header that is provided by the library, makes such definitions, *does not include other glibc headers such as features.h* (because the source file may define feature test macros later before it first explicitly includes a system header), and whose absence is silently ignored by the compiler (in order to support older glibc without the header). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #29 from joseph at codesourcery dot com 2006-06-04 17:35 --- Subject: Re: [4.2 Regression] Build failure: undefined symbol __floatunsitf On Sun, 4 Jun 2006, mmitchel at gcc dot gnu dot org wrote: > --- Comment #28 from mmitchel at gcc dot gnu dot org 2006-06-04 17:19 > --- > Joseph -- > > Would you please summarize the current state of this bug, and whether or not > you intend to do any more work on it? I'm trying to figure out how to > prioritize it for 4.2. The state is still as in comment#23 and I don't intend to do any more work on it (though I could do the US_SOFTWARE_GOFAST removal if desired). * MIPS16 (mips16.S needs implementations of the relevant functions, mips_init_libfuncs should arrange for them to be called) - preferably to be done by someone set up to test MIPS16. * FRV - see comment#9 - could do with knowledge of the intent behind the C functions such as __uitod and again with someone to test on FRV. * US_SOFTWARE_GOFAST - should be removed - see my list at <http://gcc.gnu.org/ml/gcc/2006-05/msg00440.html> of the various pieces to remove. * powerpc-linux glibc -mabi=ieeelongdouble - not supported by glibc in any meaningful way but it does provide the ABI-mandated functions for arithmetic on IEEE long double; however, there is a glibc bug whereby it provides _q_uitoq instead of the correct name _q_utoq which GCC will now call. There is no GCC bug here since GCC calls the ABI-specified function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug preprocessor/28022] Incorrect pedwarn for , expression in #if in c99 mode
--- Comment #1 from joseph at codesourcery dot com 2006-06-14 11:03 --- Subject: Re: New: Incorrect pedwarn for , expression in #if in c99 mode On Wed, 14 Jun 2006, sabre at nondot dot org wrote: > This testcase: > > #if 1 , 0 > #endif > > Should not warn with -std=c99 -pedantic. It currently does due to an inverted Why do you think that (with reference to the relevant subclauses and paragraphs of the standard)? The existing conditional looks correct to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28022
[Bug testsuite/28123] gcc.dg/cpp/_Pragma3.c is sensitive to timestamps
--- Comment #2 from joseph at codesourcery dot com 2006-06-21 15:14 --- Subject: Re: New: gcc.dg/cpp/_Pragma3.c is sensitive to timestamps On Wed, 21 Jun 2006, amylaar at gcc dot gnu dot org wrote: > It would appear that this tests success requires that either _Pragma3.c is > checked out after mi1c.h, or both are checked out simultanously as far as the > file system is concerned. You're meant to use contrib/gcc_update to adjust the timestamps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28123
[Bug target/28137] "make check" gets 10 FAIL reports with gcc.dg/c99-typespec-1.c
--- Comment #2 from joseph at codesourcery dot com 2006-06-22 14:27 --- Subject: Re: "make check" gets 10 FAIL reports with gcc.dg/c99-typespec-1.c On Thu, 22 Jun 2006, pinskia at gcc dot gnu dot org wrote: > FAIL: gcc.dg/c99-typespec-1.c (test for excess errors) > > Sounds like there is an ICE going on. It sounds to me a lot move like someone using a version of expect without HJ's patch (bug 12096). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137
[Bug c/38308] -Wformat does not work for wide strings
--- Comment #2 from joseph at codesourcery dot com 2008-11-28 17:26 --- Subject: Re: -Wformat does not work for wide strings In view of the removal of c4x support I don't now think any patch for this needs to address the format of STRING_CSTs for non-8-bit target bytes. But it should still have appropriate accessors for extracting bytes / multibyte characters / wide characters from strings (such that support for non-8-bit target bytes could be added to those accessors later), though without necessarily finding all existing code that should be using those accessors. See also bug 20110 on the format checking not allowing for the execution character set once it's extracted a character from the string. For wide characters it's -fwide-exec-charset that's relevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38308
[Bug c++/38297] O2 causes invalid code
--- Comment #14 from joseph at codesourcery dot com 2008-11-30 15:37
---
Subject: Re: O2 causes invalid code
On Sun, 30 Nov 2008, rguenth at gcc dot gnu dot org wrote:
> Note that the C standard forbids type-punning through a union.
> Basically it says that you may only read from a union member if you have
> previously written to it. It also says that all other bits apart from
> the ones you have written to contain undefined values after the write.
> So
>
> union { int i; float f; } u;
> u.i = 1;
> x = u.f;
>
> invokes undefined behavior in C (but not in GNU C because of the language
> extension).
Note that C99 TC3 adds a footnote: "*) If the member used to access the
contents of a union object is not the same as the member last used to
store a value in the object, the appropriate part of the object
representation of the value is reinterpreted as an object representation
in the new type as described in 6.2.6 (a process sometimes called "type
punning"). This might be a trap representation."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug other/38363] Use of Unicode quotes depends on LC_CTYPE rather than LC_MESSAGES
--- Comment #1 from joseph at codesourcery dot com 2008-12-02 01:36 --- Subject: Re: New: Use of Unicode quotes depends on LC_CTYPE rather than LC_MESSAGES On Tue, 2 Dec 2008, debian-gcc at lists dot debian dot org wrote: > gcc uses Unicode quote marks with LC_CTYPE=en_US.UTF-8, but not with > LC_CTYPE=C. Shouldn't that depend on LC_MESSAGES instead, not LC_CTYPE? > LC_CTYPE should only affect character classification, such as "this > character counts as uppercase". LC_CTYPE should determine the character set for messages and LC_MESSAGES their language. For translated messages, gettext should automatically convert the messages in the .mo file to the user's terminal's character set as specified by LC_CTYPE (or overridden by OUTPUT_CHARSET). For English messages, this is handled directly in the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38363
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #2 from joseph at codesourcery dot com 2008-12-06 19:09 --- Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression On Sat, 6 Dec 2008, sabre at nondot dot org wrote: > This is a bug in the C front-end. They need to use __builtin_choose_expr. No, it's a bug in the C++ front end, at least as regards the initializer. It's expressly documented that this is allowed in initializers. See also my note in <http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html> about how what should be allowed with __builtin_constant_p goes beyond what I put in my formal models of desired constant expression semantics for GCC in 2004. If you get this wrong for C then GCC will fail to bootstrap, as it's part of the GNU C semantics GCC relies on when being built with GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #4 from joseph at codesourcery dot com 2008-12-06 22:53 --- Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression On Sat, 6 Dec 2008, sabre at nondot dot org wrote: > Ok, so this is a special case when __builtin_constant_p is immediately the > operand of "?:"? Do you allow things like __builtin_constant_p(...)+0 as the > operand? Yes, this is a (documented) special case required to be compatible with existing GNU C code. __builtin_constant_p(...)+0 is not allowed as the condition; the bcp_call property propagates though parentheses and through being an operand of __builtin_choose_expr, but not otherwise. For example, ((__builtin_choose_expr(1, (__builtin_constant_p(...)), 1))) has the bcp_call property. I think the description in my formal model is right for how this property propagates, except it leaves it unclear what the property is for the result of a conditional expression where both the condition and the selected half of the expression have the bcp_call property. In that case, I don't think the conditional expression should have the property, and it doesn't in the implementation on c-4_5-branch. The formal model seems unclear here, but I think it should be interpreted as the bcp_call property being lost through the implicit conversion of the ?: operands to a common type. What I didn't realise when writing the formal model is that the conditional expression, with a bcp_call condition, must be treated like the *folded* version of the selected half of the expression, since __builtin_constant_p tests constancy of the folded version. If __builtin_constant_p accepts (0 && foo()) as constant then this needs to be accepted in the selected half of the initializer. And for optimal handling of the use case for this use of __builtin_constant_p (in particular, detecting constant insn conditions when building GCC), such expressions as (0 && foo()) should be accepted as constant by __builtin_constant_p (0 may have been a macro expansion of TARGET_64BIT or similar). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38433] Incorrect handling of line termination character with trailing spaces
--- Comment #2 from joseph at codesourcery dot com 2008-12-07 00:28 --- Subject: Re: New: Incorrect handling of line termination character with trailing spaces On Sat, 6 Dec 2008, eric dot niebler at gmail dot com wrote: > In the attached file, there is a comment terminated with a line-termination > character (\) followed by spaces. This should NOT be considered a line > terminator, yet gcc considers it as such. From 2.1/2 in the C++03 standard: > > "Each instance of a new-line character and an immediately preceding backslash > character is deleted, splicing physical source lines to form logical source > lines." This (removal of such spaces) is part of how GCC defines the implementation-defined mapping in translation phase 1. There are no input files that GCC interprets as representing a program that enters phase 2 with backslash-space at the end of a line. > That is, only backslashes immediately followed by a newline are considered > line > terminators. The existing behavior of gcc violates the standard and conflicts > with the behavior of other popular C++ compilers (EDG, MSVC). No, it conforms to the standard but does not allow certain programs to be represented. (I think this is a bad idea, but that's another matter.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #8 from joseph at codesourcery dot com 2008-12-08 21:00 --- Subject: Re: dead link on onlinedocs/gccint/Top-Level.html On Mon, 8 Dec 2008, steven at gcc dot gnu dot org wrote: > Well, I can't even find this paragraph you want to reference. The reference is to a whole manual (etc/configure.texi in the src repository), not to one paragraph. > And I was under the impression that there was a kind-of "you broke it, you fix > it rule" with GCC bugs. Am I wrong or does this just not apply to you? There is no such rule beyond the limited reversion rule in develop.html. As explained, this is a missing website feature, not a GCC bug. The link in the manual is a correct link in the global namespace for Texinfo manuals. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #10 from joseph at codesourcery dot com 2008-12-09 13:40 --- Subject: Re: dead link on onlinedocs/gccint/Top-Level.html On Tue, 9 Dec 2008, steven at gcc dot gnu dot org wrote: > [EMAIL PROTECTED] ??? This manual is apparently not available online. Keep > the cross But it is online - http://www.airs.com/ian/configure/ - and while that's not a makeinfo --html copy, when it's only linking to the manual as a whole that doesn't matter much (a single redirect in .htaccess should suffice - and the fix being such a redirect is why I say this is a web problem not a manual problem). I believe the description of how multilibs are built is still relevant, although no-one has updated that manual to reflect toplevel autoconfiscation. If the assignment issues were resolved (that manual has a Cygnus copyright notice) then it might make sense to move the multilib documentation into the GCC documentation and remove the reference to this old manual. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #7 from joseph at codesourcery dot com 2008-12-12 00:01 --- Subject: Re: New: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Thu, 11 Dec 2008, whaley at cs dot utsa dot edu wrote: > I notice that gcc does not follow the 32-bit ABI for the x86, in that it > forces > the stack alignment to 16 bytes rather than the ABI-required 4 bytes. This is > a problem when interacting with compilers that are ABI-compliant. I suppose that by "32-bit ABI for the x86" you mean a document with 1990-1996 SCO copyrights. This document should be considered of only marginal relevant to current systems; it may have described an ABI for some particular system that is now obsolete, but is not an accurate description of (for example) the ABI used on IA32 GNU/Linux, which is a de facto ABI with no written document corresponding precisely. <http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1> (and the messages linked from it) is a description of this area of the de facto ABI. In principle GCC's documentation should for all target systems give a description of the ABI it is intended to implement for those systems with links to relevant documents and descriptions of how the ABI deviates from those documents. In practice, it does not, but it is still the case that just because there exists a document claiming to be a psABI for a particular processor does not mean that GCC follows it or that it would be correct for GCC to follow it. The older the document, the less likely it is relevant; some ABIs such as x86-64 are actively maintained (meaning that defects in the ABI document may be fixed - a disagreement between implementations and documents may be concluded to be a defect on either or both sides) while others are not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #10 from joseph at codesourcery dot com 2008-12-12 01:25 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Fri, 12 Dec 2008, whaley at cs dot utsa dot edu wrote: > >I suppose that by "32-bit ABI for the x86" you mean a document with > >1990-1996 SCO copyrights. > > I was going by the linux standards base, which still links to: >http://www.caldera.com/developers/devspecs/abi386-4.pdf > which I believe is still the current official ABI of Linux. > > >This document should be considered of only marginal relevant to current > >systems; it may have described an ABI for some particular system that is > >>now obsolete, but is not an accurate description of (for example) the ABI > >used on IA32 GNU/Linux > > I thought that was precisely what the linux standards base was, and it says > word (4-byte) alignment of the stack. LSB is not of much practical relevance to Linux ABIs and is not maintained by the people who are actually familiar with those ABIs. That's apart from all the other problems with it as mentioned e.g. at <http://udrepper.livejournal.com/8511.html>. LSB may be a starting point for plausible hypotheses about the ABIs, but you need to evaluate it critically to see whether each statement is actually an accurate description of fact. For another example, on 32-bit Power Architecture it references a 1995 Sun document - maybe that was right for PowerPC Solaris in 1995, but as a member of the Power.org working group preparing a document intended to describe the actual current ABI I can confidently say the 1995 document is substantially misleading regarding the true GNU/Linux ABI in use today. > >which is a de facto ABI with no written document corresponding precisely. > > This is a link where people mention that fact that gcc is behaving > non-standardly, so people who want to interoperate with gcc better adopt their > non-standard behavior. How do you like it when MS does that? It seems > incredibly foolish to me that just because gcc doesn't want to do some trivial > bit twiddling in the function prologue, you've decided to break the ABI, all > so > that you can lose performance when people need ABI compliance, as well as > making interoperation much harder for everyone. I would fully expect that the ABI for working with Windows is that used by the present MS compilers and libraries, and if the only ABI documents available are 12 years old (I haven't looked) I would consider them of limited relevance for determining the current Windows ABI. The Power.org ABI working group has been going now for two years. Producing an accurate current ABI document where one hasn't been maintained for over a decade is a lot of work. If done for IA32 GNU/Linux I fully expect it would document that the ABI has 16-byte stack alignment. And if some disagreement between code and ABI document were found after such a document were written, the fix might well be to change the document rather than the code. Effectively, decisions such as the 16-byte alignment one have been made over the years, probably many times, that the documentation rather than the code should be changed - and unless and until there is a major effect to create a new ABI document, all those documentation changes are hidden and queued up and not collected in one place. But each such decision is one that the bug is in the document not the code. And the decision about where the bug lies is not substantially influenced by whether the document can in fact be changed or not. See also Linus's recent comments <http://lkml.org/lkml/2008/12/1/387>. The "wrong documentation is irrelevant" applies equally here. The SCO ABI is wrong documentation when Linux in 2008 is concerned, even if it was right for SCO Unix in 1996. If it is the ABI for any system, Linux in 2008 is not that system, and when looking at it you always need to be aware that it describes not the Linux ABI but one with some vague similarities to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #12 from joseph at codesourcery dot com 2008-12-15 00:21 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Fri, 12 Dec 2008, whaley at cs dot utsa dot edu wrote: > >LSB may be a starting point for plausible hypotheses about the ABIs, but > >you need to evaluate it critically to see whether each statement is > >actually an accurate description of fact. > > I.e., you are saying "we don't adhere to any standards: whatever we do is the > standard". Again, I wonder how you feel about that attitude when microsoft No; "The nice thing about standards is that there are so many to choose from" is a well-known saying. GCC chooses certain standards and documents those choices in the manuals. For the >99.% of standards not documented as being used by GCC, you should not assume they have been chosen, or that they are of any more relevance to GCC than the standard for making a cup of tea. Not choosing to implement a standard is not a bug - GCC does not make tea - though you might have a feature request to implement a new feature where a particular standard is followed. You are free to procure software on the basis of which of many standards it chooses to implement and how accurately it does so; if producers of compilers that do not make tea find that compilers making tea are more widely used because they make tea, this may cause the tea-making feature to be added to more compilers. Anyone can write a document that says anything and put any title on it. Anyone else can write a contradictory document with the same title and claim that document instead is the true standard. That someone has written such a document gives it no special status for GCC whatever. There is nothing magical about being a "standard"; it's just another document describing something that may or may not be useful, may or may not describe something a particular piece of software aims to implement, and may or may not describe what a particular piece of software does implement. If multiple implementations choose to try to implement the same document, or if it has been prepared to match what implementations do, it may then be of use in describing how to interoperate with those implementations. If it was written to describe how someone wishes things would work but they don't work that way, any influence they have to change how things work will have to come from a source other than that they have written down their wishes and put the word "standard" wishfully on them. > says it? Would you like to argue that ODF is useless, since MSOffice binary > formats are more accurate description of fact? I don't like it when MS ODF is useless for interoperating with MS Office if MS Office does not choose to use that standard for interoperation. That's obviously a choice for the MS Office maintainers. Anyone can invent a document format, write a description and call that description a standard, but writing the description doesn't make it any more or less appropriate for MS Office to implement the format. Where OOXML differs from the formats in fact used by MS Office, this may very well be a bug in the specification, whose only use is likely to be interoperating with MS Office. If all implementations of ODF do the same thing which contradicts the literal text of ODF, that is likely to be a bug in the specification as well, since the text is not serving the purpose of interoperation. > kind of boggles my mind. If a standard is out of date, you write a new > standard, or admit you are violating it in certain respects, not make the > absurd claim that whatever you happen to like doing this week is the standard. GCC's manuals "violate" the ODF specification you mentioned above by being in Texinfo. This is not a bug; it's simply there are millions of "standards" and almost all are more or less completely irrelevant to GCC. GCC no longer supports SCO Unix, so even if the document you like was an accurate description of how to interoperate with SCO Unix versions from 1996 that does not make it relevant to GCC. Anyone with the person-years to spend is free to write their own "new standard" describing what they think a particular ABI should be. There is no particular reason for anyone else to care about that document unless it reflects reality or there is a genuine commitment from multiple involved parties to implement the document where it describes something different from reality. That might apply, for example, if direction comes from the CPU vendor with agreement of multiple involved parties (c.f. the ARM EABI, or the Power.org effort I mentioned); maybe those producing x86 processors would like to coordinate the person-years of effort needed either to write a specification accu
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #8 from joseph at codesourcery dot com 2008-12-15 00:31 --- Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression I also added more __builtin_constant_p tests (gcc.dg/bconstp-[34].c) to c-4_5-branch, following this discussion, to verify more of the model for how __builtin_constant_p works in constant expressions. In general the constant expressions tests there (both those added there, and the previously existing constant expressions / overflow diagnostics tests, most of which have had XFAILs removed on the branch) reflect my interpretation for the GNU C language of both the standard constant expressions rules where unclear and of how the rules should be applied to new language features in GNU C that aren't in ISO C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #14 from joseph at codesourcery dot com 2008-12-15 18:17 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote: > And also one without application here. I am aware of no other standard for > Linux ABI other than the one in the linux standard base. Gcc did not choose > another standard, it violated the one and only existing standard. I am not GCC chose to change the *unwritten* standard for the ABI in use for IA32 GNU/Linux. The LSB is not a plausible candidate for a written standard for that ABI; the set of such candidates is presently empty. Maybe if there were a document supported by relevant stakeholders then it would be of value to follow it, but the LSB doesn't have that support (see also Ulrich's comments); it is effectively an attempt by third parties to observe the ABI and document their imperfect observations. Just because no-one has written a useful standard document in a particular area does not mean a document that is not presently useful or accurate should be followed. The ABI is undocumented; that is reality. LSB is a good-faith attempt to document it, but for LSB to be useful for its intended purpose it needs to keep playing catch-up with reality. The SCO document may have been useful before SSE, but processor architecture and language developments have made it problematic for many years. The set of ABI standards suitable for use on IA32 GNU/Linux has been empty for many years. For it to cease to be empty a document would need to be written that reflects reality and there would need to be long-term commitment from many interested parties to keep the document and the implementation in sync in future. (A document that does not reflect reality would require even more commitment, to make an incompatible break from previous ABIs in use to move to a newer cleaner ABI.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #20 from joseph at codesourcery dot com 2008-12-16 00:09 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote: > If you thought the standard adopted by LSB was the wrong > one, you should have participated in the process and fixed it. Nonsense. It's not the responsibility of the GCC community or any of its members to correct the misconceptions of any or all third parties, and never had been. There is no more responsibility to correct LSB's mistakes than to correct misconceptions about the ABI written in a random webpage, student project or magazine article. Both have exactly the same status as irrelevant to GCC unless and until GCC chooses to treat them as relevant. Millions of people write huge amounts of inaccurate information about things they don't understand and those who understand them have no responsibility to correct the information; the LSB and the IA32 GNU/Linux ABI is just one random such case among millions, with no special status. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug c++/38617] ICE passing fixed point to function
--- Comment #5 from joseph at codesourcery dot com 2008-12-24 17:28 --- Subject: Re: ICE passing fixed point to function On Wed, 24 Dec 2008, pinskia at gcc dot gnu dot org wrote: > x86_64 does not support fixed point modes at all. Someone needs to come up > with an ABI for it. If the user configured with --enable-fixed-point on a target not supporting it (i.e. anything other than MIPS) then they should expect ICEs; they should only configure that way when working on adding the support. If they didn't configure with that option the compiler should give sensible errors rather than ICEs. I don't know which is the case here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38617
[Bug target/38617] ICE passing fixed point to function
--- Comment #9 from joseph at codesourcery dot com 2008-12-24 18:01 --- Subject: Re: ICE passing fixed point to function On Wed, 24 Dec 2008, hjl dot tools at gmail dot com wrote: > I verified that there is > > auto-host.h:#define ENABLE_FIXED_POINT 0 > > But I still got ICE: Then the bug is in one or both front ends: a missing targetm.fixed_point_supported_p call, or a failure to act appropriately on the results of such a call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38617
[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm
--- Comment #3 from joseph at codesourcery dot com 2009-01-02 17:35 --- Subject: Re: testsuite __gnu_mcount_nc link error when profiling on arm On Fri, 2 Jan 2009, laurent at guerby dot net wrote: > I could not find a GLIBC 2.8 release in http://ftp.gnu.org/gnu/glibc/ > nor in ftp://sources.redhat.com/pub/glibc/releases/ > do you know if it has been formally released? glibc no longer releases tarballs, only CVS tags. The current release is 2.9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
[Bug c++/38725] [4.4 regression] ICE with goto
--- Comment #3 from joseph at codesourcery dot com 2009-01-05 05:05 --- Subject: Re: [4.4 regression] ICE with goto This being accepted for C is bug 32122. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38725
[Bug c++/35711] bad text in -Wcast-qual warning (forgets volatile)
--- Comment #10 from joseph at codesourcery dot com 2009-01-07 15:34 --- Subject: Re: bad text in -Wcast-qual warning (forgets volatile) On Wed, 7 Jan 2009, ian at airs dot com wrote: > How is it unsafe? All the const qualifier on a pointer means is that the > memory will not be changed through that pointer. http://c-faq.com/ansi/constmismatch.html gives the standard example for why such conversions are unsafe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #5 from joseph at codesourcery dot com 2009-01-13 12:52 --- Subject: Re: [4.2/4.3/4.4 regression] ICE with nested function Does standard Ada allow something like this? If so, there's not much point making it invalid GNU C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug c/27628] Incorrect memory access type used used in accessing bitfields
--- Comment #7 from joseph at codesourcery dot com 2009-01-13 16:39 --- Subject: Re: Incorrect memory access type used used in accessing bitfields On Tue, 13 Jan 2009, frikkie at zitera dot co dot za wrote: > I've submitted patches to bug report 23623 > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623) > that corrects the behavior described in this bug report. If you wish patches submitted to receive any attention, you need to follow the patch submission procedures described at <http://gcc.gnu.org/contribute.html>. Closed bugs, such as the one you've attached the patches to, receive no attention. If you can demonstrate there are problems not fixed by the patch that fixed the closed bug, you should open a new bug with a testcase that shows how it differs from the closed bug, but the patches should still go to gcc-patches as described. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #7 from joseph at codesourcery dot com 2009-01-14 13:49 --- Subject: Re: [4.2/4.3/4.4 regression] ICE with nested function If there is language-independent code that's supposed to handle this extension that doesn't handle anything in any other language, I'd be fine with deprecating and then removing the feature (returning variable-size types from nested functions) from GNU C (unless a lot of users show up after deprecation) - provided it at least isn't used in glibc (which does use some nested functions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #9 from joseph at codesourcery dot com 2009-01-14 15:06 --- Subject: Re: [4.2/4.3/4.4 regression] ICE with nested function If all such calls ICE since 3.4.5 then I think we can just remove the feature (giving an error if a nested function is declared to return a variable-length type). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug c/38929] Optimisation with inline function causes invalid behaviour
--- Comment #5 from joseph at codesourcery dot com 2009-01-21 23:27 --- Subject: Re: Optimisation with inline function causes invalid behaviour On Wed, 21 Jan 2009, rguenth at gcc dot gnu dot org wrote: > You overflow x and y in main() which invokes undefined behavior. Actually, I don't think this is undefined behavior; I think it's the same as bug 35634. There is no arithmetic on int8_t in C; the values are promoted to int (defined), arithmetic is done on int (which doesn't overflow for the promoted values) and if the values are then stored back in int8_t they are converted back (where the implementation-defined conversions are documented, and it's implementation-defined not undefined). But we know in bug 35634 that GCC is wrongly treating increment/decrement of types such as int8_t as having undefined behavior, by not representing the intermediate promotions and truncations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38929
[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #15 from joseph at codesourcery dot com 2009-01-27 13:33 --- Subject: Re: [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 On Tue, 27 Jan 2009, jakub at gcc dot gnu dot org wrote: > I wonder if the libcpp warning is correct in this case for > -std=c99/-std=gnu99, > saying that the constant is too large that it is unsigned doesn't match the > C99 > wording, which says that the constant may have a signed extended type, not I'm not clear what the issue here is supposed to be. Anything that involves a type wider than intmax_t in a program should yield a pedwarn, not just a warning, for C99. That was part of the intended effect of my patch <http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00816.html>. The part for "mode" attributes was lost with <http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00887.html> - since the relevant code is now in c-common.c again, it could be restored. I don't know offhand when the check for integer constants was lost, although I don't see it in c-lex.c. Unfortunately my original patch didn't have testcases for these diagnostics, probably because making them target-independent is hard and we didn't have the effective-target infrastructure back then. > unsigned. For 32-bit HWI, unfortunately I don't see how we could have a > larger > type than 2 * HOST_BITS_PER_WIDE_INT, as there would be no way to represet > TYPE_MIN_VALUE and TYPE_MAX_VALUE. It's very clear to me by now that HOST_WIDE_INT should only depend on the target (probably only on the target architecture), not the host; that's the only way to ensure consistency between hosts for the same target. And so all the cases that really mean something related to the target should use some other name. (There may be cases where the host not the target really is relevant, though there may also be better host types such as size_t to use in some of those cases. Unfortunately there are nearly 5000 uses of HOST_WIDE_INT in the compiler, so a huge task for anyone cleaning this up.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #17 from joseph at codesourcery dot com 2009-01-27 14:55 --- Subject: Re: [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 On Tue, 27 Jan 2009, bonzini at gnu dot org wrote: > > It's very clear to me by now that HOST_WIDE_INT should only depend on the > > target (probably only on the target architecture), not the host; that's > > the only way to ensure consistency between hosts for the same target. > > It wouldn't actually be very hard to do that. I'm almost sure that it would > "just work". > > But the (sub)problem here is that the same target architecture (32-bit i386) > has different HOST_WIDE_INT size depending on whether GCC is a 32-bit > single-arch or a 32-/64-bit bi-arch compiler. My claim is that we should stop doing this: it should always be 64-bit for x86 and ARM, rather than depending on whether the target is biarch (x86) or whether it is EABI (ARM), just as it is for other targets that may or may not be biarch (MIPS, Power, SPARC). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug c/39026] Gcc accepts invalid code
--- Comment #2 from joseph at codesourcery dot com 2009-01-29 20:02 ---
Subject: Re: New: Gcc accepts invalid code
On Thu, 29 Jan 2009, hjl dot tools at gmail dot com wrote:
> inline void foo ();
>
> int
> main ()
> {
> foo ();
> return 0;
> }
> [...@gnu-6 gcc]$ gcc /tmp/i.i -S
If you use -std=c99 -pedantic-errors you get an error, as expected.
You're compiling in gnu89 mode.
If you use -std=c99 without -pedantic-errors you get a duplicate warning:
t.c:1: warning: inline function 'foo' declared but never defined
t.c:1: warning: inline function 'foo' declared but never defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug c/39036] Decimal floating-point exception flags done wrong
--- Comment #6 from joseph at codesourcery dot com 2009-01-30 23:14 --- Subject: Re: Decimal floating-point exception flags done wrong On Fri, 30 Jan 2009, tydeman at tybor dot com wrote: > I consider emulation of decimal FP to be part of the compiler's job. Part of > that emulation is setting the FP execption flags as per IEEE-754-2008. The implementation of decimal FP for the GNU system is partly in GCC and partly in (E)GLIBC (available as patches or an EGLIBC branch). The implementation approach chosen is that the versions of the arithmetic/conversion functions that handle exceptions and rounding modes are included only in the libdfp included with (E)GLIBC, not in libgcc. (Depending on the target, copies of libm functions to handle exceptions and rounding modes may need including in libdfp to avoid a dependency on libm, and this can only be done as part of the libc/libm/libdfp implementation.) So, if you want exceptions and rounding modes support for decimal FP, use an appropriate libc version and link against the associated libdfp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39036
[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor
--- Comment #2 from joseph at codesourcery dot com 2009-05-06 11:09 --- Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote: > Reduced testcase, maybe due to the C const expression changes(?) I see nothing in the reported information about this bug to suggest this (rather than, say, the move of COMPOUND_LITERAL_EXPR handling to language-independent code). What do you think is wrong about the trees being passed by the C front end to the gimplifier? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug testsuite/40050] plugin tests don't work with multilib
--- Comment #1 from joseph at codesourcery dot com 2009-05-06 20:16 --- Subject: Re: New: plugin tests don't work with multilib On Wed, 6 May 2009, hjl dot tools at gmail dot com wrote: > On Linux/Intel64, I got > > Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc > -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -I. > -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite > -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../gcc > -I/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/../../../gcc > -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../include > -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../libcpp/include -I -O > -DIN_GCC -fPIC -shared > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/plugin/selfassign.c > -lm -m32 -o selfassign.so(timeout = 300) > Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc > -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/plugin/self-assign-test-1.c > -fplugin=./selfassign.so -O -S -m32 -o self-assign-test-1.s(timeout = > 300) > cc1: error: Cannot load plugin ./selfassign.so^M > ./selfassign.so: cannot open shared object file: No such file or directory^M > > I think LD_LIBRARY_PATH was set to multilib path. But for this case, > it should be set to the current dir. I read the problem differently. I presume -m32 are your multilib flags. It looks like both the plugin and the code being built with a compiler loading the plugin have been built with the multilib flags, and the error is because a 64-bit compiler ignores a 32-bit plugin. Plugins must never be built with multilib flags; they must be built with the *host* compiler, and while that's the same compiler as the target compiler in the native case, they must still not use the multilib flags because those won't generally be compatible with the compiler binary. The second compilation, the only loading the plugin, is the one that should keep using the multilib flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40050
[Bug c/40065] spurious format string warnings
--- Comment #3 from joseph at codesourcery dot com 2009-05-08 10:19 --- Subject: Re: spurious format string warnings On Fri, 8 May 2009, pinskia at gcc dot gnu dot org wrote: > is happening here, it is assuming %qE does not take an argument). I don't see > an issue really except you really should be compiling a cross compiler with > the > same version as you are building. I thought that was mentioned somewhere too. There is no such requirement (save maybe to some extent for Ada), it's just that you may get extra warnings using another version, or in stage 1 of a bootstrap (which deliberately does not use -Werror). It's the build-x-target compiler when build != host that must be the same version as the host-x-target compiler you are building, not the build-x-host or build-x-build compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40065
[Bug target/40130] rint from gcc.c-torture/execute miscompiled with -march=i486
--- Comment #3 from joseph at codesourcery dot com 2009-05-13 16:50 --- Subject: Re: rint from gcc.c-torture/execute miscompiled with -march=i486 On Wed, 13 May 2009, ubizjak at gmail dot com wrote: > Adding -ffloat-store also fixes these failures. ieee.exp already uses -ffloat-store on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug c/40065] spurious format string warnings
--- Comment #5 from joseph at codesourcery dot com 2009-05-14 12:01 --- Subject: Re: spurious format string warnings On Thu, 14 May 2009, bje at gcc dot gnu dot org wrote: > Andrew wrote: > > "GCC can assume %qE means anything from just printing E in quotes" > > Can you explain this? Is it really the case that the format specifier can > have > an optional argument? This is not a meaningful question. There are no limits on the possible semantics of a format string; a variadic function can apply arbitrary Turing-complete computations to its fixed arguments to determine the types of the variable arguments, and to the first N variable arguments to determine the type of argument N+1. GCC can only warn about strings not following the rules for a particular type of format that were built into GCC; if you compile code with a string intended for different, newer rules, as here, it cannot have any idea what the newer rules are and thus whether %E takes no arguments (like %%), one, two or more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40065
[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.
--- Comment #2 from joseph at codesourcery dot com 2009-05-19 16:15 --- Subject: Re: No rule to make target `proto', needed by `native'. Stop. protoize and unprotoize were removed in 4.5 having been deprecated in 4.4 - either some reference did not get removed, or an old build command is still being used that referenced them. The commands used to configure and build GCC seem more relevant here than the English error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40198
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
--- Comment #6 from joseph at codesourcery dot com 2009-05-22 10:22 ---
Subject: Re: exception propagation support not enabled
in libstdc++ 4.4 on {armeabi,hppa}-linux
On Fri, 22 May 2009, mikpe at it dot uu dot se wrote:
> Created an attachment (id=17900)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17900&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17900&action=view)
> put ARM EABI atomic builtins in both shared and static libgcc
>
> I reviewed the original ARM EABI atomic builtins code submission, and there
> was
> no indication that making this code static-libgcc only was anything but an
> accident. The attached patch makes the code available in both the shared and
> static libgcc. With this patch and r147123 reapplied to my gcc-4.4 tree the
> libstdc++ build now finds the atomic builtins as it should:
This patch is obviously wrong - if you put things in shared libgcc you
also need to assign symbol versions to them based on the version in which
they were actually added. I'm pretty sure making them static-only was
deliberate (following SH which defines all the functions as hidden, which
has the same effect as making them static-only, for example); the overhead
of PLT calls is going to be significant for such small functions.
Since the patch doesn't stop the functions being hidden in linux-atomic.c,
I doubt it actually works (the question is not configure finding them, but
whether C++ shared libraries that use them link OK with -shared-libgcc).
The only use of having these functions in shared libgcc while still hidden
is if other functions in libgcc use them.
Now, I see that SH has libgcc/config/sh/t-linux which makes libgcc_s.so a
linker script rather than a symlink. It's possible this could help for
ARM, but on the whole I think it would be better for -shared-libgcc to use
the static libgcc as needed after the shared one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug target/40236] i386: request a single option to turn off all instructions which can cause #TS
--- Comment #5 from joseph at codesourcery dot com 2009-05-29 09:42 --- Subject: Re: New: Request a single option to turn off all instructions which can cause #TS This sounds very much like the long-requested -fno-implicit-fp / -mno-implicit-fp option. We have an implementation of this at CodeSourcery (target-independent parts and some target-dependent parts) but I'm not sure there was ever any consensus on the acceptability of some form of this option for FSF GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40236
[Bug driver/40251] Using the -V option makes the compiler to exit with 0 exit code on error
--- Comment #2 from joseph at codesourcery dot com 2009-05-29 10:06 --- Subject: Re: New: Using the -V option makes the compiler to exit with 0 exit code on error The pexecute interface returns a status value from waitpid from the driver executed with -V, and gcc.c then passes this to exit () without passing it through WEXITSTATUS or similar first, so it calls exit (256) which loses the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40251
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #10 from joseph at codesourcery dot com 2009-06-06 22:22 --- Subject: Re: [4.5 regression] ICE with __complex__ double On Sat, 6 Jun 2009, hjl dot tools at gmail dot com wrote: > That is why we shouldn't close a bug report without checking > in a testcase. Closing a branch is already a full day's work without adding checking for testcases on trunk and adding them as needed to the mix. I advise adding them at the point of asserting that the bug is fixed on trunk rather than the possibly much later point of closing the bug when all earlier branches are closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #4 from joseph at codesourcery dot com 2009-06-08 09:40 ---
Subject: Re: GCC defines UNICODE instead of _UNICODE
for -municode
On Mon, 8 Jun 2009, ktietz at gcc dot gnu dot org wrote:
> to define UNICODE is absolutely correct. The define _UNICODE is fiction (but I
UNICODE is in the user's namespace; it should not be predefined if
flag_iso (if you have to use specs rather than hooks, you need
%{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance
options). We should not add to the instances of bug 545 that are still
present. If the MinGW headers use a macro in the user's namespace as a
feature test macro of some sort, they are buggy and should be fixed (with
fixincludes if necessary for existing installations).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready
--- Comment #7 from joseph at codesourcery dot com 2009-06-09 17:42 --- Subject: Re: CLooG header files are not -Wc++-compat ready On Tue, 9 Jun 2009, spop at gcc dot gnu dot org wrote: > 2009-06-09 Sebastian Pop > > PR bootstrap/40103 > * graphite.c: Remove pragma GCC diagnostic warning "-Wc++-compat". I think you should allow more time for people to update after preparing a fixed tarball for the infrastructure directory; won't this have broken bootstrap for everyone using any existing cloog-ppl release tarball (as referenced in install.texi on trunk)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40103
[Bug c/40390] possible integer wrong code bug
--- Comment #1 from joseph at codesourcery dot com 2009-06-09 18:34 ---
Subject: Re: New: possible integer wrong code bug
On Tue, 9 Jun 2009, regehr at cs dot utah dot edu wrote:
> reg...@john-home:~$ cat foo.c
> #include
>
> int foo(int y)
> {
> return (((unsigned short)y*(unsigned short)-2)>=(y?0:y));
This involves a signed integer overflow, 65534*65534. -Wstrict-overflow=3
warns you about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40390
[Bug middle-end/40393] cos gets replaced by sincos somehow, which doesn't exist on system
--- Comment #2 from joseph at codesourcery dot com 2009-06-10 00:58 --- Subject: Re: New: cos gets replaced by sincos somehow, which doesn't exist on system On Tue, 9 Jun 2009, thekevinday at gmail dot com wrote: > When I compiling lcms or ncurses I get: undefined reference to `sincos' > uClibc-0.9.28.3 or uClibc-0.30.1 > GCC build triplet: i686-pc-linux-gnu > GCC host triplet: i686-pc-linux-gnu > GCC target triplet: i686-pc-linux-gnu i686-pc-linux-gnu is not correct for a uClibc system; you should be using i686-pc-linux-uclibc. linux.h correctly defines TARGET_HAS_SINCOS to (OPTION_GLIBC) to disable use of sincos if you have a toolchain correctly configured for uClibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40393
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #1 from joseph at codesourcery dot com 2009-06-15 01:01 --- Subject: Re: New: Option -I and POSIX conformance (c99 utility) On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote: > As you can see, there is a difference for standard system include directories, > for which the option is ignored. This sounds like it is mainly a defect in POSIX; it should make it undefined behavior if you pass a -I option pointing to any directory that contains a file with the same name as any standard header (recall that standard headers do not need to correspond to physical files with the same name). Changing the search order of system directories is clearly liable to break any implementation that deliberately has more than one file of a name for some reason (maybe GCC's limits.h and glibc's version can cope with either order of inclusion, but I see no reason for a requirement for implementations to follow that), and pointing to a user's own file with the same name as a standard header is bound to cause breakage. C99 has such an undefined behavior rule in 7.1.2#3; POSIX just needs to extend it to the POSIX system headers as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #3 from joseph at codesourcery dot com 2009-06-15 10:57 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> This may be true for standard headers, but system directories don't contain
> only standard headers: in practice, they generally also contain additional
> libraries. And for instance, a -I/usr/include can be useful to override
> headers/libraries installed in /usr/local/{include,lib}.
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those directories, for example),
you are very definitely outside the scope of POSIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #5 from joseph at codesourcery dot com 2009-06-15 13:06 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> --- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
> (In reply to comment #3)
> > If you have modified the implementation (by putting headers/libraries in
> > standard directories where those headers/libraries were not provided by
> > the implementation in those versions in those directories, for example),
> > you are very definitely outside the scope of POSIX.
>
> I'm not sure I understand what you mean. But the existing practice is that
> additional headers/libraries (i.e. not those defined by the C standard)
> provided by the vendor are stored under /usr/{include,lib}. And I don't think
> this goes against POSIX. Concerning /usr/local, the FHS says:
>
> The /usr/local hierarchy is for use by the system administrator when
> installing software locally.
>
> So, it should be safe to add libraries there. And again, this is the existing
> practice.
It is not, however, safe to add libraries there that in any way conflict
with the libraries provided by the system in /usr (such as different
versions of the same libraries).
A POSIX-conforming system should have a POSIX conformance document that
explains the circumstances under which the claims of POSIX conformance are
made. Those circumstances will include restrictions on any modification
of system directories, such as limits on the contents of files in /etc for
the system to be conforming and limits on what may go in /usr/local if
some POSIX applications search that directory by default. This document
is nothing to do with GCC on its own; it has to be provided by the system
integrator and describes properties of the whole system. If the document
for the POSIX system you are using is inadequate, you should raise that
with the system integrator (and if necessary with whoever certified
conformance). And if POSIX does not render undefined options that have
the effect of changing internal configuration details of applications,
where those details have to be in a particular form for conformance (for
example, conformance requiring header and library directories in a
particular order), this is a bug in POSIX. -I or -L options pointing to
any of an implementation-defined set of system directories, or any
directory with duplicates of headers or libraries in system directories,
should be undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug target/28763] sizeof() and __attribute__ broken with bit-fields on ppc-eabi
--- Comment #13 from joseph at codesourcery dot com 2009-06-16 17:26 --- Subject: Re: wrong size of struct with some bit-fields on ppc-eabi On Tue, 16 Jun 2009, mcvick_e at iname dot com wrote: > Furthermore, as stated numerous comments back with a link to the actual PPC > ABI, bitfields are to have a 32-bit alignment period. Are you implying that There's no point in quoting an ABI document when you have chosen to use an option (-mno-bit-align in the original bug report) whose sole purpose is to deviate from the ABI. Or when you are using features such as attributes that are outside the scope of the ABI document (which is an ABI for ISO C). In fact I can only reproduce the described symptoms with -mbit-align, not -mno-bit-align - it appears the handling of this option may have been broken in the conversion to .opt files, which would be a genuine regression. The default, without ABI-breaking options, is that both have size 8, which is in accordance with the latest ABI draft being developed in the Power.org ABI working group. That is, the default behavior (for the original case without attributes) is correct, but the option that gives the size being 6 should be -mno-bit-align not -mbit-align, and this appears to have been broken since 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/28763] sizeof() and __attribute__ broken with bit-fields on ppc-eabi
--- Comment #15 from joseph at codesourcery dot com 2009-06-16 20:03 --- Subject: Re: sizeof() and __attribute__ broken with bit-fields on ppc-eabi On Tue, 16 Jun 2009, mcvick_e at iname dot com wrote: > Thanks for the update. I finally feel as though this is getting some teeth. > I > don't know what the default behavior of the 4.3.2 compiler is, however the > command line that I used to invoke this behavior excluded any bit-align > directives to the compiler. the only flags specified were: -O2 -mtune=603 > -mstrict-align -nostdlib -mcpu=603. There are several different testcases in this bug report. Please make clear exactly what code you compiled with those options and that compiler version, what you observe about the compiler output that you think is wrong, what you think it should be and how the compiler was configured. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/40463] linux-eabi.h:79:36: error: identifier "not" is a special operator name in C++
--- Comment #2 from joseph at codesourcery dot com 2009-06-17 10:13 --- Subject: Re: linux-eabi.h:79:36: error: identifier "not" is a special operator name in C++ On Wed, 17 Jun 2009, ramana at gcc dot gnu dot org wrote: > Could you specify which version of the source tree this was ? This is trunk, version 147956 or later. Using not_used instead of "not used" would suffice to fix this, but the -Wc++-compat warning probably should be smarter; there's no need to care about the expansions of unused macros like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40463
[Bug c/40474] gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2)
--- Comment #2 from joseph at codesourcery dot com 2009-06-17 13:35 --- Subject: Re: New: gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2) On Wed, 17 Jun 2009, rlerallut at free dot fr wrote: > When compiling a C or C++ program with gcc 4.3 (and 4.4), there is no longer a > warning about "no newline at end of file". This is deliberate; see bug 14331. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40474
[Bug c/40474] gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2)
--- Comment #4 from joseph at codesourcery dot com 2009-06-17 13:59 --- Subject: Re: gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2) On Wed, 17 Jun 2009, rlerallut at free dot fr wrote: > (In reply to comment #2) > > This is deliberate; see bug 14331. > > Err... What happened to following the standard ? > " > If a source file that is not empty > does not end in a new-line character, or ends in a new-line char- > acter immediately preceded by a backslash character, the behavior > is undefined. > " Behavior being undefined means no requirement for a diagnostic, and the phase 1 mapping can introduce this newline in any case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40474
[Bug c/40474] gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2)
--- Comment #6 from joseph at codesourcery dot com 2009-06-17 14:28 --- Subject: Re: gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2) On Wed, 17 Jun 2009, rlerallut at free dot fr wrote: > And what happened to configuration flags ? Configuration flags to change details of warnings are generally a bad idea. > Why is this change not mentioned in http://gcc.gnu.org/gcc-4.3/changes.html ? That only lists significant changes, not the thousands of minor improvements and bug fixes for which you can search Bugzilla. If the person fixing a PR doesn't feel it's significant enough to mention in the release notes, it won't be listed there. > Or here http://gcc.gnu.org/gcc-4.3/porting_to.html ? Your concern appears to be porting from 4.3 to 4.2, and that page is about porting in the other direction. We don't write documentation for downgrading GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40474
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #3 from joseph at codesourcery dot com 2009-06-17 15:34 --- Subject: Re: -std=c99 does not enable c99 mode in Solaris C library On Wed, 17 Jun 2009, rguenth at gcc dot gnu dot org wrote: > GCC 3.4.x is no longer maintained, please check GCC 4.3.x or newer. It is a matter of straightforward observation of the config/*.h and config/*/*.h files that these files are not linked in. (That they should be linked in was noted on the Austin Group mailing list on 19 March 2005.) sol2.h links in values-Xc.o or values-Xa.o depending on -ansi, which itself is wrong because it doesn't allow for the other spellings of that option (-std=c89, -std=iso9899:1990, or -std=iso9899:199409 for C90 AMD1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #5 from joseph at codesourcery dot com 2009-06-18 21:08 --- Subject: Re: definitions of __builtin_abs() and abs() function in one module not diagnosed What happened to the patch for PR 32455 to disallow __builtin_* declarations? That PR indicates it was approved for 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #6 from joseph at codesourcery dot com 2009-06-18 21:49 ---
Subject: Re: -std=c99 does not enable c99 mode in Solaris
C library
On Thu, 18 Jun 2009, heydowns at borg dot com wrote:
> Was looking at modifying the spec to produce the desired results and
> contribute
> patch, however ran into trouble trying to match options containing literal
> colons (-std=iso9899:199409) in %{S:X} style spec.
>
> Is there a way in the spec language to escape colons? I briefly scanned the
> spec parsing code and nothing jumped out.
>
> If not, is there some other way to match options containing colons (without
> using greedy * matches, since the part after the colon is significant here...)
You may well need to add a new feature to the specs parsing code to deal
with this.
I have some ideas about how option handling, multilib handling and some
aspects of specs should be redesigned, but this issue should not need any
redesign.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug c/40564] Invalid -Wc++-compat warning about stringized C++ operator name
--- Comment #1 from joseph at codesourcery dot com 2009-06-26 22:44 --- Subject: Re: New: Invalid -Wc++-compat warning about stringized C++ operator name A closely related case is: #define foo not used There is no important difference in the meaning of this between C and C++ if the macro is not expanded, so a warning for "not" is inappropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40564
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #9 from joseph at codesourcery dot com 2009-07-04 11:49 --- Subject: Re: -std=c99 does not enable c99 mode in Solaris C library On Sat, 4 Jul 2009, ebotcazou at gcc dot gnu dot org wrote: > > I wasn't sure exactly how to handle the various -std=gnu* modes, so I left > > those as they were. > > Joseph, any recommendations about that? I don't know what the exact effects of linking in these various objects are; whether they select between C90 and C99 behavior where those standards specify conflicting semantics for the same function, or disable Solaris extensions that conflict with the standards, or something else. If it's only selecting between the standards where they conflict, then gnu99/gnu9x should select C99, but gnu99/gnu9x should not generally disable extensions. C++ options for C++0x / GNU-extended C++0x (-std=c++0x, -std=gnu++0x) should probably be treated like those for c99/gnu99, since C++0x uses the C99 library (whereas C++98/C++03 uses the C90+AMD1 library). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug target/40647] 32-bit pointers on 64-bit operating systems
--- Comment #5 from joseph at codesourcery dot com 2009-07-04 11:54 --- Subject: Re: 32-bit pointers on 64-bit operating systems The natural analogy would be with MIPS n32 (an ILP32 ABI for 64-bit MIPS hardware), which also indicates the directory names (/lib32) to use. There would certainly be a lot of work in ABI design, binutils, compiler, glibc and kernel to implement this, but I think such an ABI would be useful. One thing to consider would be whether it would be possible to avoid having three different syscall ABIs (which probably means making the new ABI use the same syscall ABI as LP64 code); the MIPS n32 syscall ABI has been a frequent cause of trouble. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40647
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #10 from joseph at codesourcery dot com 2009-07-15 14:15 --- Subject: Re: -Wconversion: do not warn for operands not larger than target type On Wed, 15 Jul 2009, ian at airs dot com wrote: > Sure, it can wrap, but -Wconversion is not for wrapping warnings. It's for warnings about implicit conversions changing a value; the arithmetic, in a wider type (deliberately or otherwise), does not wrap, but the value gets changed by the implicit conversion back to char. If the user had explicit casts to int in their arithmetic, there could be no doubt that the warning is appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug middle-end/30789] complex folding inexact
--- Comment #2 from joseph at codesourcery dot com 2009-07-26 17:32 ---
Subject: Re: complex folding inexact
The example in this bug deals with excess overflow for division. For
infinities computing as NaN + iNaN, an example is (NaN + iInf) * (NaN
+iInf) (where NaN +iInf is obtained as (__builtin_inf () * (0.0 + 1.0i)))
- this works if computed at runtime but not constant folded. ("Works"
here means that at least one part of the result is an infinity - I do not
believe there is a specific requirement beyond that.)
For division producing NaN + iNaN, (1.0 + 0.0i) / (0.0 + 0.0i) should
produce an infinity, (__builtin_inf () * (0.0 + 1.0i)) / (1.0 + 0.0i)
should produce an infinity, (1.0 + 0.0i) / (__builtin_inf () * (0.0 +
1.0i)) should produce a zero (in which each part may have either sign).
All the above can usefully be tested for both constant folding and runtime
evaluation.
There are also cases for exact rounding where you'd expect MPC to produce
the right results but would *not* expect operations executed at runtime to
produce exactly those results. For example, (1.0 + DBL_EPSILON + 1.0i) *
(1.0 - DBL_EPSILON + 1.0i), which would only work at runtime if the code
happens to use exactly the right fused multiply-add operation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug objc/40864] Designated initializers for multi-dimensional arrays fail in Objective-C
--- Comment #1 from joseph at codesourcery dot com 2009-07-26 21:43 --- Subject: Re: New: Designated initializers for multi-dimensional arrays fail in Objective-C On Sun, 26 Jul 2009, sergei dot yakovlev at gmail dot com wrote: > Designated initializers for multi-dimensional arrays work great in C (C99), > but > fail in Objective-C (see example below). Given that Objective-C is proclaimed > a > strict superset of C, I consider this a bug. This was a property of the old C parser I carefully replicated when writing the new one. I do not know if there exists a C99-based specification of ObjC that clarifies what is intended (and note that this interacts with the old GNU form of designated initializers as well); I took it as given by the implementation at that time. /* ??? Following the old parser, [ objc-receiver objc-message-args ] is accepted as an initializer, being distinguished from a designator by what follows the first assignment expression inside the square brackets, but after a first array designator a subsequent square bracket is for Objective-C taken to start an expression, using the obsolete form of designated initializer without '=', rather than possibly being a second level of designation: in LALR terms, the '[' is shifted rather than reducing designator to designator-list. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40864
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #4 from joseph at codesourcery dot com 2009-07-27 21:02 --- Subject: Re: New: stdarg.h does not define va_copy when building for C89+POSIX On Mon, 27 Jul 2009, bmerry at gmail dot com wrote: > POSIX 2001 specifies that va_copy > (http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is > defined by stdarg.h. However, when compiling with -std=c89 > -D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in > 4.3.2, > but a quick peek in svn makes it look this this is current. POSIX 2001 is based on C99 and does not have any C89 language bindings, so it is not meaningful to say it imposes any requirements when not building in C99 mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug translation/40872] String not extracted for translation
--- Comment #17 from joseph at codesourcery dot com 2009-07-28 11:55 --- Subject: Re: String not extracted for translation On Mon, 27 Jul 2009, manu at gcc dot gnu dot org wrote: > --- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 --- > (In reply to comment #2) > > I tried to look for more similar cases. But I couldn't find anything. Not > > that it is all that easy to search for. Neither "error" nor "?" are > > particularly good search terms. :-) So I may very well have missed > > something. > > Try grep -e ' error ([^"]' gcc/*.c -A 1 > > I am sure you can come up with smart regexp for warning, warning_at, error_at, > inform and the other diagnostic functions. My approach for finding such issues has been to search for '"' and look (manually) in the result for any English strings that are not full diagnostics as the *msgid operand of a diagnostic function. > Care to contribute a patch for this and other cases? I also encourage people wanting such issues fixed to submit patches, and will review such patches (to any part of the compiler) if the more specific maintainers of those parts of the compiler do not review them first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #4 from joseph at codesourcery dot com 2009-07-30 11:24 --- Subject: Re: [4.5 Regression] FAIL: StackTrace2 output - source compiled test On Thu, 30 Jul 2009, aph at gcc dot gnu dot org wrote: > This regression in debuginfo seems to have been downgraded to P4, with no > explanation or discussion of which I'm aware. Java issues are not release-critical. Restore to P3 if you have a C or C++ test showing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #8 from joseph at codesourcery dot com 2009-07-30 16:30 --- Subject: Re: 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch On Thu, 30 Jul 2009, paolo dot carlini at oracle dot com wrote: > As a side note, I want to mention that we are very close to finally fixing > c/448 for 4.5.0. Then, any problem related to will disappear. We're still quite some way from that; I just sent a list of 14 target OSes that either need stdint.h information entered in GCC, or need to be deprecated. (This is down from 20 at the start of April: information has been added since then for Darwin, FreeBSD, HP-UX, Cygwin, MinGW and AIX.) http://gcc.gnu.org/ml/gcc/2009-07/msg00625.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #10 from joseph at codesourcery dot com 2009-07-30 19:28 --- Subject: Re: 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch On Thu, 30 Jul 2009, htl10 at users dot sourceforge dot net wrote: > I can't say about the others alpha*-dec-osf[45]*, but I can certainly give you > alphaev68-dec-osf5.1a . How do you like this info? If you have a list to hunt In the form of a patch submission following the documentation at http://gcc.gnu.org/contribute.html and in particular passing the c99-stdint-* testcases. > See as I seem to be the only one submitting testsuite results for > alpha*-dec-osf[45]* beyond 4.1-ish, what is the qualification/requirement for > OS porter/maintainer to take it off the deprecated list? It's not currently on a deprecation list, but maintainers of parts of the compiler will need to have a copyright assignment on file with the FSF and have submitted sufficient good patches to that part of the compiler to have been made maintainer by the SC. The requirement to avoid deprecation may be less than having a maintainer: monitor test results, send patches to fix issues that arise and other issues (such as this one) that need work for each OS and revise and ping patches as needed to get them in. Personally I think we should eliminate the mips-tdump and mips-tfile programs (which may mean making these targets work properly with the GNU assembler) but I haven't actually made a proposal to deprecate these targets in the absence of elimination of those programs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug tree-optimization/40921] missed optimization: x + (-y * z * z) => x - y * z * z
--- Comment #1 from joseph at codesourcery dot com 2009-07-30 23:45 --- Subject: Re: New: missed optimization: x + (-y * z * z) => x - y * z * z Note that -frounding-math should disable the proposed optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40921
[Bug c/448] -related issues (C99 issues)
--- Comment #21 from joseph at codesourcery dot com 2009-07-31 12:54 --- Subject: Re: -related issues (C99 issues) On Fri, 31 Jul 2009, paolo dot carlini at oracle dot com wrote: > I'm wondering if there is something we can/should do here about C++1x: in the > new Standard (see 18.4.1/2 in n2914, for example), for we have: > > The header defines all functions, types, and macros the same as C99 7.18. [ > Note: The macros defined by are provided unconditionally. In > particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS > (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. end note ] I would suggest predefining those macros in C++1x mode; that should make things work with all existing stdint.h implementations that care about those macros. If you need help beyond that - for example, to ensure that each of and puts things in the right namespaces - then stdint-gcc.h could certainly be adjusted to know about C++ requirements, but systems with their own stdint.h generally only use stdint-gcc.h for freestanding compilations so further help from libc implementors may be needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] -related issues (C99 issues)
--- Comment #23 from joseph at codesourcery dot com 2009-07-31 13:09 --- Subject: Re: -related issues (C99 issues) On Fri, 31 Jul 2009, paolo dot carlini at oracle dot com wrote: > Note, in C++1x, those macros should be effectively predefined *only* when > is included, not when is included. Thus, I agree - note That's not how I read N2914; it appears to say is a strict superset of . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/40951] Type-checking when returning from function missing
--- Comment #1 from joseph at codesourcery dot com 2009-08-03 19:16 --- Subject: Re: New: Type-checking when returning from function missing On Mon, 3 Aug 2009, pratik dot j dot ashar at intel dot com wrote: > Function foo() returns a char to the caller. Running objdump on the compiled > executable shows foo() doesnt do any type-checking before returning to caller, > int main() in this case. foo() returns 0xff00 in eax as opposed to only > 00. > ISO C99 std states and I quote "If a return statement with an expression is > executed, the value of the expression is returned to the caller as the value > of > the function call expression. If the expression has a type different from the > return type of the function in which it appears, the value is converted as if > by assignment to an object having the return type of the function." The link > to > spec is http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1336.pdf. return > semantics mentioned on pg 153. > > This bug does not manifest itself in given code since the caller does > type-checking. We were calling foo() via a JNI bridge. Thats when we traced > this bug. It seems to be unclear what the x86 ABI requires for return values (see bug 32843, and the thread linked from there, for example). This is certainly an ABI (back end) issue and nothing to do with the front ends. Unfortunately there is no committee maintaining the x86 ABI that can reach decisions on unclear issues and old ABI documents are of little value; determining the ABI involves examining what different implementations do. When this was discussed on the ia32-abi group <http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269> the answer was that GCC, ICC and MSVC all treat the upper bits of the return value as undefined, which indicates that that must be treated as the ABI and so your JNI bridge is buggy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40951
[Bug c/40960] POSIX requires that option -D have a lower precedence than -U
--- Comment #4 from joseph at codesourcery dot com 2009-08-04 14:54 --- Subject: Re: POSIX requires that option -D have a lower precedence than -U On Tue, 4 Aug 2009, vincent at vinc17 dot org wrote: > There would the possibility to have a POSIX mode implied by c99, but I don't > think having different behaviors would be a good idea. IMHO, Makefiles should I think that installing a variant driver program as "c99", that implements the different semantics, is exactly the right thing to do here; the present semantics are more useful for "gcc". We should have a configure option to install "cc", "c89" and "c99" drivers; they should have appropriate defaults regarding e.g. standards mode, and should also adjust the precedence of these options and make any other adjustments required by POSIX that aren't appropriate for "gcc". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960
[Bug middle-end/41001] alloca broken for -fno-builtin
--- Comment #2 from joseph at codesourcery dot com 2009-08-07 17:24 --- Subject: Re: New: alloca broken for -fno-builtin On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote: > The function alloca (for cygwin/mingw target _alloca) is broken or not > available (for linux64), when using option -fno-builtin. It is in the nature of alloca that it needs to be built in to the compiler for an effective implementation, and the lack of a library emulation (using malloc) is nothing to do with the compiler. Why do you think there is a bug here? > The linux and win32 targets the symbol alloca isn't present. For windows > targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm > present. But when using this, the stack layout is broken after calling alloca. I do not believe _alloca is meant to be an implementation of the C alloca function; if it was, it would be alloca not _alloca. Do you have any reason to believe _alloca does not follow its specification of making stack space available when called implicitly by the compiler (*not* an explicit C function call - it has its own special ABI so you can't call it explicitly from C)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug middle-end/41001] alloca broken for -fno-builtin
--- Comment #4 from joseph at codesourcery dot com 2009-08-07 22:36 --- Subject: Re: alloca broken for -fno-builtin On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote: > Well, if so. It makes no sense that -fno-builtins tries to call a function > which isn't present. But for other compilers, alloca can be invoked as > function, too. The compiler builtin part in all cases is, to be aware that > stack frame changes (hot-region, call save-area, and co are adjusted after > calling it). -fno-builtin means more or less exactly that the compiler *should not* assume anything special about a function from its name (unless the name starts __builtin or some similar reserved-namespace cases such as __sync) - that is, you declare alloca and because of -fno-builtin the compiler assumes this is your own function with no special semantics whatever. By -fno-builtin you are declaring that alloca, and all other normally built-in functions, are normal functions with no special semantics the compiler needs to know about. So of course it generates a call like it would to any other random function you might have defined in another translation unit. If you want to use alloca with its traditional memory allocation semantics with -fno-builtin, you'll need to use a malloc-based emulation such as that in libiberty, not something that uses the stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug middle-end/41001] alloca broken for -fno-builtin
--- Comment #7 from joseph at codesourcery dot com 2009-08-08 10:37 --- Subject: Re: alloca broken for -fno-builtin On Sat, 8 Aug 2009, ktietz at gcc dot gnu dot org wrote: > Well, IMHO it is the same for alloca, as for setjmp, or longjmp. Even some > code > for detecting alloca semanices is present (in a slightly broken way), see > calls.c (special_function_p). > So, if it is really the intention that by -fno-builtin all function have > standard calling convention, then this special cases in calls.c would be a > bug. I consider that those cases should be handled through attributes on built-in functions and in standard headers (added where necessary to those headers through fixincludes), rather than in special_function_p (which should go away); see at the bottom of <http://gcc.gnu.org/projects/beginner.html>. (It is not valid to use setjmp/longjmp without including the standard header, so failing if it is not included and -fno-builtin is used would be fine.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001
[Bug other/19165] (Natural) language independent error / warning classification
--- Comment #11 from joseph at codesourcery dot com 2009-08-08 16:33 --- Subject: Re: (Natural) language independent error / warning classification On Sat, 8 Aug 2009, manu at gcc dot gnu dot org wrote: > I am not planning to work on this further. This patch shows that it can be > done, but I don't know if there is any interest on this. The principle makes sense (obviously the prototype patch would need further work for actual inclusion, e.g. escaping of < and > signs for the XML output), but I think in practice it's only useful if driven by cooperation from IDE people who will help establish what the XML should look like and commit to making an IDE use the XML output in future by default when using a GCC version that supports it. I imagine that the XML should have some way of marking continuation messages as such, should include the option (as from -fdiagnostics-show-option) in some structured way, and probably should give locations and inclusion context in an XML structured way as well rather than as plain text - but discussion would be needed with IDE people on what information GCC can give and how an IDE could use it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
[Bug middle-end/30789] complex folding inexact
--- Comment #4 from joseph at codesourcery dot com 2009-08-13 01:25 --- Subject: Re: complex folding inexact On Wed, 12 Aug 2009, ghazi at gcc dot gnu dot org wrote: > > > --- Comment #3 from ghazi at gcc dot gnu dot org 2009-08-12 22:28 --- > (In reply to comment #2) > > Joseph - Thanks for your reply and testvalues. > > > There are also cases for exact rounding where you'd expect MPC to produce > > the right results but would *not* expect operations executed at runtime to > > produce exactly those results. For example, (1.0 + DBL_EPSILON + 1.0i) * > > (1.0 - DBL_EPSILON + 1.0i), which would only work at runtime if the code > > happens to use exactly the right fused multiply-add operation. > > What is the "right result" for this case? GCC with MPC produces: > -4.93038065763132378382330353301741393545754021943139377981e-32 + 2.0i) > > Unpatched GCC as well as the runtime on my x86_64 box says: > 0.0 + 2.0i > > So the runtime here is not using the fused instruction? > > Is the MPC value correct? It looks correct. You expect real part -DBL_EPSILON*DBL_EPSILON, imaginary part 2.0. I believe existing x86_64 hardware does not have fused multiply-add instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error
--- Comment #5 from joseph at codesourcery dot com 2009-08-13 12:23 --- Subject: Re: Warning "cannot pass objects of non-POD type" should be an error On Thu, 13 Aug 2009, redi at gcc dot gnu dot org wrote: > I don't know about C, but C++ says: > > "permissible undefined behavior ranges from ignoring the situation completely > with unpredictable results, to behaving during translation or program > execution > in a documented manner characteristic of the environment (with or without > the issuance of a diagnostic message), to terminating a translation or > execution (with the issuance of a diagnostic message)." [defns.undefined] > > So it is permissible to terminate translation and issue a diagnostic. You have to read the relevant standard text carefully to determine whether it is the program that is undefined, or a particular execution of the program, in this particular instance of undefined behavior. If the undefinedness is a property of the program (for example, ODR violation), translation may be terminated. If the undefinedness is a property of a particular execution of the program (for example, signed integer overflow), translation may not be terminated unless all possible executions of the program exhibit that undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #2 from joseph at codesourcery dot com 2005-11-09 18:09 --- Subject: Re: gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32 On Wed, 9 Nov 2005, jakub at gcc dot gnu dot org wrote: > Works just fine here. What glibc are you using? > pr24428.c and pr24428-2.c are the only dg-do run tls tests, so perhaps > your libc doesn't support TLS at all? The tests changed from failing to working on my (CodeSourcery Automatic Testing System) nightly builds when I switched them from running on an i686-pc-linux-gnu system to running on an x86_64 system (with more recent libc), bootstrapping with an i686-pc-linux-gnu cross-compiler and configuring with --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu; that is, the same compiler version failed under the pure 32-bit environment but passed when building as 32-bit under a 64-bit kernel (with more recent libc), and this was the only change in test results between the two environments apart from gcc.misc-tests/linkage.c which tries to link with programs built with "cc". Both environments have some form of glibc 2.3.2; it's quite possible the older one doesn't support TLS. If the state of "libc doesn't support TLS" can reliably be detected then perhaps the test should be marked UNSUPPORTED in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #4 from joseph at codesourcery dot com 2005-11-12 14:24 ---
Subject: Re: gcc.dg/tls/pr24428.c execution test and
gcc.dg/tls/pr24428-2.c execution test fail on IA32
On Thu, 10 Nov 2005, jakub at gcc dot gnu dot org wrote:
> Does even a trivial __thread using program break fail at runtime?
> __thread int thr;
> int main (void) { return thr; }
Yes, it segfaults on the system in question; it also seems to segfault
with more recent glibc configured with --without-tls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #7 from joseph at codesourcery dot com 2005-11-15 09:23 --- Subject: Re: gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32 On Tue, 15 Nov 2005, uros at kss-loka dot si wrote: > The job of compiler is IMO to compile sources correctly, and the purpose of > runtime test is to check if the system is able to run testcases. Runtime No, it is to check if the compiler generated correct code for the testcases. If this fact cannot be tested because of system limitations the result should be UNSUPPORTED, whereas if it can be tested and the code was incorrect it should be FAIL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug preprocessor/24976] simple hexadecimal number parsed as C99 hex float
--- Comment #2 from joseph at codesourcery dot com 2005-11-21 18:21 --- Subject: Re: New: simple hexadecimal number parsed as C99 hex float On Mon, 21 Nov 2005, bernie at develer dot com wrote: > This testcase: > > int a = 0xe+100; 0xe+100 is a single preprocessing number. If the end of <http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html> is unclear, please let us know how we could have improved it so that you would have realised it applies to this situation and so there is no bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #3 from joseph at codesourcery dot com 2005-11-23 14:07 --- Subject: Re: New: Build failure on sparc-sun-solaris2.9: undefined symbol __floatunsitf On Wed, 23 Nov 2005, fxcoudert at gcc dot gnu dot org wrote: > Undefined first referenced > symbol in file > __floatunsitf libgcc/./_floatditf_s.o What did the assembly code look like before and after my patch? If it previously used __floatsitf, where did it get the definition of that symbol? If not, I suspect a bug in the optabs.c changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #4 from joseph at codesourcery dot com 2005-11-23 14:09 --- Subject: Re: Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote: > /work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to > `__floatunsidf' ARM should be getting __floatunsidf from ieee754-df.S. Why isn't it? Did the code previously use __floatsidf, and if so where did it get __floatsidf from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #6 from joseph at codesourcery dot com 2005-11-23 14:28 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote: > > ARM should be getting __floatunsidf from ieee754-df.S. Why isn't it? > > Did the code previously use __floatsidf, and if so where did it get > > __floatsidf from? > > Because this is NetBSD, which doesn't use ieee754-df.S. And the C > library only provides __floatsidf. In that case the obvious solution is for the NetBSD configuration to start using that one function from ieee754-df.S. (I checked that the implementations in GCC of __float* already had corresponding implementations of __floatun* as required - missing rs6000/ppc64-fp.c in the process - but couldn't check for any case where these functions came from libc.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #8 from joseph at codesourcery dot com 2005-11-23 14:54 ---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote:
> Not that simple, because the implementation of __floatunsidf is tightly
> integrated with the implementation of __adddf3. And we don't want to
> override that because the ieee754-df.S implementation does not support
> raising signals.
In that case there's the possibility of a trivial C implementation along
the lines of
double __floatunsidf (unsigned i)
{
double r = (double)(int)i;
if ((int)i < 0)
r += 0x1p32f;
return r;
}
(with a bit more complexity for correct rounding in the "float" case, as
expand_float does). Adding such implementations to libgcc2.c is the
simplest workaround for this bug, but I'd hope that most issues can be
resolved separately so such implementations are only needed in the case of
__float* in libc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #9 from joseph at codesourcery dot com 2005-11-25 02:51 ---
Subject: Patch for sparc-solaris build failure
This patch fixes some of the problems associated with the use of
libcalls for unsigned-to-floating conversions (bug 24998). The
underlying problem was that my patch did not allow for targets which
defined their own libcall names, referring to functions in libc.
It does not address the powerpc64-linux problem (where
config/rs6000/ppc64-fp.c needs unsigned functions added); I understand
from IRC that someone has an unsubmitted patch for that already. It
does not address the arm-netbsdelf problem (__floatsidf in libc),
which really needs to be addressed by someone who can test that
platform; likewise any other platform with the GNU names in libc.
Of the platforms using libcalls to libc, it fixes the issue for SPARC
(_Q_utoq specified in the ABI, _Q_ulltoq from the Solaris libc) and
PowerPC (_q_utoq in the ABI; for some reason glibc's
sysdeps/powerpc/soft-fp/q_utoq.c defines _q_uitoq but this looks like
a bug given the ABI and given that the Versions file says _q_utoq).
It doesn't fix the issue for ia64-hpux, which I intend to address in a
followup patch (the HP-UX libc has _U_Qfcnvxuf_dbl_to_quad for
unsigned DImode to TFmode conversion, but nothing for unsigned SImode
to TFmode conversion so I'll add a C wrapper). I can't test hppa-hpux
right now though the issues are probably similar. In the cases of
MIPS and FRV I hope the relevant maintainers can help. The MIPS issue
seems only to be with mips16.S which needs implementations of the
relevant functions. The FRV issue is that there are trivial C
implementations of the form
double __uitod (unsigned int a)
{
return a;
}
but unlike for the signed functions there is nothing to make the
compiler call those names; if the intention was for these functions to
use the wrapper around a signed libcall the compiler formerly
generated, the right approach (given that this seems to be a
soft-float target) might be to remove these trivial implementations
and instead treat them just like the signed functions.
The tests are much bigger than the rest of the patch, and I hope for
the most part more thorough than gcc.c-torture/execute/conversion.c
which tests similar things (and gets largely optimized away at higher
optimization levels).
If one of the included testcases fails on your platform because of
undefined references to __floatun*, and it does not have a
corresponding undefined reference to the corresponding signed
conversion function without "un" in the name, add a note to bug 24998.
If it fails for any other reason indicating a bug in GCC, open an
appropriate new bug if there isn't one already (I filed bug 25028 for
a problem with TImode conversions being broken, shown up by the
testcases). Some tests may fail because of external issues: the
__float128 tests are XFAILed on x86/x86_64 because they need an
external library implementing the TFmode functions (but when the fixes
are complete they should work OK on ia64-hpux which has enough
functions in libc).
I've verified that this patch makes a sparc-sun-solaris2.8 build go
beyond where it previously failed, and tested the new testcases for
syntax and XFAILs on x86_64-unknown-linux-gnu. OK to commit?
2005-11-25 Joseph S. Myers <[EMAIL PROTECTED]>
PR middle-end/24998
* config/rs6000/rs6000.c (rs6000_init_libfuncs): Use _q_utoq for
unsigned conversions from SImode to TFmode.
* config/sparc/sparc.c (sparc_init_libfuncs): Use _Q_utoq and
_Q_ulltoq for unsigned conversions from SImode and DImode to
TFmode.
testsuite:
2005-11-25 Joseph S. Myers <[EMAIL PROTECTED]>
PR middle-end/24998
* gcc.dg/torture/fp-int-convert-float.c,
gcc.dg/torture/fp-int-convert-double.c,
gcc.dg/torture/fp-int-convert-long-double.c,
gcc.dg/torture/fp-int-convert-timode.c,
gcc.dg/torture/fp-int-convert-float80.c,
gcc.dg/torture/fp-int-convert-float80-timode.c,
gcc.dg/torture/fp-int-convert-float128.c,
gcc.dg/torture/fp-int-convert-float128-timode.c,
gcc.dg/torture/fp-int-convert.h: New files.
diff -rupN GCC.orig/gcc/config/rs6000/rs6000.c GCC/gcc/config/rs6000/rs6000.c
--- GCC.orig/gcc/config/rs6000/rs6000.c 2005-11-23 14:11:11.0 +
+++ GCC/gcc/config/rs6000/rs6000.c 2005-11-24 23:34:31.0 +
@@ -9078,6 +9078,7 @@ rs6000_init_libfuncs (void)
set_conv_libfunc (sfix_optab, SImode, TFmode, "_q_qtoi");
set_conv_libfunc (ufix_optab, SImode, TFmode, "_q_qtou");
set_conv_libfunc (sfloat_optab, TFmode, SImode, "_q_itoq");
+ set_conv_libfunc (ufloat_optab, TFmode, SImode, "_q_utoq");
}
}
diff -rupN GCC.orig/gcc/config/sparc/sparc.c GCC/gcc/config/sparc/sparc.c
--- GCC.orig/gcc/config/sparc/sparc.c 2005-10-28 23:33:40.0 +
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #15 from joseph at codesourcery dot com 2005-11-26 03:55
---
Subject: Patch for ia64-hpux problems
This patch fixes the ia64-hpux problems with my __floatun* patch. It adds
a full set of C implementations of __floatunsi* which should also be
usable to solve the arm-netbsdelf problems.
Bootstrapped with no regressions on ia64-hp-hpux11.23. OK to commit?
2005-11-26 Joseph S. Myers <[EMAIL PROTECTED]>
* config/floatunsisf.c, config/floatunsidf.c,
config/floatunsixf.c, config/floatunsitf.c: New files.
* config/ia64/t-hpux: Add floatunsitf.c.
* config/ia64/ia64.c (ia64_init_libfuncs): Use
_U_Qfcnvxuf_dbl_to_quad for unsigned DImode-to-TFmode conversion.
diff -rupN GCC.orig/gcc/config/floatunsidf.c GCC/gcc/config/floatunsidf.c
--- GCC.orig/gcc/config/floatunsidf.c 1970-01-01 00:00:00.0 +
+++ GCC/gcc/config/floatunsidf.c2005-11-25 15:21:38.0 +
@@ -0,0 +1,15 @@
+/* Public domain. */
+typedef int SItype __attribute__ ((mode (SI)));
+typedef unsigned int USItype __attribute__ ((mode (SI)));
+typedef float DFtype __attribute__ ((mode (DF)));
+
+DFtype
+__floatunsidf (USItype u)
+{
+ SItype s = (SItype) u;
+ DFtype r = (DFtype) s;
+ if (s < 0)
+r += (DFtype)2.0 * (DFtype) ((USItype) 1
+<< (sizeof (USItype) * __CHAR_BIT__ - 1));
+ return r;
+}
diff -rupN GCC.orig/gcc/config/floatunsisf.c GCC/gcc/config/floatunsisf.c
--- GCC.orig/gcc/config/floatunsisf.c 1970-01-01 00:00:00.0 +
+++ GCC/gcc/config/floatunsisf.c2005-11-25 15:26:54.0 +
@@ -0,0 +1,18 @@
+/* Public domain. */
+typedef int SItype __attribute__ ((mode (SI)));
+typedef unsigned int USItype __attribute__ ((mode (SI)));
+typedef float SFtype __attribute__ ((mode (SF)));
+
+SFtype
+__floatunsisf (USItype u)
+{
+ SItype s = (SItype) u;
+ if (s < 0)
+{
+ /* As in expand_float, compute (u & 1) | (u >> 1) to ensure
+correct rounding if a nonzero bit is shifted out. */
+ return (SFtype) 2.0 * (SFtype) (SItype) ((u & 1) | (u >> 1));
+}
+ else
+return (SFtype) s;
+}
diff -rupN GCC.orig/gcc/config/floatunsitf.c GCC/gcc/config/floatunsitf.c
--- GCC.orig/gcc/config/floatunsitf.c 1970-01-01 00:00:00.0 +
+++ GCC/gcc/config/floatunsitf.c2005-11-25 15:21:48.0 +
@@ -0,0 +1,15 @@
+/* Public domain. */
+typedef int SItype __attribute__ ((mode (SI)));
+typedef unsigned int USItype __attribute__ ((mode (SI)));
+typedef float TFtype __attribute__ ((mode (TF)));
+
+TFtype
+__floatunsitf (USItype u)
+{
+ SItype s = (SItype) u;
+ TFtype r = (TFtype) s;
+ if (s < 0)
+r += (TFtype)2.0 * (TFtype) ((USItype) 1
+<< (sizeof (USItype) * __CHAR_BIT__ - 1));
+ return r;
+}
diff -rupN GCC.orig/gcc/config/floatunsixf.c GCC/gcc/config/floatunsixf.c
--- GCC.orig/gcc/config/floatunsixf.c 1970-01-01 00:00:00.0 +
+++ GCC/gcc/config/floatunsixf.c2005-11-25 15:21:43.0 +
@@ -0,0 +1,15 @@
+/* Public domain. */
+typedef int SItype __attribute__ ((mode (SI)));
+typedef unsigned int USItype __attribute__ ((mode (SI)));
+typedef float XFtype __attribute__ ((mode (XF)));
+
+XFtype
+__floatunsixf (USItype u)
+{
+ SItype s = (SItype) u;
+ XFtype r = (XFtype) s;
+ if (s < 0)
+r += (XFtype)2.0 * (XFtype) ((USItype) 1
+<< (sizeof (USItype) * __CHAR_BIT__ - 1));
+ return r;
+}
diff -rupN GCC.orig/gcc/config/ia64/ia64.c GCC/gcc/config/ia64/ia64.c
--- GCC.orig/gcc/config/ia64/ia64.c 2005-11-20 16:20:24.0 +
+++ GCC/gcc/config/ia64/ia64.c 2005-11-25 15:10:32.0 +
@@ -8437,6 +8437,9 @@ ia64_init_libfuncs (void)
set_conv_libfunc (sfloat_optab, TFmode, SImode, "_U_Qfcnvxf_sgl_to_quad");
set_conv_libfunc (sfloat_optab, TFmode, DImode, "_U_Qfcnvxf_dbl_to_quad");
+ /* HP-UX 11.23 libc does not have a function for unsigned
+ SImode-to-TFmode conversion. */
+ set_conv_libfunc (ufloat_optab, TFmode, DImode, "_U_Qfcnvxuf_dbl_to_quad");
}
/* Rename all the TFmode libfuncs using the HPUX conventions. */
diff -rupN GCC.orig/gcc/config/ia64/t-hpux GCC/gcc/config/ia64/t-hpux
--- GCC.orig/gcc/config/ia64/t-hpux 2005-10-28 23:33:38.0 +
+++ GCC/gcc/config/ia64/t-hpux 2005-11-25 15:38:27.0 +
@@ -9,7 +9,7 @@ MULTILIB_MATCHES =
# Support routines for HP-UX 128 bit floats.
-LIB2FUNCS_EXTRA=quadlib.c
+LIB2FUNCS_EXTRA=quadlib.c $(srcdir)/config/floatunsitf.c
quadlib.c: $(srcdir)/config/ia64/quadlib.c
cat $(srcdir)/config/ia64/quadlib.c > quadlib.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #5 from joseph at codesourcery dot com 2005-11-28 00:45 --- Subject: Re: New: [3.4/4.0/4.1/4.2] builtin printf/fprintf is confused by -fexec-charset On Sun, 27 Nov 2005, ghazi at gcc dot gnu dot org wrote: > With a program compiled with e.g. -O2 -fexec-charset=IBM1047, the builtin > handlers for printf and fprintf get confused because they check for matching > stuff in the format string like "%s", "%s\n", "%c" and trailing "\n" using the > host's charset values. So they don't match correctly when compiling strings > in This looks the same as bug 20109 to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #17 from joseph at codesourcery dot com 2005-11-28 23:43
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
Current status:
PA needs fixing, probably similarly to ia64-hpux.
So does MIPS16.
FRV may need fixing, probably by the FRV maintainers.
m68k needs the functions added to config/m68k/fpgnulib.c (bug 25138).
There may be breakage in the US_SOFTWARE_GOFAST case (config/gofast.h),
though I suspect this is unused.
arm-netbsdelf needs fixing; if the config/floatunsi{sf,df}.c files I added
prove inadequate for that then I'll look at fixing whatever's wrong with
them. Likewise, any other platform getting __floatsi* from libc needs
fixing in a similar way: use those files to call the signed libcall.
There may be a glibc bug in sysdeps/powerpc/soft-fp/q_utoq.c defining
_q_uitoq which is the wrong name.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug testsuite/25167] FAIL: gcc.dg/weak/weak-14.c
--- Comment #1 from joseph at codesourcery dot com 2005-11-30 00:34 --- Subject: Re: New: FAIL: gcc.dg/weak/weak-14.c Isn't this just bug 24478? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25167
