[Bug c++/29295] ++ operator with bool typedef increments or operator -- with bool typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-30 08:18 --- /* Forbid using -- on `bool'. */ if (TREE_TYPE (arg) == boolean_type_node) That is wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||accepts-invalid, wrong-code Summary|++ operator with bool |++ operator with bool |typedef increments |typedef increments or ||operator -- with bool ||typedef http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29295
[Bug c++/29295] ++ operator with bool typedef increments or operator -- with bool typedef
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-30 08:20 ---
We also accept the following bad code:
typedef bool my_bool;
int main()
{
my_bool b = false;
b--;
return 0;
}
So confirmed, and not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0
||4.0.4 4.1.2 3.0.4
Last reconfirmed|-00-00 00:00:00 |2006-09-30 08:20:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29295
[Bug c++/29295] ++ operator with bool typedef increments or operator -- with bool typedef
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-30 08:26 --- It has been wrong since at least: r9186 | mrs | 1995-03-15 15:03:59 -0800 (Wed, 15 Mar 1995) | 2 lines 58th Cygnus<->FSF merge -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29295
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-09-30 08:27 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug c++/29291] [4.2 regression] ICE on invalid use of new
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29291
[Bug target/29296] Makeing multi libgcc Error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-30 08:28 --- Can you send the error? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|gcc-3.4.6 | GCC host triplet|debian/gnu linux Kernel-| |2.4.32 | GCC target triplet|sh-unknown-linux-gnu-gcc|sh-unknown-linux-gnu |3.4.6 | Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29296
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-09-30 08:29 --- (In reply to comment #19) > Confirmed: > > andl-144(%ebp), %ebx <--- bogus value in %ebx > movl%eax, -144(%ebp) This smells like an aliasing issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-09-30 08:50 --- > This smells like an aliasing issue. But it's not, it's if-conversion. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Keywords|alias | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-30 09:25 --- Typically something I'd hope the new out-of-ssa pass would improve. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug c++/29297] New: Segmentation fault on "invalid use of `::'"
test.ii:7: error: invalid use of `::'
test.ii:7: error: declaration of `sp::a sp::a::my_type'
test.ii:1: error: changes meaning of `my_type' from `typedef int my_type'
g++.new: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
typedef int my_type;
namespace sp
{
struct a
{
my_type var;
a(sp::my_type);
a get() {}
};
}
Running on x86_64 with unpatched 3.4.6. Fails against patched 4.1.1 as well (do
not have an unpatched one ready). Could not reproduce this on i386.
--
Summary: Segmentation fault on "invalid use of `::'"
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefaan dot deroeck at gmail dot com
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29297
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #9 from rguenther at suse dot de 2006-09-30 11:46 ---
Subject: Re: [4.2 Regression] memcpy optimization
causes wrong-code
On Sat, 29 Sep 2006, pinskia at physics dot uc dot edu wrote:
> --- Comment #7 from pinskia at physics dot uc dot edu 2006-09-29 22:13
> ---
> Subject: Re: [4.2 Regression] memcpy optimization causes wrong-code
> > --- Comment #6 from jakub at gcc dot gnu dot org 2006-09-29 22:04
> > ---
> > Is:
> > extern void abort (void);
> >
> > struct S { struct S *s; } s;
> > struct T { struct T *t; } t;
> >
> > static inline void
> > foo (void *s)
> > {
> > struct T *p = s;
> > __builtin_memcpy (&p->t, &t.t, sizeof (t.t));
>
> I think the problem is really is &p->t include an access or not?
> I know if p is NULL, this is undefined as &p->t is now have a NULL pointer
> access but does that include using memcpy?
If you write it as memcpy (p, &t, ...) then it is ok. Now I think
by applying common sense 6.5.3.2/3 can be applied to &p->t, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #10 from rguenther at suse dot de 2006-09-30 11:47 --- Subject: Re: [4.2 Regression] memcpy optimization causes wrong-code On Sat, 29 Sep 2006, mrs at apple dot com wrote: > --- Comment #8 from mrs at apple dot com 2006-09-29 23:15 --- > > If it is a VAR_DECL, then I believe the optimization is always safe > > Not in C++. As safe as using memcpy, which does not add any semantics to an access using the VAR_DECL. So I believe this is safe even for C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #11 from jakub at gcc dot gnu dot org 2006-09-30 11:49 --- The primary advantage of the single entry optimization is actually that at tree level we can find out if something is only addressable because of the memcpy/memset/mempcpy/memmove and not for other reasons. So, creating a pointer to the object, adding may_alias attribute to the type and dereferencing it doesn't buy us much, because it would still be addressable. So, either we have a way to mark the VAR_DECL (or component thereof) read resp. write with alias set 0, or we need the patch I posted, possibly with additional check for C++/ObjC++ and don't do the optimization at all for C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug c++/29298] New: rejects valid specialization of member template classes
Similar to 14494 and 18950 but for inner classes. This is a stripped-down
example. Workaround appreciated, but has to be class specialization (not member
funtion).
This works with icc, and is thus a portability issue...
g++-20060930 gives:
%COMP.sh "-g -c -W" member_templates_2.cc
member_templates_2.cc:11: error: explicit specialization in non-namespace scope
'struct sentry'
member_templates_2.cc:11: error: enclosing class templates are not explicitly
specialized
member_templates_2.cc:12: error: template parameters not used in partial
specialization:
member_templates_2.cc:12: error: 'F'
// test
template
struct sentry
{
template
struct metadata
{
static int
foo() { return 5; }
};
template<>
struct metadata
{
static int
foo() { return 6; }
};
};
int main()
{
int i1, i2;
typedef sentry sentry_type;
i1 = sentry_type::metadata::foo();
i2 = sentry_type::metadata::foo(); // 6
return 0;
}
--
Summary: rejects valid specialization of member template classes
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #23 from lopezibanez at gmail dot com 2006-09-30 12:36 --- I think I found out what is going on, although I cannot decide myself what is the correct action. For functions declared within class scope we do: (gcc/cp/decl.c start_method() line 11285) DECL_DECLARED_INLINE_P (fndecl) = 1; if (flag_default_inline) DECL_INLINE (fndecl) = 1; Winline tests DECL_DECLARED_INLINE (which is correct). However, as shown above, fno-default-inline does not change the DECL_DECLARED_INLINE but DECL_INLINE. Solutions: 1) Nothing, things are correct as they are. 2) When we are going to emit the warning, we check for fno-default-inline and check that the function is declared within class scope. I have no idea how to do this or whether it is appropriate. 3) fno-default-inline sets both DECL_DECLARED_INLINE and DECL_INLINE to false. It may break other things and the text of fno-default-inline says that these functions will have linkage like inline functions. 4) Something else. -- lopezibanez at gmail dot com changed: What|Removed |Added CC||lopezibanez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-09-30 13:31 --- Subject: Bug 28096 Author: ebotcazou Date: Sat Sep 30 13:31:29 2006 New Revision: 117331 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117331 Log: PR rtl-optimization/28096 * ifcvt.c (check_cond_move_block): Return FALSE if the source of an assignment has already been used as a destination earlier in the block. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20060930-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-09-30 13:35 --- Should work now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg01398.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug c/29299] New: gcc "used" attribute has no effect on local-scope static variables
Adding the "used" attribute to locally-scoped static variables has no effect, and they are not emitted into the output .s file. I am using this in combination with the "section" attribute so I can collect the data together; it doesn't matter to me that there's no useful mapping between the C name and the assembler name. -- Summary: gcc "used" attribute has no effect on local-scope static variables Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeremy at goop dot org GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug c/29280] misleading warning for assignment used as truth construct
--- Comment #2 from elanthis at awesomeplay dot com 2006-09-30 15:20 --- I only bring it up because I've repeatedly seen novice programmers get confused by the warning. It might be clear to someone who's an experienced C developer, but then, they probably don't really need the warning all that much anyhow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #8 from drow at gcc dot gnu dot org 2006-09-30 15:37 --- Subject: Re: want way to #include but still able to finish compiling On Thu, Sep 28, 2006 at 06:09:12AM -, bangerth at dealii dot org wrote: > Daniel, would you prefer if we marked this as WONTFIX? I think this thing > is so contentious that we're not going to do anything about it until there's > some sort of resolutions from the ISO committees. > > I just don't see any purpose in keeping around lots of PRs that we don't plan > to do anything about. We're having enough trouble telling the important PRs > from the not so important ones already... Makes sense to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-30 15:56 --- >From 14.7.2 [temp.expl.spec] paragraph 2: An explicit specialization shall be declared in the namespace of which the template is a member, or, for member templates, in the namespace of which the enclosing class or enclosing class template is a member. ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-30 16:00 --- Dup of PR 16934, PR 15359, PR 8665, and others. PR 8665 has the best description of why this is not a bug and also has the link to where in the standard this is invalid so closing as a dup of that bug. *** This bug has been marked as a duplicate of 8665 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug c++/8665] explicit specialization of the member class template of a class template
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-30 16:00 --- *** Bug 29298 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8665
[Bug c++/8665] explicit specialization of the member class template of a class template
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-30 16:02 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8665
[Bug c++/8665] explicit specialization of the member class template of a class template
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-30 16:02 --- Mark as invalid as this testcase is in fact invalid based on comment #1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8665
[Bug c/29299] gcc "used" attribute has no effect on local-scope static variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-30 16:04 --- Do you have an example code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-09-30 16:20 ---
Working on a fix. In view of legitimate uses for this in conjunction with GNU
extensions, such as
int a[1] = { [0 ... ] = 10, [5] = 0, [1000] = 0 };
(giving an array a non-0 default value), the new warning will be covered by its
own option, in -Wextra but not -Wall.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2005-12-23 00:04:07 |2006-09-30 16:20:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug c/29299] gcc "used" attribute has no effect on local-scope static variables
--- Comment #2 from jeremy at goop dot org 2006-09-30 16:46 --- Created an attachment (id=12360) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12360&action=view) compile with "gcc -O -S t.c" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug target/29300] New: FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-1.c -Wextra -Wall -fno-show-c olumn -S -o pthread-init-1.s(timeout = 300) In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-1.c:10 : /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: (near initialization for 'pmutex.m_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: (near initialization for 'pcond.c_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: (near initialization for 'prwlock.rw_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: (near initialization for 'ponce.po_mutex.m_short') output is: In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-1.c:10 : /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: (near initialization for 'pmutex.m_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: (near initialization for 'pcond.c_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: (near initialization for 'prwlock.rw_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: (near initialization for 'ponce.po_mutex.m_short') FAIL: gcc.dg/pthread-init-1.c (test for excess errors) Excess errors: In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-1.c:10 : /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: (near initialization for 'pmutex.m_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: (near initialization for 'pcond.c_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: (near initialization for 'prwlock.rw_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: (near initialization for 'ponce.po_mutex.m_short') Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-2.c -Wextra -Wall -ansi -fno- show-column -S -o pthread-init-2.s(timeout = 300) In file included from /usr/include/pthread.h:7, from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common .h:7, from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-2.c:10 : /usr/include/sys/pthread.h:818: error: expected ';', ',' or ')' before '*' token In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-2.c:10 : /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:13: warning: (near initialization for 'pmutex.m_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:16: warning: (near initialization for 'pcond.c_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:19: warning: (near initialization for 'prwlock.rw_short') /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: missin g braces around initializer /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pthread-init-common.h:22: warning: (near initial
[Bug middle-end/29301] New: [4.2 Regression] ICE in check_cfg, at haifa-sched .c:4657 while compiling openssl
This happens with gcc 4.2 SVN rev. 116997: gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o evp_pkey.o evp_pkey.c evp_pkey.c: In function 'EVP_PKEY2PKCS8_broken': evp_pkey.c:382: warning: function called through a non-compatible type evp_pkey.c:382: note: if this code is reached, the program will abort evp_pkey.c: In function 'dsa_pkey2pkcs8': evp_pkey.c:478: warning: function called through a non-compatible type evp_pkey.c:478: note: if this code is reached, the program will abort evp_pkey.c: In function 'EVP_PKEY2PKCS8_broken': evp_pkey.c:416: internal compiler error: in check_cfg, at haifa-sched.c:4657 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.2 Regression] ICE in check_cfg, at haifa-sched .c:4657 while compiling openssl Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29301
[Bug middle-end/29301] [4.2 Regression] ICE in check_cfg, at haifa-sched .c:4657 while compiling openssl
--- Comment #1 from bero at arklinux dot org 2006-09-30 19:00 --- Created an attachment (id=12361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12361&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29301
[Bug middle-end/29301] [4.2 Regression] ICE in check_cfg, at haifa-sched .c:4657 while compiling openssl
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-30 19:30 --- works for me with rev. 117329 - can you tell the output of "-v" added to the compilation line? Otherwise this might be a dup of PR27863. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29301
[Bug middle-end/29299] [4.2 Regresion] gcc "used" attribute has no effect on local-scope static variables
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-30 19:40 --- 4.1.2 works: .local bar.1279 .comm bar.1279,4,4 .local bof .comm bof,4,4 while 4.2.0 does not: .local bof .comm bof,4,4 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 GCC build triplet|i386-redhat-linux | GCC host triplet|i386-redhat-linux | GCC target triplet|i386-redhat-linux | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-09-30 19:40:21 date|| Summary|gcc "used" attribute has no |[4.2 Regresion] gcc "used" |effect on local-scope static|attribute has no effect on |variables |local-scope static variables Target Milestone|--- |4.2.0 Version|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-09-30 19:46 --- Subject: Bug 24010 Author: jsm28 Date: Sat Sep 30 19:46:06 2006 New Revision: 117334 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117334 Log: PR c/24010 * c.opt (Woverride-init): New. * c-opts.c (c_common_post_options): Default warn_override_init to extra_warnings. * c-typeck.c (add_pending_init, output_init_element): Warn for overriding initializers without side effects. * doc/invoke.texi (-Woverride-init): Document. (-Wextra): Update. testsuite: * gcc.dg/Woverride-init-1.c, gcc.dg/Woverride-init-2.c, gcc.dg/Woverride-init-3.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/Woverride-init-1.c trunk/gcc/testsuite/gcc.dg/Woverride-init-2.c trunk/gcc/testsuite/gcc.dg/Woverride-init-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/c-typeck.c trunk/gcc/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug libfortran/29302] New: nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
With the Xcode 2.4 release, the nan_inf_fmt.f90 testcase in gfortran.fortran-torture/execute has begun to segfault on Darwin PPC at both -m32 and -m64. The backtrace from a segfault is... Starting program: /Users/howarth/testdir/nan_inf_fmt/a.out Reading symbols for shared libraries .++ done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x3fffe615 0x90101fc8 in strtol_l () (gdb) bt #0 0x90101fc8 in strtol_l () #1 0x00255810 in output_float (dtp=0xbfffeb30, f=0x1808c50, value=inf) at ../../../gcc-4.2-20060928/libgfortran/io/write.c:496 #2 0x00256124 in write_float (dtp=0xbfffeb30, f=0x1808c50, source=0xa , len=-1610603800) at ../../../gcc-4.2-20060928/libgfortran/io/write.c:912 #3 0x002507ec in formatted_transfer (dtp=0xbfffeb30, type=BT_REAL, p=0xa, kind=4, size=4, nelems=1) at ../../../gcc-4.2-20060928/libgfortran/io/transfer.c:954 #4 0x0024eac8 in *__gfortran_transfer_real (dtp=0x250314, p=0xbfffeaf8, kind=4) at ../../../gcc-4.2-20060928/libgfortran/io/transfer.c:1237 #5 0x2a04 in MAIN__ () at nan_inf_fmt.f90:17 #6 0x3af0 in main (argc=1073735189, argv=0x0) at ../../../gcc-4.2-20060928/libgfortran/fmain.c:18 It has been suggested on the list that this might be due to size mismatch and that the new Xcode 2.4 is exposing a latent bug in libgfortran... http://gcc.gnu.org/ml/fortran/2006-09/msg00103.html -- Summary: nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-30 20:46 --- Created an attachment (id=12362) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12362&action=view) assembly file for nan_inf_fmt that seqfaults on Darwin PPC with Xcode 2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-30 21:09 --- I will see if I can spot something here. Jack, I will need your help testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-30 21:36 --- Valgrind shows tight as a drum on i686-linux. Do you have something equivalent to valgrind for Darwin PPC? I am not seeing anything obvious in the code. On i686 the call at line 496 is to atoi(). Your system is showing a strtol_l. These are slightly different and maybe atoi() is mapped to strtol_l on this archtecture. I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-09-30 21:53 --- Jack, I would forward this one to Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug gcov-profile/29303] New: gcov.texi: "Invoking gcov" section header needs @command.
The following patch should be applied to gcov.texi, in order for the "Invoking
gcov" section header to match the style of the other section headers in the
gcov chapter:
Index: gcov.texi
===
--- gcov.texi (revision 117335)
+++ gcov.texi (working copy)
@@ -110,7 +110,7 @@
@c man end
@node Invoking Gcov
[EMAIL PROTECTED] Invoking gcov
[EMAIL PROTECTED] Invoking @command{gcov}
@smallexample
gcov @[EMAIL PROTECTED]@r{]} @var{sourcefile}
--
Summary: gcov.texi: "Invoking gcov" section header needs
@command.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmoses at stanford dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29303
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-09-30 22:50 --- Jerry, I've run this with guardmalloc... http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/libgmalloc.3.html using all the permutations and nothing gets triggered. Jack ps It seems the crashes are specific to those lines that have... write(l,fmt=fmt)pos_inf or write(l,fmt=fmt)neg_inf The lines with... write(l,fmt=fmt)nan never cause a segfault so a minimal failing testcase is... implicit none character*40 l character*12 fmt real zero, pos_inf zero = 0.0 pos_inf = 1.0/zero fmt = '(F0.0)' write(l,fmt=fmt)pos_inf end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-30 23:28 --- Can you attach the full log because I know people that actually build gfortran on AIX all the time in fact with --with-gmp, etc: --with-gmp=/farm/dje --with-mpfr=/farm/dje http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg01648.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug c++/29287] signed to unsigned in struct initializer should generate a warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-30 23:30 --- Use -Wconversion. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29287
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-30 23:30 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-30 23:32 --- Can you attach the preprocessed source as requested by the website: http://gcc.gnu.org/bugs.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug middle-end/29268] need to generalize realignment support in the vectorizer
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-30 23:35 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-09-30 23:35:19 date|| Summary|missed optimization: need to|need to generalize |generalize realignment |realignment support in the |support in the vectorizer |vectorizer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29268
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-30 23:37 --- Also it should be noted before strict aliasing came about, restrict did nothing in the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug target/25376] section attribute doesn't work on darwin
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-10-01 00:29 --- Shouldn't this bug be marked as closed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-01 00:40 --- (In reply to comment #5) > Jerry, > I've run this with guardmalloc... > > Jack, This is an Apple library problem. Please report the inappropriate use of strtol_l to Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug tree-optimization/29290] [4.1 Regression] SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-01 02:08 --- Program received signal SIGSEGV, Segmentation fault. 0x0841a529 in exit_phi_for_loop_p (loop=Variable "loop" is not available. ) at /home/pinskia/src/gcc/gcc-4.1/gcc/gcc/lambda-code.c:2186 2186 if (TREE_CODE (stmt) != PHI_NODE Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | Keywords||ice-on-valid-code Known to fail||4.1.2 Known to work||4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-10-01 02:08:01 date|| Summary|SPEC CPU2000 178.galgel ICE |[4.1 Regression] SPEC |using -O3 -ftree-loop-linear|CPU2000 178.galgel ICE using ||-O3 -ftree-loop-linear Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29290
[Bug other/29271] Incorrect -fdump-rtl-sched documentation
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-01 02:22 --- I am applying the ovbious patch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271
[Bug java/29304] New: autoconf should be used in libjava to check for fabs, fabsf and scalbn
Currently libjava doesn't check for the existance of math functions in libm
before declaring them. This results in warnings on Darwin PPC...
symbol _fabsf used from dynamic library /usr/lib/libm.dylib(fabs.o) not from
earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(sf_fabs.o)
symbol _fabs used from dynamic library /usr/lib/libm.dylib(fabs.o) not from
earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(s_fabs.o)
symbol _scalbn used from dynamic library /usr/lib/libm.dylib(scalb.o) not from
earlier dynamic library
/sw/lib/gcc4/lib/libgcj.8.dylib(s_scalbn.o/sw/lib/odcctool
s/bin/ld: warning suggest use of -bind_at_load, as lazy binding may result in
errors or different symbols being used
)
creating gappletviewer
We should be using wrappers like libgfortran/intrinsics/c99_functions.c does.
In this case we need...
Index: classpath/native/fdlibm/sf_fabs.c
===
--- classpath/native/fdlibm/sf_fabs.c (revision 117342)
+++ classpath/native/fdlibm/sf_fabs.c (working copy)
@@ -19,6 +19,8 @@
#include "fdlibm.h"
+#ifndef HAVE_FABSF
+#define HAVE_FABSF 1
#ifdef __STDC__
float fabsf(float x)
#else
@@ -31,9 +33,12 @@
SET_FLOAT_WORD(x,ix&0x7fff);
return x;
}
+#endif
#ifdef _DOUBLE_IS_32BITS
+#ifndef HAVE_FABS
+#define HAVE_FABS 1
#ifdef __STDC__
double fabs(double x)
#else
@@ -43,5 +48,6 @@
{
return (double) fabsf((float) x);
}
+#endif
#endif /* defined(_DOUBLE_IS_32BITS) */
Index: classpath/native/fdlibm/s_scalbn.c
===
--- classpath/native/fdlibm/s_scalbn.c (revision 117342)
+++ classpath/native/fdlibm/s_scalbn.c (working copy)
@@ -32,6 +32,8 @@ twom54 = 5.55111512312578270212e-17, /
huge = 1.0e+300,
tiny = 1.0e-300;
+#ifndef HAVE_SCALBN
+#define HAVE_SCALBN 1
#ifdef __STDC__
double scalbn (double x, int n)
#else
@@ -63,3 +65,4 @@ tiny = 1.0e-300;
return x*twom54;
}
#endif /* _DOUBLE_IS_32BITS */
+#endif
--
Summary: autoconf should be used in libjava to check for fabs,
fabsf and scalbn
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29304
[Bug classpath/29304] autoconf should be used in libjava to check for fabs, fabsf and scalbn
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-10-01 04:17 --- We will also need to add... AC_CHECK_LIB([m],[fabsf],[AC_DEFINE([HAVE_FABSF],[1],[libm includes fabsf])]) AC_CHECK_LIB([m],[fabs],[AC_DEFINE([HAVE_FABS],[1],[libm includes fabs])]) AC_CHECK_LIB([m],[scalbn],[AC_DEFINE([HAVE_SCALBN],[1],[libm includes scalbn])]) to configure.ac in libjava. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29304
[Bug middle-end/28915] [4.1/4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-10-01 04:33 --- With my reduced testcase on the 4.1 branch we get an ICE. And infinite loop in "4.1.0 20051026" also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 Known to work||4.0.0 Summary|[4.2 regression] ICE: tree |[4.1/4.2 regression] ICE: |check: expected class |tree check: expected class |'constant', have|'constant', have |'declaration' (var_decl) in |'declaration' (var_decl) in |build_vector, at tree.c:973 |build_vector, at tree.c:973 Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug c/29305] New: local label-as-value being placed before function prolog
In this code:
static void *bof;
int foo()
{
__label__ boo;
boo: bar();
bof = &&boo;
}
the label "boo" is emitted as .L2, but it is being placed before the function
prologue:
foo:
.L2:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
callbar
movl$.L2, bof
leave
ret
If I add a goto to the label, it is placed correctly:
static void *bof;
int foo()
{
__label__ boo;
boo: bar();
bof = &&boo;
goto boo;
}
foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
.L3:
callbar
movl$.L3, bof
jmp .L3
--
Summary: local label-as-value being placed before function prolog
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeremy at goop dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug c/29305] local label-as-value being placed before function prolog
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-01 04:43 --- This is not a bug really. label as values are only supposed to be used for used with gotos. Read: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Labels-as-Values.html Maybe it can be made a little clearer but it seems pretty clear to me that what you are trying should not work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug c/29305] local label-as-value being placed before function prolog
--- Comment #2 from jeremy at goop dot org 2006-10-01 05:18 ---
What I'm trying to do is get the address of particular faulting instructions in
an asm:
faulted: asm volatile("ud2");
so that an exception handler can come back later and match a fault address with
an instruction. The behaviour I'd like to see is that &&faulted always points
to the "ud2" instruction.
It seems a bit perverse that gcc will quietly generate a bad result unless I
actually goto the label in some way: it should either fail outright (which
would be defensiable, but annoying for me), or do the right thing.
--
jeremy at goop dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-01 05:29 ---
It is failing right out if you don't have any computed gotos in your function
(or a goto to that label).
You should try doing:
asm volatile("faulted: ud2");
and make faulted a static function but that might not work with unrolling, etc.
Really there is no way for doing what you are asking and really not the correct
way to think about what you are doing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c |middle-end
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #9 from acahalan at gmail dot com 2006-10-01 05:32 --- (In reply to comment #4) > This is definitely firmly in the class of "extension to the language that > requires a thorough proposal to be presented to the standards committee" Of course. I mentioned that. I'm more familiar with the POSIX/UNIX standardization than the C/C++ standardization. Perhaps they have very different rules, but what I've seen with the one group is that the committee strongly prefers that there be an existing implementation. If they wait for existing implementations, and you wait for them, then no progress can be made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
Re: [Bug preprocessor/29245] want way to #include but still able to finish compiling
On Sun, 2006-10-01 at 05:32 +, acahalan at gmail dot com wrote: > > --- Comment #9 from acahalan at gmail dot com 2006-10-01 05:32 --- > (In reply to comment #4) > > This is definitely firmly in the class of "extension to the language that > > requires a thorough proposal to be presented to the standards committee" > > Of course. I mentioned that. > > I'm more familiar with the POSIX/UNIX standardization than the C/C++ > standardization. Perhaps they have very different rules, but what > I've seen with the one group is that the committee strongly prefers > that there be an existing implementation. But after the proposal has been written formally. -- Pinski
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #10 from pinskia at physics dot uc dot edu 2006-10-01 05:36 --- Subject: Re: want way to #include but still able to finish compiling On Sun, 2006-10-01 at 05:32 +, acahalan at gmail dot com wrote: > > --- Comment #9 from acahalan at gmail dot com 2006-10-01 05:32 --- > (In reply to comment #4) > > This is definitely firmly in the class of "extension to the language that > > requires a thorough proposal to be presented to the standards committee" > > Of course. I mentioned that. > > I'm more familiar with the POSIX/UNIX standardization than the C/C++ > standardization. Perhaps they have very different rules, but what > I've seen with the one group is that the committee strongly prefers > that there be an existing implementation. But after the proposal has been written formally. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #4 from jeremy at goop dot org 2006-10-01 05:36 --- Well, it isn't failing in any obvious fashion. It's quietly putting the label at the wrong place, without complaint. The same code later in a function does put the labels at the right place, so the failure mode is moderately subtle. If you don't intent to support my use-case, then gcc should warn/error-out rather than be quietly wrong. That said, I don't really understand why this can't be supported. In what way is this "not the correct way to think about what I'm doing"? How else should I achieve what I want? I should mention that this is Linux kernel code, and there are a number of places within the kernel where it would be useful to take the address of a particular statement without needing to "goto" to it, but have the code generated as if there is a goto (ie, merely taking the address of a label should be taken to be equivalent to actually having a goto to that label). -- jeremy at goop dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #5 from jeremy at goop dot org 2006-10-01 05:42 --- Created an attachment (id=12363) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12363&action=view) More complete example of what I'm trying to do -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-01 05:45 --- (In reply to comment #4) > Well, it isn't failing in any obvious fashion. It's quietly putting the label > at the wrong place, without complaint. There is no wrong place if you don't use it via a local computed goto as mention in the documetnion. > The same code later in a function does > put the labels at the right place, so the failure mode is moderately subtle. > If you don't intent to support my use-case, then gcc should warn/error-out > rather than be quietly wrong. It is not placing the label in the wrong place as you don't have a computed goto in the function. > > That said, I don't really understand why this can't be supported. In what way > is this "not the correct way to think about what I'm doing"? How else should > I > achieve what I want? what do you really want? Because what you have mentioned so far seems like you should be writting a .s file and not something in C. > I should mention that this is Linux kernel code, and there are a number of > places within the kernel where it would be useful to take the address of a > particular statement without needing to "goto" to it, but have the code > generated as if there is a goto (ie, merely taking the address of a label > should be taken to be equivalent to actually having a goto to that label). It is wrong to store the label to jump back to that label outside of the function as mentioned in the documention. Read the documentation again. Actually it sounds like you would like to have more information for people filing bug reports well this is not the correct way of doing it. You should plan a better way. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #7 from jeremy at goop dot org 2006-10-01 05:55 --- Subject: Re: local label-as-value being placed before function prolog pinskia at gcc dot gnu dot org wrote: > what do you really want? Because what you have mentioned so far seems like > you > should be writting a .s file and not something in C. > I'm replacing a bunch of arch-specific assembler with C, because generating assembler to emit structure definitions is just painful makework. All I need is a bit of cooperation from gcc to generate a label pointing to the right instruction, and it will save me a heap of code. There is also another set of Linux patches which are trying to use labels in a similar way to mark tracepoints in the code, for later insertion of instrumentation, which will clearly not be reliable with gcc in its current state. > Read the documentation again. > I have, in detail, and it doesn't really preclude how I want to use these labels. I do not want to jump into the function from outside, or use goto on them at all. But that doesn't mean I don't have a use for them. > Actually it sounds like you would like to have more information for people > filing bug reports well this is not the correct way of doing it. You should > plan a better way. > I'm not sure I can parse this. But I'd like you to consider this as a feature request for gcc, because from my perspective gcc doing what I want is far better than the alternatives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #8 from jeremy at goop dot org 2006-10-01 05:58 --- Reopen as enhancement, in the hope gcc implements more useful semantics for taking the address of a label. -- jeremy at goop dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-01 06:24 --- (In reply to comment #8) > Reopen as enhancement, in the hope gcc implements more useful semantics for > taking the address of a label. They are useful if used correctly. You are not using them correctly. They are only for computed gotos and nothing else. They are not designed for anything else. In fact if GCC changes the behavior, it would be for the worse as then people using them correctly would be punished. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
