Re: fortran-testcase/dce question
Andrew Pinski <[EMAIL PROTECTED]> wrote on 20/09/2005 18:09:20: > > On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote: > > > We've had the testcase below in autovect-branch for a while, testing > > that > > the 3 loops get vectorized. On mainline the third loop now gets > > eliminated > > by DCE (.t44.dce3). Not sure I understand why... isn't the print loop > > enough to keep it alive? > > It should be but from the looks of it. For some reason in alias2, we > don't say > D.503_30 points to anyoffset in &e unlike before. You might be able to > generate a > C testcase for this too. > > Can you also file a bug? > It's PR23989 thanks, dorit > Thanks, > Andrew Pinski >
unwind-dw2-fde.c failed on my port
Hi, There is a little progress. I find it's concerned with gcc optimize. When I change the option -O2 to -O0, it passes the make. Of course, I'd like to say there are something wrong in my backend. But, can somebody give me any clue? Thanks. Eric
Re: Problem with gcc 4.0.1
Ernest L. Williams Jr. wrote:
Hi,
The following code fragment is now causing problems under gcc 4.0.1
Everything is perfect under "gcc version 3.4.3"
Any recommended work-arounds?
= code fragment==
#ifndef __LOC_PV_FACTORY_H__
#define __LOC_PV_FACTORY_H__
line 10 --> #include "pv_factory.h"
line 11 -->
line 12 --> class LOC_PV_Factory : public PV_Factory
line 13 --> {
line 14 --> public:
line 15 --> LOC_PV_Factory();
line 16 --> ~LOC_PV_Factory();
line 17 --> ProcessVariable *create(const char *PV_name);
line 18 --> private:
line 19 --> friend class LOC_ProcessVariable;
line 20 --> static void forget(LOC_ProcessVariable *pv);
line 21 --> };
GCC was incorrectly accepting this code. You should add a declaration
of class LOC_ProcessVariable outside class LOC_PV_Factory, either
through its include file or with a forward declaration ("class
LOC_ProcessVariable;").
By the way, the correct list to ask would have been [EMAIL PROTECTED]
(this one is for development "of" GCC, not "with" GCC).
Paolo
Re: Problem with gcc 4.0.1
On Wed, 2005-09-21 at 10:51 +0200, Paolo Bonzini wrote:
> Ernest L. Williams Jr. wrote:
> > Hi,
> >
> > The following code fragment is now causing problems under gcc 4.0.1
> > Everything is perfect under "gcc version 3.4.3"
> > Any recommended work-arounds?
> > = code fragment==
> > #ifndef __LOC_PV_FACTORY_H__
> > #define __LOC_PV_FACTORY_H__
> >
> > line 10 --> #include "pv_factory.h"
> > line 11 -->
> > line 12 --> class LOC_PV_Factory : public PV_Factory
> > line 13 --> {
> > line 14 --> public:
> > line 15 --> LOC_PV_Factory();
> > line 16 --> ~LOC_PV_Factory();
> > line 17 --> ProcessVariable *create(const char *PV_name);
> > line 18 --> private:
> > line 19 --> friend class LOC_ProcessVariable;
> > line 20 --> static void forget(LOC_ProcessVariable *pv);
> > line 21 --> };
>
> GCC was incorrectly accepting this code.
So is this a bug that is now fixed or is bad coding practices getting
caught with a stricter GCC distribution?
> You should add a declaration
> of class LOC_ProcessVariable outside class LOC_PV_Factory, either
> through its include file or with a forward declaration ("class
> LOC_ProcessVariable;").
Awesome. Now everything works for me.
>
> By the way, the correct list to ask would have been [EMAIL PROTECTED]
> (this one is for development "of" GCC, not "with" GCC).
>
Sounds good. I will subscribe to [EMAIL PROTECTED]
Thanks for your help and response,
Ernesto
> Paolo
No effect of -fshort-enums..is it a bug
Hi,
I have compiled a testcase
int main()
{
enum aa {
a = 0, b =127 , c
};
printf("size = %d %d %d\n", sizeof(a),sizeof(b), sizeof(c));
printf("value= %d %d %d\n", a,b,c);
return 0;
}
On gcc (GCC) 4.1.0 20050915 (experimental) with the following option
-fshort-enums.
The option -fshort-enums has no effect and the output is same as it is without
this option.
I also tried the same tc on gcc (GCC) 3.3.1 (SuSE Linux). But in this case the
output changed with and without this option.
I am using an SuSe linux -- X86_AMD64 machine.
I think it's a bug. Can anybody please confirm?
Thanks
Gaurav
Re: No effect of -fshort-enums..is it a bug
On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida wrote:
> int main()
> {
> enum aa {
> a = 0, b =127 , c
> };
>
> printf("size = %d %d %d\n", sizeof(a),sizeof(b), sizeof(c));
> printf("value= %d %d %d\n", a,b,c);
> return 0;
> }
> The option -fshort-enums has no effect and the output is same as it is
> without this option.
It's not a bug. Add sizeof(enum aa) to your printf; _that_ will be
affected by -fshort-enums. The type of the enumerators remains int.
--
Daniel Jacobowitz
CodeSourcery, LLC
RE: No effect of -fshort-enums..is it a bug
Thanks for the reply,
But why is there a difference in the output of same tc, with an old gcc
compiler and a new version of compiler.
Was there a bug in the earlier gcc.
I have a doubt.
Gcc manual says that
"-fshort-enums
Allocate to an enum type only as many bytes as it needs for the
declared range of possible values. Specifically, the enum type will be
equivalent to the smallest integer type which has enough room."
Does -fshort-enum guides the size of enumeration type or the size of
enumerator constant ?
After modifying the tc as
#include
int main()
{
enum aa {
a = 0, b =127 , c
};
printf("size = %d %d %d\n", sizeof(enum aa),sizeof(b),
sizeof(c));
printf("value= %d %d %d\n", a,b,c);
return 0;
)
The output is
size = 1 1 1
value= 0 127 128
when gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
And
size = 1 4 4
value= 0 127 128
when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
Which of the two output is standard confirming.?
> -Original Message-
> From: Daniel Jacobowitz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 21, 2005 6:10 PM
> To: Gaurav Gautam, Noida
> Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> Subject: Re: No effect of -fshort-enums..is it a bug
>
> On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida wrote:
> > int main()
> > {
> > enum aa {
> > a = 0, b =127 , c
> > };
> >
> > printf("size = %d %d %d\n", sizeof(a),sizeof(b),
sizeof(c));
> > printf("value= %d %d %d\n", a,b,c);
> > return 0;
> > }
>
> > The option -fshort-enums has no effect and the output is same as it
is
> without this option.
>
> It's not a bug. Add sizeof(enum aa) to your printf; _that_ will be
> affected by -fshort-enums. The type of the enumerators remains int.
>
> --
> Daniel Jacobowitz
> CodeSourcery, LLC
GCC 4.0.2 and PR 23993
I'm soliciting feedback regrading a problem in the 4.0.2 release.
PR 23993 is a rejects-valid C++ PR that represents a regression from
GCC 4.0.1. That's particularly unfortunate; we really want to avoid
introducing new breakage on the release branch.
It is, sadly, more fallout from my static data member patch; it has
uncovered a latent bug in integral_constant_value.
Here is the test case from the PR:
const int data[2][4] = {
{ 0, 1, 2, 3 }
};
template
void t(int k) {
int candidate = data[1][k];
}
The key is that an const array (or, perhaps, structure) of integral
type is accessed in a template. I have a patch for the PR, which I am
testing now; the patch is attached, and is relatively simple.
So, my options are:
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
2. Apply the patch, respin the release, and release it.
3. Apply the patch, spin RC3, and go through another testing cycle.
My current plan is (2) because I think that this is an important bug
and because I think the patch is safe and, in particular, highly
unlikely to introduce any follow-on problems of its own. However, I
realize that I can't be entirely objective about this situation, so
I'd appreciate any feedback.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Index: init.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/init.c,v
retrieving revision 1.429
diff -c -5 -p -r1.429 init.c
*** init.c 6 Sep 2005 14:55:03 - 1.429
--- init.c 21 Sep 2005 13:26:27 -
*** build_offset_ref (tree type, tree name,
*** 1565,1580
[5.19/1]. FIXME:If we did lazy folding, this could be localized. */
tree
integral_constant_value (tree decl)
{
! while ((TREE_CODE (decl) == CONST_DECL
! || (TREE_CODE (decl) == VAR_DECL
! /* And so are variables with a 'const' type -- unless they
!are also 'volatile'. */
! && CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (decl))
! && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl
{
tree init;
/* If DECL is a static data member in a template class, we must
instantiate it here. The initializer for the static data
member is not processed until needed; we need it now. */
--- 1565,1576
[5.19/1]. FIXME:If we did lazy folding, this could be localized. */
tree
integral_constant_value (tree decl)
{
! while (TREE_CODE (decl) == CONST_DECL
!|| DECL_INTEGRAL_CONSTANT_VAR_P (decl))
{
tree init;
/* If DECL is a static data member in a template class, we must
instantiate it here. The initializer for the static data
member is not processed until needed; we need it now. */
Re: Segmentation Fault building GCC for i686-pc-mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TJ Laurenzo wrote: > I'm getting a segmentation fault in the GCC build from today's CVS > HEAD. I am building the suite for mingw using a cross compiler from > Linux. This setup was working fine prior to updating to the latest > CVS head today. My old sources, which were working correctly, were > from 9/1/2005. In both cases, I had applied patch-rev4.diff from bug > 21766 prior to building. > > If I disable optimizations by removing -O2 arguments and rerunning the > command manually, the file compiles without error. > > Let me know if there is anything else that I can provide to help nail > down this problem. Yes, you can provide a stacktrace and probably debug this yourself. Read http://gcc.gnu.org/wiki/DebuggingGCC first and get the "debugx" and "debug" scripts referred to from there. Change to the folder: `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' and execute once again the command that seemed to fail: i686-pc-mingw32-gcc -DHAVE_CONFIG_H - -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include - -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 - -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include - -c /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c -DDLL_EXPORT -DPIC -o .libs/mark_rts.o If it reproduces, execute the command once again but add "debugx cc1" in the beginning - this will start GDB and you'd be able to debug the actual compiler "cc1". Now enter "run" within GDB and when the fault occurs, use "backtrace" to get a stack trace that might give you/others more information. HTH, Ranjit. > - > make[2]: Entering directory > `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' > /bin/sh ./libtool --mode=compile i686-pc-mingw32-gcc -DHAVE_CONFIG_H > -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include > -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 > -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include > -c -o mark_rts.lo > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c > i686-pc-mingw32-gcc -DHAVE_CONFIG_H > -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include > -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 > -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include > -c /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c > -DDLL_EXPORT -DPIC -o .libs/mark_rts.o > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c: > In function 'GC_approx_sp': > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c:379: > warning: function returns address of local variable > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c: > In function 'GC_add_roots_inner': > /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c:175: > internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make[2]: *** [mark_rts.lo] Error 1 > make[2]: Leaving directory > `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' > make: *** [all-target-boehm-gc] Error 2 > - > - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMWrgYb1hx2wRS48RAl6GAJ4/KT8jIu58Z0LmOdFBS+hpjCWrbACfX03I mkhVx1Us3MtDbOy7+JaIJuM= =Byoz -END PGP SIGNATURE-
Re: No effect of -fshort-enums..is it a bug
On Wed, Sep 21, 2005 at 07:03:49PM +0530, Gaurav Gautam, Noida wrote: > Thanks for the reply, > > But why is there a difference in the output of same tc, with an old gcc > compiler and a new version of compiler. > > Was there a bug in the earlier gcc. > > I have a doubt. > > Gcc manual says that > > "-fshort-enums > Allocate to an enum type only as many bytes as it needs for the > declared range of possible values. Specifically, the enum type will be > equivalent to the smallest integer type which has enough room." > > Does -fshort-enum guides the size of enumeration type or the size of > enumerator constant ? C99, section 6.7.2.2: [#3] The identifiers in an enumerator list are declared as constants that have type int and may appear wherever such are permitted. ... [#4] Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration. I'm not 100% sure what #3 means for enumerators whose value does not fit in the range of "int", but it's pretty clear that the implementation is not allowed to change the type of enumerators. -- Daniel Jacobowitz CodeSourcery, LLC
Re: unwind-dw2-fde.c failed on my port
On Wed, 2005-09-21 at 16:40 +0800, Eric Fisher wrote: > Hi, > > There is a little progress. I find it's concerned with gcc optimize. > When I change the option -O2 to -O0, it passes the make. Of > course, I'd like to say there are something wrong in my backend. > But, can somebody give me any clue? > Unfortunately not. This is the hard part of debugging. You are going to have to stare at dumps and disassembly to figure out what is going on. I'd tell you to run the gcc testsuite and start hunting down failures, but i don't believe any of the execute tests will work without libgcc.a working.
Re: GCC 4.0.2 and PR 23993
> So, my options are: > > 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting >on my disk.) > > 2. Apply the patch, respin the release, and release it. > > 3. Apply the patch, spin RC3, and go through another testing cycle. > > My current plan is (2) because I think that this is an important bug > and because I think the patch is safe and, in particular, highly > unlikely to introduce any follow-on problems of its own. However, I > realize that I can't be entirely objective about this situation, so > I'd appreciate any feedback. Has Benjamin applied his patch on the 4.0 branch? If so, my feeling is that RC3 would not be superfluous. -- Eric Botcazou
Re: No effect of -fshort-enums..is it a bug
Daniel Jacobowitz wrote: I'm not 100% sure what #3 means for enumerators whose value does not fit in the range of "int", but it's pretty clear that the implementation is not allowed to change the type of enumerators. Of course an implementation can do whatever it likes in response to switches, compiler dependent declarations etc.
Re: GCC 4.0.2 and PR 23993
> 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting >on my disk.) Let's drop-kick this sucker to the ftp server already. >Has Benjamin applied his patch on the 4.0 branch? I have. I am awaiting solaris test details. -benjamin
Re: No effect of -fshort-enums..is it a bug
"Gaurav Gautam, Noida" <[EMAIL PROTECTED]> writes: > Does -fshort-enum guides the size of enumeration type or the size of > enumerator constant ? An enumerator constant is not an object, thus it has no size of its own. Since the enumerator constants are of type int, not the enum type, -fshort-enum should not have any effect on their type. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC 4.0.2 and PR 23993
Mark Mitchell wrote: 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting on my disk.) 2. Apply the patch, respin the release, and release it. 3. Apply the patch, spin RC3, and go through another testing cycle. I vote for option 3., not 1. and also not 2. (sorry ;) Paolo.
Re: GCC 4.0.2 and PR 23993
Mark Mitchell <[EMAIL PROTECTED]> wrote: > 1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting >on my disk.) > > 2. Apply the patch, respin the release, and release it. > > 3. Apply the patch, spin RC3, and go through another testing cycle. My feeling is that these 4.0 releases are under the reflectors, everybody looks at them since it's a new GCC cycle and they want to see if it's getting better or worse. I don't think we should rush bugfixes releases. My humble opinion is to go with RC3, and possibly test it with Boost to make sure the static data member patch didn't totally break it. It would be unfortunate to regress too much in bugfix releases. -- Giovanni Bajo
[RFC] propagating loop dependences from trees to RTL (for SMS)
As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html I would like to improve SMS by passing data dependencies information computed in tree-level to rtl-level SMS. Currently data-dependency graph built for use by SMS has an edge for every two data references (i.e. it's too conservative). I want to check for every loop, using functions defined in tree-data-ref.c, if there are data dependencies in the loop. The problem is how to pass this information to SMS (note - we're only trying to convey whether there are no dependencies at all in the loop - i.e. one bit of information). The alternatives being considered are: 1. Introduce a new BB bit flag and set it for the header BB of a loop that has no data dependencies. This approach already works, but only if the old loop optimizer (pass_loop_optimize) is disabled (otherwise the bit doesn't survive). One potential problem is that the loop header BB may change between the tree-level and SMS as result of some optimization pass (can that really happen?) 2. Use a bitmap (as suggested in http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01353.html) that is indexed using the BB index. In my case I need to define and use the property within different functions. I can define a static function "set_and_check_nodeps(bb_loop_header)" and define a bitmap there. Like the previous solution, The problem that can arise is that some intermediate optimizations can change the header of the loop. By the way, is it guaranteed that a BB keeps the same index throught the entire compilation? 3. Use insn_notes - introduce a new note "NOTE_INSN_NO_DEPS_IN_LOOP" to be inserted after the "NOTE_INSN_LOOP_BEG" for relevant loops. 4. Other ideas? thanks, Vladimir
Request for testsuite help (gcc.dg/compat)
I was wondering if I could get some help/advice from a testsuite expert. I have a patch that I want to submit that makes sure elements of an array are not given an alignment greater than their size. See http://gcc.gnu.org/ml/gcc/2005-03/msg00729.html This test was causing a bunch of regressions, most of which have been fixed now by Jakub and Dorit. But the patch still causes a couple of regressions in the gcc.dg/compat tests that I have been unable to fix. The failures I get are: FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_y_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_y_tst.o compile There used to be more layout failures but Jakub submitted a patch earlier (May 2005) that fixed all but these. I know that the gcc.dg-struct-layout-1_generate program creates a t002_test.h header file and that that file contains: T(582,void * atal8 a[2];double b;unsigned short int c;,F(582,a[0],(void *)&intarray[78],(void *)&intarray[187])F(582,b,198407.656250,218547.203125)F(582,c,55499U,5980U)) and that atal8 is a define for "__attribute__((aligned (8)))" which means that we get "void * __attribute__((aligned (8))) a[2];" and that is what is causing the problem (8 byte alignement of the elements in an array where the elements are only 4 bytes long. But what I have not been able to do is to figure out how to get gcc.dg-struct-layout-1_generate to stop generating this type. Even after looking at Jakubs patch that fixed the other layout failures, I haven't been able to come up with a fix. Can anyone help me with this? Steve Ellcey [EMAIL PROTECTED]
Re: failed to build libgfortran gcc-4.0.1 on mips-sgi-irix6.5
Rainer Emrich <[EMAIL PROTECTED]> writes: > /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/xgcc > - > -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/ > - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/ > - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/lib/ > - -isystem > /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/include > - -isystem > /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/sys-include > - -DHAVE_CONFIG_H -I. > - > -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran > - -I. > - > -iquote/raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/io > - -std=gnu99 -Wall -O2 -g -O2 -mabi=32 -c > /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/generated/exp_c8.c > - -o exp_c8.o > /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/generated/exp_c8.c:38: > error: conflicting types for 'cabs' > /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/include/math.h:676: > error: previous declaration of 'cabs' was here This is a known bug (PR libfortran/15266), fixed in the upcoming GCC 4.0.2 release by this patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00902.html Hope this helps. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Re: No effect of -fshort-enums..is it a bug
On Wed, Sep 21, 2005 at 10:54:56AM -0400, Robert Dewar wrote: > Daniel Jacobowitz wrote: > > > >I'm not 100% sure what #3 means for enumerators whose value does not > >fit in the range of "int", but it's pretty clear that the > >implementation is not allowed to change the type of enumerators. > > Of course an implementation can do whatever it likes in response > to switches, compiler dependent declarations etc. Yes, but -fshort-enums is not intended to interfere with C99 compliance. And nowadays it doesn't. -- Daniel Jacobowitz CodeSourcery, LLC
moene.indiv.nluug.nl is back in business (black and white only, though).
L.S., The host of my domain has been forcefully upgraded to an HP zv6025, sporting an Athlon 64 processor, 512 Mbyte of memory and 60 Gbytes of disk. The upgrade took so long (2.5 months) because I was determined to run Debian AMD64 on it (the hardware was delivered next day). Coming weekend I'll concentrate on the crest of Debian installation - the summit of geekdom [ Scene 23: The Bridge of Death ] ... KEEPER: Stop - what's your name ? MOENE: I am Moene, the King of the Blind. KEEPER: What's your quest ? MOENE: My quest is to find the holy XF86Config-4. KEEPER: What's the airspeed accelleration of an unpatched Windows System ? MOENE: Windows 2000 or Windows XP ? KEEPER: I ... I don't know that - Aaaarrhhh! ... BEDEVERE: You sure know a lot about Windows systems ! MOENE:As a King, you have to know these things ... ... ... clop, clop, whinny ...
Re: make distclean can not remove intl/config.cache
Yao Qi <[EMAIL PROTECTED]> writes:
> Make distclean can not remove intl/config.cache and fixincludes/config.cache.
>
> The configure commandline I used in GCC building is
> ../gcc-dfp-cvs-Aung-10/configure --enable-languages=c --enable-shared
> --enable-threads=posix --enable-checking --with-system-zlib
> --enable-__cxa_atexit -with-cpu=default32 --target=powerpc64-linux
> --host=powerpc64-linux --build=powerpc64-linux
> --with-as=/home/qiyao/binutils/binutils_build/gas/as-new
> --with-ld=/home/qiyao/binutils/binutils_build/ld/ld-new
>
> I think these two cache files should be removed when make distclean, but I am
> not sure about it, would anyone like to take some look? Any suggestion and
> comments are highly appreciated!
Sounds like a bug.
> May I code a patch on this?
Yes, please.
One way to fix this would be to convert those directories to use
automake, but it would be fine to just add config.cache to the list in
the distclean targets in {intl,fixincludes}/Makefile.in.
Ian
warning about classpath import
I'm finally ready to do another classpath import, and near the last minute I realized that the import may temporarily break the build, due to an unfortunate interaction between the classpath Makefile and the way cvs import works. FWIW I'd prefer to continue using cvs import since it does seem to help the process a little. So, I thought I would put off the import for a little while and warn people about it. Unless there are objections I am going to do the import on Friday. I've already done all the needed testing so the window of breakage (should any occur) will be reasonably small -- enough time to import, update, and then apply a few required patches to libgcj. Tom
Re: proposed Opengroup action for c99 command (XCU ERN 76)
[EMAIL PROTECTED] (Joseph S. Myers) wrote on 16.09.05 in <[EMAIL PROTECTED]>:
> C++ requires (A) and provides examples of valid programs where it can be
> told whether a normalisation of UCNs is part of the implementation-defined
> phase 1 transformation. As I gave in a previous discussion,
>
> #include
> #include
> #define h(s) #s
> #define str(s) h(s)
> int
> main()
> {
> if (strcmp(str(str(\u00c1)), "\"\\u00c1\"")) abort ();
> if (strcmp(str(str(\u00C1)), "\"\\u00C1\"")) abort ();
> }
Incidentally, gcc 3.3.5 passes this test.
However, I'm far from convinced that this is reasonable for a compiler
supporting UCNs. It seems to me they really ought to be handled more like
trigraphs, so that this would be
if (strcmp(str(str(\u00C1)), "\"\u00C1\"")) abort ();
(note one less backslash), and the case of the C would be irrelevant - in
fact, *anything* that makes it relevant feels like a bug to me.
I think comparing \u00C1 to \xC1 is a false friend here - \xC1 is only
valid inside a string. Instead look at identifiers.
If str(str(ab\00C1cd)) == "\"ab\\00C1cd\"", then I'll certainly be
unpleasantly surprised - that is almost certainly not what I wanted.
MfG Kai
Re: Warning C vs C++
[EMAIL PROTECTED] (Per Abrahamsen) wrote on 19.09.05 in <[EMAIL PROTECTED]>: > Robert Dewar <[EMAIL PROTECTED]> writes: > > > Per Abrahamsen wrote: > > > >> The idea was that you would be sure to get all the (boolean) warnings > >> that are relevant for your project, and can give an explicit reason > >> for each warning you don't want. > >> It would be particularly useful when upgrading GCC, in order to be > >> sure you get the benefit of any new boolean warnings added. > > > > Of course any generally useful new boolean warnings would be > > included in -Wall. > > Yeah, but I want the specifically useful warnings as well :-) > > From my Makefile: > > WARNING = -W -Wall -Wno-sign-compare \ > -Wconversion -Woverloaded-virtual \ > -Wsign-promo -Wundef -Wpointer-arith -Wwrite-strings > # -Wold-style-cast: triggered by header files for 2.95/woody > # -Wmissing-noreturn: triggered by some virtual functions. > # -Wmissing-prototypes -Wstrict-prototypes: Not C++ flags. > > At some point I went through the manual and added all the warning > flags I could find, then commented out those that did not apply to my > coding style or environment. Apparently there were six additional > flags that either didn't trigger any warnings on my code, or where I > found a rewrite made the code clearer. That is a pretty common way of doing things. Incidentally, any time I've done this, I wanted labels on warnings as to what option was responsible (which we finally seem to be getting) instead of guessing ... and more than once I'd have loved to keep about half of a warning flag whose other half was just noise: many of gcc's warning flags are too coarse-grained. Also, there should probably be more documentation to "so, how do I avoid this particular warning, then?" - there are a number of cases where it's highly nonobvious. When all you can do to silence a warning is switch it off, that detracts from the value of said warning. For example, the longjump endangers variable warning (I forget the exact wording) - how do I tell it that I don't care about this variable when there's a longjump, and how do I convince the code generator to not endanger this other variable? Without knowing that, what do I get from the warning? MfG Kai
Re: Warning C vs C++
> Incidentally, any time I've done this, I wanted labels on warnings > as to what option was responsible -fdiagnostics-show-option
Re: Segmentation Fault building GCC for i686-pc-mingw32
Correlating the stacktrace with CVS revealed that this was fixed a few hours after I updated. The bug was 23929. Ranjit, thanks for the help getting the debugger going. TJ
Re: warning about classpath import
Tom Tromey wrote: I'm finally ready to do another classpath import, Do you plan on another classpath import before the 4.1 release? David Daney.
Re: GCC 4.0.2 and PR 23993
Giovanni Bajo wrote: > Mark Mitchell <[EMAIL PROTECTED]> wrote: > > >>1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting >> on my disk.) >> >>2. Apply the patch, respin the release, and release it. >> >>3. Apply the patch, spin RC3, and go through another testing cycle. > > My humble opinion is to go with RC3 There were three opinions, all in this direction. That's why I asked. I'll put an RC3 as soon as I can. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: > On Friday, September 16, 2005, at 10:19 AM, Jonathan Turkanis wrote: > >> > I think I can give you an answer which is completely correct and yet >> > completely useless: -fvisibility=default is supported on every platform. >> >> Thank you -- it's not completely useless. > It is. > >> I don't want to recommend that users supply -fvisibility=default > Telling users to supply that flag is useless. It is the default. It's advertised as the default, but the threads I cited in my last post suggest that in some cases specifying -fvisibility=default produces different results that not specifying any default visibility option, regardless of what the spec says (see below). > Conceptually, you would want to tell them to not use -fvisibility=hidden. > >> if it will result in an 'unrecognized option' error on some platforms. >> I sense a joke lurking here. > We are confounded as to why you would want to tell a users to specify a flag that is the default. After reading to the end of your email, I now understand your question better. I didn't mention recommending -fvisibility=default until *after* you made the remark to which I was responding. >> > As Mike says, >> >> >> If you tell us what the real question is, maybe we can answer that one. >> >> To me, that sounds like an insult > No, we just have enough experience and knowledge, and we actually do want to help you, but we know enough to know you are hiding the real question from us, Give me a break! What am I trying to hide? Not that I'm writing a book. I've posted dozens of messages to various newsgroups in the course of my research, and I've mentioned the fact that I was writing a book whenever it was relevant ... or when people seem to be ignoring my questions. What's really going on is that you seem to have assumed I wasn't really asking what I plainly was asking. Below you actually give a pretty good answer to my original question. > and we know that you need the real answer, but we can't give it to you, since we don't have the question. >> : why do you think I wouldn't ask the "real" question? > Experience. I'm tempted to ask "in what?", but I think I don't really want to know. >> The docs for -fvisibility say: "Set the default ELF image symbol visibility to the specified option —- all symbols will be marked with this unless overridden within the code" > > > > You can read this without the word ELF and is looses nothing, in fact, it would be more accurate. Okay. I'll try ignoring words here and there and see if improves the quality of the documentation. My guess is it can't hurt. >> So it seems a fair question to ask where -fvisibility is supported. An answer that isn't "completely useless" would be appreciated. > > > > M-x grep VISIBILITY tells you the answer. What are you grepping? > The answer, is precisely on darwin, and all platforms whose in tree gas assembler is elf whose version is 2.13 and above or if the assembler accepts: > > .hidden foo > > without returning a non-zero return code from the assembler and the linker is 2.13 and above if in tree, otherwise as long as the linker isn't older than 2002-04-04 or people mussed up the version string of the linker or is 2.12.0 or older we suppose symbol visibility. > > Now, did that precisely answer your question? > > Compare that with, every interesting platform now supports visibility default/hidden. > >> I'm trying to decide what recommendations to make with repect to -fvisibility for a forthcoming O'Reilly C++ book. > Gosh, now we have a hint at the real question. Now that you have a hint, tell me what it is. > I suspect the answer is, > go ahead and use it >> At first it looked like a nice way to enable Windows-style exporting of symbols from dynamic libraries on some UNIX/Linux platforms. Now it appears that there may be some serious problems with it, at least as currently implemented. See e.g., http://article.gmane.org/gmane.comp.lib.boost.build/10072 and http://article.gmane.org/gmane.comp.lib.boost.build/10110. Those threads were also the first indication I had that -fvisibility was supported on some non-ELF platforms. >> >> I don't have time to verify the assertions made in that thread -- the book went into production in August -- but I trust the author and he seems to have conducted some careful experiments. I'm now inclined just to say that the option, together with the attribute, offered the possibility of Windows-style exporting on some (unspecified) platforms, but that initial implementation is buggy; -fvisibility=default should be specified everywhere, until further notice. > > > Ah, now we can start getting to the meat of the question. > > Buggy? Aha! Now I've got your attention. > I think I might disagree with that assessment if you are referring to the inability to catch hidden types across the hidden boundary. > > Anyway, the real issue boils down to some rather s
Re: [gomp] implement a handfull of easy directives
Richard Henderson <[EMAIL PROTECTED]> writes:
> * builtin-types.def (BT_PTR_LONG, BT_PTR_PTR, BT_FN_BOOL, BT_FN_INT,
> BT_FN_VOID_PTRPTR, BT_PTR_FN_VOID_PTR, BT_FN_VOID_UINT_UINT,
> BT_FN_BOOL_LONGPTR_LONGPTR, BT_FN_VOID_OMPFN_PTR_UINT,
> BT_FN_VOID_OMPFN_PTR_UINT_UINT,
> BT_FN_BOOL_LONG_LONG_LONG_LONGPTR_LONGPTR,
> BT_FN_BOOL_LONG_LONG_LONG_LONG_LONGPTR_LONGPTR,
> BT_FN_VOID_OMPFN_PTR_UINT_LONG_LONG_LONG,
> BT_FN_VOID_OMPFN_PTR_UINT_LONG_LONG_LONG_LONG): New.
I'm working on a target with two gazillion special builtins (well, a
few hundred) and I got tired of defining a new special type every time
I wanted to define a different builtin. So I did this, slightly
simplified:
enum c2_builtin_type
{
C2_INT, /* int */
C2_SHORT, /* short */
C2_CHAR, /* char */
C2_VPTR, /* void * */
C2_VOID, /* void */
/* plus other weird types */
C2_NONE, /* indicates no type */
C2_MAX
};
struct builtin_description
{
/* The code for this function. */
int icode;
/* The name of the builtin function. */
const char *name;
/* Code for return type. */
enum c2_builtin_type ret_type;
/* Code for parameter types. */
enum c2_builtin_type param_types[6];
};
tree btypes[C2_MAX];
struct ftype_cache
{
tree fn_type;
struct ftype_cache *next_arg[C2_MAX];
} ftypes;
btypes[C2_INT] = integer_type_node;
btypes[C2_SHORT] = short_integer_type_node;
btypes[C2_CHAR] = char_type_node;
btypes[C2_VPTR] = ptr_type_node;
btypes[C2_VOID] = void_type_node;
btypes[C2_NONE] = NULL_TREE;
(plus all the other weird types)
for (i = 0; i < ARRAY_SIZE (builtins); ++i)
{
const struct builtin_description *p;
struct ftype_cache **pf;
unsigned int j;
p = &builtins[i];
/* We cache the function type when we build it so that we don't
duplicate function types unnecessarily. */
gcc_assert (btypes[p->ret_type] != NULL_TREE);
pf = &ftypes.next_arg[p->ret_type];
for (j = 0; j < 6; ++j)
{
if (*pf == NULL)
{
*pf = alloca (sizeof (struct ftype_cache));
memset (*pf, 0, sizeof (struct ftype_cache));
}
if (p->param_types[j] == C2_NONE)
break;
gcc_assert (btypes[p->param_types[j]] != NULL_TREE);
pf = &(*pf)->next_arg[p->param_types[j]];
}
if (*pf == NULL)
{
*pf = alloca (sizeof (struct ftype_cache));
memset (*pf, 0, sizeof (struct ftype_cache));
}
if ((*pf)->fn_type == NULL)
{
gcc_assert (p->ret_type != C2_NONE);
(*pf)->fn_type = build_function_type_list (btypes[p->ret_type],
btypes[p->param_types[0]],
btypes[p->param_types[1]],
btypes[p->param_types[2]],
btypes[p->param_types[3]],
btypes[p->param_types[4]],
btypes[p->param_types[5]],
NULL_TREE);
}
lang_hooks.builtin_function (p->name, (*pf)->fn_type,
p->icode, BUILT_IN_MD,
NULL, NULL);
}
The builtins table is initialized with a separate .def file, but it
boils down to initializers this:
{ code, "__builtin_name", C2_INT,
{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
This way I only have to write the type in one place, I only create the
function types I need, and the types are cached so I don't create the
same type more than once.
Much simpler in the long run, I think.
(And this is why I needed this patch:
2005-02-11 Ian Lance Taylor
* tree.c (build_function_type_list): Work correctly if there are
no arguments.
for the case of a builtin which takes no parameters, for which we wind
up calling build_function_type_list (NULL_TREE, NULL_TREE, ).)
Ian
Re: On which platforms is -fvisibility supported?
Geoffrey Keating wrote: > Jonathan Turkanis <[EMAIL PROTECTED]> writes: > >> Geoffrey Keating wrote: >> >>> Jonathan Turkanis <[EMAIL PROTECTED]> writes: If you tell us what the real question is, maybe we can answer that one. >> >> >> To me, that sounds like an insult: why do you think I wouldn't ask the >> "real" question? But I'll give you the benefit of the doubt and assume >> you mean something as yet unspecified. > I think the real question you meant to ask was "I am writing a book. > I'm trying to decide what recommendations to use with respect to > -fvisibility. Is it widely supported? Where? And do you have any > other suggestions as to what to recommend?" I'm getting tired of this. You assumed I'm must have meant something else than what I plainly asked; once I mentioned that I was writing a book, you realized I really meant what I said. There's no point trying to retrospectively justify your obfuscation. > [Please don't think that I was trying to insult you. Finding the real > question to ask is very hard, but is often much more useful than > finding an answer---a lot of the time, by the time you've found the > question, the answer is obvious.] I feel like I've finally come of age. Thanks. > So, the first thing you should know is that all -fvisibility options > are supported when you are using a recent GNU assembler with ELF. > -fvisibility=default is supported everywhere. -fvisibility=hidden is > supported on all Darwin platforms (but the other two settings are not). That wasn't so hard now, was it? > Something that you should understand, though, is that > -fvisibility=hidden is not an optimisation option. It changes the > meaning of a program. The change it makes is that functions, > variables, and types defined in one dynamic library are different to > functions, variables, and types of the same name defined in a > different dynamic library; so they have different addresses, different > contents, and different typeinfo. I under this. > Sometimes, this is exactly what you want, and other times it isn't. > If it's mostly what you want but not completely, you can use the > #pragma and the attribute to control it at a finer level; the option > only sets the default for the #pragma, and the #pragma in turn only > sets the default for the attribute. When you build Boost as a shared > library, that's an example of where you don't want this behaviour, at > least for certain types defined in the Boost headers. When you build > it as a static library, that's an example of where you probably do > want this behaviour. As I mentioned in my reply to Mike Stump, the Boost problems apparently occur even if none of the visibility options, pragmas or attributes are used. -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Jonathan Turkanis <[EMAIL PROTECTED]> writes: > I'm getting tired of this. You assumed I'm must have meant something > else than what I plainly asked; once I mentioned that I was writing a > book, you realized I really meant what I said. That's pretty much it, yes. Many years of experience have shown us by tedious example that most people ask the wrong question. Sorry you got caught, and sorry you feel insulted. Your question was easy to write, but was one that only a couple of people would know how to answer off the top of their head. If you want to get a question answered by an expert, you have to make the effort to not seem like a random newbie. I'm sorry it has to be that way, but that's the reality of the net. Ian
Re: make distclean can not remove intl/config.cache
Ian Lance Taylor wrote:
Sounds like a bug.
May I code a patch on this?
Yes, please.
One way to fix this would be to convert those directories to use
automake, but it would be fine to just add config.cache to the list in
the distclean targets in {intl,fixincludes}/Makefile.in.
Ian
Thanks for your comments. Here is a patch for it.
2005-09-22 Yao Qi <[EMAIL PROTECTED]>
* gcc/intl/Makefile.in (distclean): Add config.cache.
* gcc/fixincludes/Makefile.in (distclean): Likewise.
Index: gcc/fixincludes/Makefile.in
===
RCS file: /cvsroot/gcc/gcc/fixincludes/Makefile.in,v
retrieving revision 1.11
diff -c -r1.11 Makefile.in
*** gcc/fixincludes/Makefile.in 15 Aug 2005 00:50:43 - 1.11
--- gcc/fixincludes/Makefile.in 22 Sep 2005 05:18:28 -
***
*** 134,140
rm -f mkheaders mkheaders.almost
distclean: clean
! rm -f Makefile config.h config.log config.status stamp-h
maintainer-clean: distclean
rm -f $(srcdir)/fixincl.x
--- 134,140
rm -f mkheaders mkheaders.almost
distclean: clean
! rm -f Makefile config.h config.log config.status stamp-h config.cache
maintainer-clean: distclean
rm -f $(srcdir)/fixincl.x
Index: gcc/intl/Makefile.in
===
RCS file: /cvsroot/gcc/gcc/intl/Makefile.in,v
retrieving revision 1.5
diff -c -r1.5 Makefile.in
*** gcc/intl/Makefile.in13 May 2005 08:03:46 - 1.5
--- gcc/intl/Makefile.in22 Sep 2005 05:51:01 -
***
*** 182,188
clean: mostlyclean
distclean: clean
! rm -f Makefile ID TAGS
maintainer-clean: distclean
--- 182,188
clean: mostlyclean
distclean: clean
! rm -f Makefile ID TAGS config.status config.cache config.log
maintainer-clean: distclean
--
Regards, Yao
Yao Qi
