Re: Using __sync_* builtins within libgcc code
Paolo Carlini wrote: Luke Dalessandro wrote: I'm making some modifications to exception handling inside of unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for, unfortunately I can't seem to figure out how to correctly use builtins in the context of libgcc. I've tried a bunch of different things, but I consistently get the error bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined reference to `__sync_bool_compare_and_swap_4' Maybe you can usefully exploit the recently added __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros or add a few more along the same way... Thank you Paolo, this allows me to wrap cas in a function that falls back to a mutex for targets that don't support builtins. I was aware of the i386 restriction, but didn't realize that i686-* platforms still defaulted to i386. Thanks for everyone's help. Luke
C++ warnings vs. errors
Hi,
since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html
a lot of C++ code is now accepted on mainline (when compiling without
special flags like -fpermissive and -pedantic), that used to be rejected.
Instead of getting closer to the standard we get away from it, which is a
bad idea IMHO - especially since the standard should be widely adopted by
now, given that it's about 10 years old. So here's a collection of some
warnings that I'd rather see as errors:
* Scopes in for-loops:
void foo()
{
for (int i=0; i10; ++i) {}
i = 0;
}
warn.cc: In function 'void foo()':
warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
warn.cc:3: warning: using obsolete binding at 'i'
Btw, because the compiler tries to be smart to track new scoping and old
scoping at once it rejects valid code, accepts invalid code and even
generates wrong code in some cases (see PR10852).
* Declaration with no type:
foo() {}
warn.cc:1: warning: ISO C++ forbids declaration of 'foo' with no type
Or even worse IMHO:
struct A
{
i;
};
warn.cc:3: warning: ISO C++ forbids declaration of 'i' with no type
* Invalid use of 'template':
struct A
{
static void foo();
};
templateint void bar()
{
A::template foo();
}
warn.cc: In function 'void bar()':
warn.cc:8: warning: 'A::foo()' is not a template
Btw, I don't know why we should accept this even with -fpermissive.
* Using 'struct' for a union:
union A {};
struct A a;
warn.cc:2: warning: 'struct' tag used in naming 'union A'
* Static members of local classes:
void foo()
{
struct A
{
static int i;
};
}
warn.cc: In function 'void foo()':
warn.cc:5: warning: local class 'struct foo()::A' shall not have static data
member 'int foo()::A::i'
* Return without value:
int foo()
{
return;
}
warn.cc: In function 'int foo()':
warn.cc:1: warning: return-statement with no value, in function returning
'int'
* Definition in wrong namespace:
struct A
{
void foo();
};
namespace N
{
void A::foo() {}
}
warn.cc:8: warning: definition of 'void A::foo()' is not in namespace
enclosing 'A'
* Operator new:
struct A
{
void* operator new(char);
};
warn.cc:3: warning: 'operator new' takes type 'size_t' ('unsigned int') as
first parameter
* Sizeof for function types:
void foo() { sizeof(foo); }
warn.cc: In member function 'void A::foo()':
warn.cc:1: warning: ISO C++ forbids applying 'sizeof' to an expression of
function type
What do you think?
Regards,
Volker
Re: C++ warnings vs. errors
Volker Reichelt [EMAIL PROTECTED] writes: since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html a lot of C++ code is now accepted on mainline (when compiling without special flags like -fpermissive and -pedantic), that used to be rejected. Instead of getting closer to the standard we get away from it, which is a bad idea IMHO - especially since the standard should be widely adopted by now, given that it's about 10 years old. So here's a collection of some warnings that I'd rather see as errors: It sounds like you want to change some pedwarns to permerrors. Go for it. Ian
Re: RFC: Extend x86-64 psABI for 256bit AVX register
On Tue, Jun 10, 2008 at 05:48:57PM +0200, Jan Hubicka wrote:
On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote:
1) make __m256 passed on stack on variadic functions and in registers
otherwse. Then we don't need to worry about varargs changes at all.
This will break unprototyped calls.
2) extend rax to pass info about if __m256 registers are present and
upper half needs to be saved.
This will break passing __m256 arguments to functions with prologues
compiled with legacy compiler that will do wild jump. All other cases
should work
3) Save upper halves whenever we want to save SSE registers. This will
break calling variadic functions compiled with __m256 support in.
I guess either 1) or 2) is fine for me, as I told earlier, I am not big
fan of 3). I guess 1) is easier and probably make more sense?
I vote for 1), though I think it should be passed on stack only for ...
args. E.g. for
void foo (__m256 x, ...);
void bar (__m256 x, __m256 y, __m256 z)
{
foo (x, y, z);
}
the first argument would be passed in %ymm0, while the unnamed arguments
y and z would be pushed to stack.
I agree. We will add testcases for whatever psABI extension we have
chosen.
I guess we all agree on passing variadic arguments on stack (that is
only those belonging on ...) and rest in registers. It seems easiest in
regard to future register set extensions too. Only negative thing is
that calls to variadic functions will become bit longer, but I guess it
is not big deal. (the fact that register passing conventions are shorter
and variadic functions tends to be called many times was also original
motivation to support register passing on pretty much everything for
varargs in psABI)
There is no precedent for passing named parameters in registers but
unnamed parameters on the stack. On IA32 for the __m128 types, we
pass ALL __m128 parameters on the stack for varargs functions, not
just the unnamed ones. I think we should do the same for x86-64.
H.J.
Books suggestion
Hello I would like to suggest to books you have not mentionned on this page : http://gcc.gnu.org/readings.html Bes regards Titre : GCC : the complete reference Auteur(s) : Griffith, Arthur. Auteur Date(s) : cop. 2002 Langue(s) : anglais Pays : Etats-Unis Editeur(s) : New York ; Chicago ; San Francisco [etc.] : McGraw-Hill/Osborne, cop. 2002 Description : xxiii-647 p. ; 24 cm ISBN : 0-07-222405-3 (br.) Titre : The Definitive Guide to GCC Auteur(s) : Wall, Kurt. Auteur Von Hagen, William (19..-). Auteur Date(s) : cop. 2004 Langue(s) : anglais Pays : Etats-Unis Editeur(s) : New York : Apress, cop. 2004 Description : 1 vol. (XXVIII-519 p.) : ill. ; couv. ill. en coul. ; 24 cm Collection(s) : (The expert's voice) ISBN : 1-59059-109-7 (br.) : 52,70 EUR -- Tel : (33) 1 39 63 78 39 INRIA Rocquencourt, projet MATHFI
Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
The third operand to 'ins' must be a constant int, not a register.
Signed-off-by: David Daney [EMAIL PROTECTED]
---
include/asm-mips/bitops.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 6427247..9a7274b 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile
unsigned long *addr)
2:b 1b \n
.previous \n
: =r (temp), =m (*m)
- : ir (bit), m (*m), r (~0));
+ : i (bit), m (*m), r (~0));
#endif /* CONFIG_CPU_MIPSR2 */
} else if (cpu_has_llsc) {
__asm__ __volatile__(
An old trick to get gcc to do the right thing. Basically at the stage when
gcc is verifying the constraints it may not yet know that it can optimize
things into an i argument, so compilation may fail if r isn't in the
constraints. However we happen to know that due to the way the code is
written gcc will always be able to make use of the i constraint so no
code using r should ever be created.
The trick is a bit ugly; I think it was used first in asm-i386/io.h ages ago
and I would be happy if we could get rid of it without creating new problems.
Maybe a gcc hacker here can tell more?
It is not nice to lie to GCC.
CCing GCC and Richard in hopes that a wider audience may shed some light on the
issue.
David Daney
Re: Help requested on C++ template syntax (for Emacs development).
Alan == Alan Mackenzie [EMAIL PROTECTED] writes: Alan So, the question: is it possible to identify with 100% certainty, PURELY Alan SYNTACTICALLY (i.e. without access to the compiler's symbol table), Alan when ... is a pair of template (C++) or generic (Java) brackets? In Java, yes, if the source is error-free. Alan I'm thinking of things like Alan foo (a b, c d); Alan I think this is unambiguously a function call with 2 parameters, the Alan expressions a b and c d. In Java this is a function call. If 'a' is a type, this is an error, since you can't declare 'd' here. So... if cc-mode assumes that the code it is looking at is syntactically correct, you can always guess. But, it is a lot nicer for the user if errors are flagged. That way lies the Eclipse approach :-) Alan Another related question: although there is no maximum bound on how far Alan apart template/generic brackets can be, I believe that in practice, they Alan are never that far apart (a few hundred bytes max, perhaps). Is this, in Alan fact, the case? For Java, yeah, generally speaking. There may be exceptions. And sometimes I think you may find surprising amounts of whitespace in there. For C++, I think you are just doomed. Even if you could get the compiler to emit perfect information, it would only emit information about the code it actually saw -- not stuff in ignored #if groups. Tom
Re: C++ warnings vs. errors
2008/6/11 Ian Lance Taylor [EMAIL PROTECTED]: Volker Reichelt [EMAIL PROTECTED] writes: since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html a lot of C++ code is now accepted on mainline (when compiling without special flags like -fpermissive and -pedantic), that used to be rejected. Instead of getting closer to the standard we get away from it, which is a bad idea IMHO - especially since the standard should be widely adopted by now, given that it's about 10 years old. So here's a collection of some warnings that I'd rather see as errors: It sounds like you want to change some pedwarns to permerrors. Go for it. Absolutely. Thanks to Jonathan Wakely, we did change quite a few. However, right now, I don't have neither the free time nor the knowledge of the ISO C++ standard to go through all of them and evaluate whether they should be pedwarns or permerrors. So, just grep pedwarn gcc/cp/*.c and s/pedwarn/permerror/ as you see fit. A tip: if it is guarded by if (pedantic) it should probably stay as pedwarn. It doesn't make sense for a permerror to be guarded by the pedantic flag. Moreover, you will probably find things that we don't handle well when using fpermissive, so they should be just errors. Thanks, Manuel.
Re: C++ warnings vs. errors
On Wed, Jun 11, 2008 at 04:12:18PM +0200, Volker Reichelt wrote:
* Scopes in for-loops:
void foo()
{
for (int i=0; i10; ++i) {}
i = 0;
}
warn.cc: In function 'void foo()':
warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
warn.cc:3: warning: using obsolete binding at 'i'
Btw, because the compiler tries to be smart to track new scoping and old
scoping at once it rejects valid code, accepts invalid code and even
generates wrong code in some cases (see PR10852).
That was originally there because, around the time the standard was
first adopted, there was a lot of old code that used the original
cfront scoping rule. But people have had a decade now to get their
code right. It might even be better to toss the support for the
alternative parsing entirely, so the compiler just reports the final
use of i as a reference to an undefined symbol.
Error with 'typedef' and 'long _Fract'
I am writing a new backend for GCC 4.3.1 and have run into the
following issue with GCC 4.3.1's support for the
fixed-point 'long _Fract' type when used in a 'typedef'.
I believe this issue is generic to GCC and not to the backend.
See the (very short) testcase below and the output from GCC.
Basically: when I use a 'typedef' for the 'long _Fract' type,
GCC generates an error but when I replace the typedef with
a #define that, at least in this case, leads to equivalent
code, GCC completes without error (and the resulting .s file
contains correct assembly).
It seems as if the typedef is not being handled correctly.
Or am I misunderstanding something?
% cat foo.c
#ifdef USE_TYPEDEF
/* Error occurs when this typedef is used */
typedef long _Fract fract32_t;
#else
/* Error does NOT occur when this define is used */
#define fract32_t long _Fract
#endif
fract32_t foo(fract32_t a)
{
return a + 0.25lr;
}
% gcc -DUSE_TYPEDEF -O3 foo.c
foo.c: In function 'foo':
foo.c:11: sorry, unimplemented: GCC cannot support operators with
integer types and fixed-point types that have too many integral and
fractional bits together
foo.c:11: error: invalid operands to binary + (have 'fract32_t' and
'long _Fract')
% gcc -O3 foo.c
no errors
[lto] function to DECL associations for WPA repackaging
Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the Repackaging section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. Ollie
Re: [lto] function to DECL associations for WPA repackaging
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild [EMAIL PROTECTED] wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the Repackaging section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard.
Re: C++ warnings vs. errors
Hi Volker, thanks for picking these issues up. I told Manuel I'd
review the rest of the remaining pedwarns, but haven't had time to do
it either.
2008/6/11 Volker Reichelt:
* Scopes in for-loops:
void foo()
{
for (int i=0; i10; ++i) {}
i = 0;
}
warn.cc: In function 'void foo()':
warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
warn.cc:3: warning: using obsolete binding at 'i'
I suggest making this a permerror and changing the text slightly, see
http://gcc.gnu.org/ml/gcc/2008-01/msg00192.html
* Declaration with no type:
foo() {}
warn.cc:1: warning: ISO C++ forbids declaration of 'foo' with no type
See the part about special handling of 'main' in
http://gcc.gnu.org/ml/gcc/2008-01/msg00189.html
* Invalid use of 'template':
* Using 'struct' for a union:
These two can both be fixed by changes in cp/parser.c - all cases of
pedwarn that are not guarded by testing 'pedantic' should be
permerrors.
I'm reviewing the mails linked above, as well as the other cases you
listed. I haven't updated my gcc tree in weeks, so it will take me a
while to bootstrap and test. If you get a patch ready first, please CC
me as I'm not subscribed to gcc-patches.
Thanks,
Jon
[lto] What is lto_file_vtable for?
From what I can tell from grepping the lto source, the vtable entry in lto_file is set but never used. Is this old code that never got removed or the beginning of an idea that never got implemented? I'm inclined to remove it if it's not doing anything. Ollie
Re: [lto] What is lto_file_vtable for?
On Wed, Jun 11, 2008 at 4:38 PM, Ollie Wild [EMAIL PROTECTED] wrote: From what I can tell from grepping the lto source, the vtable entry in lto_file is set but never used. Is this old code that never got removed or the beginning of an idea that never got implemented? I'm inclined to remove it if it's not doing anything. It was needed when the LTO reader had to map DWARF2 sections. It is obsolete now. --Bill
Re: [lto] function to DECL associations for WPA repackaging
Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild [EMAIL PROTECTED] wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the Repackaging section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard. ollie is asking which global and static vars are referenced by each function, not the local variables. my sense is not to associate put this directly in the cgraph but to keep it as a side table that is indexed by something like the cgraph node id. The reason for leaning in this direction is that what happens in the cgraph stays in the cgraph, and the infomation we are talking about here is is only really useful for the whopr repackaging. This is why i have resisted honza's wanting to associate other ipa local information in the cgraph. We have a pass that computes this info currently, the ipa_referenced vars, but i am considering blowing this pass away since the information is not currently being used in the compiler. I need to chat with danny about this next time we talk. However, the lto function body scanner/serializer can just as easily compute this when it serializes a function. We can then serialize this in a one section per compilation unit manner. kenny
[Bug libgomp/36469] bootstrap broken on HPUX PA
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:27 --- Subject: Bug 36469 Author: jakub Date: Wed Jun 11 06:27:04 2008 New Revision: 136650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136650 Log: PR libgomp/36469 * configure.ac: Add AC_CHECK_FUNCS (strtoull). * configure: Regenerated. * config.h.in: Regenerated. * env.c (strtoull): Define to strtoul if HAVE_STRTOULL is not defined. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config.h.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/env.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36469
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 06:31 --- Subject: Bug 36408 Author: jakub Date: Wed Jun 11 06:30:55 2008 New Revision: 136651 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136651 Log: PR c++/36408 * semantics.c (stmt_expr_value_expr): Don't crash on empty STATEMENT_LIST. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libgomp/36208] Boolean type discrepancy between gfortran and libgomp
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:44 --- This ought to be fixed on the trunk - BT_BOOL is the C _Bool type even in Fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36208
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-11 06:48 --- Subject: Bug 36408 Author: jakub Date: Wed Jun 11 06:47:36 2008 New Revision: 136652 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136652 Log: PR c++/36408 * semantics.c (stmt_expr_value_expr): Don't crash on empty STATEMENT_LIST. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libgomp/35881] OMP wrong results for omp_get_max_threads
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-11 06:48 --- Fixed on the trunk as part of the OpenMP 3.0 support. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug libgomp/35644] omp_set_num_threads not working?
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:53 --- That's correct actually. omp_set_num_threads sets the NTHREADS_VAR ICV, i.e. something that will be used to determine the number of threads of the next #pragma omp parallel. omp_get_num_threads returns the number of threads in the current team, as you call it in sequential code, that has to be always 1. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35644
[Bug libgomp/36471] omp_get_ancestor_thread_num_8 has no implicit type.
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 07:07 --- Subject: Bug 36471 Author: jakub Date: Wed Jun 11 07:06:14 2008 New Revision: 136654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136654 Log: PR libgomp/36471 * omp_lib.f90.in (omp_get_ancestor_thread_num_8, omp_get_team_size_8): Fix pastos. Modified: trunk/libgomp/ChangeLog trunk/libgomp/omp_lib.f90.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36471
[Bug libgomp/36471] omp_get_ancestor_thread_num_8 has no implicit type.
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 07:12 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36471
[Bug fortran/36495] New: libgfortran should be build with FCFLAGS -fimplicit-none
As PR 36471 shows, building libgfortran's Fortran parts with -fimplicit-none can help detecting programming errors in the Fortran written parts of libgfortran. I suggest to use such a patch: Index: configure.ac === --- configure.ac(Revision 136654) +++ configure.ac(Arbeitskopie) @@ -123,7 +123,7 @@ m4_rename([real_PRECIOUS],[_AC_ARG_VAR_P # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. if test x$GCC = xyes; then - AM_FCFLAGS=-I . -Wall -fno-repack-arrays -fno-underscoring + AM_FCFLAGS=-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring ## We like to use C99 routines when available. This makes sure that ## __STDC_VERSION__ is set such that libc includes make them available. AM_CFLAGS=-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings Index: intrinsics/dprod_r8.f90 === --- intrinsics/dprod_r8.f90 (Revision 136654) +++ intrinsics/dprod_r8.f90 (Arbeitskopie) @@ -20,6 +20,7 @@ elemental function _gfortran_specific__dprod_r8 (p1, p2) + implicit none real (kind=4), intent (in) :: p1, p2 real (kind=8) :: _gfortran_specific__dprod_r8 -- Summary: libgfortran should be build with FCFLAGS -fimplicit-none Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36495
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
--- Comment #1 from irar at il dot ibm dot com 2008-06-11 08:00 --- Reproduced on powerpc64-suse-linux. Doesn't occur when compiled with -O2 -ftree-vectorize instead of -O3 (the vectorizer generates the same code in both cases). -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 08:00:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry
--- Comment #61 from rguenther at suse dot de 2008-06-11 08:07 --- Subject: Re: [4.2 Regression] points-to analysis slow and memory hungry On Tue, 10 Jun 2008, giovannibajo at libero dot it wrote: --- Comment #60 from giovannibajo at libero dot it 2008-06-10 17:26 --- If a knowledgable GCC developer could suggest *any* workaround at -O1 for this bug in 4.2 (including disabling whatever alias analysys causes the problem), it might be proposed as a fix within distros at least. You can try if --param max-fields-for-field-sensitive=0 improves the situation. Other than that, try, in tree-ssa-structalias.c:create_variable_info_for remove the make_constraint_from_escaped and make_constraint_to_escaped calls for the is_global cases. Note that you need to adjust find_what_p_points_to to include escaped variables if escaped_id is set in the solution and that call clobbering will need similar adjustments (and remember escaped_id includes all globals implicitly). The problem with the sipQt testcase is that it has 1s of global vars it creates constraints for, even though they are unused. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug libgomp/36475] [gomp] register keyword in openmp handled for-loop fails
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 08:20 --- IMHO pedantically that's not valid OpenMP. #pragma omp for for (init-expr; test-expr; incr-expr) structured-block One of the following: init-exprvar = lb integer-type var = lb random-access-iterator-type var = lb pointer-type var = lb register keyword isn't part of the integer-type, it is a storage-class-specifier and the above syntax doesn't mention storage class specifiers anywhere. Furthermore, I don't see why you'd actually need register keyword there at all, in today's compilers the keyword is pretty useless, except when used together with asm (regname), but that's not something we can/want to support for #pragma omp for loops. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36475
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-11 08:37 --- Vectors have the alias set of their element type and int and long do not have conflicting alias sets. The vectorizer clearly should choose vector long * instead of vector int *. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/36474] [4.3 Regression] GCC takes forever to compile a certain file
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-11 09:17 --- Fixed as far as possible. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug tree-optimization/36474] [4.3 Regression] GCC takes forever to compile a certain file
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-06-11 09:17 --- Subject: Bug 36474 Author: rguenth Date: Wed Jun 11 09:16:09 2008 New Revision: 136656 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136656 Log: 2008-06-11 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36474 * opts.c (decode_options): Set max-fields-for-field-sensitive parameter to 100 for -O2, -Os and -O3. * params.def (max-fields-for-field-sensitive): Set default to zero. * doc/invoke.texi (max-fields-for-field-sensitive): Document defaults. * gcc.dg/tree-ssa/alias-15.c: Adjust testcase. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/doc/invoke.texi branches/gcc-4_3-branch/gcc/opts.c branches/gcc-4_3-branch/gcc/params.def branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/alias-15.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug middle-end/32492] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #16 from josep dot m dot perez at bsc dot es 2008-06-11 10:06
---
The following code still triggers this bug in 4.3 but not in 4.2:
templateclass T
class B {
public:
class C {
public:
__attribute__((always_inline)) C(C const c)
{
}
};
void __attribute__((always_inline)) g(C c)
{
}
};
void trigger(Bint b, Bint::C c)
{
b.g(c);
}
I'm using g++-4.3 (Debian 4.3.1-1) 4.3.1 on x86.
--
josep dot m dot perez at bsc dot es changed:
What|Removed |Added
CC||josep dot m dot perez at bsc
||dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32492
[Bug target/36450] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #8 from aldot at gcc dot gnu dot org 2008-06-11 10:35 --- Created an attachment (id=15747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15747action=view) ICEs on trunk This ICEs on trunk with -mpreferred-stack-boundary=2 but works wih =4 gcc-4.4-HEAD -std=gnu99 -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -march=i386 -mpreferred-stack-boundary=2 -O3 -ftree-vect-loop-version -ftree-vectorize -fvariable-expansion-in-unroller -funswitch-loops -funroll-all-loops -ftree-loop-distribution -ftree-loop-im -fivopts -fvect-cost-model -mtune=pentium4 -march=pentium4 -Wfatal-errors -c -o sort.o sort.5.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug middle-end/35412] [4.4 Regression] Correctness with -ftrapv depended on libcall notes
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35542
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug c++/36407] [4.3/4.4 regression] ICE with conversion and -fpermissive
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-11 11:10 --- Thanks for the clarification. I agree. Jason, can you have a look here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Priority|P4 |P1 Summary|[4.3/4.4 regression] ICE|[4.3/4.4 regression] ICE |with invalid conversion |with conversion and - ||fpermissive http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407
[Bug target/35860] [4.3/4.4 Regression] [avr] code bloat caused by -fsplit-wide-types
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] [avr] code |[4.3/4.4 Regression] [avr] |bloat caused by -fsplit-|code bloat caused by - |wide-types |fsplit-wide-types Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug fortran/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #7 from aph at gcc dot gnu dot org 2008-06-11 10:49 --- This isn't just a mingw bug. It is also manifested in GNU/Linux if gcc itself is built with -O0, as you need to do when debugging gcc. There perhaps should be some limit to how far VRP goes before giving up. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 10:49:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug testsuite/36458] [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug tree-optimization/36449] Incorrect code generated for access to a large struct
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-11 11:15 --- Fixed for 4.3.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.4.0 |4.3.2 4.4.0 Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36449
[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-11 11:15 --- Subject: Bug 35336 Author: rguenth Date: Wed Jun 11 11:14:59 2008 New Revision: 136662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136662 Log: 2008-06-11 Richard Guenther [EMAIL PROTECTED] PR middle-end/35336 * fold-const.c (fold_truthop): Remove code generating BIT_FIELD_REFs of structure bases. (fold_binary): Likewise. (make_bit_field_ref): Remove. (optimize_bit_field_compare): Remove. (all_ones_mask_p): Remove. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35336
[Bug c++/36407] [4.3/4.4 regression] ICE with invalid conversion
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-06-11 10:47 --- The code used to compile with -fpermissive, so this is actually an ice-on-valid-code bug. Given that this is also a regression on the 4.3 branch, the priority should by P1, I think. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords|error-recovery, ice-on- |ice-on-valid-code |invalid-code| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407
[Bug bootstrap/33396] add --enable-intermodule
--- Comment #11 from aldot at gcc dot gnu dot org 2008-06-11 12:30 --- Created an attachment (id=15748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15748action=view) updated patch including unwind and eh and handling of static includes untested draft for --disable-shared which contains: # XXX: FIXME: for static libs vis_hide is forced off, so why does the normal # build above have this superfluous occurence? # Play safe and provide this wrong rule and retain the mention of vis_hide # above. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #15046|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33396
[Bug c++/36486] g++ accepts code with ambiguous overloading
--- Comment #3 from richard-gccbugzilla at metafoo dot co dot uk 2008-06-11 12:58 --- I'm not 100% certain that g++ is at fault. Given that icc, Comeau and MS all reject it, I'm inclined to think that g++ is probably the one which gets this wrong, so I've raised this here first. This hinges on whether f0 and f1 are ordered by the standard partial ordering on function templates. It appears superficially that they are not, since from the arguments to f1 you cannot deduce the template parameters of f0, nor vice versa. However, it appears to depend on interpretation of [temp.deduct.type]/5, which says that The non-deduced contexts are: [...] A template parameter used in the parameter type of a function parameter that has a default argument that is being used in the call for which argument deduction is being done. I'm not sure whether that applies here, but if it does, perhaps that makes f1 more specialized than f0, and this is a bug in all the other compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug bootstrap/36496] New: [4.2.3/4.2.4 regression] bootstrap error - section .eh_frame: bad cie version
During bootstrap get ld: fatal: unwind table: file /usr/local/gcc-4.2.4/src/obj-x86_64-SunOS/./gcc/amd64/crtend.o: section .eh_frame: bad cie version 0: offset 0xfd7fffdfcbe0 This did NOT happen during build of gcc-4.2.3. This may be related to gccbug # 33100. -- Summary: [4.2.3/4.2.4 regression] bootstrap error - section .eh_frame: bad cie version Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kate01123 at gmail dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36496
[Bug other/36498] New: [4.3 Regression] time/memory hog for large c++ source.
the 4.3.1 release introduces a new time/memory hog which wasn't present in 4.3.0-20080417. results (with default max-fields-for-field-sensitive param): 4.3.0-20080417 : mem: 580MB, time: 1min32sec. 4.3.1 : aborted at 4.3GB/14min. -- Summary: [4.3 Regression] time/memory hog for large c++ source. Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #1 from pluto at agmk dot net 2008-06-11 14:05 --- Created an attachment (id=15749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15749action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug fortran/36497] New: USE association, cray pointers and error checking
gfortran -fcray-pointer accepts the following program while ifort rejects it with: Error: line 11: The attributes of this name conflict with those made accessible by a USE statement. [X] If one comments the Cray pointer out, gfortran prints: Error: Symbol 'x' at (1) already has basic type of INTEGER Expected: a) gfortran also detects this problem when using Cray pointers b) The error message is made clearer by pointing to the module module test integer(8) ipt, x pointer (ipt, x) end module program bar use test ! implicit none integer(8) x x = 2 print *,x end -- Summary: USE association, cray pointers and error checking Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #2 from pluto at agmk dot net 2008-06-11 14:10 --- testcase tested with: $ i486-gnu-linux-g++ -g0 -O2 -std=gnu++0x -fno-threadsafe-statics -fPIC hescoreScr.ii -c gdb report still the same backtrace: (gdb) bt #0 0x0066891b in set_bb_for_stmt () #1 0x0069c4cb in create_phi_node () #2 0x0068d066 in insert_phi_nodes_for () #3 0x0068d3e8 in insert_updated_phi_nodes_for () #4 0x0068e59c in update_ssa () #5 0x006bd21a in compute_may_aliases () #6 0x005f2c8a in execute_function_todo () #7 0x005f274d in execute_todo () #8 0x005f294a in execute_one_pass () #9 0x005f2a9c in execute_pass_list () #10 0x005f2aae in execute_pass_list () #11 0x00695892 in tree_rest_of_compilation () #12 0x00792902 in cgraph_expand_function () #13 0x0079404e in cgraph_optimize () #14 0x004482ef in cp_write_global_declarations () #15 0x0066362e in toplev_main () #16 0x2b69a416c4a4 in __libc_start_main () from /lib64/libc.so.6 #17 0x004023a9 in _start () -- pluto at agmk dot net changed: What|Removed |Added GCC target triplet||i486-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c++/36499] New: non-compliant behaviour with nested classes
First, please excuse me for my poor english.
Actual standard says on section 11.8 Nested classes [class.access.nest]
The members of a nested class have no special access to members of an enclosing
class, nor to classes or
functions that have granted friendship to an enclosing class; the usual access
rules (clause 11) shall be
obeyed. The members of an enclosing class have no special access to members of
a nested class; the usual
access rules (clause 11) shall be obeyed and gives as example
class E {
int x;
class B { };
class I {
B b; // error: E::B is private
int y;
void f(E* p, int i)
{
p-x = i; // error: E::x is private
}
};
int g(I* p)
{
return p-y; // error: I::y is private
}
};
While trying this code, Gcc sees well that I::y is private in the g function,
but doesn't in the void e::i::f one, nor for the B b declaration.
--
Summary: non-compliant behaviour with nested classes
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot dunski at ibelgique dot com
GCC host triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36499
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-11 14:17 --- The warning happens also with the pointer being ref-all as the alias warning code asks for the alias set of the pointed-to type. Thus it probably makes sense to give that alias-set zero as well (or rather special-case the alias check, as tree-ssa-alias.c:may_alias_p does). I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 14:27 --- Caused by PR29928. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-11 14:29
---
Note that the documentation of may_alias is extremely confusing IMHO (and
c_common_get_alias_set is wrong).
Accesses to objects with types with this attribute are not subjected to
type-based alias analysis, but are instead assumed to be able to alias
any other type of objects, just like the @code{char} type.
the char type is not special, but instead you are allowed to access all
memory via an _lvalue_ of character type!
The above suggests that
long __attribute__((__may_alias__)) x;
*(short *)x;
is ok, but it is not.
A better wording would be to say
Accesses through pointers to types with this attribute are not subject
to type-based alias analysis, but are instead assumed to be able to alias
any other type of objects. These lvalue expressions are treated like
having a character type. ...
Note that an object of a type with this attribute does not have any
special semantics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug bootstrap/36496] [4.2.3/4.2.4 regression] bootstrap error - section .eh_frame: bad cie version
--- Comment #1 from hjl dot tools at gmail dot com 2008-06-11 14:41 --- *** This bug has been marked as a duplicate of 33100 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36496
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #18 from hjl dot tools at gmail dot com 2008-06-11 14:41 --- *** Bug 36496 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||kate01123 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-11 14:46 --- Eventually the fix for PR36154 may be the cause. Can you check backing out 2008-05-08 Richard Guenther [EMAIL PROTECTED] PR middle-end/36154 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Make sure to create a representative for trailing arrays for PTA. ? Or the fix for PR36339, which would be 2008-05-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Move pt_anything and subvariable clobbering code out of the loop. 2008-05-27 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Escaped pt_anything pointers cause all addressable variables to be call clobbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-11 14:55 --- Created an attachment (id=15750) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15750action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-11 15:20 --- The offending function is virtual bool hcScr::hescoreScr::init(Tcl_Interp*, hc::IAccessBase*, vcm::vcmptrcfgmgr::IConfigManager) but probably only after inlining. The trunk is fine, as is compiling with --param max-fields-for-field-sensitive=0. Most of the time/memory is spent in update_ssa () in phi-insertion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Known to work|4.3.0 |4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-06-11 15:20:43 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug tree-optimization/36245] [4.4 Regression] internal compiler error: in build2_stat, at tree.c:3116
--- Comment #14 from dnovillo at gcc dot gnu dot org 2008-06-11 15:39 --- Subject: Bug 36245 Author: dnovillo Date: Wed Jun 11 15:39:09 2008 New Revision: 136672 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136672 Log: 2008-06-11 Diego Novillo [EMAIL PROTECTED] Merge from lto-streamer sub-branch: 2008-06-09 Bill Maddox [EMAIL PROTECTED] * lto-tags.h: Add new tags LTO_local_type_ref and LTO_global_type_ref. Split LTO_type_decl and LTO_field_decl into LTO_type_decl0, LTO_type_decl1, LTO_field_decl0, and LTO_field_decl1. * lto-tree-tags.h: Set names and tree code mappings for the new tags. * lto-function-out.c: Tidy comments and formatting. (output_record_start): Add forward declaration. (type_function_context): New function. (field_decl_is_local, type_decl_is_local): New functions. (output_type_ref_1): Write local (e.g., variably-modified) types to local_decls stream. (output_type_ref): Use type_ref as debug token to avoid confusing clash with use of type elsewhere. (output_local_decl_ref): Update comment. (output_expr_operand): Cases for FIELD_DECL and TYPE_DECL now write local declarations to local_decls stream. (output_local_var): Rename to output_local_var_decl. (output_local_var_decl): Remove code to set slot in local_decls_index, now handled by output_local_decl. (output_local_tree): New function. (output_local_field_decl, output_local_type_decl, output_local_type): New functions. (output_local_decl): New function. (output_field_decl): Use new tag LTO_field_decl1, to distinguish from local fields. (output_type_decl): Use new tag LTO_type_decl1, to distinguish from local fields. * lto-function-in.c: Tidy comments and formatting. (input_local_tree, input_local_var_decl, input_local_field_decl, input_local_type_decl, input_local_type): Add forward declarations. (input_type_ref_1): Distinguish references to global or local declaration streams. (input_type_ref): Use type_ref as debug token to avoid confusing clash with use of type elsewhere. (input_expr_operand): Cases for FIELD_DECL and TYPE_DECL now read local declarations from local_decls stream. (input_local_tree): New function. (input_local_var): Rename to input_local_var_decl. (input_local_var_decl): Input record tag is now an argument. (input_local_field_decl, input_local_type_decl, input_local_type): New functions. (input_local_decl): New function. (input_local_vars): Call input_local_decl instead of input_local_var. (lto_static_init_local): Don't call add_referenced_var on non-vars. * lto-section-out.c (lto_hash_decl_slot_node, lto_eq_decl_slot_node): Use object pointer, not UID, as hash key. 2008-06-04 Rafael Espindola [EMAIL PROTECTED] * lto-function-out.c (output_tree): call error with the TREE_CODE name. 2008-06-04 Ollie Wild [EMAIL PROTECTED] * dwarf2out.c (dwarf2_called_from_lto_p): Remove. (current_fde): New function. (add_fde_cfi): Call current_fde. (lookup_cfa): Call curent_fde. (dwarf2out_end_epilogue): Call current_fde. (dwarf2out_switch_text_section: Call current_fde. (lto_void_type_die): Remove. (dwarf_attr_name): Declare static. Remove flag_generate_lto check. (assign_symbol_name): Remove. (assign_symbol_names): Expand call to assign_symbol_name. (base_type_die): Replace DW_ATE_GNU_complex_unsigned and DW_ATE_GNU_complex_signed encodings with DW_ATE_lo_user. Remove byte_size computation. Remove extra precision information. (may_reference_to_unused): Rename reference_to_unused. (rtl_for_decl_init): Rename calls to may_reference_to_unused. (convert_cfa_to_fb_loc_list): Call current_fde. (gen_subprogram_die): Remove flag_generate_lto and dwarf2_called_from_lto_p checks. (gen_variable_die): Remove context_die == comp_unit_die checks. (add_high_low_attributes): Remove
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-11 16:58 --- Ok... -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 16:58:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug c++/4131] The C++ compiler don't place a const class object to .rodata section with non trivial constructor
--- Comment #22 from jyasskin at gmail dot com 2008-06-11 18:05 ---
This is related to generalized constant expressions
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf) in C++0x.
Those will be marked by the explicit 'constexpr' keyword and will require the
initialization to be done at static rather than dynamic initialization time,
while this bug is about the optional optimization of moving some extra objects
from dynamic to static time.
If I understand it correctly, in C++0x, the following code will require f to be
placed in either the .rodata or .data sections, rather than .bss as it's placed
now.
struct Foo
{
constexpr Foo(int a) { t = a; }
int t;
}
constexpr Foo f(1);
I'd also like to point out that with the extra optimization described here, the
following code could also place f in the .data section:
struct Foo
{
constexpr Foo(int a) { t = a; }
int t;
}
Foo f(1); // Note that f is non-const.
This would be useful for getting atomic variables initialized before anything
else starts up, but it may well belong in a separate feature request.
--
jyasskin at gmail dot com changed:
What|Removed |Added
CC||jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
gfortran-4.3.1 internal compiler error
gfortran built on a CoreDuo running MacOSX 10.4.11 from gcc-4.3.1 using --enable-languages=c,c++,fortran,objc,java,obj-c++,treelang --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x- includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable- libjava-multilib --with-arch=nocona --build=i686-apple-darwin8 # gfortran -v Using built-in specs. Target: i686-apple-darwin8 Configured with: ../gcc-4.3.1/configure --prefix=/sw --prefix=/sw/lib/ gcc4.3 --mandir=/sw/share/man --infodir=/sw/share/info --enable- languages=c,c++,fortran,objc,java,obj-c++,treelang --with-arch=nocona --build=i686-apple-darwin8 --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/ X11R6/lib --disable-libjava-multilib Thread model: posix gcc version 4.3.1 (GCC) The option -ftree-loop-linear causes an internal compiler error in the following command : gfortran -fPIC -O3 -Wall -ftree-loop-linear -c cget35.f -o cget35.o cget35.f: In function 'cget35': cget35.f:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. (and the same with zget35.f _ both come from netlib's LAPACK testing, in lapack-3.1.1/TESTING/EIG from http://www.netlib.org/lapack/ lapack-3.1.1.tgz, both attached) The difficulty arose originally with several additional -f flags on the compile command, removed them for clarity. Also it is not machine-specific; I get the same on a powerpc G5 . (with appropriately changed machine-specific configure options for gcc-4.3.1) Note also there are many variants of those files in that directory [sget... , zget... , other numbers (24, 36, ..) replacing 35 ] that do not have this trouble. gfortran-4.3.0 did not have this problem. JF Mertens cget35.f Description: Binary data zget35.f Description: Binary data
[Bug target/36450] [4.4 Regression] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #9 from aldot at gcc dot gnu dot org 2008-06-11 18:12 --- (In reply to comment #8) Created an attachment (id=15747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15747action=view) [edit] ICEs on trunk This ICEs on trunk with -mpreferred-stack-boundary=2 but works wih =4 s/wih =4/with anything but 2/ and of course works with e.g. 4.3.0 20080218 or trunk from a few weeks ago. gcc-4.4-HEAD -S -o /dev/null -fno-guess-branch-probability -mpreferred-stack-boundary=2 -Os sort.5.i -v Using built-in specs. Target: i686-linux-gnu Configured with: ../../src/gcc-4.4/configure -v --enable-languages=c,fortran --prefix=/opt/i686/gcc-4.4/ --enable-shared --with-system-zlib --libexecdir=/opt/i686/gcc-4.4/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.4-HEAD --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=yes --enable-debug --with-gmp=/opt/i686/gmp-4.2.2/ --with-mpfr=/opt/i686/mpfr-2.3.0 --disable-multilib --disable-intermodule i686-linux-gnu Thread model: posix gcc version 4.4.0 20080611 (experimental) (GCC) COLLECT_GCC_OPTIONS='-S' '-o' '/dev/null' '-fno-guess-branch-probability' '-mpreferred-stack-boundary=2' '-Os' '-v' '-mtune=generic' /opt/i686/gcc-4.4/bin/../../gcc-4.4/lib/gcc/i686-linux-gnu/4.4.0/cc1 -fpreprocessed sort.5.i -quiet -dumpbase sort.5.i -mpreferred-stack-boundary=2 -mtune=generic -auxbase-strip /dev/null -Os -version -fno-guess-branch-probability -o /dev/null GNU C (GCC) version 4.4.0 20080611 (experimental) (i686-linux-gnu) compiled by GNU C version 4.4.0 20080611 (experimental), GMP version 4.2.1, MPFR version 2.3.0-p4. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0d5bbb5fdfd81762cf963cab59cb1e94 sort.5.i:13: warning: useless storage class specifier in empty declaration sort.5.i: In function sort_main: sort.5.i:75: internal compiler error: in insert_save, at caller-save.c:787 Please submit a full bug report, -- aldot at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in |[4.4 Regression] ICE in |insert_restore/insert_save |insert_restore/insert_save |with GET_MODE_ALIGNMENT mem |with GET_MODE_ALIGNMENT mem http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug c/36500] New: gcc ICEs when being passed -mfpu=neon
When crosscompiling for OMAP3 gcc will ICE if you use -mfpu=neon
No ICE: -march=armv7-a -mtune=cortex-a8 -mfpu=vfp -mfloat-abi=softfp
ICE: -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
Testcase:
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ cat helloworld.c
#include stdio.h
int main(void)
{
printf(Hello world!\n); while(1);
return 0;
}
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ arm-angstrom-linux-gnueabi-gcc-4.3.1
helloworld.c -o helloworld -march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mfloat-abi=softfp
helloworld.c:1: 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.
Replace it with -mfpu=vfp:
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ arm-angstrom-linux-gnueabi-gcc-4.3.1
helloworld.c -o helloworld -march=armv7-a -mtune=cortex-a8 -mfpu=vfp
-mfloat-abi=softfp
[EMAIL PROTECTED]:/OE/angstrom-tmp/work$ file helloworld
helloworld: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux
2.6.14, dynamically linked (uses shared libs), not stripped
--
Summary: gcc ICEs when being passed -mfpu=neon
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: koen at openembedded dot org
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug c/36500] gcc ICEs when being passed -mfpu=neon
--- Comment #1 from koen at openembedded dot org 2008-06-11 18:53 --- marking it as blocker, since NEON can't be used -- koen at openembedded dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #6 from pluto at agmk dot net 2008-06-11 19:27 --- this patch causes regression. r135125 | rguenth | 2008-05-09 21:19:33 +0200 (Fri, 09 May 2008) | 10 lines 2008-05-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36187 * tree-dfa.c (dump_variable): Correct dumping of SFT_BASE_FOR_COMPONENTS_P. * tree-ssa-structalias.c (set_uids_in_ptset): Set SFT_UNPARTITIONABLE_P correctly for the union case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-11 19:36 --- Then the following should fix it. Index: tree-flow-inline.h === --- tree-flow-inline.h (revision 135770) +++ tree-flow-inline.h (working copy) @@ -1712,6 +1712,11 @@ var_can_have_subvars (const_tree v) if (!DECL_P (v) || MTAG_P (v)) return false; + /* Unions cannot have subvars. */ + if (TREE_CODE (TREE_TYPE (v)) == UNION_TYPE + || TREE_CODE (TREE_TYPE (v)) == QUAL_UNION_TYPE) +return false; + /* Aggregates can have subvars. */ if (AGGREGATE_TYPE_P (TREE_TYPE (v))) return true; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-11 15:20:43 |2008-06-11 19:36:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c++/36501] New: GCC accepts invalid namespace qualified name when last namespace is repeated
The following code is accepted by GCC without any error. It shows that if the
last qualified name given is repeated any number of times then GCC ignores it.
GCC versions from v3.3.3 to v4.3.1 tested on Darwin and Linux platforms.
namespace fred
{
class A
{
public:
A()
{ }
};
}
int main()
{
fred::A a0;
fred::A::A a1;
fred::A::A::Aa2;
fred::A::A::A::A a3;
return 0;
}
--
Summary: GCC accepts invalid namespace qualified name when last
namespace is repeated
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gp dot bolton at computer dot org
GCC build triplet: i386-apple-darwin9.2.2
GCC host triplet: i386-apple-darwin9.2.2
GCC target triplet: i386-apple-darwin9.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36501
[Bug c/36500] gcc ICEs when being passed -mfpu=neon
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-06-11 19:54 --- Already fixed by my patches r136660 on trunk, r136661 on 4.3 branch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug target/36425] Option -mno-isel not working
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-06-11 20:03 --- Subject: Bug 36425 Author: jsm28 Date: Wed Jun 11 20:02:55 2008 New Revision: 136681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136681 Log: 2008-06-11 Edmar Wienskoski [EMAIL PROTECTED] PR target/36425 * config/rs6000/rs6000.c (rs6000_override_options): Set rs6000_isel conditionally to the absence of comand line override. * config/rs6000/linuxspe.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Remove duplicate rs6000_isel setting. * config/rs6000/eabispe.h: Ditto. testsuite: 2008-06-11 Edmar Wienskoski [EMAIL PROTECTED] * gcc.target/powerpc/e500-1.c: New test case to verify mno-isel option. Added: trunk/gcc/testsuite/gcc.target/powerpc/e500-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/eabispe.h trunk/gcc/config/rs6000/linuxspe.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #8 from pluto at agmk dot net 2008-06-11 20:14 --- (In reply to comment #7) Then the following should fix it. Index: tree-flow-inline.h === --- tree-flow-inline.h (revision 135770) +++ tree-flow-inline.h (working copy) @@ -1712,6 +1712,11 @@ var_can_have_subvars (const_tree v) if (!DECL_P (v) || MTAG_P (v)) return false; + /* Unions cannot have subvars. */ + if (TREE_CODE (TREE_TYPE (v)) == UNION_TYPE + || TREE_CODE (TREE_TYPE (v)) == QUAL_UNION_TYPE) +return false; + /* Aggregates can have subvars. */ if (AGGREGATE_TYPE_P (TREE_TYPE (v))) return true; with this change g++ needs ~1GB and ~4minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c++/36242] OpenMP multi-threading crashes
--- Comment #3 from steven at gcc dot gnu dot org 2008-06-11 20:19 --- Jakub is the OpenMP guru. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242
[Bug c++/36242] OpenMP multi-threading crashes
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-11 20:29 --- Using OpenMP pragmas in multiple pthread_create created threads concurrently isn't supported in 4.2/4.3. There is a support for it on the trunk since a few days ago though. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-11 20:41 --- Hm, the patch in comment #6 only affects the case where we have a union with subvars. Did you check that just reverting this patch brings us back to 580MB and 1min32? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #10 from pluto at agmk dot net 2008-06-11 20:50 --- (In reply to comment #9) Hm, the patch in comment #6 only affects the case where we have a union with subvars. Did you check that just reverting this patch brings us back to 580MB and 1min32? yes, i've checked r135124 and it needs only ~580MB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-06-11 21:04 --- Ah, but that test also reverts all followup patches, like 2008-05-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Move pt_anything and subvariable clobbering code out of the loop. 2008-05-27 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Escaped pt_anything pointers cause all addressable variables to be call clobbered. so, did you apply the patch in comment #7 on top of r135125 or on top of the branch head? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #3 from martin at kfib dot org 2008-06-11 21:13 --- Exact line for compiling is: avr-gcc -mmcu=atmega48 -Walltest.c -o test And now I'm very confused. I KNOW I've tried with and without optimization before and that it made no difference (or possibly I'm a major clutz) but now I can only reproduce the bug if I don't optimize. If I optimize (all kinds), I get 3, but without optimization I get 2. This is what I get without optimization: 6c: df 93 pushr29 6e: cf 93 pushr28 70: 00 d0 rcall .+0 ; 0x72 main+0x6 72: 00 d0 rcall .+0 ; 0x74 main+0x8 74: 00 d0 rcall .+0 ; 0x76 main+0xa 76: cd b7 in r28, 0x3d ; 61 78: de b7 in r29, 0x3e ; 62 7a: 80 91 00 01 lds r24, 0x0100 7e: 90 91 01 01 lds r25, 0x0101 82: 9c 83 std Y+4, r25; 0x04 84: 8b 83 std Y+3, r24; 0x03 86: 8a e3 ldi r24, 0x3A ; 58 88: 8d 83 std Y+5, r24; 0x05 8a: 1e 82 std Y+6, r1 ; 0x06 8c: 1a 82 std Y+2, r1 ; 0x02 8e: 19 82 std Y+1, r1 ; 0x01 90: 8b 81 ldd r24, Y+3; 0x03 92: 8a 33 cpi r24, 0x3A ; 58 94: 29 f4 brne.+10; 0xa0 main+0x34 96: 89 81 ldd r24, Y+1; 0x01 98: 9a 81 ldd r25, Y+2; 0x02 9a: 81 60 ori r24, 0x01 ; 1 9c: 9a 83 std Y+2, r25; 0x02 9e: 89 83 std Y+1, r24; 0x01 a0: 8d 81 ldd r24, Y+5; 0x05 a2: 8a 33 cpi r24, 0x3A ; 58 a4: 29 f4 brne.+10; 0xb0 main+0x44 a6: 89 81 ldd r24, Y+1; 0x01 a8: 9a 81 ldd r25, Y+2; 0x02 aa: 82 60 ori r24, 0x02 ; 2 ac: 9a 83 std Y+2, r25; 0x02 ae: 89 83 std Y+1, r24; 0x01 b0: e7 e2 ldi r30, 0x27 ; 39 b2: f0 e0 ldi r31, 0x00 ; 0 b4: 8f e0 ldi r24, 0x0F ; 15 b6: 80 83 st Z, r24 b8: e8 e2 ldi r30, 0x28 ; 40 ba: f0 e0 ldi r31, 0x00 ; 0 bc: 89 81 ldd r24, Y+1; 0x01 be: 80 83 st Z, r24 c0: 80 e0 ldi r24, 0x00 ; 0 c2: 90 e0 ldi r25, 0x00 ; 0 c4: 26 96 adiwr28, 0x06 ; 6 c6: 0f b6 in r0, 0x3f; 63 c8: f8 94 cli ca: de bf out 0x3e, r29 ; 62 cc: 0f be out 0x3f, r0; 63 ce: cd bf out 0x3d, r28 ; 61 d0: cf 91 pop r28 d2: df 91 pop r29 d4: 08 95 ret The result is that my LEDs indicate a very shining 0x02 on the outport. However, with -Os I get: 6c: 8f e0 ldi r24, 0x0F ; 15 6e: 87 b9 out 0x07, r24 ; 7 70: 83 e0 ldi r24, 0x03 ; 3 72: 90 e0 ldi r25, 0x00 ; 0 74: 88 b9 out 0x08, r24 ; 8 76: 80 e0 ldi r24, 0x00 ; 0 78: 90 e0 ldi r25, 0x00 ; 0 7a: 08 95 ret This is with version 4.3.1. I've verified with 4.1.2 and it behaves the same; without optimization it bugs, with it works. I guess I forgot to do a make clean and thus deserve the title klutz. Sorry for the confusion. Unfortunately the same doesn't go for my actual program (this one was just a test case). It bugs badly no matter optimization (yes, I've verified that I've made a make clean this time) and it boils down to that if I do: display.write_string (Hello); it bugs, but if I do: char h[6]; h[0] = 'H'; h[1] = 'e'; h[2] = 'l'; h[3] = 'l'; h[4] = 'o'; h[5] = 0; display.write_string (h); it prints out a nice little Hello on my LCD. Something is definitely very fishy in how the char-arrays are handled and I can't figure it out. I know you said in the faq that you don't want the source code, but if you want to look at it it's at http://martin.kfib.org/atmelLCD.zip. Maybe it can shed some light over this. It behave the same if I optimize or not (and I hope that I haven't screwed anything up now...); in test.cc if I use the code that I claim works I get a nice little Hello on the LCD but if I use the one that I clam doesn't work I just get garbage on the LCD. Would you like me to generate .i-files too or what's the next step? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.
--- Comment #12 from pluto at agmk dot net 2008-06-11 21:17 --- (In reply to comment #11) Ah, but that test also reverts all followup patches, like (...) so, did you apply the patch in comment #7 on top of r135125 or on top of the branch head? on top of the branch head (r136662). summary: r135124 needs max. 580MB(the 'virt' column from htop)/~1.5min r135125 and newer needs at least 4.3GB/14min. r136662 with suggested patch needs ~1GB/4min. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36498
[Bug c/36500] gcc ICEs when being passed -mfpu=neon
--- Comment #3 from koen at openembedded dot org 2008-06-11 21:44 --- And indeed that patch fixes it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36500
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #4 from hutchinsonandy at aim dot com 2008-06-11 22:05 --- I'm sure Eric will weight in again to verify code posted executes correctly (it looks correct to me). I suspect you have some config or memory issue. For example, unoptimized, the string is stored at location 0x100 and 0x101. So if this get trashed, (by another part of software) the result will be 2. Also watch your stack space. Unoptimized, it will be large and overflow data areas The optimization, of course will bypass such problems -and that works. This also shows that front end and middle of gcc are ok. The code contains no tricky or seldom used instructions - so it appears highly unlikely to be a problem with back end which is specfic to avr. If Eric confirms this he may mark bug as invalid - but you can pursue a solution on other forums (such as http://lists.nongnu.org/mailman/listinfo/avr-gcc-list) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug target/36502] New: i386/darwin generates unnecessary stack ops in every function
gcc -v
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../gcc/configure --prefix=/usr/local/gcc44
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.0 20080611 (experimental) (GCC)
gcc changes esp in every function, even if it has no stack values. Given:
int a;
void f() {a++;}
gcc -O -fomit-frame-pointer -fno-pic -S add.c
_f:
subl$12, %esp
incl_a
addl$12, %esp
ret
Apple's GCC doesn't do this and neither does 4.4 on other systems (as far as I
know).
--
Summary: i386/darwin generates unnecessary stack ops in every
function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC target triplet: i386-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36503] New: x86 can use x -y for x 32-y
gcc -v
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../gcc/configure --prefix=/usr/local/gcc44
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.0 20080611 (experimental) (GCC)
gcc compiles
int shift32(int i, int n)
{
return i (32 - n);
}
to
_shift32:
subl$12, %esp
movl$32, %ecx
subl20(%esp), %ecx
movl16(%esp), %eax
sarl%cl, %eax
addl$12, %esp
ret
Since all 286-and-up CPUs only use the low 5 bits of ecx when shifting, this
can be:
_shift32:
movl8(%esp), %ecx
movl4(%esp), %eax
negl %ecx
sarl%cl, %eax
ret
This is very common in bitstream readers, where it's used to read the top N
bits from a word. ffmpeg already has an inline asm to do it, which I'd like to
get rid of.
I'd guess this applies to some other architectures; it probably works on
x86-64, but doesn't on PPC.
--
Summary: x86 can use x -y for x 32-y
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC target triplet: i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug target/36503] x86 can use x -y for x 32-y
-- astrange at ithinksw dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug target/36504] New: [4.3 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
when building xorg-server with -O3 -fprefetch-loop-arrays and gcc-4.3.1 on an amd64 linux system, we hit an ICE like so: texenvprogram.c: In function 'emit_combine': texenvprogram.c:739: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. older versions of gcc seem to work. building for x86 seems to work. -- Summary: [4.3 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vapier at gentoo dot org GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug target/36504] [4.3 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
--- Comment #1 from vapier at gentoo dot org 2008-06-11 23:37 --- Created an attachment (id=15751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15751action=view) reduced texenvprogram.i $ gcc -c -O3 -fprefetch-loop-arrays texenvprogram.i texenvprogram.i: In function ?create_new_program?: texenvprogram.i:20: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-11 23:43 --- This is due to alignment requirement interacting weirdly with the back-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug c++/36501] GCC accepts invalid namespace qualified name when last namespace is repeated
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-11 23:44 --- *** This bug has been marked as a duplicate of 11764 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36501
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-06-11 23:44 --- *** Bug 36501 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gp dot bolton at computer ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug c++/36499] non-compliant behaviour with nested classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-11 23:49 --- This is not a bug in GCC, read PR 359 for more info why. *** This bug has been marked as a duplicate of 359 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36499
[Bug c++/359] [DR 45] g++ incorrectly grants access to private members to nested classes
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-06-11 23:49 --- *** Bug 36499 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||philippe dot dunski at ||ibelgique dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=359
[Bug target/36503] x86 can use x -y for x 32-y
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 00:05 --- I'd guess this applies to some other architectures; Not really. It depends on the definition of the shift. Most targets have undefined values are produced from negative shifts values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #7 from kris dot van dot hees at oracle dot com 2008-06-12 00:12 --- Patch looks good to me. Good catch! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
