Re: [Bug c/27153] 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). -- Joseph S. Myers [EMAIL PROTECTED]
Re: @dircategory Software development
On Mon, 29 May 2006, Karl Berry wrote: > rms asked me to try systematize the Texinfo dir categories to match the > Free Software Directory where possible. So I hope you will be ok > with changing the gcc manuals to say > @dircategory Software development > instead of > @dircategory Programming > (and "Software libraries" instead of "GNU libraries" for libiberty.) > > A patch is appended. I left the "GNU Ada Tools" manuals alone > (gnat_rm.texi and gnat_ugn.texi), since it wasn't immediately clear to > me why they were categorized differently than the rest. Whatever you > think best. Please submit a patch against SVN trunk to [EMAIL PROTECTED] with ChangeLog entries for each relevant ChangeLog. (As a doc fix it can be applied to release branches as well as trunk, and the same patch might apply to both, but we need to fix trunk first.) http://gcc.gnu.org/contribute.html -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: [Bug c/39026] 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
--
Joseph S. Myers
jos...@codesourcery.com
Re: GCC rejects valid code?
On Thu, 24 Jan 2008, Roberto Bagnara wrote:
> While looking at the rules governing struct/union declarations in C, I
> stumbled
> upon this example:
>
> union A {
> int i;
> float f;
> };
>
> void
> foo(struct A** p) {
> *p = 0;
> }
>
> This is accepted by both Comeau and the Intel C compiler, but is rejected
> by GCC 4.1.2 and 4.3.0 on the grounds that
>
> bug.c:7: error: ‘A’ defined as wrong kind of tag
>
> My interpretation is that line 7 does not define `union A' with the
> wrong kind of tag; it declares a (totally unrelated) `struct A'.
> However, I am not sure. Should I file a bug report for this?
Tags have a single namespace, not three namespaces. Because a declaration
of the tag A is visible when "struct A" is used, and "struct A** p" does
not define the contents of the type and is not just "struct A;", it refers
to the previous type of that tag (6.7.2.3#9, paragraph numbering from
N1256). Referring to a union type with "struct" in turn violates
paragraph 2 (added in C99 TC3 following DR#251).
--
Joseph S. Myers
[EMAIL PROTECTED]
Re: Priorites for PR 35435 and PR 35441
On Fri, 28 Mar 2008, Volker Reichelt wrote: > Hi Joseph, > > on March 15 you changed to priority of PR 35435 and PR 35441 to P4. > IMHO this is not in line with our current policy: > > * PR 35435 is not an error-recovery bug (i.e. we don't issue a valid > error message before the ICE). So this should rather be P2, I think. > * PR 35441 is a diagnostic bug, in which completely garbled diagnostics > are emitted. This is a user-visible regression. Richard Guenther > changed the related bugs PR 35442 and 35443 to P2, which I think is > the right setting. > > Would you mind changing the priorities? Or explain why P4 is the correct > setting after all? I made a judgement of how significant I felt the bugs were (which includes questions of how likely they are to affect users). If you think continued presence of these bugs in Stage 3 should delay moving to regression-only mode for 4.4 (which is what the choice of P2 or P4 is about), feel free to set them back to P3 for another RM to look at them. -- Joseph S. Myers [EMAIL PROTECTED]
Re: [Bug testsuite/39550] compat tests for flexible array members
On Wed, 25 Mar 2009, hjl dot tools at gmail dot com wrote: > Flexible array member isn't allowed in union: However, a union may contain a structure that in turn contains a flexible array member. And a union may contain a union containing such a structure, and so on. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc's cpp makes ?: left-associative
On Mon, 20 Dec 2010, David Holland wrote: > as well as with the gcc 4.1 used by CentOS and NetBSD. The Debian one > is unfortunately the latest gcc I have ready access to. However, this > is obscure enough that I'm assuming nobody else is likely to have > noticed it in the meantime. This no longer appears and was probably fixed by: 2008-05-06 Tom Tromey PR preprocessor/35313, PR preprocessor/36088: * expr.c (optab) : Set precedence to 4. (reduce) : Special case CPP_COMMA and CPP_COLON. -- Joseph S. Myers jos...@codesourcery.com
Re: [Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
On Sat, 27 Aug 2011, rguenth at gcc dot gnu.org wrote:
> Hmmm. Partitioning unshares string constants and I suppose ipa-cp propagates
> one of it to the callee.
>
> Not sure if this is a well-defined testcase though. If it is we'd probably
> need to add CONST_DECLs for address-taken constants and register them with
> the varpool (and disallow &"..." in gimple).
>
> It should be possible to make a non-LTO testcase that fails similarly
> by instructing the assembler/linker not to merge strings.
>
> Joseph, does C require that a string literal "..." has a single underlying
> object or would the testcase be undefined?
It's completely clear that once a pointer to a string literal has been
assigned to a variable, that variable has a well-defined value pointing to
that particular copy of the string literal, and so compares equal to
itself. So the testcase ought to pass.
I believe each instance of a string literal in the source code after
preprocessing corresponds to just one object of static storage duration
(so the values from different calls to the same function containing a
string literal must also compare equal, for example) though the objects
from separate string literals in the source code may or may not overlap or
coincide. (There is no requirement for, or restriction against,
unification between copies of the same inline function included in
different translation units.) So the value of "foo" == "foo" is
unspecified, but given
const char *return_foo (void) { return "foo"; }
the value of return_foo () == return_foo () must be 1.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
On Wed, 28 Sep 2011, paolo.carlini at oracle dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 > > Paolo Carlini changed: > >What|Removed |Added > > CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot >||com Paolo, you appear to have removed gcc-bugs from the CC list of several bugs. I don't know how you did it - our Bugzilla is supposed to prevent accidental removal of gcc-bugs, all bugs in the gcc product should always have gcc-bugs in their CC lists - but please add it back to the bugs from which you removed it. -- Joseph S. Myers jos...@codesourcery.com
Re: [Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
Something is strange ... messages sent to bugs from which gcc-bugs was removed do in fact still go to gcc-bugs anyway. So maybe there is no real problem with messages not going to gcc-bugs - but an apparent removal of gcc-bugs should not appear in messages reporting a change that presumably didn't intend to remove gcc-bugs, that's noise. -- Joseph S. Myers jos...@codesourcery.com
Re: g++ off-by-one bug in utf16 conversion
This is bug 41698. Please send a patch to gcc-patches, including the addition of a testcase to the testsuite. -- Joseph S. Myers jos...@codesourcery.com
Re: Double backslashes in fixincl header (__FD_ZERO macro)
On Fri, 6 May 2005, Bruce Korb wrote: > That is, indeed, very bizarre. I opened that file and the lines that > are supposed to be continued with backslashes ended with: \\\n\ > which is correct. After you extract it, you have: \n\ > which is not correct. I am at a loss as to what to suggest. Are you sure you aren't confusing the lines in apzAab_Fd_Zero_Asm_Posix_Types_HPatch (with \\\n\) with those in apzAab_Fd_Zero_Gnu_Types_HPatch (with \n\)? -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Someone introduced a libiberty crashing bug in the past week
On Mon, 20 Jun 2005, Daniel Berlin wrote: > The crash line is > 3729 if (pedantic && !DECL_IN_SYSTEM_HEADER (fundecl)) > > Here, fundecl is null. Any problem with fundecl being null should also be reproducible with a call through a function pointer where fundecl would never have been set to non-null anyway. Restoring fundecl = function; in the if (TREE_CODE (function) == FUNCTION_DECL) part of build_function_call should fix the particular ICE, but the problem with function pointers should still get a PR filed. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: test failures due to quote marks
On Fri, 22 Oct 2004, Nathan Sidwell wrote: > Today I had a load of test failures, which AFAICT stem from the > diagnostics being emitted with 0x321 & 0x322 quote marks rather than > regular ` and ' marks. I don't think I've changed anything in my > environment -- it's building a pristine tree in the same shell that worked > yesterday. The patch to define HAVE_LANGINFO_CODESET went in, so now UTF-8 LC_CTYPE gets proper quotes in English messages. If the testsuite doesn't run with LC_ALL=C, something must be broken - I'd just presumed that any testsuite harness testing diagnostics would have set LC_ALL=C for years to avoid failing when translations are used. But absent that, LC_ALL=C should be set for make check. The easiest place to set LC_ALL for running the testsuite is probably in gcc/Makefile.in where other environment variables are set for the testsuite, though there may be a "right" place in the dejagnu files somewhere. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: [Bug target/30370] Build failure in libgcc2 powitf2 with ICE in gen_reg_rtx
On Sat, 6 Jan 2007, rask at sygehus dot dk wrote: > Like > ifneq (,$(findstring gnu,$(target))) > ifeq (,$(findstring gnuspe,$(target))) > ... > endif > endif > ? Yes, just like that. > How about s/gnuspe/spe/ in case someone comes up with a powerpc-gnufubarspe > target? Seems reasonable. -- Joseph S. Myers [EMAIL PROTECTED]
