Re: [Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)
> > > > --- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17 > --- > Well, some of the structural analysis for which emit errors is done even later > than that, so it would be naive to pretend that we can catch everything during > parsing. I don't understand why it is hard. > > If you find a non-intrusive way of bubbling this diagnostic up to the parser, > be my guest. Otherwise, we should close as WONTFIX. GDR will become upset with you if you close as WILL NOT FIX. Also I did not mark this as a regression on purpose so we can keep track of the problems with reporting errors late in the game. Really after the front-end is done parsing, calling error should be turned into an internal error. -- Pinski
Re: [Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
> > > > --- Comment #5 from dann at godzilla dot ics dot uci dot edu 2006-05-03 > 18:54 --- > IMO Comment #4 does not look close enough at what is actually happening. > IMO tree-ch is the root cause here. > > Given the above CFG, critical edge splitting transforms this into: > Given the above CFG PRE will dutifully fill with code a lot of the empty basic > blocks: None of the above issues are the real issue. TREE CH is doing the correct thing simplifying the loop. PRE is doing the correct thing by getting rid of redundants. The main issue is really the RA not being so good. -- Pinski
Re: [Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
> > > > --- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 --- > (In reply to comment #4) > > Then the real question is why do you think this is a bug? > > 1. it is a bug to create temporaries and assert 'volatile' on them Why do you say that? > 2. there is code in create_tmp_var_raw() that creates a type with > qualifiers removed, but this new_type is then not used at the > moment. I don't think create_tmp_var_raw should remove the quals. -- Pinski
Re: mingw gcc-4.2-20060506
> > > compile fails using mingw gcc-4.0.3 > > using ../configure -v --enable-languages=c,c++ --with-gcc --with-gnu-ld > --with-gnu- > as --prefix=/mingw > > i get an error: > > make[3]: *** No rule to make target `../../gcc/objc/objc-act.c', needed by > `s-gtype'. Stop. > make[3]: Leaving directory `/home/user/gcc-4.2-20060506/mybuild/gcc' > make[2]: *** [all-stage1-gcc] Error 2 > make[2]: Leaving directory `/home/user/gcc-4.2-20060506/mybuild' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/home/user/gcc-4.2-20060506/mybuild' > make: *** [all] Error 2 You did not say what tar file you downloaded but I am going to assume gcc-core (since this is the only place where the problem is). Anyways this is PR 27063 and it is only a packaging problem. -- Pinski
Re: templates and inheritance
On May 15, 2006, at 9:15 PM, Bar-Tov Aharon-R53349 wrote:
hello,
something that seems like a problem (havn't found something in the
bug base).
template
class t_base
{
public:
T *ptr;
};
template
class t_derived : public t_base
{
public:
t_derived() { ptr = NULL; }
};
This is described on the changes page for 3.4:
http://gcc.gnu.org/gcc-3.4/changes.html:
In a template definition, unqualified names will no longer find
members of a dependent base (as specified by [temp.dep]/3 in the C++
standard). For example,
template struct B {
int m;
int n;
int f ();
int g ();
};
int n;
int g ();
template struct C : B {
void h ()
{
m = 0; // error
f (); // error
n = 0; // ::n is modified
g (); // ::g is called
}
};
You must make the names dependent, e.g. by prefixing them with this-
>. Here is the corrected definition of C::h,
template void C::h ()
{
this->m = 0;
this->f ();
this->n = 0
this->g ();
}
As an alternative solution (unfortunately not backwards compatible
with GCC 3.3), you may use using declarations instead of this->:
template struct C : B {
using B::m;
using B::f;
using B::n;
using B::g;
void h ()
{
m = 0;
f ();
n = 0;
g ();
}
};
-- Pinski
Re: [Bug target/27082] segfault with virtual class and visibility ("hidden")
> > > > --- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 --- > Hmm, that's interesting. When I call g++ from a Makefile I get a > "unrecognizable insn" error but calling it directly leads to the segfault. > I've no idea if this "unrecognizable insn" error is helpful in any way but I > thought I'd mention it here. > > Anyway, I can confirm this segfault on Alpha with gcc 4.0/4.1/4.2. That means there is some memory curption going on. -- Pinski
Re: [Bug c++/27648] [4.0/4.1/4.2 Regression] ICE on attribute on pointers in static_cast
> > > > --- Comment #3 from janis at gcc dot gnu dot org 2006-05-22 18:40 --- > I get errors for both the submitter's testcase and the testcase in comment > #1. > With the comment #1 testcase on powerpc-linux: > > Is the testcase valid code? I can do a regression hunt for when the compiler > started getting the ICE instead of errors, but is that helpful? Yes it is valid though rejected. Yes it is still helpful to figure out when the ICE started to happen. -- Pinski
Re: [Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
> > > > --- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 --- > It is creative offsetof indeed -- this a "explanation" from a bit of code > referenced to this one [while it isn't free yet, its license does allow > posting > bits of it online]: > Looks like someone was desperate to get his stuff to compile with -Werror > without having to fix the cause. Well it is undefined for non-PODs to do offsetof which is why GCC warns. -- Pinski
Re: [Bug libfortran/24685] real(16) formatted input is broken for huge values
>
>
>
> --- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-24 18:58
> ---
> (In reply to comment #18)
> > it is still broken on powerpc{,64}
>
> Hi Jakub, I'm not sure exactly what is still broken. On
> powerpc-apple-darwin7.9.0, with mainline gfortran 20060512:
Darwin is broken a different way and it is a mess that I was trying to fix but
it
is still broken because I don't care that much anymore.
-- Pinski
Re: [Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap
> > > > --- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-24 22:18 > --- > The bug is with > > Path: . > URL: svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 > Revision: 114050 > Node Kind: directory > Schedule: normal > Last Changed Author: jsm28 > Last Changed Rev: 113935 > Last Changed Date: 2006-05-20 19:51:30 +0200 (Sat, 20 May 2006) > Properties Last Updated: 2006-05-20 21:30:42 +0200 (Sat, 20 May 2006) > > The call to add_referenced_var in tree-ssa-loop-manip.c appears > to have been introduced by revision 114018, by Andrew MacLeod. > In tree-dfa.c, I see a static inline function of this name. There are > several other uses, without prototypes or function definitions: Something must be wrong with your download of GCC. gimplify.c: add_referenced_var (t); lambda-code.c: add_referenced_var (resvar); lambda-code.c: add_referenced_var (resvar); lambda-code.c: add_referenced_var (ivvar); lambda-code.c: add_referenced_var (ivvar); lambda-code.c: add_referenced_var (uboundvar); tree-complex.c: add_referenced_var (r); tree-dfa.c: add_referenced_var (t); tree-dfa.c:add_referenced_var (*tp); tree-dfa.c:add_referenced_var (tree var) tree-dfa.c: add_referenced_var (t); tree-flow.h:extern void add_referenced_var (tree); tree-if-conv.c: add_referenced_var (var); tree-outof-ssa.c: add_referenced_var (tmp); tree-outof-ssa.c: /* add_referenced_var will create the annotation and set up some tree-ssa-alias.c: add_referenced_var (tag); tree-ssa-alias.c: add_referenced_var (global_var); tree-ssa-alias.c: add_referenced_var (subvar); tree-ssa-alias.c:add_referenced_var in the above loop will take care of tree-ssa-loop-im.c: add_referenced_var (var); tree-ssa-loop-ivopts.c: add_referenced_var (cand->var_before); tree-ssa-loop-manip.c: add_referenced_var (var); tree-ssa-loop-manip.c:add_referenced_var (var); tree-ssa-operands.c: a VUSE for .GLOBAL_VAR if it has been created. See add_referenced_var tree-ssa-phiopt.c: add_referenced_var (tmp); tree-ssa-phiopt.c:add_referenced_var (tmp); tree-ssa-phiopt.c: add_referenced_var (tmp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (temp); tree-ssa-pre.c: add_referenced_var (SSA_NAME_VAR (TREE_OPERAND (stmt, 0))); tree-ssa-structalias.c: add_referenced_var (heapvar); tree-ssa-structalias.c: add_referenced_var (heapvar); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-tailcall.c: add_referenced_var (tmp); tree-vect-patterns.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (dest); tree-vect-transform.c: add_referenced_var (tmp); tree-vect-transform.c: add_referenced_var (addr_expr); tree-vect-transform.c: add_referenced_var (vect_ptr); tree-vect-transform.c: add_referenced_var (vec_dest); tree-vect-transform.c: add_referenced_var (new_var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (var); tree-vect-transform.c: add_referenced_var (addr_tmp); tree-vect-transform.c: add_referenced_var (or_tmp); tree-vect-transform.c: add_referenced_var (and_tmp); That is what I get. Are you sure that you are not having a mix of 4.1 code and trunk code. -- Pinski
Re: [Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
> > > > --- Comment #9 from danglin at gcc dot gnu dot org 2006-05-24 23:23 > --- > Subject: Bug 27627 > > Author: danglin > Date: Wed May 24 23:23:10 2006 > New Revision: 114059 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114059 > Log: > PR target/27627 > * pa/pa-modes.def: Use mips_single_format, mips_double_format and > mips_quad_format formats instead of ieee_single_format, > ieee_double_format and ieee_quad_format formats, respectively. You might not want to us MIPS_QUAD format because it is not even close to IEEE Quad format but instead it is more like the PPC quad format. -- Pinski
Re: [Bug ada/27769] cross-gnatmake needs host gcc
> > > > --- Comment #2 from laurent at guerby dot net 2006-05-25 18:08 --- > I'm unable to build even a C compiler to the avr target, binutils-2.16.1 + > newlib-1.13.0 + gcc-4.1.1-prerelease I get: avr has its own libc and is not supported by newlib. -- Pinski
Re: Return code of gcc
On Jun 4, 2006, at 10:12 AM, Vu Quang Cao wrote: Hi, I'm writing a program, which executes gcc for compiling a C proram. Now, I need the returned code of gcc after compiling. This is offtopic of this channel. Also it depends on what OS you are using? From an unix shell script you can use $? as the return code. -- Pinski
Re: bug report
Hi Hayashi-san,
I am writing to you regarding bug report
about under this code
aaa(int bbb) {
char *ccc[bbb]
}
gcc response no error. but memory error occured.
GCC accepts this as an extension to the ISO C 90 and ISO C++
languages by default. The extension is called Variable Length
Arrays and it is officially part of the ISO C99 language.
Thanks,
Andrew Pinski
Re: [Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
> > > > --- Comment #7 from dnovillo at gcc dot gnu dot org 2006-06-12 21:10 > --- > > This is still an issue. http://gcc.gnu.org/ml/fortran/2006-06/msg00178.html I think this is only an issue when you have a normal multi lib x86_64 but use --disable-multilib. -- Pinski
Re: [Bug c++/28017] lack of guard variables for explicitly instantiated template static data
> #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl) \ > || DECL_ONE_ONLY (decl) \ > || DECL_WEAK (decl) \ > || > (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ > || (! DECL_EXPLICIT_INSTANTIATION (decl) \ > && ! DECL_TEMPLATE_SPECIALIZATION (decl) > > ? The latter. -- Pinski
Re: [Bug c++/28017] lack of guard variables for explicitly instantiated template static data
> > > > --- Comment #7 from hhinnant at apple dot com 2006-06-13 21:41 --- > (In reply to comment #6) > > Subject: Re: lack of guard variables for explicitly instantiated template > > static data > > > > > #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl) > > > \ > > > || DECL_ONE_ONLY > > > (decl) \ > > > || DECL_WEAK (decl) \ > > > || > > > (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ > > > || (! DECL_EXPLICIT_INSTANTIATION (decl) \ > > > && ! DECL_TEMPLATE_SPECIALIZATION (decl) > > > > > > ? > > > > The latter. > > Thanks. But this doesn't pass the test case on darwin. I'm not familiar > enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC. Could > you > double check the above. The "!" in front of DECL_EXPLICIT_INSTANTIATION looks > especially suspicious to me. You want the opposite of that like: (TARGET_WEAK_NOT_IN_ARCHIVE_TOC && (DECL_EXPLICIT_INSTANTIATION (decl) || DECL_TEMPLATE_SPECIALIZATION (decl))) I was quoting the case when DECL_WEAK would be set on the decl. TARGET_WEAK_NOT_IN_ARCHIVE_TOC is only defined to 1 for darwin. -- Pinski
Re: [Bug libgomp/28008] [4.2 Regression] build failure due to PTHREAD_STACK_MIN not being declared
On Jun 14, 2006, at 8:17 AM, rth at gcc dot gnu dot org wrote: --- Comment #2 from rth at gcc dot gnu dot org 2006-06-14 15:17 --- libgomp is a new feature, and therefore has no "regressions" per se, and therefore any bug fix applies. That does not matter. Please read Mark's email again. Would you have applied this to the branch, if no then you should not have applied the patch. Applying a patch which just fixes a bug and not a regression when the mainline is in release-branch rules is just wrong. -- Pinski
Re: [Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
> The problem turned up a week or so before I filed PR 27528, and after > considerable rs6000 changes made by David Edelsohn. The change just exposed a latent bug. I am trying to make sure that you understand that and not blaming David. Could someone please CC Richard Sandiford, if he is not already since -fsection-anchors is his creation. -- Pinski
Re: [Bug middle-end/26991] Target Help Seg Fault.
On Jun 26, 2006, at 9:41 AM, corsepiu at gcc dot gnu dot org wrote: --- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 16:41 --- Traceback: => the SEGFAULT occurs in memset. Could it be, "static char* printed" should be initialized = 0? Looks like reload is storing to cl_options_count :). There was a 4.2 bug about this, somehow it got exposed for 4.1.x now. -- Pinski
Re: [Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
> > > std::cout.width(6000); > This program allocates 60 million bytes on the stack in the last output > statement. You get what you deserve really. If there are checks then it will be slow. -- Pinski
Re: [Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
> > > > --- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 > 22:04 --- > Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 > UNIX > V5.1B > > The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). On x86-linux-gnu with FC4 I hear, I could not reproduce it on FC5, I am in the middle of a GCAC checking build. -- Pinski
Re: [Bug libstdc++/28297] New: GCC 4.1.1 fails to build on Mac OS X 10.4.6
> > GCC 4.1.1 fails to build on Mac OS X 10.4.6. > 1. Extract source code. > 2. Open Terminal. > 3. Run ./configure --enable-threads --x-includes=/usr/X11R6 > --x-libraries=/usr/X11R6 --with-cpu=powerpc --with-mpfr=/usr/local/lib > --with-gmp=/usr/local/lib. > 4. Run make. > 5. The following error appears halting the build process: > checking for sin in -lm... configure: error: Link tests are not allowed after > GCC_NO_EXECUTABLES. > make[1]: *** [configure-target-libstdc++-v3] Error 1 > make: *** [all] Error 2 > GCC 4.1.1 should compile properly. > I'm using Apple's GCC 4.0.1 for compiling. This works for me, try using "make bootstrap" instead of make. -- Pinski
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 15, 2006, at 10:45 PM, ams at gnu dot org wrote: Because the rules in config.gcc say so: And that is not why, but that is what is causing linux.h being included? Again why is Linux.h being included? -- Pinski
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 12:17 AM, ams at gnu dot org wrote:
GNU and GNU/Linux are similar enough not to warrant duplication of the
code from linux.h in gnu.h.
Depends, the duplication is small anyways as linux.h is only 129 lines
(including copyright and comments).
In fact it is way wrong now anyways as there is no uclibc for hurd.
So the duplication factor should not matter as there is hardly any
duplication.
Only the following code will be duplicated which is hardly any after
all:
/* Don't assume anything about the header files. */
#define NO_IMPLICIT_EXTERN_C
#undef ASM_APP_ON
#define ASM_APP_ON "#APP\n"
#undef ASM_APP_OFF
#define ASM_APP_OFF "#NO_APP\n"
#undef MD_EXEC_PREFIX
#undef MD_STARTFILE_PREFIX
#undef STARTFILE_SPEC
#if defined HAVE_LD_PIE
#define STARTFILE_SPEC \
"%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%
s;:crtbegin.o%s}"
#else
#define STARTFILE_SPEC \
"%{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%
s;:crtbegin.o%s}"
#endif
#undef ENDFILE_SPEC
#define ENDFILE_SPEC \
"%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
#ifndef CC1_SPEC
#define CC1_SPEC "%{profile:-p}"
#endif
#undef CPLUSPLUS_CPP_SPEC
#define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"
#if defined(HAVE_LD_EH_FRAME_HDR)
#define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
#endif
/* Define this so we can compile MS code for use with WINE. */
#define HANDLE_PRAGMA_PACK_PUSH_POP
#define LINK_GCC_C_SEQUENCE_SPEC \
"%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}"
/* Use --as-needed -lgcc_s for eh support. */
#ifdef HAVE_LD_AS_NEEDED
#define USE_LD_AS_NEEDED 1
#endif
#define TARGET_POSIX_IO
-- Pinski
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 12:45 AM, ams at gnu dot org wrote:
That is from [gcc]/gcc/config/linux.h, I'm talking about
[gcc]/gcc/config/i386/{linux,gnu}.h. Which is also the one causing
problems without the patch I sent.
bzzz, wrong. TARGET_C99_FUNCTIONS is not defined anywhere in
config/i386/linux.h, it is defined in config/linux.h. Also
powerpc-gnu and alpha-gnu are going to have the same issue.
powerpc-gnu is worse though.
Please try again at actually looking into this issue.
It is obviously you did not look into that much.
Also kBSD is incorrect anyways and should be fixed in the same
matter but that is a different bug.
-- Pinski
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 1:07 AM, ams at gnu dot org wrote: Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. -- Pinski
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 1:10 AM, Andrew Pinski wrote: Why it is not obvious and I say the patch is incorrect. Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. If you want them be included. And I still say the patch is incorrect. I already explained why I thought it was incorrect as linux.h should not be included. Also the comment in your patch is incorrect as the definition comes from config/linux.h and not from config/i386/linux.h. -- Pinski
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
On Jul 16, 2006, at 1:25 AM, ams at gnu dot org wrote: The patch is correct, that you think that the code we use from */linux.h should be in */gnu.h is not related to this bug. This is the setup we have used for almost 10 years, and I see no reason to change it. The setup works, it minimises the workload on both parties, and it is clean. Actually you are incorrect about not being related to this bug as it is the reason why this bug showed up and it is not clean as shown by this bug. Move along and fix/post a correct fix to the mailing list. -- Pinski
Re: [Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu wrote: > LSB was merely the umbrella bringing together a bunch of pre-existing > standards > for use in Linux. There is the problem, LSB did the incorrect thing of thinking the written standard applied to what really was being done when the LSB was doing its work. Standards are made to be amended. Witness how many RFCs there are and how many make previous ones outdated. Thanks, Andrew Pinski
Re: Doesn't compile. Is it a bug?
On Wed, Jan 7, 2009 at 11:25 AM, Juan Linietsky wrote: > This code doesn't compile. It complains that A::_say is protected when > in reality it's being used from B. calling A::_say works fine, but > obtaining the address fails compilation. This is not a bug since A::_say is protected and therefor if it was allowed the user could be able to call A::_say from a place normally not allowed to call A::_say. Thanks, Andrew Pinski
Re: [Bug tree-optimization/38835] field-insensitive PTA causes libstdc++ miscompiles
On Fri, Jan 16, 2009 at 10:30 AM, rguenth at gcc dot gnu dot org wrote: > > (void *)((intptr_t)&iptr + (intptr_t)p - (intptr_t)&iptr) > > <==> > > (void *)(intptr_t)p > > which is guaranteed by the std No that is not guaranteed because of: If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type. :).
Re: [Bug tree-optimization/38835] field-insensitive PTA causes libstdc++ miscompiles
On Fri, Jan 16, 2009 at 10:37 AM, rguenth at gcc dot gnu dot org wrote: > > > --- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-16 18:37 > --- > Guaranteed by 7.18.1.4. > "These types are optional." :)
Re: Attachments for gcc bugzilla entry #39028
2009/1/29 Stephan Springl : > Hi, > > I just wanted to upload the attached files to gcc bugzilla entry #39028, but > I always hit a bugzilla bug. Could you please attach these files to the bug > for me? Well first patches go to gcc-patches@ list with a changelog. And then you don't need to upload them. Also try to login before attaching them. Thanks, Andrew Pinski
Re: [Bug target/15623] nop insertion does not look see restrict pointers
Sent from my iPhone On Jun 25, 2009, at 12:30 PM, "rguenth at gcc dot gnu dot org" > wrote: --- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 19:30 --- which makes this bug ... ??? dependent on a bug you're going to file? Most likely closing as won't fix as this is not important for any newer ppcs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
Re: [Bug c/40645] New: Bus error caused by ldd/std instructions in struct copy.
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:33 PM, "dentongosnell at yahoo dot com" > wrote:
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1
'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-
shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/
include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-
gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
To trigger the bug :-
$ gcc align_bug.c
$ ./a.out
Bus error
$
Here is align_bug.c :-
-
#include
struct b_one {
int i;
double d;
};
struct b_two {
int i1;
int i2;
};
union myblock {
struct b_one one;
struct b_two two;
};
void myfunc(union myblock *dp1, union myblock *dp2)
{
dp2->two = dp1->two;
}
int main()
{
int w;
struct b_two a = {1,2};
struct b_two b;
myfunc((union myblock *)&a, (union myblock *)&b);
printf("%d %d\n", b.i1, b.i2);
return 0;
}
--
The problem seems to happen in "myfunc" when the compiled code tries
to copy the 8-byte structure dp2->two to dp1->two, using a ldd/std
instruction pair. The problem seems to be that dp1 and dp2 (ie a and
b in main) aren't strictly enough aligned for that. If you take out
the redundant "int w" in main then a and b happen to be aligned okay
and the bus error doesn't happen.
I think the compiler is assuming "union myblock" has the same
alignment as "struct b_one", which is more strictly aligned than
"struct b_two" because of its double member.
I realise that casting &a to (union myblock*) in main may technically
invoke undefined behaviour... but I think the cast is reasonable given
that union myblock contains the type of a.
One other thing, there is a flag "-mno-faster-structs" which this page
suggests would prevent this sort of ldd/std use
(http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html). Unfortunately
this flag doesn't seem to make any difference to this case.
--
Summary: Bus error caused by ldd/std instructions in
struct copy.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dentongosnell at yahoo dot com
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
Re: [Bug regression/40665] New: dereferencing type-punned pointer warnings cannot be disabled
Sent from my iPhone
On Jul 6, 2009, at 6:12 PM, "mikulas at artax dot karlin dot mff dot
cuni dot cz" wrote:
Gcc became recently (4.4) very bad regarding false positive type-
punned
warnings. In previous versions, the warnings could be suppressed by
casting to
(void *), in 3.x and 4.1 it worked perfectly, in 4.3 it still worked
somehow
(except in -Wstrict-aliasing=3 mode), in 4.4 there are cases where
it doesn't
work at all.
I don't want to completely disable the warnings with -Wno-strict-
aliasing (this
could leave bugs unnotified), but I need a method to disable them on
case-by-case basis once I verified that the code in question is
correct.
Simple example, compile with -O2 -Wall:
extern int c;
int a(void)
{
return *(short *)(void *)&c;
}
This is a very bad example of a false positive as you are acessing an
int as a short; that is undefined. I will look at your code later on,
my laptop for home is currently broken.
In 4.4 the warning can't be disabled at all! The (void *) cast
doesn't suppress
the warning and none of three options to -Wstrict-aliasing helps. In
4.3 the
cast to (void *) suppressed the warning in -Wstrict-aliasing 1,2
modes (and
didn't suppress it in the default mode 3), in 4.4 the warning can't be
suppressed at all.
Gcc developers tried to made these warnings more "intelligent" with
less false
positives, but unfortunatelly they completely broke the method to
disable them
in the specific case. For me, false positives are not a major
problem --- when
I get a false positive, I just read the code, check it and if I
conclude that
it's OK, I disable the warning with (void *).
But if there's no way to disable false positives, it makes the
warnings
completely useless.
--
Summary: dereferencing type-punned pointer warnings cannot
be
disabled
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
Re: [Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
Sent from my iPhone On Jul 6, 2009, at 6:34 PM, "mikulas at artax dot karlin dot mff dot cuni dot cz" wrote: --- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 01:34 --- Created an attachment (id=18146) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces "type- punned" warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
Re: [Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
Thus code is undefined you have an acess of a char array as a struct. Yes you are only taking the address of an element but it is still considered an acess by the standards. Sent from my iPhone On Jul 6, 2009, at 6:34 PM, "mikulas at artax dot karlin dot mff dot cuni dot cz" wrote: --- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 01:34 --- Created an attachment (id=18146) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces "type- punned" warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
Re: [Bug rtl-optimization/40679] New: Optimizer handles loops with volatiles and post-incr. wrong
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com" > wrote:
If the following code is compiled with -Os for ARM or ColdFire, the
exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of
volatile
unsigned long does not show the problem.
I suspect the post-increment optimization to be the problem, because
the
PowerPC version does not show the problem.
Also: Using a different start-address for tbl, does not show the
problem.
It looks more like a wrapping issue. 4*64 = 256. So we go from -256u
to 0 which causes wrapping of the pointer which is undefined and
therefor I think gcc is doing the correct thing (If got my numbers
correct).
The problem has been reported also for 4.4.0.
typedef volatile unsigned long __vu32;
void bs()
{
int i;
__vu32 *tbl = (__vu32 *)0xff00;
for(i = 0; i < 64; ++i){
//-> tbl[i] = (__vu32)10;
*tbl++ = (__vu32)10;
}
}
Cmd-line: arm-none-eabi-gcc -S -Os t.c
Output:
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file "t.c"
.text
.align 2
.global bs
.type bs, %function
bs:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mvn r2, #255
.L2:
mov r3, #10
str r3, [r2], #4
b .L2
.size bs, .-bs
.ident "GCC: (Sourcery G++ Lite 2008q3-39) 4.3.2"
--
Summary: Optimizer handles loops with volatiles and post-
incr.
wrong
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bastian dot schick at sciopta dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-mingw32
GCC target triplet: i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
Re: [Bug tree-optimization/40844] New: O2 optimizes out assignment to bitfield
Sent from my iPhone
On Jul 23, 2009, at 10:22 PM, "jim at bodwin dot us" > wrote:
Incorrect code is produced for the following source with the O2
option. In
particular, the assignment to the bitfield field2 is optimized out
of the code
entirely and regImage is left all zero. Correct code is produced
with the O1
option and (at least) with gcc version 4.3.2.
Source Code
typedef struct hwreg {
short field1 : 4;
short field2 : 2;
short field3 : 10;
} hwreg_t;
void foo(volatile short *hwPtr, short f2) {
hwreg_t regImage; // Place to build reg image bit-by-bit
*(short *) ®Image = 0;
regImage.field2 = f2;
*hwPtr = *((short *) ®Image);
}
I think you are violating c/c++ aliasing rules here.
Object dump
/tmp/foo.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e3a03000mov r3, #0 ; 0x0
4: e24dd004sub sp, sp, #4 ; 0x4
8: e1c030b0strhr3, [r0]
c: e28dd004add sp, sp, #4 ; 0x4
10: e12fff1ebx lr
gcc -v output
Configured with: ../gcc-4.4.1/configure --target=arm-elf --disable-
__cxa_atexit
--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/
arm-elf :
(reconfigured) ../gcc-4.4.1/configure --target=arm-elf --disable-
__cxa_atexit
--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/
arm-elf
Thread model: single
gcc version 4.4.1 (GCC)
--
Summary: O2 optimizes out assignment to bitfield
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at bodwin dot us
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40844
Re: [Bug tree-optimization/24840] [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807
> > > > --- Comment #2 from malitzke at metronets dot com 2005-11-14 03:58 > --- > Subject: Re: [4.1 Regression] ICE > process_assert_insertions_for, at tree-vrp.c:2807 > > > Here is another try supposedly in plain text. The first bounced at your end > while my copy came ok. > Regards Ray Try the web interface instead of mailing it. -- Pinski
Re: [Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
> > > > --- Comment #2 from woodzltc at sources dot redhat dot com 2005-11-15 > 02:26 --- > Hi Andrew, > > (In reply to comment #1) > > Confirmed, > > DECL_ARG_TYPE should be the reference type and the DECL_TYPE should be the > > normal type. > > > > This might also fix the implicate bug too (I forgot the number). > > Do you means that you already had a fix for this? If so, would you please > point me to a link of that patch? I am very keen to see how this is fixed. I > believe that I can learn something from your patch. Thanks. No, just an idea on how to fix it and how the C++ represents some of its arguments which are passed via a reference. -- Pinski
Re: [Bug middle-end/24804] [3.4 Regression] Produces wrong code
> --- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39 > --- > The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts > there isn't anything left for the RTL gcse pass to do. However, I believe the > bug is still there in the code, it is just very much harder to reproduce now. This might be also related to PR 25130 (it might be exposing the bug in 4.1 even). -- Pinski
Re: [Bug bootstrap/25455] [4.2 Regression] "make all" with a native build now does a bootstrap instead of a normal build
> > > > --- Comment #6 from pcarlini at suse dot de 2005-12-16 18:36 --- > (In reply to comment #5) > > (In reply to comment #4) > > > Too funny, the Andrew-centric view of the world :-) :-) > > Other people do the same too. I was just the first to complain. > > > > There still needs to be a way to build without a bootstrap and without > > reconfiguring. If there is not then we will get bug reports about that. > > And > > this is still a documention failure. > > I agree about the documentation issue, maybe. Still, I don't think there is > anything wrong with this change, I agree totally with Joseph, FWIW my opinion > about such matters. I mean, normal users *must* boostrap anyway, GCC hackers > have just to pass a very simple config option (and running configure is very > fast, in general). Personally, I adapted to the new behavior in 2 minutes. My main problem with how this was handled was there was not big warning about what was going to change and how to change your workflow. Only it was going to change. If Paolo B. had posted an email which said something like the following: If you did a "make all" before to just build (and not bootstrap) GCC, configure with --disable-bootstrap. But he did not which is why there is a bug report. -- Pinski
Re: [Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'
On Dec 22, 2005, at 5:38 AM, trick at icculus dot org wrote: --- Comment #10 from trick at icculus dot org 2005-12-22 10:38 --- Maybe you could add a new variable attribute so that these warnings could at least be avoided in cases where the coder knows the code is correct ? Something like: int x __attribute__((__notuninited__)); int x = x; Will make the warning go away, plus this is documented in the options section under -Winit-self. -- Pinski
Re: [Bug c++/25610] New: 'invalid use of member' error on correct code with templates
On Dec 30, 2005, at 9:31 PM, yuri at tsoft dot com wrote:
template
struct S {
static inline void exec1(A &vv) {
vv.s1<1>(1);
}
};
You are missing a template keyword.
You want:
vv.template s1<1>(1);
Otherwise you end up with (vv.s1 < 1) > 1 as there is no way for a
compiler
to know that vv.s1 is a template as vv is dependent.
-- Pinski
Re: [Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
> > > > --- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 --- > For most (if not all) s-osinte*.ads C type redeclarations, I believe it should > be sufficient to use a record containing a > System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an > alignement clause (I don't know if C or GNU C allows to retrieve the alignment > of a struct like sizeof for size). GNU C does, __alignof__ (struct a). -- Pinski
Re: [Bug libstdc++/25191] exception_defines.h #defines try/catch
On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote: | I realize that once the customer specifies -fno-exceptions, all bets | are off. Great. Fix the problem in the front-end. As I said before, there is still a diagnostic issue and now it is worse with doing that in the front-end since people don't read docs that well so we will be getting bug reports about try/catch not doing the correct thing when -fno-exceptions is supplied (yes I am serious). -- Pinski
Re: [Bug middle-end/25636] cc1 and cc1plus --help core
On Jan 15, 2006, at 8:48 PM, drab at kepler dot fjfi dot cvut dot cz wrote: --- Comment #9 from drab at kepler dot fjfi dot cvut dot cz 2006-01-16 01:48 --- OK, so how about this, couldn't this be an issue? --- opts.c.old 2006-01-15 23:36:53.0 +0100 +++ opts.c 2006-01-16 02:48:17.0 +0100 @@ -1291,7 +1291,7 @@ print_filtered_help (unsigned int flag) unsigned int i, len, filter, indent = 0; bool duplicates = false; const char *help, *opt, *tab; - static char *printed; + static char *printed = NULL; No because static variables are initialized to 0 by default by the C standard. -- Pinski
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
--- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
---
(In reply to comment #3)
const does nothing when it comes to local variables except for not
letting you
touch it in other expressions. It does nothing for optimizations or
anything
else.
This last point is not obvious at all, in my opinion. Why not? In
principle,
certainly const-ness *can* help optimizers one way or the other. Is
this just a
current limitation? A design choice? Anything in the standard making
that
tricky? I would like to know more.
int f(const int *a, int *b)
{
*b = 1;
return *a;
}
a and b can alias and there is no way around that at all because that is
what the C++ standard says.
-- Pinski
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way around that at all because that is
> > what the C++ standard says.
>
> In this case the compiler should warn because a could be declared "const int *
> const" and b could be declared "int * const".
That still does not change the fact that a could point to the same location as
b is pointing too.
-- Pinski
Re: [Bug other/23541] All error messages produce segfault
On Jul 19, 2006, at 9:19 AM, lucier at math dot purdue dot edu wrote: I must be one hell of an atypical guy building 4.1.1, my bootstrap on x86-64 RHEL 4.0 didn't work (PR 28066), Well PR 28066 is not a GCC bug but a bug in an older pre-release of binutils. -- Pinski
Re: [Bug bootstrap/28469] New: stage2 error: toplev.c redefines floor_log2
> > > > When executing `make bootstrap', the following error occurs. > > stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2 -g > -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -DHAVE_CONFIG_H -I. -I. > -I../../share/src/gcc-4.0.3/gcc -I../../share/src/gcc-4.0.3/gcc/. > -I../../share/src/gcc-4.0.3/gcc/../include > -I../../share/src/gcc-4.0.3/gcc/../libcpp/include \ > -DTARGET_NAME=\"i686-pc-linux-gnu\" \ > -c ../../share/src/gcc-4.0.3/gcc/toplev.c -o toplev.o > ../../share/src/gcc-4.0.3/gcc/toplev.c: In function 'toplev_main': > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1713: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1717: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1719: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1723: sorry, unimplemented: called from > here > make[2]: *** [toplev.o] Error 1 This is a bug in the kernel headers which have been fixed in a newer kernel already. -- Pinski
Re: [Bug c/28473] New: with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
> > When compiling with -O or greater optimization, and if x > INT_MAX, then code > like this: > uint64_t y = (uint64_t)round(x); > assigns the wrong value to y (the top 32 bits are all 1s). But this code > assigns the right value to z: > double dz = round(x); > uint64_t z = dz; > > It almost seems as if gcc -O in some cases compiles using a built-in > declaration of round() that returns a 32-bit int. Yes this is wrong code, GCC is generating for some reason lround instead of llround. Thanks, Andrew Pinski
Re: [Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
> > > > --- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- > (In reply to comment #6) > > This _is_ plain ANSI C89. > > ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the > "#"---but what of it? It's good practice anyhow to place the mark first, and > the Tru64 compiler isn't exactly alone in enforcing this convention. ISO C90 is ANSI C89 :). -- Pinski
Re: [Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
> > > > --- Comment #2 from pluto at agmk dot net 2006-07-31 17:54 --- > (In reply to comment #1) > > What is on line 24 in the awk file? > > (...) > # > # Usage: awk -f opt-gather.awk file1.opt [...] > outputfile > > function sort(ARRAY, ELEMENTS) <=== line 24 Hehe, maybe Sun's awk is not a POSIX awk like most of their system is not either.
Re: [Bug target/28668] internal compiler error: in find_reloads, at reload.c:3690
> > > > --- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14 > --- > Subject: Re: internal compiler error: in find_reloads, at > reload.c:3690 > > > Ah! This is not really a gcc bug then. That's a bit of > a relief. It is most likely a GCC bug but with the port to the target and not in the common parts of GCC. -- Pinski
Re: [Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
> > > > --- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 > --- > Dorit, > > >This flag is needed in order to allow vectorization of reduction (summation > >in your case) of floating-point data. > > OK, but this is a bd flag to require. From the computational scientist's > point of view, there is a *vast* difference between reordering (which many > aggressive optimizations imply) and failing to have IEEE compliance. Almost > no > computational scientist will use non-IEEE code (because you have essentially > no > idea if your answer is correct), but almost all will allow reordering. So, it > is really important to separate the non-IEEE optimizations from the IEEE > compliant ones. Except for the fact IEEE compliant fp does not allow for reordering at all except in some small cases. For an example is (a + b) + (-a) is not the same as (a + (-a)) + b, so reordering will invalid IEEE fp for larger a and small b. Yes maybe we should split out the option for unsafe math fp op for reordering but that is different issue. -- Pinski
Re: [Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
> Which part of: > > __builtin_isunordered(nan,nan) = 1 > __builtin_isnan(nan) = 0 > > is consistent? Did you read what the options do because it seems like you did not and you keep on agruing that it is inconsistent except for the fact this is way these options are done as it just says "allows for optimizations" and not always assume finite math and ignore NaNs all the time. -- Pinski
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
On Wed, 2006-08-23 at 13:40 +, hosking at cs dot purdue dot edu wrote: > > --- Comment #4 from hosking at cs dot purdue dot edu 2006-08-23 13:40 > --- > Here is a stack trace showing call to resize_phi_node from execute_pre. Do you have a testcase or is this with a modified compiler? -- Pinski
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
> > > > --- Comment #8 from hosking at cs dot purdue dot edu 2006-08-23 23:43 > --- > I can send whatever traces you might need for diagnosis. Can you provide the dump generated by -fdump-tree-pre-details? -- Pinski
Re: [Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote: > > --- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 --- > I have been unsuccessful in reproducing this problem on a i386-redhat-linux. I think the failure can only reproduce on x86_64-linux-gnu and I could not get even the reduced testcase ICEing on i686-linux-gnu. Thanks, Andrew Pinski
Re: [Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
On Fri, 2006-09-01 at 22:30 +, mark at codesourcery dot com wrote: > So, that's what should be fixed. Except that means introducing a language hook which is only to be useful in one place. The other way of fixing this is not to call fold if we have a MINUS_EXPR with the 2nd operand as 1, we just use the first. Really I don't see any reason why we should introduce a language hook when we can just strip the NON_LVALUE_EXPR right after fold and introducing a language hook which will only help in one specific case. The real real way of fixing this is to move the C++ front-end's templates from using trees and use something which is just specific to the C++ front-end and we would not have to call fold here at all since we will just store the length of the array instead of the "length-1". -- Pinski
Re: [Bug c++/28943] New: Unusable error message when using a conditional-expression with multiple type arguments
On Sun, 2006-09-03 at 19:35 +, lindevel at gmx dot net wrote:
> assert_testcase.cpp: In function ‘int main()’:
> assert_testcase.cpp:16: error: ‘debug(((const char*)"Some
> string"))’ has type ‘void’ and is not a
> throw-expression
That says to me that the expression `debug("Some string")' has a type of
void (and is not a throw expression) which is invalid for ?: if the
other type is not void. I don't see where the problem is. A throw
expression is valid (here by the C++ standard) even though it has a
expression type of void.
-- Pinski
Re: [Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
On Sun, 2006-09-03 at 20:08 +, lindevel at gmx dot net wrote: > > --- Comment #4 from lindevel at gmx dot net 2006-09-03 20:08 --- > You proved ##c++ wrong! They bet that I would be ignored. ;) > > The thing is that a void itself is not invalid. Using (expr ? void : void) > works as you see in my report. > In ##c++ I was told that ( x ? y : z ) wants both y and z to be of the same > type. And that is stated in no way by the error message. void is valid if the both sides of the : are void, otherwise it is invalid. And they don't have to be the same type either, they can be different as long as one is convertible to the other (like float and int or two classes where one is a base class of the other). -- Pinski
Re: [Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
On Wed, 2006-09-06 at 14:19 +, bunk at stusta dot de wrote: > > --- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 --- > Note: > "checking host system type... powerpc64-unknown-linux-gnu" is obviously wrong No it is not. -- Pinski
Re: Problem with inheriting from partial specialization
>
> Dear gcc-bugs-mailinglist,
>
> I'm having a problem with inheriting from a partial specialization of
> a class, and in particular using a public templatized instance
> variable of the partial specialization. I've genericized the code with
> somebody else to the following reduction which shows the essence of
> the problem.
>
>
> template
> class B {
> public:
> char x;
> };
>
> template
> class B {
> public:
> char x;
> };
>
> template
> class C : public B {
> public:
> void function() {
> printf("%c", x);
You need either B::x or this->x to make the access of x as dependent.
Please also read http://gcc.gnu.org/gcc-3.4/changes.html which talks about this
and many
other changes that might affect your code.
And maybe http://gcc.gnu.org/gcc-4.0/changes.html
and http://gcc.gnu.org/gcc-4.1/changes.html
Thanks,
Andrew Pinski
Re: [Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test
On Mon, 2006-09-18 at 13:48 +, ebotcazou at gcc dot gnu dot org
wrote:
>
> --- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-18 13:48
> ---
> > + /* TER is not run at -O0, so our representation of alignment
> > + information and its propagation is non-existant. */
> > + if (!optimize)
> > +return 0;
>
> Perhaps
>
> if (!flag_tree_ter)
> return 0;
>
> would be more accurate?
Well -f{no-,}tree-ter can be still passed and you will get it wrong,
what about:
if (!optimize || !flag_tree_ter)
return 0;
Thanks,
Andrew Pinski
Re: [Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote: > > --- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 --- > I am getting exactly the same here on ppc (so it is not just arm specific): Yes it is. The bug you are getting with PPC is a different bug and should be filed separately. Thanks, Andrew Pinski
Re: [Bug target/11594] testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"
>
>
>
> --- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-20
> 23:49 ---
> Does anyone know why we don't run this test at lp64 on powerpc? I find that on
> powerpc-apple-darwin8 the following changes allow...
>
> make check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
> dg.exp=20020103-1.*"
>
> to pass at both -m32 and -m64 on Darwin PPC...
Yes because AIX uses TOC, just like ppc64-linux so you will get LC for sure.
-- Pinski
Re: [Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
On Fri, 2006-09-22 at 17:05 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-22 17:05 > --- > (In reply to comment #13) > > Yet another test case from Anton we don't catch. Will they never end?!?! ;) > I bet a beer or a shot of vodka, that this is caused by MEM_REF not expanding > with a REG_POINTER. And I lost because we have: ;; sum = sum + MEM[base: base, index: (int *) i * 4B] (insn 29 27 30 (set (reg:SI 128) (ashift:SI (reg/v:SI 123 [ i ]) (const_int 2 [0x2]))) -1 (nil) (nil)) (insn 30 29 31 (set (reg:SI 129) (mem:SI (plus:SI (reg:SI 128) (reg/v/f:SI 125 [ base ])) [0 S4 A32])) -1 (nil) (nil)) (insn 31 30 0 (set (reg/v:SI 122 [ sum ]) (plus:SI (reg/v:SI 122 [ sum ]) (reg:SI 129))) -1 (nil) (nil)) -- Pinski
Re: [Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
On Tue, 2006-09-26 at 04:44 +, acahalan at gmail dot com wrote: > > Although it wouldn't work for the example code, extending the aliasing > behavior > of (char*) to (void*) would fix the problem for LOTS of code out in the wild. > People normally use a (void*) when they want a generic pointer type to play > casting games with. This is a case where the C standard is very far from the > reality of how people write code. The example code is fairly unusual. But C aliasing is not based on pointers but on accesses so it is wrong to it that way. -- Pinski
Re: [Bug c++/29185] inconsistent warning: deleting array
>
>
>
> --- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
> You mean something like: if (is_pointer (p)) delete p;
>
> I suppose that could happen but why should it be any different than other
> non-sensical but lexically valid constructs with undefined behavior that
> require a diagnostic today? E.g.:
>
> template
> void foo () {
> if (0 < N) {
> int array [N];
> ...
> }
> }
That is not undefined behavior, just plain invalid.
>
> Or:
>
> template
> U* bar (T *p) {
> if (is_convertible)
> return p;
> return 0;
> }
Likewise. This is a different issue.
> Isn't template metaprogramming the expected solution to this type of a
> problem?
int a[1];
int *b = a;
delete b;
is also undefined but it is hard to reject without having flow contrl inside the
front-end.
-- pinski
Re: [Bug c++/19351] operator new[] can return heap blocks which are too small
> > > > --- Comment #8 from geoffk at gcc dot gnu dot org 2006-09-27 23:51 > --- > Isn't this handled by -ftrapv? No because sizeof is unsigned and -ftrapv only deals with signed types. -- Pinski
Re: [Bug middle-end/29272] [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?
-- Pinski
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
Re: [Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion
On Thu, 2006-10-05 at 05:00 +, seongbae dot park at gmail dot com wrote: > With 4.1.0 i686-unknown-linux-gnu target: > > # gcc -O2 m.c -S try -O2 -msse2, you get: _Z8todoubledd: subl$12, %esp fldl24(%esp) faddl 16(%esp) fstpl (%esp) movsd (%esp), %xmm0 addl$12, %esp cvttsd2si %xmm0, %eax ret Though I think the movsd should not be there but that is a different issue. -- Pinski
Re: [Bug libgcj/29324] add wait handling hook
On Thu, 2006-10-05 at 05:42 +, daney at gcc dot gnu dot org wrote: > > --- Comment #3 from daney at gcc dot gnu dot org 2006-10-05 05:42 --- > One way to fix it would be to have a reaper thread for *each* Process. Then > the reaper could do a waitpid(pid...) instead of waitpid(-1...). If one only > spawns a few processes, this would be fine. This would allow us to get rid of > the SIGCHLD handler as well. > > Another option would to have the process reaper be a seperate process, but > that > scares me. Even multiple threads scares me for Linux since that would mean double the amount of processes in the process table. Maybe Linux needs this problem if it still exists. I know Linux threads had this problem but I forget if NTPL does. Thanks, Andrew Pinski
Re: [Bug fortran/25850] real kind=16 failures on powerpc-darwin
On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote: > It is unclear to me where you intend to put this function. > If it is in the gfortran frontend, I will outright reject > the patch and lobby to have it removed if anyone applies. It should be in darwin.c in the back-end. C also has the same issue. -- Pinski
Re: [Bug c++/29455] Issues with -Wchar-subscripts
On Sat, 2006-10-14 at 17:52 +, h dot b dot furuseth at usit dot uio dot no wrote: > > Also you forgot one thing '%' does not have to match up with the ANSI > > character set so it could be negative in signed char which means char > > (which could default to signed char) would be different. > > No. In a conforming C implementation, the character *which C interprets > as '%'* must have a positive value. Maybe you are thinking of the > opposite case: What its glyph _looks like_ on some display device is out > of scope for the C standard. But at this point, we are talking about C++ where 'a' is of type char. I have to look at what the C++ standard says about this. -- Pinski
Re: [Bug c++/29469] [DR 224] error: non-template 'pair' used as template
On Sat, 2006-10-14 at 18:25 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-14 18:25 > --- > DR 224 says this is invalid code Sorry valid code. -- Pinski
Re: [Bug c++/2316] g++ fails to overload on language linkage
On Sun, 2006-10-15 at 03:24 +, gcc-bugzilla at kayari dot org wrote: > > --- Comment #13 from gcc-bugzilla at kayari dot org 2006-10-15 03:24 > --- > If this ever gets fixed (which I hope it does) then maybe it should depend on > -std=c++98 so this continues to work by default, or it will break a lot of > code > that incorrectly passes extern "C++" functions to e.g. pthread_create and > sigaction. That's a lot of code. The problem is -std=c++98 vs no options should not produce different code which can happen as shown in this bug already, that we have wrong code. -- Pinski
Re: [Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
> Additionally, link times are much longer than with 3.4.6 Link times are usually a binutils issue unless you are comparing with the same version of binutils. -- Pinski
Re: [Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
> Thus, two options present themself: ditch automake generated targets, do it > manually as everywhere else or tweak the Makefile.am to touch libgomp.info > before invoking `missing makeinfo`. > > Preferences? This only matters when building from SVN. I say we should just require makeinfo and forget about the problem. -- Pinski
Re: r122342 ICE tree check at tree-cfg.c:2042
On 2/27/07, Shaun Jackman <[EMAIL PROTECTED]> wrote: $ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I. I submitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984 for this bug. It is a generic issue. Thanks, Andrew Pinski
Re: [Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
On 9 Mar 2007 23:00:55 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: Other than that, more precise alias information can cause more register pressure, too. Fix the register allocator instead of complaining about this issue. I am sorry but if people want a compiler which works for x86, they just need to fix the RA. Now I could care less about x86. -- Pinski
Re: [Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr <[EMAIL PROTECTED]> wrote: Since sin() and cos() are non trivial functions, I am very surprised that a wrong API makes a 50% difference. Well Here is how it can make a 50% difference (at least on the Cell, the 970 has less of a restriction and only the dispatch group is rejected). Modern PowerPC processors like not to store stuff to the stack and then load it again with in a number of cycles (cell is around 50 cycles while the 970 is just within a dispatch group). Transfering between the integer register set and the floating point register set can only be done via memory so you will get a LHS or a LRU reject (depending on what processor you are on). This can either cause a 50 cycle delay or reject of the dispatch group (the later can cause multiple rejects). The number of cycles used up by this issue can add up with both sides of the function having this hazard. Thanks, Andrew Pinski
Re: Bug in GCC code generation (powerpc-eabi)
On 3/21/07, Informatica Tecnologia Dual <[EMAIL PROTECTED]> wrote:
Hi.
I'm using the GCC compiler for PPC405 as delivered with Xilinx EDK 8.1.
The exact version is: powerpc-eabi-gcc (GCC) 3.4.1 ( Xilinx EDK 8.1.1
Build EDK_I.19.3 190106 )
I found a bug in the code generation.
My code is a serial receiver and uses an uninitialized uchar nData:
uchar nBits;
uchar nData;
for (nBits=0; nBits<8; nBits++) {
nData >>= 1;// the bug is related to this statement
if (function()) nData |= 0x80;
}
Although nData is not initialized, the correct state after the first
"nData >>= 1" statement would be any value between 0x00 and 0x7f.
However, on my target board I found it to be >= 0x80.
And if nData is not initialized you are invoking undefined behavior
according to the C/C++ standards so the behavior here is ok. Yes you
are not expecting this behavor but that is not our fault you are
depening on undefined behavior.
Thanks,
Andrew Pinski
Re: [Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: The problematic STRIP_SIGN_NOPS() call is from fold_unary() which is called from try_combine_conversion() in tree-ssa-pre.c. STRIP_SIGN_NOPS() is called with the expression: No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its folding. It should have called fold_convert on the expression if the types are different and it is a constant. -- Pinski
Re: [Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
On 3/23/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > The problematic STRIP_SIGN_NOPS() call is from fold_unary() > which is called from try_combine_conversion() in tree-ssa-pre.c. > > STRIP_SIGN_NOPS() is called with the expression: No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its folding. It should have called fold_convert on the expression if the types are different and it is a constant. Ok, the real issue is that we call fold with NOP_EXPR> instead of just NOP_EXPR so you have to figure out where we should fold the first NOP_EXPR instead of that patch. -- Pinski
Re: [Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
On 17 Jul 2007 05:15:47 -, cnstar9988 at gmail dot com <[EMAIL PROTECTED]> wrote: --- Comment #18 from cnstar9988 at gmail dot com 2007-07-17 05:15 --- (In reply to comment #17) > Did you copy all of the libraries including the 64bit ones? hp 11.11(pa8800), supports both 32 and 64bit. That comment was not for you, it was the reporter for this specific bug. -- Pinski
Re: [Bug libgomp/32789] Profiling not possible with -fopenmp
On 17 Jul 2007 10:24:12 -, jensseidel at users dot sf dot net <[EMAIL PROTECTED]> wrote: An Open MPI related discussion about atomic operations happened the last days, because architecture specific assembler code failed again for some exotic platforms. And that is the reason why GCC added atomic builtins when openmp came in also. There are manuals for a reason :). -- Pinski
Re: bug and fix for gcc 4.xx on Solaris sparc
On 7/18/07, Rejean Lepage <[EMAIL PROTECTED]> wrote: Hello, I did not find how to add a bug in gcc bugzilla. Anyway do what you want whith this information. This error occurs on sparc Solaris 9 and sparc Solaris 10, when compiling GCC version 4.1.2 and 4.2.0. This is mentioned on the install page already, see: http://gcc.gnu.org/install/specific.html#x-x-solaris2 Thanks, Andrew Pinski
Re: [Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
On 25 Jul 2007 08:40:09 -, dorit at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote In the meantime, would you please try this patch?: Of course after my patch for PR 16660, the patch here should be changed to just return true always. Thanks, Andrew Pinski
Re: [Bug middle-end/32887] warning for memset with zero size
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: I think that is a sensible feature request, am I missing something Andrew? memset with a zero size is valid code. Thanks, Andrew Pinski
Re: [Bug target/32951] missed memcpy -> movdqa optimization.
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net <[EMAIL PROTECTED]> wrote: > moreover i'm wondering why gcc uses movdqa for unaligned loads? Because __m128i is assumed to be aligned. -- Pinski
Re: [Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
On 12 Aug 2007 22:45:07 -, steven dot chapel at sbcglobal dot net <[EMAIL PROTECTED]> wrote: > The code above works with gcc 3.4.5. Which means it worked in g77 and not in gfortran (which is new for 4.0.0). Now we have this weird thing about how gfortran is a new front-end and g77 was removed. So this could go either as a regression or really a new feature. Also why does this program use con anyways, shouldn't it just use the default units which are connected to stdio/stdout anyways as they might not be connected to the console anyways? Thanks, Andrew Pinski
Re: Fix gcc bootstrap problem
On 8/20/07, Nick Clifton <[EMAIL PROTECTED]> wrote: > bfd/ChangeLog > 2007-08-20 Nick Clifton <[EMAIL PROTECTED]> > > * elflink.c (elf_fixup_link_order): Rewrite conversion of > s->alignment_power into an offset mask in order to avoid a gcc > error message. This is wrong, this error message is really an internal error (witness the ICE after the error). We really should be using inform (or a different from error) for these internal error message. Can you provide me (or file a bug) with the preprocessed source for this ICE? The "i386-dis.c" ICE is most likely PR 22371. Thanks, Andrew Pinski
Re: RFC: Bogus gimplification type mismatch error ?
On 8/20/07, Nick Clifton <[EMAIL PROTECTED]> wrote: > But before I check such a patch in I would like to know if the gcc > error message is really correct, or if I have run across a > gimplification bug. As mentioned before this error message is really an internal error, we really should be fixing GCC and not changing binutils. And I already mentioned this is most likely PR 22371 and that you should be filing bug reports about these two errors/ICEs. Thanks, Andrew Pinski
