an inter-procedural SSA-based pass
hi, I am trying to write an inter-procedural SSA-based pass: all the existing (in trunk) IPA passes seem to be running on a non-ssa representation and I have been unable to figure out how to hack passes.c to make it schedule an inter-procedural pass right after ssa construction or after the end of all_optimizations. Is this possible ? If so, could someone suggest how to hack passes.c to do this ? Maybe it is the idea of writing an IPA pass operating on SSA which is just plain braindead in which case it would be nice for someone to tell me so :) thank you, Mathieu
Re: an inter-procedural SSA-based pass
On Wed, 2006-09-13 at 08:34 +0200, mathieu lacage wrote: hi, Maybe it is the idea of writing an IPA pass operating on SSA which is just plain braindead in which case it would be nice for someone to tell me so :) It is not braindead except GCC currently does not support that on the mainline. On the ipa-branch you can do it, in fact inlining is already done on SSA there and works. Thanks, Andrew Pinski
Re: an inter-procedural SSA-based pass
Andrew Pinski wrote: On Wed, 2006-09-13 at 08:34 +0200, mathieu lacage wrote: hi, Maybe it is the idea of writing an IPA pass operating on SSA which is just plain braindead in which case it would be nice for someone to tell me so :) It is not braindead except GCC currently does not support that on the mainline. On the ipa-branch you can do it, in fact inlining is already done on SSA there and works. And if you want that, I have patches to do that as late as after ivopts (though that's quite disgusting because the only way to delete aliasing info right now is to leave SSA and re-enter it). Paolo
Re: an inter-procedural SSA-based pass
On Wed, 2006-09-13 at 08:34 +0200, mathieu lacage wrote: hi, Maybe it is the idea of writing an IPA pass operating on SSA which is just plain braindead in which case it would be nice for someone to tell me so :) It is not braindead except GCC currently does not support that on the mainline. On the ipa-branch you can do it, in fact inlining is already done on SSA there and works. Thanks, Andrew Pinski Right. And also Interprocedural constant propagation and matrix flattening are ssa IPA optimizations implemented on ipa branch. Razya
pr27650 - dllimport of virtual methods broken.
Is any of you able to give some comments on pr27650 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650 In particular I am interested in an opinion of Danny's fix. http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html I definately don't know enough about attributes and dllimport to comment. The fix works, but is it correct? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716
svn problems?
Has anyone else had problems accessing the svn server today for gcc? I tried from home and work today. In both cases, the 'svn update' never produces any updates of new files or completes. Jack
Re: svn problems?
Jack Howarth wrote: Has anyone else had problems accessing the svn server today for gcc? I tried from home and work today. In both cases, the 'svn update' never produces any updates of new files or completes. Jack I was beginning to think I was the only one. I did a svn co and a svn update. Neither produced any results. I was trying to checkout the 4.1 branch, after previously deleting it. Bobby
Re: svn problems?
Yes, I noticed that and sent a mail to [EMAIL PROTECTED] You can workaround by relocating the working copy to use http:// instead, as in: svn switch --relocate svn://gcc.gnu.org/svn/gcc/trunk http://gcc.gnu.org/svn/gcc/trunk On 13/09/06, Jack Howarth [EMAIL PROTECTED] wrote: Has anyone else had problems accessing the svn server today for gcc? I tried from home and work today. In both cases, the 'svn update' never produces any updates of new files or completes. Jack
-fwhole-program for a shared library object
Hi, I'm interested in the new -fwhole-program -combine functionality offered in GCC 4.1 but am having trouble applying it to this particular scenario. Is -fwhole-program supposed to cover situations like this? Should I be doing this another way? Is this a bug? I am building a .so library from several .c files. Several functions and variables are shared between these files. Currently, these files are built into individual .o files then linked together at the end into a .so object. The public interface to this library is only 2 functions (this is a Python module). Currently, all of the shared functions/variables in these files are accessible to the outside world. I want to avoid this - these functions are internal only. I only want 2 specific functions available to the outside. So, after reading about -fwhole-program -combine I added __attribute__((externally_visible)) to the 2 functions I'm looking to provide to library users. I also modified the compliation system to compile all the files in the same command, and ended up with: gcc -shared -fwhole-program -combine file1.c file2.c file3.c -o mylib.so Now, when I try and run a program against this library, it fails to load due to undefined symbols in mylib.so. The symbols it claims about are internal functions/variables shared between the various .c files but *not* intended for use by the outside world (hence they shouldn't be in the external symbol table or however it works). What am I missing? Thanks, Daniel
Re: noise from gcc.dg/torture/fp-convert tests
On Wed, Sep 13, 2006 at 12:44:56AM +, Joseph S. Myers wrote:
On Tue, 12 Sep 2006, Eric Christopher wrote:
Joseph S. Myers wrote:
On Tue, 12 Sep 2006, Eric Christopher wrote:
So, these are xfailed, but still produce quite a bit of noise on both
x86_64-darwin and x86_64-linux since they fail to produce a working
executable
and then xfail. Should we move them to skip or link only and xfail them.
With
link only they do manage to be quiet in the logs and we'll still notice
if
they start linking correctly and can move them to run then.
thoughts? pre-approved? :)
Add a means to XFAIL the link of an execute test, if such a means doesn't
already exist in the testsuite infrastructure.
As opposed to changing the test to a link, find a way to xfail at the link
stage instead of at the run stage?
Yes. Some marking so that the compile/link is expected to fail (and so
doesn't produce a WARNING) but if it succeeds (XPASS) then the execute
test is run.
Eric, Do you mean that they're noisy because of the WARNINGs? I always
find warnings annoying, perhaps test_summary should filter them out.
A few things about XFAILs:
- The only way to XFAIL a run test is on the dg-do directive. If the
test also needs to specify a list of targets on which to run, that
must be moved to a dg-skip-if directive, where it can be negated by
using { ! { targets_to_run } }.
- dg-xfail-if only applies to the compile/assemble/link, not to the
execution. If the compile/assemble/link passes then it is reported
as an XPASS and the test is run. This is just what Joseph suggested
we need a way to do.
When playing with this I discovered something alarming. This test:
/* { dg-do run } */
/* { dg-xfail-if link fails { powerpc*-*-linux* } } */
extern int foo (void);
int
main ()
{
return foo ();
}
gets different output on powerpc64-linux depending on whether it's built
with -m32 or -m64:
elm3b145% /opt/gcc-nightly/trunk/bin/gcc -m32 linkfail.c
/tmp/ccY3gdwZ.o: In function `main':linkfail.c:(.text+0x14): undefined
reference to `foo'
collect2: ld returned 1 exit status
elm3b145% /opt/gcc-nightly/trunk/bin/gcc -m64 linkfail.c
/tmp/ccirb9Cu.o:(.text+0x14): undefined reference to `foo'
collect2: ld returned 1 exit status
Notice that for -m32, the message from the linker includes In function
`main':; this causes prune_gcc_output to remove that line of output,
which results in the failure not being recognized. I wonder how many
targets this affects, and how many link failures are not recognized
because of it.
Janis
Re: svn problems?
[EMAIL PROTECTED] (Jack Howarth) writes: Has anyone else had problems accessing the svn server today for gcc? I tried from home and work today. In both cases, the 'svn update' never produces any updates of new files or completes. This should now be fixed. We were being hit hard by a single system. That system has now been blocked. Ian
Re: Equivalence problem with g77
g77 does not allow you to define an equivalence after DATA statements. here is a reduced example: INTEGER*4DEBUGidx PARAMETER (DEBUGidx = 1) INTEGER*4MAPelements PARAMETER (MAPelements = 262) INTEGER*4MAPlevel(0:MAPelements-1) DATA MAPlevel ( 0) / 5/ EQUIVALENCE (DEBUGlevel, MAPlevel(DEBUGidx)) END Move the DATA statements after the equivalence and it will compile. g77 is no longer supported. the replacement fortran compiler, gfortran, compiles your example code without error. upgrading to gfortran might be an option. gfortran is available with versions of gcc 4.0, with the caveat that 4.0 is beta and 4.2 is very usable. since g77 is no longer in active development; you have a couple of options: first, if you are willing to maintain your own version of g77, you can change g77 to work the way you want. source is available in many places. second, and probably simpler, is to write a script which pre-processes the include files to get things in the correct order. from your example, the logic would be very simple...copy from input to output all statements except DATA, save all the DATA in a list and write them after the input file is completely read. HTH, Bud Davis
Re: noise from gcc.dg/torture/fp-convert tests
Eric, Do you mean that they're noisy because of the WARNINGs? I always find warnings annoying, perhaps test_summary should filter them out. Yeah, that's what I meant. Notice that for -m32, the message from the linker includes In function `main':; this causes prune_gcc_output to remove that line of output, which results in the failure not being recognized. I wonder how many targets this affects, and how many link failures are not recognized because of it. Ick. -eric
Re: pr27650 - dllimport of virtual methods broken.
Carlos O'Donell wrote: Is any of you able to give some comments on pr27650 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650 In particular I am interested in an opinion of Danny's fix. http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html I definately don't know enough about attributes and dllimport to comment. The fix works, but is it correct? I think the idea of the patch is correct: virtual functions shouldn't be marked dllimport because you need their addresses to be constants so that they can go in virtual tables. However, I think that the winnt.c change (which has already been checked in) shouldn't be necessary. It only makes sense if we set DECL_DLLIMPORT_P at one point, and then set it back to zero, indicating that we don't want to allow the function to be dllimport'ed. But, in that case, I don't think dllimport should still be on the DECL_ATTRIBUTES list. So, it seems like a band-aid. The cp/decl2.c change also seems less than ideal. The key invariant is that virtual functions can't be dllimport'd. So, I think we should mark them that way when they're declared, perhaps in grokfndecl or in cp_finish_decl. It could be that I'm missing something, though; Danny might want to debate my conclusions. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Rebuild C code from GCC intermediate format
Leonardo Mata wrote on 09/08/06 15:56: I wish to know if there exists any plugin that translate these intermediate format into C sources. Not that I know of. There is an existing effort to implement link-time optimizations (search for LTO in the archives and web pages) that may at some point give you enough to get started.
RE: pr27650 - dllimport of virtual methods broken.
From: Mark Mitchell
Carlos O'Donell wrote:
Is any of you able to give some comments on pr27650
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
In particular I am interested in an opinion of Danny's fix.
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html
The cp/decl2.c change also seems less than ideal. The key
invariant is
that virtual functions can't be dllimport'd. So, I think we
should mark
them that way when they're declared, perhaps in grokfndecl or in
cp_finish_decl.
It could be that I'm missing something, though; Danny might want to
debate my conclusions.
The problem I had was with the second case below. We don't know if a
method is implicitly virtual
until search.c:look_for_overrides_r). Would t be better to unset
DECL_DLLIMPORT_P (and remove the attribute as well) there?
// Don't import explicitly virtual method.
struct base
{
virtual void key_method();
__attribute__((dllimport)) virtual ~base();
};
void base::key_method() {}
// Nor an implicitly virtual method.
struct derived : public base
{
void key_method();
__attribute__((dllimport)) ~derived();
};
void derived::key_method() {}
Danny
Re: pr27650 - dllimport of virtual methods broken.
Danny Smith wrote: The problem I had was with the second case below. We don't know if a method is implicitly virtual until search.c:look_for_overrides_r). Would t be better to unset DECL_DLLIMPORT_P (and remove the attribute as well) there? Ah, right, good point. I always forget that case,.partly because I really think that processing should be done when the function is declared. We can know whether it's virtual at that point, so I think we should. But, that's not how things work now. :-( So, perhaps the best place would be in check_for_override. That's called for all methods when the class is complete. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[Bug target/25920] after compiled with -pg for profiling, all the spec2kfp cases failed at runtime
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:02 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25920
[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-13 06:05 --- This is nothing we can really do for very very old versions of GCC really, they are no longer supported. By the way when building 3.3.4, you should use make bootstrap and not just make, it will most likely pass at that point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27767
[Bug c++/20599] variadic template support
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-09-13 06:19 --- For the record, I'm strongly in favor of variadic templates. Key parts of TR1 (tuple, functional) necessitate some kind of compiler support in order to have full implementations: the current limits on tuple size are an embarrasment. The current implementation strategies for these library elements are highly complex and far too pre-processor slap-happy for my comfort or taste. As these parts of TR1 are already (as of Berlin) part of C++0X, I think it behooves the C++ community to get real about robust solutions. I think starting -std=c++0x is a great idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug other/29049] possible problem: building gcc = 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #27 from WISD00M at GMX dot NET 2006-09-13 06:19 --- (In reply to comment #26) # uname -a as previously mentioned (comment #9), it's: Linux syssiphus 2.6.17.4 #1 SMP PREEMPT Mon Sep 11 14:42:28 CEST 2006 i686 unknown # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 901.73 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 900.09 processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 901.13 processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 902.21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug middle-end/28964] [4.0/4.1/4.2 Regression] partition_stack_vars uses unstable sort
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 06:21 --- Confirmed, this is a regression as partition_stack_vars is new in 4.0.x. I am thinking about either creating a meta-bug or a keyword about all the problems with unstable sorts/hashing with memory addresses problems. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 06:21:02 date|| Summary|partition_stack_vars uses |[4.0/4.1/4.2 Regression] |unstable sort |partition_stack_vars uses ||unstable sort Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug bootstrap/28962] building a cross compiler with --disable-multilib fails
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-13 06:23 --- (In reply to comment #7) Is there a good reason why gcc can't officially support being built without a libc by either figuring out that there's no libc itself or by offering some kind of --i-do-not-have-a-libc option to configure? Yes because you are configuring wrong in the first place. Try looking at what crosstool does for how to build a cross compiler. http://kegel.com/crosstool/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-09-13 06:26 --- Janis, this is how to set timeout on the make check command line: time make check RUNTESTFLAGS=-v -v -v -v --tool_opts timeout=300 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c++/29028] No warning about unused names introduced with using declarations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028
[Bug other/28994] host-darwin.c not 64bit clean
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 06:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 06:29:13 date|| Summary|64-bit problem in host- |host-darwin.c not 64bit |darwin.c|clean http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug rtl-optimization/28982] Incorrect reloading of automodification expressions
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-09-13 06:31 --- Subject: Bug 28982 Author: rsandifo Date: Wed Sep 13 06:30:59 2006 New Revision: 116919 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116919 Log: gcc/ PR rtl-optimization/28982 * reload.c (find_reloads_address_1): Use RELOAD_OTHER for the index of a PRE_MODIFY or POST_MODIFY address. * reload1.c (inc_for_reload): Use find_replacement on the original base and index registers. gcc/testsuite/ PR rtl-optimization/28982 * gcc.c-torture/execute/pr28982a.c: New test. * gcc.c-torture/execute/pr28982b.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr28982a.c trunk/gcc/testsuite/gcc.c-torture/execute/pr28982b.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28982
[Bug rtl-optimization/28982] Incorrect reloading of automodification expressions
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-09-13 06:32 --- Patch applied -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28982
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #3 from ian at airs dot com 2006-09-13 06:36 --- When I run the demangler on _ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE I get void jmain::main(JArrayjava::lang::String**) The relevant patch went in on 2005-12-10 to libiberty/cp-demangle.c. Can you confirm that you have that patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 06:39 --- (In reply to comment #3) When I run the demangler on _ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE I get void jmain::main(JArrayjava::lang::String**) What happens when running it in Java mode (note the -s java)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug rtl-optimization/28622] [4.1 regression] ICE in extract_insn, at recog.c:2084 (unecognizable insn) [m68k]
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-13 06:46 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-07 23:00:26 |2006-09-13 06:46:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:56 ---
This one works for me but I doubt it is correct:
Index: ../../gcc/ipa-utils.c
===
--- ../../gcc/ipa-utils.c (revision 116919)
+++ ../../gcc/ipa-utils.c (working copy)
@@ -212,6 +212,7 @@ ipa_utils_reduced_inorder (struct cgraph
tree
get_base_var (tree t)
{
+ tree temp;
if ((TREE_CODE (t) == EXC_PTR_EXPR) || (TREE_CODE (t) == FILTER_EXPR))
return t;
@@ -221,7 +222,11 @@ get_base_var (tree t)
TREE_CODE (t) != FUNCTION_DECL
TREE_CODE (t) != CONST_DECL)
{
- t = TREE_OPERAND (t, 0);
+ temp = staticp (t);
+ if (temp)
+t = temp;
+ else
+t = TREE_OPERAND (t, 0);
}
return t;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #5 from ian at airs dot com 2006-09-13 07:23 --- OK, with -s java I get jmain.main(java.lang.String[])void I misunderstood Daniel's report. Sorry about that. The fact that the function's return type is printed at the end is deliberate. This is because -s java sets DMGL_RET_POSTFIX. This was added as part of the patch for PR 9861. I've added Terry to the CC list for this PR; perhaps he can explain why it works that way. -- ian at airs dot com changed: What|Removed |Added CC||tj at laurenzo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug target/28622] [4.1 regression] ICE in extract_insn, at recog.c:2084
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 07:57
---
The removed comment says:
- /* If will do cse, generate all results into pseudo registers
- since 1) that allows cse to find more things
- and 2) otherwise cse could produce an insn the machine
- cannot support. An exception is a CONSTRUCTOR into a multi-word
- MEM: that's much more likely to be most efficient into the MEM.
- Another is a CALL_EXPR which must return in memory. */
So it looks like point 2 is true.
Except that CSE has not been run yet. :-)
The problem is that the ashrdi3 expander is not matched by existing insns in
the (MEM, MEM, CONST_INT) case. Either the predicates need to be tightened
or one of the operands needs to be forced to a register in the preparation
statements.
While you're at it, please delete the 3 bogus comments added by Jeff as part
of revision 24814:
(define_expand ashrdi3
[(set (match_operand:DI 0 nonimmediate_operand )
(ashiftrt:DI (match_operand:DI 1 general_operand )
(match_operand 2 const_int_operand )))]
!TARGET_COLDFIRE
{
/* ??? This is a named pattern like this is not allowed to FAIL based
on its operands. */
if (GET_CODE (operands[2]) != CONST_INT
|| ((INTVAL (operands[2]) 1 || INTVAL (operands[2]) 3)
INTVAL (operands[2]) != 8 INTVAL (operands[2]) != 16
(INTVAL (operands[2]) 31 || INTVAL (operands[2]) 63)))
FAIL;
} )
Of course expanders are allowed to fail in the preparation statements based
on their operands, that's precisely why FAIL exists! See the example in the
13.15 section of the internals manual.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
Component|rtl-optimization|target
GCC host triplet|m68k-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
[Bug bootstrap/29058] New: Unable to build under Irix 6.5
Hi!
I don't seem to be able to build the development sources (4.2.0 20060911) under
SGI ('uname -a': IRIX64 fuel3 6.5 01100304 IP35).
I've tried several things, but I keep getting the following error when
'bootstraping':
config.status: executing default commands
if [ x != x ] [ ! -d pic ]; then \
mkdir pic; \
else true; fi
touch stamp-picdir
UX:make: ERROR: don't know how to make regex.c (bu42).
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
This is most likely related to our local set-up (...), but I have absolutely no
idea of what else I can do, or where else to look for help...
Can anyone suggest anything?
Thanks!
Philippe
PS: the way I'm getting about to it: setenv CC gcc ;
/USER/philippe/Irix/Gcc_Sources/configure
--prefix=/USER/philippe/Irix/Gcc --enable-languages=c,fortran
--disable-maintainer-mode --disable-shared
--with-mpfr=/USER/philippe/Irix/Mpfr --with-gmp=/USER/philippe/Irix/Gmp
--with-htmldir ; make
--
Summary: Unable to build under Irix 6.5
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29058
[Bug rtl-optimization/28618] The scheduler extends the lifetime of CLASS_LIKELY_SPILLED registers
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:18 --- There might be problems if no matching set can be found in the current basic block. I'll have to think about how to best check for this. I'm currently leaning to add a field in struct deps for the head of the current basic block, and setting that field in sched_analyze. Why not use reg_last-sets? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 08:18:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28618
[Bug fortran/29051] segfault when too few values are in data statement of character array
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-13 08:21 --- Bud, Quite by chance, I had noticed the cause of this a couple of days ago; if you look at the Doxygen documentation for gfc_data, you will see that the only reference to the locus field 'where' is in resolve.c(resolve_data), where the error is emitted. I was mulling over where the locus was being set and why the documentation might miss it, when I saw your PR and realised that it isn't set at all! An Occam's Razor moment. The patch is going to the list in a few minutes. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-13 04:27:37 |2006-09-13 08:21:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
[Bug c++/29059] New: [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
Compiling as C works, C++ fails. This worked with 20060823.
(sid)118:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O re-ru32un.c
re-ru32un.c: In function 'void LoadUserAlph(char*)':
re-ru32un.c:4: error: invalid operand to unary operator
[0];
re-ru32un.c:4: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O re-ru32un.c
(sid)119:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c re-ru32un.c
(sid)120:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O re-ru32un.c
(sid)121:[EMAIL PROTECTED]: ~] cat re-ru32un.c
extern char *strcpy (char *__restrict __dest, __const char *__restrict __src);
char wrkstr_un[270];
extern void
LoadUserAlph (char *s)
{
s = wrkstr_un;
strcpy (s, );
};
--
Summary: [4.2 regression] ICE: verify_stmts failed (invalid
operand to unary operator [0];)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug rtl-optimization/28173] [4.0/4.1 regression] misses constant folding
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:24 --- Roger, could you comment on Ramana's proposition? Thanks in advance. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot ||org, ebotcazou at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28173
[Bug rtl-optimization/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:32 --- Please indicate whether it's a regression from earlier versions of GCC. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Comment #7 from irar at il dot ibm dot com 2006-09-13 08:32 --- I think, the problem here is that we only check SMT and not NMT. I am preparing a patch to fix this. NMT is stored in ptr_info_def of data-ref, and only if it does not exist, SMT will be checked. -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com, ||dnovillo at redhat dot com AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-21 01:04:59 |2006-09-13 08:32:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug fortran/29051] segfault when too few values are in data statement of character array
--- Comment #5 from patchapp at dberlin dot org 2006-09-13 08:35 --- Subject: Bug number PR29051 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00496.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
[Bug rtl-optimization/28062] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:37 --- If the ICE has disappeared on both branches, the testcase should be added to the testsuite and the PR closed. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|[latent] ICE in |ICE in simplify_subreg, at |simplify_subreg, at |simplify-rtx.c:4466 |simplify-rtx.c:4466 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:44 --- Please indicate the version(s) of the compiler, whether it's a regression, etc. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #6 from aph at gcc dot gnu dot org 2006-09-13 09:01 --- I don't understand why this bug has been reported. Are you using an up-to-date libiberty to do the demangling? When I try c++filt --format java, I get Hello.main(java.lang.String[])void which is correct. The exact form of the demangled string was discussed at greeat length in the thread http://gcc.gnu.org/ml/java-patches/2005-q3/msg00414.html. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug c++/29043] Constructor for POD type with const member without member initializer accepted
--- Comment #2 from andrew dot stubbs at st dot com 2006-09-13 09:23
---
(In reply to comment #1)
As you've written it, class C doesn't have any non-static members. Struct
C::s
hasn't been declared as a member object of C. const int i is a member of
C::s,
not C, so C() without member initializers should be acceptable.
How about this example:
struct S {
const int i;
};
class C
{
public:
C() { }
S s;
};
void f()
{
C c;
S s;
}
This fails at the line `S s;' in f(), but the `C c;' line is accepted silently.
The standard says the requirement applies to data-members *containing* a member
of const-qualified type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-13
10:10 ---
(In reply to comment #5)
This is not DLL-related, the following code doesn't have the expected
behaviour
(although it works fine on i686-linux, even in the static case):
$ cat ctesti.c
#include stdio.h
void print_from_gcc(char* txt) {
printf(%s\n,txt);
}
int main(int argc, char** argv) {
print_from_gcc (c);
print_from_gfortran_(f);
print_from_gcc (c);
print_from_gfortran_(f);
return 0;
}
Changing main() in ctesti.c to start with:
int main(int argc, char** argv) {
setvbuf(stdout, NULL, _IOLBF, 0);
fixes the redirection problem.
If you stll think that this is a libgfortran bug (I don't)
you could add
setvbuf(stdout, NULL, _IOLBF, 0);
to unix.c:output_stream() so that stdout always is line-buffered even when
!isatty(fileno(stdout))
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug java/28090] incorrect implementation of expand_java_arraystore
--- Comment #4 from bonzini at gnu dot org 2006-09-13 10:10 --- PR19505 is fixed, is the patch still bad? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28090
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression]|[4.1/4.2 regression] |procedure doesn't modify In |procedure doesn't modify In |Out parameter |Out parameter Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #1 from bonzini at gnu dot org 2006-09-13 10:43 --- A somewhat disconnected comment on the ecj-branch build process... Are you planning to distribute ecj as a JAR file too? If so, there should be no changes to the documentation for building out of tarballs. If you don't want to put the JAR in svn, To build from svn, a pre-existing GCJ would be necessary that can build ecj. The build process should go like this: - the gcc directory builds the bytecode-native compiler - if there is a JAR, the ecj directory looks for ../gcc/gcj and uses that one to build the native compiler - if not, the toplevel configury should pass the path to a GCJ somewhere and the ecj directory will use it to build the JAR. I think the JAR should be built in the build directory, unless --enable-generated-files-in-srcdir. more on the third bullet: find the GCJ in the toplevel, as we do for C++ (grep for CXX= in the toplevel configure -- there is room for improvement but I don't think it's important). In the Makefile.tpl, add somewhere [EMAIL PROTECTED]@ and pass it down to ecj via HOST_FLAGS_TO_PASS. Later on, ecj could even be bootstrapped using POSTSTAGE1_FLAGS_TO_PASS to point to the just build gcj and ecj. (How does gcj find the ecj to use? Might this require spec hacking?) -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug c++/29054] [4.0/4.1 Regression] ICE on friend template specialization
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-13 11:39 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.3 4.1.1 Known to work|4.2.0 |3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-13 11:39:13 date|| Summary|ICE on friend template |[4.0/4.1 Regression] ICE on |specialization |friend template ||specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug c++/29054] [4.0/4.1 Regression] ICE on friend template specialization
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-13 11:41 --- (gdb) run Starting program: /abuild/rguenther/gcc41-g/gcc/cc1plus -quiet t.ii Program received signal SIGSEGV, Segmentation fault. 0x080f565b in instantiate_decl (d=0xb7d9cf00, defer_ok=0, expl_inst_class_mem_p=0 '\0') at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:11957 11957 spec_parm = TREE_CHAIN (spec_parm); both tmpl_parm and spec_parm are zero. (gdb) bt #0 0x080f565b in instantiate_decl (d=0xb7d9cf00, defer_ok=0, expl_inst_class_mem_p=0 '\0') at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:11957 #1 0x080f5e1a in instantiate_pending_templates (retries=0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/pt.c:12065 #2 0x0813fa19 in cp_finish_file () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/decl2.c:2857 #3 0x08049d18 in finish_file () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/cp/cp-lang.c:144 #4 0x0826bac4 in c_common_parse_file (set_yydebug=0) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/c-opts.c:1144 #5 0x086d9d84 in compile_file () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/toplev.c:991 #6 0x086db68f in do_compile () at /space/rguenther/src/svn/gcc-4_1-branch/gcc/toplev.c:1949 #7 0x086db6f1 in toplev_main (argc=3, argv=0xbf939b04) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/toplev.c:1981 #8 0x0827e022 in main (argc=Cannot access memory at address 0x0 ) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
[Bug fortran/29060] New: spread causes ICE in gfc_trans_array_constructor
Hi, I got AN ICE trying to compile -- module bcc implicit none private type md_field real,dimension(:,:),pointer :: position end type md_field real,dimension(1:3,1:2),parameter :: unitcell = reshape((/ 0.25,0.25,0.25, 0.75,0.75,0.75 /),(/3,2/)) contains subroutine createBccLattice(x,counts) integer,dimension(1:3),intent(in) :: counts type(md_field),pointer :: x integer :: i,j,k do i=1,counts(1) do j=1,counts(2) do k=1,counts(3) x % position(:,1:2) = unitcell + spread((/ i,j,k/),2,size(unitcell,2)) end do end do end do return end subroutine createBccLattice end module bcc -- maybe it is related to some other spread related errors, I encountered in an older gfortran debian package, which seemed to occure only after several spread calls. Unfortunately at that time it was too difficult to get a nice code snippet for the report. For your information: [EMAIL PROTECTED]:~/bugs/gfortran$ LANG=C gfortran -v -c ICE5.f90 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) /usr/lib/gcc/x86_64-linux-gnu/4.1.2/f951 ICE5.f90 -quiet -dumpbase ICE5.f90 -mtune=k8 -auxbase ICE5 -version -o /tmp/ccsURLG7.s GNU F95 version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) (x86_64-linux-gnu) compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128471 ICE5.f90: In function 'createbcclattice': ICE5.f90:11: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1317 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. [EMAIL PROTECTED]:~/bugs/gfortran$ -- Summary: spread causes ICE in gfc_trans_array_constructor Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: keinstein_junior at gmx dot net GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-09-13 12:20 --- Andrew, The proposed patch doesn't work. It converts the internal compiler error into a compiler time error of... gcc-4 -O3 -g -m64 array-9.c array-9.c:7: error: declaration of 'x' as array of voids -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
mcfv4e flag to gas
Hi
I am using gcc 20060906 snapshot to compile a 2.6.10 kernel for a
Coldfire MCF5484 (and uclibc 0.9.28).
The question is that I was getting some errors like this:
{standard input}: Assembler messages:
{standard input}:22: Error: invalid instruction for this architecture;
needs ColdFire ISA_B (5407 [5470, 5471, 5472, 5473, 5474, 5475], 547x
[5475, 5474, 5473, 5472, 5471, 5470, 5480, 5481, 5482, 5483, 5484,
5485], 548x [5485, 5484, 5483, 5482, 5481, 5480]) -- statement `mov3q.l
#1,%d0' ignored
So it seems that although the flag -mcfv4e was being used for gcc, it
was not passed into the assembler. I checked this with -v option, and I
check that.
No -mcfv4e flag was being passed into gas.
I am solving this setting -Xassembler -mcfv4e flags, but I suppose this
is not the best way to solve this.
Any ideas?
Thanks
Miguel Ángel Álvarez
- PLEASE NOTE
---
This message, along with any attachments, may be confidential or legally privileged.
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and
notify the sender immediately.
Thank you for your help.
µSysCom uses virus scanning software but excludes any liability for viruses
contained in any attachment.
ROGAMOS LEA ESTE TEXTO
---
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal.
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.
µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #7 from drow at gcc dot gnu dot org 2006-09-13 12:31 --- Subject: Re: Libiberty demangler can not handle new Java mangling. I don't understand why this bug has been reported. The bug was reported because the combination of the mangling change and the demangler postfix behavior messes up GDB. You used to be able to say break 'jmain.main(java.lang.String[])' but now that's not found; you'd have to add the trailing void manually. As per your message: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00434.html Several affected tests in the GDB testsuite broke. Of course they're somewhat provisional tests because there are earlier tests in the same file which use much more user-friendly forms, that are still not supported by GDB. The Java debug support has not gotten much love lately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug java/29044] Libiberty demangler can not handle new Java mangling.
--- Comment #8 from drow at gcc dot gnu dot org 2006-09-13 12:31 --- Not a bug then. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29044
[Bug c++/29046] Failure to define friend functions for all template instatiations
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-09-13 13:46 --- (In reply to comment #4) (In reply to comment #3) Now we don't do that either but that is a different bug. Actually we do reject it with -pedantic so that is not a different bug after all but a change, a delerate change in fact. Are you sure that is a change at all? I tested using -pedantic . The compiler version I've used won't give a diagnostic without -pedantic, either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29046
[Bug testsuite/29055] gcc.target/powerpc/darwin-bool-1.c fails on powerpc-apple-darwin8 at -m64
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-13
13:52 ---
So I assume I just need to create a patch that adds...
* { dg-skip-if { powerpc*-*-darwin* } { -m64 } { } } */
to the darwin-bool-1.c testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29055
[Bug java/29061] New: nternal compiler error: in make_class_data, at java/class.c:1774
testserver.java in Jessie 1.0.1. cmmand : gcj -v -c -o testserver.o testserver.java Using built-in specs. Reading specs from /usr/lib/gcc/i586-suse-linux/4.1.0/../../../libgcj.spec rename spec lib to liborig Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) /usr/lib/gcc/i586-suse-linux/4.1.0/jc1 testserver.java -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase testserver.java -mtune=generic -auxbase-strip testserver.o -g1 -version -o /tmp/ccZeNZmX.s GNU Java version 4.1.0 (SUSE Linux) (i586-suse-linux) compiled by GNU C version 4.1.0 (SUSE Linux). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64554 Class path starts here: /usr/local/classpath/share/classpath/glibj.zip/ (zip) /usr/share/java/libgcj-4.1.0.jar/ (system) (zip) testserver.java:9: internal compiler error: in make_class_data, at java/class.c:1774 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: nternal compiler error: in make_class_data, at java/class.c:1774 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linh at mytum dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #1 from linh at mytum dot de 2006-09-13 14:16 --- Created an attachment (id=12251) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12251action=view) this testserver in jesssie-1.0.1 is compiled under classpath-0.92. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug other/29049] possible problem: building gcc = 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #28 from hjl at lucon dot org 2006-09-13 15:03 --- Apparently, your target_flags sets MASK_64BIT. You need to run gdb on cc1 and set hardware watchpoint on target_flags to see where it sets MASK_64BIT: [EMAIL PROTECTED] gcc]$ touch x.i [EMAIL PROTECTED] gcc]$ gdb cc1 GNU gdb 6.4.50.20060406-cvs Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/tls/libthread_db.so.1. Breakpoint 1 at 0x8138b96: file ../../gcc/diagnostic.c, line 602. Breakpoint 2 at 0x8138b43: file ../../gcc/diagnostic.c, line 547. Function exit not defined. Function abort not defined. (gdb) watch target_flags Hardware watchpoint 3: target_flags (gdb) r -fpreprocessed x.i -quiet -dumpbase x.i -mtune=pentiumpro -auxbase x -version -o x.s Starting program: /export/gnu/import/gcc-4.1.0/build/gcc/cc1 -fpreprocessed x.i -quiet -dumpbase x.i -mtune=pentiumpro -auxbase x -version -o x.s Hardware watchpoint 3: target_flags Hardware watchpoint 3: target_flags Hardware watchpoint 3: target_flags Old value = 0 New value = 8388808 decode_options (argc=12, argv=0xbff24ef4) at ../../gcc/opts.c:634 634 flag_unwind_tables = targetm.unwind_tables_default; (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. Hardware watchpoint 3: target_flags Old value = 8388808 New value = 8405192 override_options () at ../../gcc/config/i386/i386.c:1614 1614 if (TARGET_SSEREGPARM (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. Hardware watchpoint 3: target_flags Old value = 8405192 New value = 8405208 override_options () at ../../gcc/config/i386/i386.c:1667 1667 if ((flag_unwind_tables || flag_asynchronous_unwind_tables (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. GNU C version 4.1.0 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-3). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2547d670e9349240a4187f725ff2e074 Program exited normally. (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug c/29062] New: Parse error after label and variable declaration
Consider following code:
//
1 int main(int argc, char** argv) {
2if (argc 1) {
3 goto finish;
4}
5 finish:
6int ret = 1;
7return ret;
8 }
//
Though I tested different versions of GCC (3.3.5, 3.4.4, 4.1.1), I was not able
to compile the code above. This is the error message on a debian sarge with GCC
3.3.5:
//
[EMAIL PROTECTED]:~/src gcc label.c
label.c: In function `main':
label.c:8: error: syntax error before int
label.c:9: error: `ret' undeclared (first use in this function)
label.c:9: error: (Each undeclared identifier is reported only once
label.c:9: error: for each function it appears in.)
//
I am not sure, whether my code violates the standard, or this is a bug.
However, if I enclose the code after the finish label with curly brackets
(lines 6 and 7), the error disappears.
--
Summary: Parse error after label and variable declaration
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdalman at project-psi dot org
GCC host triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug libstdc++/29063] New: valarray does not undefine all temp macros
valarray should undefine all temp macros, but it does not
$ cat test.cpp
#include valarray
$ g++-4.0 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.1 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.2 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.0 -E -dM test.cpp | grep _DEFINE_
#define _DEFINE_ARRAY_FUNCTION(_Op,_Name) templatetypename _Tp inline void
_Array_augmented_ ##_Name(_Array_Tp __a, size_t __n, const _Tp __t) { for
(_Tp* __p = __a._M_data; __p __a._M_data + __n; ++__p) *__p _Op ##= __t; }
templatetypename _Tp inline void _Array_augmented_ ##_Name(_Array_Tp __a,
size_t __n, _Array_Tp __b) { _Tp* __p = __a._M_data; for (_Tp* __q =
__b._M_data; __q __b._M_data + __n; ++__p, ++__q) *__p _Op ##= *__q; }
templatetypename _Tp, class _Dom void _Array_augmented_ ##_Name(_Array_Tp
__a, const _Expr_Dom, _Tp __e, size_t __n) { _Tp* __p(__a._M_data); for
(size_t __i = 0; __i __n; ++__i, ++__p) *__p _Op ##= __e[__i]; }
templatetypename _Tp inline void _Array_augmented_ ##_Name(_Array_Tp __a,
size_t __n, size_t __s, _Array_Tp __b) { _Tp* __q(__b._M_data); for (_Tp* __p
= __a._M_data; __p __a._M_data + __s * __n; __p += __s, ++__q) *__p _Op ##=
*__q; } templatetypename _Tp inline void _Array_augmented_
##_Name(_Array_Tp __a, _Array_Tp __b, size_t __n, size_t __s) { _Tp*
__q(__b._M_data); for (_Tp* __p = __a._M_data; __p __a._M_data + __n; ++__p,
__q += __s) *__p _Op ##= *__q; } templatetypename _Tp, class _Dom void
_Array_augmented_ ##_Name(_Array_Tp __a, size_t __s, const _Expr_Dom, _Tp
__e, size_t __n) { _Tp* __p(__a._M_data); for (size_t __i = 0; __i __n;
++__i, __p += __s) *__p _Op ##= __e[__i]; } templatetypename _Tp inline void
_Array_augmented_ ##_Name(_Array_Tp __a, _Arraysize_t __i, _Array_Tp __b,
size_t __n) { _Tp* __q(__b._M_data); for (size_t* __j = __i._M_data; __j
__i._M_data + __n; ++__j, ++__q) __a._M_data[*__j] _Op ##= *__q; }
templatetypename _Tp inline void _Array_augmented_ ##_Name(_Array_Tp __a,
size_t __n, _Array_Tp __b, _Arraysize_t __i) { _Tp* __p(__a._M_data); for
(size_t* __j = __i._M_data; __j__i._M_data + __n; ++__j, ++__p) *__p _Op ##=
__b._M_data[*__j]; } templatetypename _Tp, class _Dom void _Array_augmented_
##_Name(_Array_Tp __a, _Arraysize_t __i, const _Expr_Dom, _Tp __e,
size_t __n) { size_t* __j(__i._M_data); for (size_t __k = 0; __k__n; ++__k,
++__j) __a._M_data[*__j] _Op ##= __e[__k]; } templatetypename _Tp void
_Array_augmented_ ##_Name(_Array_Tp __a, _Arraybool __m, _Array_Tp __b,
size_t __n) { bool* __ok(__m._M_data); _Tp* __p(__a._M_data); for (_Tp* __q =
__b._M_data; __q __b._M_data + __n; ++__q, ++__ok, ++__p) { while (! *__ok) {
++__ok; ++__p; } *__p _Op ##= *__q; } } templatetypename _Tp void
_Array_augmented_ ##_Name(_Array_Tp __a, size_t __n, _Array_Tp __b,
_Arraybool __m) { bool* __ok(__m._M_data); _Tp* __q(__b._M_data); for (_Tp*
__p = __a._M_data; __p __a._M_data + __n; ++__p, ++__ok, ++__q) { while (!
*__ok) { ++__ok; ++__q; } *__p _Op ##= *__q; } } templatetypename _Tp, class
_Dom void _Array_augmented_ ##_Name(_Array_Tp __a, _Arraybool __m, const
_Expr_Dom, _Tp __e, size_t __n) { bool* __ok(__m._M_data); _Tp*
__p(__a._M_data); for (size_t __i = 0; __i __n; ++__i, ++__ok, ++__p) { while
(! *__ok) { ++__ok; ++__p; } *__p _Op ##= __e[__i]; } }
#define _DEFINE_BINARY_OPERATOR(_Op,_Name) templatetypename _Tp inline
_Expr_BinClos_Name, _ValArray, _ValArray, _Tp, _Tp, typename __fun_Name,
_Tp::result_type operator _Op(const valarray_Tp __v, const valarray_Tp
__w) { _GLIBCXX_DEBUG_ASSERT(__v.size() == __w.size()); typedef _BinClos_Name,
_ValArray, _ValArray, _Tp, _Tp _Closure; typedef typename __fun_Name,
_Tp::result_type _Rt; return _Expr_Closure, _Rt(_Closure(__v, __w)); }
templatetypename _Tp inline _Expr_BinClos_Name, _ValArray,_Constant, _Tp,
_Tp, typename __fun_Name, _Tp::result_type operator _Op(const
valarray_Tp __v, const _Tp __t) { typedef _BinClos_Name, _ValArray,
_Constant, _Tp, _Tp _Closure; typedef typename __fun_Name, _Tp::result_type
_Rt; return _Expr_Closure, _Rt(_Closure(__v, __t)); } templatetypename _Tp
inline _Expr_BinClos_Name, _Constant, _ValArray, _Tp, _Tp, typename
__fun_Name, _Tp::result_type operator _Op(const _Tp __t, const
valarray_Tp __v) { typedef _BinClos_Name, _Constant, _ValArray, _Tp, _Tp
_Closure; typedef typename __fun_Name, _Tp::result_type _Rt; return
_Expr_Closure, _Tp(_Closure(__t, __v)); }
$ g++-4.0 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.0.4 20060904 (prerelease) (Debian
[Bug c/29062] Parse error after label and variable declaration
--- Comment #1 from schwab at suse dot de 2006-09-13 15:32 --- A label can only be part of a statement. A declaration is not a statement. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Parse error after label and |Parse error after label and |variable declaration|variable declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug fortran/28526] 'end' is recognized as a variable incorrectly
--- Comment #3 from tobi at gcc dot gnu dot org 2006-09-13 16:06 --- This is intriguing. Why would 'end' be treated any different from 'xxx'? -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:06:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
[Bug c++/29043] Constructor for POD type with const member without member initializer accepted
--- Comment #3 from bangerth at dealii dot org 2006-09-13 16:10 --- Confirmed with the testcase from attachment #2. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:10:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
[Bug fortran/28443] gfortran does not implement the present intrinsic procedure correctly for optional character strings
--- Comment #8 from tobi at gcc dot gnu dot org 2006-09-13 16:11 --- This is another variation of the theme in 26227 *** This bug has been marked as a duplicate of 26227 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28443
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #6 from tobi at gcc dot gnu dot org 2006-09-13 16:11 --- *** Bug 28443 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||cyan+gcc at compsoc dot ||nuigalway dot ie http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/28809] No diagnostic for missing interface for same file procedure
--- Comment #4 from tobi at gcc dot gnu dot org 2006-09-13 16:12 --- Again, the same theme as 26227. *** This bug has been marked as a duplicate of 26227 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #7 from tobi at gcc dot gnu dot org 2006-09-13 16:12 --- *** Bug 28809 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||jchodera at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug c++/29059] [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:17 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-checking, ice-on-valid- ||code Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:17:26 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug rtl-optimization/28062] [latent] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-13 16:20 --- (In reply to comment #13) If the ICE has disappeared on both branches, the testcase should be added to the testsuite and the PR closed. But the bug still exists, just was covered up by my tree-inline patches for PR 28075. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in simplify_subreg, at |[latent] ICE in |simplify-rtx.c:4466 |simplify_subreg, at ||simplify-rtx.c:4466 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-13 16:22 ---
(In reply to comment #5)
Andrew,
The proposed patch doesn't work. It converts the internal
compiler error into a compiler time error of...
Yes the patch does work as this is invalid code to begin with :).
Look at the testcase:
struct A
{
int i;
void x[1]; /* { dg-error array of voids } */
};
void foo(struct A a) {}
See how there is a dg-error there, that error is expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
[Bug libstdc++/29063] valarray does not undefine all temp macros
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:27 --- _D is in the reserved identifier space IIRC so I think this is a non bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29063
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-13 16:45 --- I tried this with 4.1 (failed due to missing imports), the RH 4.1 (worked) and svn head (worked). So, I think we would need more information to proceed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 16:49 --- I am thinking SUSE created their 4.1.0 before 4.1.0 was release, I think this is the same as PR 25366. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug libstdc++/29063] valarray does not undefine all temp macros
--- Comment #2 from pcarlini at suse dot de 2006-09-13 16:51 --- As a matter of fact valarray *always* undefines the macros, besides in those two specific cases (and the first one is even undefined weren't for a typo ;) So, we can as well do the two-lines change... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 16:51:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29063
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
--- Comment #6 from janis at gcc dot gnu dot org 2006-09-13 16:54 --- Benjamin, I had tried that, but it adds timeout=300 to the options passed to the compiler. Does it really work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug bootstrap/29058] Unable to build under Irix 6.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:56 --- UX:make: ERROR: don't know how to make regex.c (bu42). This sounds like you are not using GNU make which is required. Can you try again this time using GNU make? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Unable to build under Irix |Unable to build under Irix |6.5 |6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29058
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #4 from linh at mytum dot de 2006-09-13 16:59 --- (In reply to comment #2) I tried this with 4.1 (failed due to missing imports), the RH 4.1 (worked) and svn head (worked). So, I think we would need more information to proceed. I compiled this with 4.1, Suse 10.1. Now I try this with jikes 1.22. Then It works well. I think it is a bug with gcj in Suse 10.1. Thanks for help -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug java/29061] nternal compiler error: in make_class_data, at java/class.c:1774
--- Comment #5 from tromey at gcc dot gnu dot org 2006-09-13 17:17 --- Fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
[Bug rtl-optimization/28062] [latent] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-13 17:37 --- But the bug still exists, just was covered up by my tree-inline patches for PR 28075. Your patch may simply be the fix. If we have no testcase, we have no bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #4 from mbo dot massimo at tiscali dot it 2006-09-13 18:03 --- I have installed the fix and the problem is now resolved. I have tested it on a large program and it is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug c++/29065] New: obscure error for attempt to use destructor declarator syntax for destructor call
This code snippet:
class X
{
~X() {}
void f ()
{
X::~X ();
}
};
violates clause 12.4 ; 12 (explicit destructor calls must use a member
access operator) . However, the diagnostic given is somewhat confusing:
dstr.c: In member function void X::f():
dstr.c:6: error: no matching function for call to X::~X()
dstr.c:3: note: candidates are: X::~X()
--
Summary: obscure error for attempt to use destructor declarator
syntax for destructor call
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29065
[Bug ada/29025] [4.1/4.2 regression] procedure doesn't modify In Out parameter
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:09 --- I have installed the fix and the problem is now resolved. I have tested it on a large program and it is OK. Great, thanks for the feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
[Bug c++/29059] [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
--- Comment #2 from janis at gcc dot gnu dot org 2006-09-13 18:13 --- A regression hunt on powerpc-linux identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=116656 r116656 | jakub | 2006-09-02 06:55:09 + (Sat, 02 Sep 2006) Interestingly enough, I've been looking into runtime failures in FreePOOMA that started with the same patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug c++/29066] New: ARM C++ ABI mishap
Given the test case below, it appears that while a pointer to a member function
(PTMF) is initialized properly, the check against a NULL pointer still fails.
The same case passes properly on x86 and SH4 - it appears to be an ARM ABI
detail which causing the heartburn.
In most platforms, the member pointer (being __pfn and __delta) the __pfn uses
the LSB to determine if the PTMF is pointing to a virtual or static function,
and then uses the __delta as needed. In the ARM case, since Thumb ISA needs
that LSB, the ARM C++ ABI designates the LSB of the __delta to make that
designation (and the __delta is also twice the actual adjustment needed).
Debugging the testcase shows the __pfn as 0, and the __delta as 1, which tells
me that it's offset 0 into the vtable to call the proper member function.
Alas, the check against NULL seems to show that the logic to determine NULL
isn't checking both the __pfn and the LSB of the __delta (NULL is __pfn=0 and
LSB of __delta is 0).
Am I missing something, or is this a bug (I did a search on ARM,C++,ABI and
didn't turn up anything)? Thanks in advance for any ideas/feedback.
Here is the testcase:
#include iostream
using namespace std;
class X {
public:
virtual void a(void)=0;
virtual void b(void)=0;
X(void);
virtual ~X(void);
protected:
private:
/* none */
};
X::X(void) {
;
}
X::~X(void) {
;
}
class Z : public X {
public:
void a(void);
void b(void);
Z(void);
~Z(void);
protected:
private:
};
Z::Z(void) {
;
}
Z::~Z(void) {
;
}
void Z::a(void) {
cout Doing Z::a endl;
}
void Z::b(void) {
cout Doing Z::b endl;
}
static int doit = 1;
static int donot = 0;
void f(X *obj) {
void (X::*xp)(void) = 0;
if (doit) {
xp = X::a;
} else if (donot) {
xp = X::b;
}
if(xp!=0) {
(obj-*xp)();
} else {
cout Failed! XP is still Zero endl;
}
}
int main(int argc, char* argv[]) {
Z myobj;
f(myobj);
return 0;
}
--
Summary: ARM C++ ABI mishap
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amallory at qnx dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug c++/29066] ARM C++ ABI mishap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 18:25 --- Is this really the arm eabi C++ ABI and not really the arm C++ ABI? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug ada/21952] [4.1/4.2 regression] Annoying attribute directive ignored warnings
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:27 --- Subject: Bug 21952 Author: ebotcazou Date: Wed Sep 13 18:27:24 2006 New Revision: 116926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116926 Log: PR ada/21952 * gigi.h (gnat_internal_attribute_table): Declare. * misc.c (LANG_HOOKS_ATTRIBUTE_TABLE): Define to above. * utils.c (gnat_internal_attribute_table): New global variable. (builtin_function): Always call decl_attributes on the builtin. (handle_const_attribute): New static function. (handle_nothrow_attribute): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gigi.h trunk/gcc/ada/misc.c trunk/gcc/ada/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] [4.1/4.2 regression] Annoying attribute directive ignored warnings
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:27 --- Subject: Bug 21952 Author: ebotcazou Date: Wed Sep 13 18:27:46 2006 New Revision: 116927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116927 Log: PR ada/21952 * gigi.h (gnat_internal_attribute_table): Declare. * misc.c (LANG_HOOKS_ATTRIBUTE_TABLE): Define to above. * utils.c (gnat_internal_attribute_table): New global variable. (builtin_function): Always call decl_attributes on the builtin. (handle_const_attribute): New static function. (handle_nothrow_attribute): Likewise. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/gigi.h branches/gcc-4_1-branch/gcc/ada/misc.c branches/gcc-4_1-branch/gcc/ada/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] [4.1/4.2 regression] Annoying attribute directive ignored warnings
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:29 --- Fixed in upcoming 4.1.2 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00512.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug c++/29065] obscure error for attempt to use destructor declarator syntax for destructor call
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 18:29 --- Actually that is incorrect and this code is really valid by DR 272. This is a dup of bug 12333 which is about rejecting this code. *** This bug has been marked as a duplicate of 12333 *** -- 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=29065
[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-13 18:29 --- *** Bug 29065 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333
[Bug c++/29066] ARM C++ ABI mishap
--- Comment #2 from amallory at qnx dot com 2006-09-13 18:30 --- (In reply to comment #1) Is this really the arm eabi C++ ABI and not really the arm C++ ABI? ARM eabi is an alias for the ABI for the ARM Architecture. Do you have anything on point to help clairify the issue? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29066
[Bug c++/29059] [4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator [0];)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 18:34 --- (In reply to comment #2) A regression hunt on powerpc-linux identified the following patch: This is what I was expecting actually, I might look at this later, we might just need a fold (read from constant string) so we can fold [0] correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29059
[Bug c++/29033] %s substituted with left/right can't be properly translated
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29033
[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:40 --- Subject: Bug 28591 Author: ebotcazou Date: Wed Sep 13 18:40:26 2006 New Revision: 116928 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116928 Log: PR ada/28591 * decl.c (components_to_record): Defer emitting debug info for the record type associated with the variant until after we are sure to actually use it. Added: trunk/gcc/testsuite/gnat.dg/specs/unchecked_union.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug target/29030] gcc.dg/array-9.c produces internal compiler error on Darwin at -m64
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2006-09-13 18:41 --- Okay. I'll run a complete make check tonight to verify that the patch introduces no regressions in at least the c, c++ and fortran language build. Assuming no regressions, do you want to submit the patch or should I (assuming Geoff has no objections to it)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:42 --- Fixed on mainline. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00514.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
