[Bug c++/28567] New: [cygwin] ICE in eh_alloc.cc on 'make install'

[baraclese at googlemail dot com]

Hi,
Building and installing gcc-4.1.1 on cygwin failed in the final make install
step. Here's my script:
../gcc-4.1.1/configure --with-gcc --with-gnu-ld --with-gnu-as --enable-threads
--disable-nls --enable-languages=c,c++ --disable-win32-registry
--disable-shared --disable-sjlj-exceptions --without-x --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads
-fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap 2>err.log

on make install, the ICE occurs here:
/home/Kevin/objs/./gcc/xgcc -shared-libgcc -B/home/Kevin/objs/./gcc -nostdinc++
-L/home/Kevin/objs/i686-pc-cygwin/libstdc++-v3/src
-L/home/Kevin/objs/i686-pc-cygwin/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/include -isystem
/usr/local/i686-pc-cygwin/sys-include
-I/home/Kevin/gcc-4.1.1/libstdc++-v3/../gcc
-I/home/Kevin/objs/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
-I/home/Kevin/objs/i686-pc-cygwin/libstdc++-v3/include
-I/home/Kevin/gcc-4.1.1/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -c
../../../../gcc-4.1.1/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o
../../../../gcc-4.1.1/libstdc++-v3/libsupc++/eh_alloc.cc:1: warning:
-ffunction-sections may affect debugging on some targets
../../../../gcc-4.1.1/libstdc++-v3/libsupc++/eh_alloc.cc: In function 'void*
__cxxabiv1::__cxa_allocate_exception(size_t)':
../../../../gcc-4.1.1/libstdc++-v3/libsupc++/eh_alloc.cc:160: internal compiler
error: Segmentation fault

Additional notes:
Removing the -O2 option makes the ICE occur a bit later in eh_alloc.cc:183.


-- 
   Summary: [cygwin] ICE in eh_alloc.cc on 'make install'
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baraclese at googlemail dot com
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28567

[Bug c++/28567] [cygwin] ICE in eh_alloc.cc on 'make install'

[baraclese at googlemail dot com]

--- Comment #1 from baraclese at googlemail dot com  2006-08-02 08:51 
---
Created an attachment (id=11990)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11990&action=view)
preprocessed file created via -save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28567

[Bug c++/28567] [cygwin] ICE in eh_alloc.cc on 'make install'

[dannysmith at users dot sourceforge dot net]

--- Comment #2 from dannysmith at users dot sourceforge dot net  2006-08-02 
09:56 ---
--disable-sjlj-exceptions in your configure options will cause serious problems
on cygwin unless you also provide support for enabling Dwarf2 EH frame.

Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28567

[Bug c/28568] New: compiler generates incorrect ARM instructions when using long bitfields

[jason dot morgan at vpnsolutions dot uk dot com]

#define __REG32 volatile unsigend long

typedef struct
{
  __REG32 Bit0 :1;
  __REG32 Bit1 :1;
  ...etc...
  __REG32 Bit31 :1;
}__Bitfield;

#define ADDRESS 

#define REG (*( __REG32 *)(ADDRESS))
#define REG_bit (*(__Bitfield *)®)

When I access the register using the bitfield I get the code like the following

LCD_bit.Backlight=1;//??
 358:   e3a0320emov r3, #-536870912 ; 0xe000
 35c:   e283390aadd r3, r3, #163840 ; 0x28000
 360:   e5d32001ldrbr2, [r3, #1]
 364:   e3822004orr r2, r2, #4  ; 0x4
 368:   e5c32001strbr2, [r3, #1]


-- 
   Summary: compiler generates incorrect ARM instructions when using
long bitfields
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot morgan at vpnsolutions dot uk dot com
GCC target triplet: arm-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

[Bug c/28569] New: Segmentation fault from struct pointers

[sawada at icepp dot s dot u-tokyo dot ac dot jp]

When I compile following source code with command line option -O, gcc stops due
to segmentation fault. I have attached also error message from gcc.

This problem could be fixed by initializing pointers like
   char *p = 0;
   AAA *aaa = 0;
   BBB *bbb = 0;

My system is "Linux 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 10:16:56 CDT 2006 i686
i686 i386 GNU/Linux"

source code
typedef struct {
   int m1;
   int m2;
} AAA;

typedef struct {
   int n1;
   int n2;
} BBB;

void function()
{
   char *p;
   AAA *aaa;
   BBB *bbb;

   aaa = p + bbb->n2;
   if ((p + aaa->m2) == bbb) {
  aaa->m2 = 0;
   }
}
--





-- error message --
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-20060722/configure --prefix=/scratch1/sawada/sw/
--program-suffix=4.2
Thread model: posix
gcc version 4.2.0 20060722 (experimental)
 /scratch1/sawada/sw/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -E -quiet
-v -iprefix /scratch1/sawada/sw/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/
src/odb.c -mtune=generic -O -fpch-preprocess -o odb.i
ignoring duplicate directory
"/scratch1/sawada/sw//lib/gcc/i686-pc-linux-gnu/4.2.0/include"
ignoring duplicate directory
"/scratch1/sawada/sw//lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /scratch1/sawada/sw/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/include

/scratch1/sawada/sw/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include
 /usr/local/include
 /scratch1/sawada/sw//include
 /usr/include
End of search list.
 /scratch1/sawada/sw/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1
-fpreprocessed odb.i -quiet -dumpbase odb.c -mtune=generic -auxbase-strip
linux/lib/odb.o -O -version -o odb.s
GNU C version 4.2.0 20060722 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.2.0 20060722 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c60a7c38da40d38cd0cf294fac9048c8
src/odb.c: In function 'function':
src/odb.c:17: warning: assignment from incompatible pointer type
src/odb.c:18: warning: comparison of distinct pointer types lacks a cast
gcc4.2: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: Segmentation fault from struct pointers
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sawada at icepp dot s dot u-tokyo dot ac dot jp


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28569

[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2006-08-02 10:38 
---
Please provide a fully compilable testcase that demonstrates the bug.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

[Bug awt/16825] need to reimplement QuadCurve2D.solveQuadratic

[aph at gcc dot gnu dot org]

--- Comment #23 from aph at gcc dot gnu dot org  2006-08-02 10:56 ---
QuadCurve2D.solveQuadratic already uses the algorithm in Numerical Recipes.

*** This bug has been marked as a duplicate of 323 ***


-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aph at redhat dot com
 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16825

[Bug rtl-optimization/323] optimized code gives strange floating point results

[aph at gcc dot gnu dot org]

--- Comment #83 from aph at gcc dot gnu dot org  2006-08-02 10:56 ---
*** Bug 16825 has been marked as a duplicate of this bug. ***


-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2006-08-02 10:58 ---
(In reply to comment #0)
> #define __REG32 volatile unsigend long
> 
> typedef struct
> {
>   __REG32 Bit0 :1;
>   __REG32 Bit1 :1;
>   ...etc...
>   __REG32 Bit31 :1;
> }__Bitfield;
> 
> #define ADDRESS 
> 
> #define REG (*( __REG32 *)(ADDRESS))
> #define REG_bit (*(__Bitfield *)®)
> 
> When I access the register using the bitfield I get the code like the 
> following
> 
> LCD_bit.Backlight=1;//??
>  358:   e3a0320emov r3, #-536870912 ; 0xe000
>  35c:   e283390aadd r3, r3, #163840 ; 0x28000
>  360:   e5d32001ldrbr2, [r3, #1]
>  364:   e3822004orr r2, r2, #4  ; 0x4
>  368:   e5c32001strbr2, [r3, #1]
> 

this code isn't wrong. gcc doesn't know that is a register
mapped into arm address space which requires full-word access.
imo this is a dup of PR23623.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields

[jason dot morgan at vpnsolutions dot uk dot com]

--- Comment #3 from jason dot morgan at vpnsolutions dot uk dot com  
2006-08-02 11:30 ---
Indeed it is.

I didn't mean to post this and was still researching the problem when I
accidently posted it.  I found PR23623 shortly afterwards.

What is the status of PR23624.   I see there was a checkin, what do I have to
do to make use of the change?

*** This bug has been marked as a duplicate of 23623 ***


-- 

jason dot morgan at vpnsolutions dot uk dot com changed:

   What|Removed |Added

 CC||jason dot morgan at
   ||vpnsolutions dot uk dot com
 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

[jason dot morgan at vpnsolutions dot uk dot com]

--- Comment #11 from jason dot morgan at vpnsolutions dot uk dot com  
2006-08-02 11:30 ---
*** Bug 28568 has been marked as a duplicate of this bug. ***


-- 

jason dot morgan at vpnsolutions dot uk dot com changed:

   What|Removed |Added

 CC||jason dot morgan at
   ||vpnsolutions dot uk dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623

[Bug c++/28523] [4.0 Regression] Throw of a derived class casted to its base class using a C-style cast

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code, monitored
   Target Milestone|4.1.2   |4.0.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28523

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[paulthomas2 at wanadoo dot fr]

--- Comment #4 from paulthomas2 at wanadoo dot fr  2006-08-02 12:02 ---
Subject: Re:  [4.2 Regression]: Optional argument failed


I'll take a look at this as soon as I get home (friday).  There is a PR out on
PRESENT that I noticed before leaving.  I'll try to gather together the
problems and sort them out in one fell swoop.

Best regards

Paul


> Message du 31/07/06 02:23
> De : "kargl at gcc dot gnu dot org" 
> A : [EMAIL PROTECTED]
> Copie à : 
> Objet : [Bug fortran/28548] [4.2 Regression]: Optional argument failed
> 
> 
> 
> --- Comment #3 from kargl at gcc dot gnu dot org 2006-07-31 00:23 ---
> Andrew, I think it is a bug. The language in section 12.4.1.5 is somewhat
> convoluted and the description of PRESENT() suggest that PRESENT is special.
> 
> From 12.4.1.5:
> 
> An optional dummy argument that is not present is subject to the
> following restrictions:
> 
> (3) It shall not be supplied as an actual argument corresponding to
> a nonoptional dummy argument other than as the argument of the
> PRESENT intrinsic function.
> 
> (5) If it is an array, it shall not be supplied as an actual argument
> to an elemental procedure unless an array of the same rank is
> supplied as an actual argument corresponding to a nonoptional dummy
> argument of that elemental procedure.
> 
> 
> 13.14.82 PRESENT (A)
> 
> Description. Determine whether an optional argument is present.
> 
> Class. Inquiry function.
> 
> Argument. 'A' shall be the name of an optional dummy argument
> that is accessible in the subprogram in which the
> PRESENT function reference appears. It may be of any
> type and it may be a pointer. It may be scalar or array
> valued. It may be a dummy procedure. The dummy argument
> 'A' has no INTENT attribute.
> 
> 
> -- 
> 
> kargl at gcc dot gnu dot org changed:
> 
> What |Removed |Added
> 
> CC| |kargl at gcc dot gnu dot org
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> 
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548

[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields

[rearnsha at gcc dot gnu dot org]

--- Comment #4 from rearnsha at gcc dot gnu dot org  2006-08-02 12:35 
---
> What is the status of PR23624.   I see there was a checkin, what do I have to
> do to make use of the change?


You have to convert your code/system to use the EABI version of GCC; or you
have to modify your source so that it doesn't use volatile bitfields.  The EABI
for ARM mandates the behaviour of volatile bitfields, but the arm-elf
configuration does not use that ABI and has different semantics in this area.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

[Bug rtl-optimization/28569] [4.2 Regression] Segmentation fault from struct pointers

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-08-02 12:40 ---
Confirmed:

Starting program: /abuild/rguenther/trunk-g/gcc/cc1 -O -quiet t.i
t.i: In function 'function':
t.i:17: warning: assignment from incompatible pointer type
t.i:18: warning: comparison of distinct pointer types lacks a cast

Program received signal SIGSEGV, Segmentation fault.
0x082950e5 in fold_rtx (x=0xb7d53a14, insn=0x0)
at /space/rguenther/src/svn/trunk/gcc/cse.c:3718
3718int old_cost = COST_IN (XEXP (x, i), code);

we are recursing endlessly.  Likely a dup of PR27616 (the testcase also looks
similar).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||27616
 Status|UNCONFIRMED |NEW
  Component|c   |rtl-optimization
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2006-08-02 12:40:23
   date||
Summary|Segmentation fault from |[4.2 Regression]
   |struct pointers |Segmentation fault from
   ||struct pointers


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28569

[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields

[jason dot morgan at vpnsolutions dot uk dot com]

--- Comment #5 from jason dot morgan at vpnsolutions dot uk dot com  
2006-08-02 12:56 ---
The problem is that I am porting code from the IAR systems compiler that makes
large use of bitfields to access registers.  Obviously it handles bitfields
correctly. And I don't particularly want to re-write every access.

Where do I obtain EABI and what effect will it have on my toolchain?

Is there any plan or project to merge the resolution to PR23623 back into gcc
4.1.1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

[Bug debug/28063] [4.2 regression] Dwarf no longer uses merged strings for DW_AT_comp_dir

[drow at gcc dot gnu dot org]

--- Comment #2 from drow at gcc dot gnu dot org  2006-08-02 13:32 ---
Subject: Bug 28063

Author: drow
Date: Wed Aug  2 13:31:56 2006
New Revision: 115874

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115874
Log:
gcc/
PR debug/28063
* dwarf2out.c (prune_unused_types_prune): Move call to
prune_unused_types_update_strings to cover the parent DIE also.
gcc/testuite/
PR debug/28063
* gcc.dg/debug/dwarf2/dwarf-merge.c: New test.
* lib/target-supports.exp (get_compiler_messages): Add WANT_OUTPUT.
Optionally return assembly text.  Update callers.
(check_no_compiler_messages): Update verbose messages.
(check_no_messages_and_pattern): New.
(check_effective_target_string_merging): New.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-merge.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28063

[Bug debug/23336] [4.0/4.1 Regression] enum constants not visible to gdb because of -feliminate-unused-debug-types

[drow at gcc dot gnu dot org]

--- Comment #11 from drow at gcc dot gnu dot org  2006-08-02 13:35 ---
Fixed for 4.2.


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] enum
   |enum constants not visible  |constants not visible to gdb
   |to gdb because of - |because of -feliminate-
   |feliminate-unused-debug-|unused-debug-types
   |types   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23336

[Bug debug/28063] [4.2 regression] Dwarf no longer uses merged strings for DW_AT_comp_dir

[drow at gcc dot gnu dot org]

--- Comment #3 from drow at gcc dot gnu dot org  2006-08-02 13:37 ---
Now fixed in 4.2; nothing else affected.


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28063

[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #9 from mkuvyrkov at gcc dot gnu dot org  2006-08-02 13:44 
---
(In reply to comment #8)
> The time that this started occurring looks to be about the time that Maxim was
> making scheduling changes for IA64 speculation.  Maxim could you look at this
> bug and see if it is related to any of your changes to IA64 scheduling?  I did
> a little analysis and it looks like we are merging/concatinated two basic
> blocks (3 and 7) but we wind up with a NOTE_INSN_BASIC_BLOCK for block 7 in 
> the
> middle of the merged basic block 3.

That's my bug, sorry.
In this testcase we hit a rare case when we end up with dead code during
scheduling.

More specifically:
--
(insn 127 128 108 3 (set (reg:DI 332 ar.lc)
(reg:DI 35 r35)) 5 {*movdi_internal} (nil)
(expr_list:REG_DEAD (reg:DI 35 r35)
(nil)))
(call_insn/j 108 127 146 3 (call (mem:DI (symbol_ref:DI ("cr") [flags 0x3]
) [0 S8 A64])
(const_int 0 [0x0])) 321 {sibcall_nogp} (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 320 b0))
(expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
(nil
---

More specifically, a call (108) - which will exit from the function - is
scheduled before insn (127) thus making it dead.  To schedule the dead insn we
should create an empty basic block right after call.  But I've made a mistake
and current code creates new basic block just before it.

While debugging one of the above testcases I've also discovered another problem
in switching between blocks in the ebb.  While switching to the next block we
should skip empty ones so that jumps won't be moved across blocks when not
particularly needed.

The attached patch works for all testcases and as soon as regtesting is over
I'll post it to gcc-patches list.

> 
> (I tried to add [EMAIL PROTECTED] to the CC list but Bugzilla wouldn't do it.

It is because [EMAIL PROTECTED] doesn't have a Bugzilla account.
You could've add [EMAIL PROTECTED] .

Thanks for the testcases.  It is good to have several testcases as only one of
them revealed the second problem.


Thanks,
Maxim


-- 

mkuvyrkov at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |mkuvyrkov at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-07-29 10:57:44 |2006-08-02 13:44:23
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489

[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #12 from mkuvyrkov at gcc dot gnu dot org  2006-08-02 13:45 
---
Created an attachment (id=11996)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11996&action=view)
Patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490

[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #10 from mkuvyrkov at gcc dot gnu dot org  2006-08-02 13:49 
---
Created an attachment (id=11997)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11997&action=view)
Patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489

[Bug c++/28573] New: incorrectly allowing non-constant expression to offsetof()

[karl dot corbin at Summit dot Fiserv dot com]

The following code incorrectly compiles, and worse returns incorrect result.
on i686-pc-linux-gnu, both 4.1.0 and 4.1.1

-- start snip
#include 

// (incomplete) template class that encapsulates an array of chars
template class CharArray
{
public:
   char d[i];
   char& operator [] ( int indx )
   {
  return d[indx];
   }
};

struct Foo
{
   int i;
   CharArray<44> caCharArray;
};


int main( int argc, char* argv[] )
{
   Foo foo;
   int i;

// Shouldn't compile, and worse results in incorrect offset.
   i = offsetof(Foo, caCharArray[0]);

}

-- end snip
variables as an array index correctly give an error, but unfortunatly not
everything that looks like an constant array index is.


-- 
   Summary: incorrectly allowing non-constant expression to
offsetof()
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: karl dot corbin at Summit dot Fiserv dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28573

[Bug c++/28573] [4.0/4.1/4.2 Regression] incorrectly allowing non-constant expression to offsetof()

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Known to fail||3.3.3 4.0.0 4.1.0
  Known to work||3.4.0
Summary|incorrectly allowing non-   |[4.0/4.1/4.2 Regression]
   |constant expression to  |incorrectly allowing non-
   |offsetof()  |constant expression to
   ||offsetof()
   Target Milestone|--- |4.0.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28573

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #5 from skunk at iskunk dot org  2006-08-02 16:18 ---
Created an attachment (id=11998)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11998&action=view)
test-cc.pl: Fussy compiler simulator script

This is a Perl script I put together to investigate the CFLAGS behavior,
instead of repeated bootstraps on my 64-bit Slowaris box. You set the following
environment variables...

CC=/path/to/test-cc.pl
REAL_CC=gcc
CFLAGS="(your usual compiler flags) --foobaz"

...and the script will bork if it does not see exactly one instance of
--foobaz. Otherwise, it'll remove that option, and invoke $REAL_CC with what
remains. The system/stage[23] compiler will, of course, similarly choke if it
sees --foobaz.

So here, you have a way of verifying that $CC and $CFLAGS are always and only
used together. Currently, this is not the case; I'm seeing GCC's stage1 build
passing nothing more than "-g" to the compiler, despite CFLAGS. (Even setting
STAGE1_CFLAGS in the environment before configure time has no effect.) There is
also a point in the stage2 build where $CFLAGS is passed to xgcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #6 from skunk at iskunk dot org  2006-08-02 16:30 ---
Interestingly enough, the test-cc script teased out an apparent bug in
config/depstand.m4 (routines to check the compiler's mode of dependency
generation). When the compiler is invoked, at the $SHELL line in the below
excerpt...

(begin config/depstand.m4 excerpt)
depcmd="depmode=$depmode \
   source=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
   depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
   $SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c"
echo "| $depcmd" | sed -e 's/  */ /g' >&AS_MESSAGE_LOG_FD
if env $depcmd > conftest.err 2>&1 &&
(end config/depstand.m4 excerpt)

...no compiler flags are passed to it.

You'll have to work around this in order to make use of the wrapper script, but
would this be worth a new bug report? You could imagine a case where the
compiler does something stupid here (strict K&R mode?) if it doesn't get a
certain flag.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp

[atgraham at gmail dot com]

--- Comment #7 from atgraham at gmail dot com  2006-08-02 17:03 ---
Is it possible that #28493 is a symptom of the same problem?  Does anyone build
the darwin compiler with SjLj exceptions?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983

[Bug target/28574] New: [4.2 regression] switch statement points to unreferenced label at -O2

[tbm at cyrius dot com]

Compiling an application on IA-64, I got errors during linking about undefined
references to a label.  This reference is produced by the compiler as part of a
switch statement but the label itself is not actually generated.  Note that
this looks so much like PR27531 but the patch that fixed that problem on sparc
doesn't help on ia64.  I hope though that previous investigation for PR27531
will help solve this problem.  It certainly looks related, although I cannot
tell for sure.

[EMAIL PROTECTED]:~/bugs$ /usr/lib/gcc-snapshot/bin/gcc -O2 yasm-module.c
/usr/lib/crt1.o: In function `_start':
(.text+0x41): undefined reference to `main'
/tmp/ccOFSz00.o: In function `yasm_list_modules':
yasm-module.c:(.text+0x70): undefined reference to `.L11'
yasm-module.c:(.text+0x80): undefined reference to `.L11'
collect2: ld returned 1 exit status
[EMAIL PROTECTED]:~/bugs$ /usr/lib/gcc-snapshot/bin/gcc -O1 yasm-module.c
/usr/lib/crt1.o: In function `_start':
(.text+0x41): undefined reference to `main'
collect2: ld returned 1 exit status
[EMAIL PROTECTED]:~/bugs$ gcc-4.1 -O2 yasm-module.c
/usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../crt1.o: In function `_start':
(.text+0x41): undefined reference to `main'
collect2: ld returned 1 exit status
[EMAIL PROTECTED]:~/bugs$ gcc-4.0 -O2 yasm-module.c
/usr/lib/gcc/ia64-linux-gnu/4.0.4/../../../crt1.o: In function `_start':
(.text+0x41): undefined reference to `main'
collect2: ld returned 1 exit status
[EMAIL PROTECTED]:~/bugs$


-- 
   Summary: [4.2 regression] switch statement points to unreferenced
label at -O2
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
 GCC build triplet: [EMAIL PROTECTED]
  GCC host triplet: ia64-linux-gnu
GCC target triplet: ia64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2006-08-02 17:17 ---
Created an attachment (id=11999)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11999&action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-08-02 17:24 ---
(In reply to comment #7)
> Is it possible that #28493 is a symptom of the same problem?  Does anyone 
> build
> the darwin compiler with SjLj exceptions?

Why would they, dwarf-2 eh's overhead is much smaller if throws are not done
than sjlj exceptions.  Also I think this is a different problem and the problem
in the other PR is much older (dates back to 3.3/3.4 at least).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops

[danglin at gcc dot gnu dot org]

--- Comment #32 from danglin at gcc dot gnu dot org  2006-08-02 18:21 
---
Patch here: .


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244

[Bug c++/28567] [cygwin] ICE in eh_alloc.cc on 'make install'

[baraclese at googlemail dot com]

--- Comment #3 from baraclese at googlemail dot com  2006-08-02 18:35 
---
I see, I set the resolution to INVALID since it is the wrong usage of a
configure option that caused this bug on the cygwin platform. There is
additional information on the cygwin mailing list archives about this issue.


-- 

baraclese at googlemail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28567

[Bug web/28575] New: misleading __builtin_choose_expr documentation error

[twang at apple dot com]

This documentation error exists for all versions of gcc-3.*, gcc-4.*
documentation.

Relevant links are 
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Other-Builtins.html
http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Other-Builtins.html

The error text is:
Built-in Function: type __builtin_choose_expr (const_exp, exp1, exp2)
You can use the built-in function __builtin_choose_expr to evaluate code
depending on the value of a constant expression. This built-in function returns
exp1 if const_exp, which is a constant expression that must be able to be
determined at compile time, is nonzero. 

--> Otherwise it returns 0.
should be
--> Otherwise it returns exp2.

This is confusing and misleading for the actual functionailty of the builtin,
it shold be changed.


-- 
   Summary: misleading __builtin_choose_expr documentation error
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: twang at apple dot com
 GCC build triplet: powerpc-apple-darwin8
  GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28575

[Bug c/28575] misleading __builtin_choose_expr documentation error

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu dot org
   Severity|minor   |enhancement
  Component|web |c
  GCC build triplet|powerpc-apple-darwin8   |
   GCC host triplet|powerpc-apple-darwin8   |
 GCC target triplet|powerpc-apple-darwin8   |
   Keywords||documentation


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28575

[Bug c/28575] misleading __builtin_choose_expr documentation error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-02 18:50 ---
Confirmed. This has been an issue since the function was added.


-- 

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-08-02 18:50:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28575

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2006-08-02 19:03 ---
There are a million reasons why labels can disappear in GCC. This happens
because GCC deletes or keeps labels based on ref counting (LABEL_NUSES and
friends) and this is just too fragile.

The way for you to narrow down the bug is this:

1. Compile with -daAP
2. Look in the .s file which instruction references the missing label. There
should be a LABEL_REF with a number.
3. Grep for "code_label.*" in the RTL dumps.  The label should at least
appear in the .expand dump.

This will help you find the pass during/after which the label disappears.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug middle-end/28417] suboptimal 'division by constant' optimization

[vda dot linux at googlemail dot com]

--- Comment #9 from vda dot linux at googlemail dot com  2006-08-02 19:05 
---
Thanks for the link to .pdf! Who's Tege? And his email address is ...?

Ok. This new version of the patch is working for signed divisions too, and is
giving the results which are always same or better than "old" code.

If it would be deemed acceptable for mainline, it can be simply be integrated
into choose_multiplier().

Since new code needs to know maximum possible dividend instead of (n,prec)
tuple, and it can generate better code if dividend is known to be small enough
(example: (n & 0x) / 10 will need only a mul, not mul+shift), it will make
sense to propagate possible dividend range into choose_multiplier() intead of
(n,prec). TODO later...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417

[Bug middle-end/28417] suboptimal 'division by constant' optimization

[vda dot linux at googlemail dot com]

--- Comment #10 from vda dot linux at googlemail dot com  2006-08-02 19:05 
---
Created an attachment (id=12000)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12000&action=view)
Alternative algorithm v. 2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[steven at gcc dot gnu dot org]

-- 

steven 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-08-02 19:12:41
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[tbm at cyrius dot com]

--- Comment #3 from tbm at cyrius dot com  2006-08-02 19:13 ---
Thanks for the explanation!  I see the following two references in the
assembler file but I don't see any code_label references to those number in the
dumps.

//(insn/c 185 231 30 2 (set (reg/f:DI 14 r14 [386])
//(plus:DI (high:DI (label_ref:DI 48))
//(reg:DI 1 r1))) 76 {*load_symptr_high} (nil)
//(nil))
addl r14 = @ltoffx(.L11), r1// 185  *load_symptr_high

and:

//(insn:TI 186 230 229 3 (set (reg/f:DI 14 r14 [386])
//(lo_sum:DI (reg/f:DI 14 r14 [386])
//(label_ref:DI 48))) 77 {*load_symptr_low} (nil)
//(nil))
ld8.mov r14 = [r14], .L11   // 186  *load_symptr_low


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[tbm at cyrius dot com]

--- Comment #4 from tbm at cyrius dot com  2006-08-02 19:15 ---
Ah, sorry, looked for the wrong number.  The last pass which has the case_label
is:

yasm-module.c.144r.peephole2:(code_label 48 47 49 11 "" [3 uses])


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[tbm at cyrius dot com]

--- Comment #5 from tbm at cyrius dot com  2006-08-02 19:17 ---
So from 144r (peephole2) to 145r (ce3) it goes from:

;; Insn is not within a basic block
(code_label 48 47 49 11 "" [3 uses])

;; Insn is not within a basic block
(jump_insn 49 48 50 (addr_diff_vec:DI (label_ref:DI 48)
 [
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
]
(const_int 0 [0x0])
(const_int 0 [0x0])) -1 (nil)
(nil))

(barrier 50 49 103)


to:

...(insn 185 35 186 3 (set (reg/f:DI 14 r14 [386])
(plus:DI (high:DI (label_ref:DI 48))
(reg:DI 1 r1))) 76 {*load_symptr_high} (nil)
(nil))

(insn 186 185 44 3 (set (reg/f:DI 14 r14 [386])
(lo_sum:DI (reg/f:DI 14 r14 [386])
(label_ref:DI 48))) 77 {*load_symptr_low} (nil)
(nil))

...

and here's where the case_label is lost.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[steven at gcc dot gnu dot org]

-- 

steven 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-08-02 19:24:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug middle-end/28417] suboptimal 'division by constant' optimization

[amylaar at gcc dot gnu dot org]

--- Comment #11 from amylaar at gcc dot gnu dot org  2006-08-02 19:34 
---
(In reply to comment #9)
> Thanks for the link to .pdf! Who's Tege? And his email address is ...?

Torbjoern Granlund; homepage:  http://swox.se/~tg/ .  From MAINTAINERS:
*synthetic multiply Torbjorn Granlund   [EMAIL PROTECTED]


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[tbm at cyrius dot com]

--- Comment #6 from tbm at cyrius dot com  2006-08-02 19:43 ---
Slightly more reduced testcase:

typedef enum yasm_module_type {
YASM_MODULE_ARCH = 0,
YASM_MODULE_DBGFMT,
YASM_MODULE_OBJFMT,
YASM_MODULE_LISTFMT,
YASM_MODULE_OPTIMIZER
} yasm_module_type;

typedef struct yasm_module {
const char *name;
};

typedef struct yasm_module yasm_arch_module;
typedef struct yasm_module yasm_dbgfmt_module;
typedef struct yasm_module yasm_objfmt_module;
typedef struct yasm_module yasm_listfmt_module;
typedef struct yasm_module yasm_optimizer_module;

typedef struct module {
void *data;
} module;

static struct {
module *m;
int n;
} module_types[] = {
 {},
};

void
yasm_list_modules(yasm_module_type type,
  void (*printfunc) (const char *name))
{
int i;
module *modules = module_types[type].m;
yasm_arch_module *arch;
yasm_dbgfmt_module *dbgfmt;
yasm_objfmt_module *objfmt;
yasm_listfmt_module *listfmt;
yasm_optimizer_module *optimizer;

for (i=0; i<2; i++) {
switch (type) {
case YASM_MODULE_ARCH:
arch = modules[i].data;
printfunc(arch->name);
break;
case YASM_MODULE_DBGFMT:
dbgfmt = modules[i].data;
printfunc(dbgfmt->name);
break;
case YASM_MODULE_OBJFMT:
objfmt = modules[i].data;
printfunc(objfmt->name);
break;
case YASM_MODULE_LISTFMT:
listfmt = modules[i].data;
printfunc(listfmt->name);
break;
case YASM_MODULE_OPTIMIZER:
optimizer = modules[i].data;
printfunc(optimizer->name);
}
}
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug java/28576] New: PlainDatagramSocketImpl::connect: not implemented yet

[miguel at jpolicy dot org]

Using snapshot 20060729.

./configure --prefix=/usr/local/ --program-suffix=-4.2 --enable-languages=java

No compilation errors.

Using Debian Sarge 3.1

smtp:/home/passaro# gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

Using dnsjava, I got this error:

Exception in thread "Handler" java.lang.InternalError:
PlainDatagramSocketImpl::connect: not implemented yet
   at
gnu.java.net.PlainDatagramSocketImpl.connect(natPlainDatagramSocketImpl.cc:155)
   at java.net.DatagramSocket.connect(DatagramSocket.java:512)
   at java.net.DatagramSocket.connect(DatagramSocket.java:734)
   at gnu.java.nio.DatagramChannelImpl.connect(DatagramChannelImpl.java:124)
   at org.xbill.DNS.UDPClient.connect(UDPClient.java:26)
   at org.xbill.DNS.UDPClient.sendrecv(UDPClient.java:68)
   at org.xbill.DNS.SimpleResolver.send(SimpleResolver.java:262)
   at org.xbill.DNS.ExtendedResolver$Resolution.start(ExtendedResolver.java:93)
   at org.xbill.DNS.ExtendedResolver.send(ExtendedResolver.java:364)
   at org.xbill.DNS.Lookup.lookup(Lookup.java:450)
   at org.xbill.DNS.Lookup.resolve(Lookup.java:502)
   at org.xbill.DNS.Lookup.run(Lookup.java:516)
   at
org.apache.james.jspf.DNSServiceXBillImpl.getTXTRecords(DNSServiceXBillImpl.java:119)
   at
org.apache.james.jspf.DNSServiceXBillImpl.getSpfRecord(DNSServiceXBillImpl.java:66)
   at org.apache.james.jspf.SPF.checkSPF(SPF.java:146)
   at org.apache.james.jspf.SPF.checkSPF(SPF.java:87)
   at jpolicy.rule.SPFCheck.runCheck(SPFCheck.java:17)
   at jpolicy.PolicyProtocol.runRules(PolicyProtocol.java:274)
   at jpolicy.PolicyProtocol.run(PolicyProtocol.java:180)


-- 
   Summary: PlainDatagramSocketImpl::connect: not implemented yet
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: miguel at jpolicy dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28576

[Bug java/28577] New: make of gcc-4.1.1 failed using icc v9.1.042 on ia64

[t35t0r at gmail dot com]

Trying to compile gcc-4.1.1 with icc-9.1.042 . I did:

setenv CC icc
setenv CXX icc
./configure --prefix=/not/normal --enable-threads --enable-tls
make

It got to this location and failed:

/usr/include/sys/ucontext.h: At global scope:
/usr/include/sys/ucontext.h:49: error: array bound is not an integer constant
../.././libjava/prims.cc:146: warning: unused parameter '_sip'
make[3]: *** [prims.lo] Error 1
make[3]: Leaving directory
`/blah/user/gcc-4.1.1/ia64-unknown-linux-gnu/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/blah/user/gcc-4.1.1/ia64-unknown-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/blah/user/gcc-4.1.1'
make: *** [all] Error 2

I guess this is a icc problem but I don't know. I can also post a bug to
premier.intel.com .


-- 
   Summary: make of gcc-4.1.1 failed using icc v9.1.042 on ia64
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t35t0r at gmail dot com
 GCC build triplet: ia64 ia64 ia64 GNU/Linux
  GCC host triplet: ia64 ia64 ia64 GNU/Linux
GCC target triplet: ia64 ia64 ia64 GNU/Linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28577

[Bug libmudflap/28578] New: A most simple multithreaded program (practically any multithreaded one) causes mudflap violation

[vesselinpeev at hotmail dot com]

Here are the exact steps carried out, resulting in the violation "mudflap
violation 1 (unregister)", despite this program being absolutely correct. Note
also that I have confirmed the identical problem with the gcc trunk -- version
4.2.0 (20060729) as well:

$ cat test.c
#include 
#include 

void* test_thread(void* arg)
{
printf("\nHello from thread!");
pthread_exit(NULL);
}

int main()
{
#ifdef _REENTRANT
printf("\nYes, _REENTRANT is defined");
#endif
pthread_t thread;
int arg = 0;
pthread_create(&thread, NULL, test_thread, (void*)arg);
pthread_exit(NULL);
return 0;
}

$ gcc -g -fmudflapth -pthread test.c -lmudflapth

$ ./a.out

***
mudflap violation 1 (unregister): time=1154562440.431557 ptr=0x67d4e0 size=0
pc=0x6273e9
  /usr/lib/libmudflapth.so.0(__mf_unregister+0x49) [0x6273e9]
  /usr/lib/libmudflapth.so.0(__real_free+0xae) [0x62833e]
  /lib/libdl.so.2 [0xa7051a]
number of nearby objects: 0
Yes, _REENTRANT is defined
Hello from thread!


-- 
   Summary: A most simple multithreaded program (practically any
multithreaded one) causes mudflap violation
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vesselinpeev at hotmail dot com
  GCC host triplet: 386


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578

[Bug java/28577] make of gcc-4.1.1 failed using icc v9.1.042 on ia64

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-02 20:13 ---

Two issues, first you should be building in a different directory than the
source directory.  Second, is that you should be using make bootstrap instead
of make.

Does doing both of them fix the problem?

If not, then what is the line 49 of the file /usr/include/sys/ucontext.h?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28577

[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'

[andreast at gcc dot gnu dot org]

--- Comment #10 from andreast at gcc dot gnu dot org  2006-08-02 20:18 
---
Subject: Bug 28546

Author: andreast
Date: Wed Aug  2 20:18:05 2006
New Revision: 115883

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115883
Log:
2006-08-02  Andreas Tobler  <[EMAIL PROTECTED]>

PR libgcj/28546
* include/no-threads.h: Declare _Jv_Thread_t as empty class.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/include/no-threads.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546

[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'

[andreast at gcc dot gnu dot org]

--- Comment #11 from andreast at gcc dot gnu dot org  2006-08-02 20:18 
---
Fixed.


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546

[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2006-08-02 
20:26 ---
Subject: Re:  [4.2 Regression] ./java/lang/Thread.h:31: error: using
typedef-name '_Jv_Thread_t' after 'class'

> --- Comment #11 from andreast at gcc dot gnu dot org  2006-08-02 20:18 
> ---
> Fixed.

Thanks.  Next problem is stack traces with no threads.

Exception in thread "main" java.lang.InternalError: Thread.start called but thr
eads not available
*** Got java.lang.InternalError: Thread.start called but threads not available
while trying to print stack trace.
FAIL: PR18699 execution - source compiled test

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546

[Bug libmudflap/28578] A most simple multithreaded program (practically any multithreaded one) causes mudflap violation

[vesselinpeev at hotmail dot com]

--- Comment #1 from vesselinpeev at hotmail dot com  2006-08-02 20:27 
---
I have tested on more gcc / glibc combinations. The mudflap violation occurs
with glibc 2.4 (the latest glibc version currently), whereas with versions
2.3.5 and 2.3.6, the following printed and occurs instead:

*** glibc detected *** free(): invalid pointer: 0x08ebc9b0 *** Aborted


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578

[Bug c++/28557] [4.0/4.1/4.2 regression] Trouble with templated type conversion operator

[mmitchel at gcc dot gnu dot org]

--- Comment #1 from mmitchel at gcc dot gnu dot org  2006-08-02 20:34 
---
Subject: Bug 28557

Author: mmitchel
Date: Wed Aug  2 20:33:48 2006
New Revision: 115885

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115885
Log:
PR c++/28557
* pt.c (tsubst_baselink): Substitute into BASELINK_OPTYPE.
PR c++/28557
* g++.dg/template/conv9.C: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/conv9.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557

[Bug c++/28557] [4.0/4.1/4.2 regression] Trouble with templated type conversion operator

[mmitchel at gcc dot gnu dot org]

--- Comment #2 from mmitchel at gcc dot gnu dot org  2006-08-02 20:35 
---
Subject: Bug 28557

Author: mmitchel
Date: Wed Aug  2 20:35:41 2006
New Revision: 115886

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115886
Log:
PR c++/28557
* pt.c (tsubst_baselink): Substitute into BASELINK_OPTYPE.
PR c++/28557
* g++.dg/template/conv9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/conv9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557

[Bug c++/28557] [4.0 regression] Trouble with templated type conversion operator

[mmitchel at gcc dot gnu dot org]

--- Comment #3 from mmitchel at gcc dot gnu dot org  2006-08-02 20:37 
---
Fixed in 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2 regression]|[4.0 regression] Trouble
   |Trouble with templated type |with templated type
   |conversion operator |conversion operator


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557

[Bug c++/28479] [4.2 regression] cc1plus just sits there eating CPU and RAM for a simple program

[mmitchel at gcc dot gnu dot org]

--- Comment #6 from mmitchel at gcc dot gnu dot org  2006-08-02 20:39 
---
Richard --

Please revert your patch.  A missed-optimization problem is less severe than
this failure mode.  Then, let's work out what's going on and what other options
are available.

-- Mark


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28479

[Bug c++/27084] Does not propagate memory load base through useless type conversion

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2006-08-02 20:49 
---
Subject: Bug 27084

Author: rguenth
Date: Wed Aug  2 20:48:59 2006
New Revision: 115887

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115887
Log:
2006-08-02  Richard Guenther  <[EMAIL PROTECTED]>

  PR c++/28479
  Revert
  2006-07-05  Richard Guenther  <[EMAIL PROTECTED]>
  Andrew Pinski  <[EMAIL PROTECTED]>

  PR c++/27084
  * cp-objcp-common.c (cxx_types_compatible_p): Ignore
  top level qualifiers for pointer type comparisons.

  * g++.dg/tree-ssa/copyprop-1.C: XFAIL.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/copyprop-1.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084

[Bug c++/28479] [4.2 regression] cc1plus just sits there eating CPU and RAM for a simple program

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2006-08-02 20:49 ---
Subject: Bug 28479

Author: rguenth
Date: Wed Aug  2 20:48:59 2006
New Revision: 115887

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115887
Log:
2006-08-02  Richard Guenther  <[EMAIL PROTECTED]>

  PR c++/28479
  Revert
  2006-07-05  Richard Guenther  <[EMAIL PROTECTED]>
  Andrew Pinski  <[EMAIL PROTECTED]>

  PR c++/27084
  * cp-objcp-common.c (cxx_types_compatible_p): Ignore
  top level qualifiers for pointer type comparisons.

  * g++.dg/tree-ssa/copyprop-1.C: XFAIL.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-objcp-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/copyprop-1.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28479

[Bug c++/28479] [4.2 regression] cc1plus just sits there eating CPU and RAM for a simple program

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2006-08-02 20:49 ---
Done.

I have XFAILed the testcase instead of removing it again.  I'll re-open the
missed optimization PR.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28479

[Bug c++/27084] Does not propagate memory load base through useless type conversion

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2006-08-02 20:50 
---
Patch was reverted.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2006-08-02 20:52 ---
;; Insn is not within a basic block
(code_label 48 47 49 11 "" [3 uses])

;; Insn is not within a basic block
(jump_insn 49 48 50 (addr_diff_vec:DI (label_ref:DI 48)
 [
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
]
(const_int 0 [0x0])
(const_int 0 [0x0])) -1 (nil)
(nil))


So we lose a jump table.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug c++/28347] [4.1/4.2 regression] ICE on typedef with initialization

[lmillward at gcc dot gnu dot org]

-- 

lmillward at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |lmillward at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-02 20:59:57
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28347

[Bug c++/28347] [4.1/4.2 regression] ICE on typedef with initialization

[patchapp at dberlin dot org]

--- Comment #1 from patchapp at dberlin dot org  2006-08-02 21:00 ---
Subject: Bug number PR c++/28347

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-08/msg00046.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28347

[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2006-08-02 21:10 ---
Happens when we are in find_if_case_1, where we call:

  delete_basic_block (then_bb);

The basic block we try to remove is this one:

;; basic block 5, loop depth 1, count 0
;; prev block 9, next block 6
;; pred:
;; succ:   6 [100.0%]
;; Registers live at start:  12 [r12] 32 [r34] 33 [r35] 34 [r36] 35 [r37] 36
[r38] 37 [r39] 38 [r40] 112 [r32] 113 [r33] 272 [p16] 273 [p17]
(note 129 214 47 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 47 129 48 5 (parallel [
(set (pc)
(reg:DI 326 b6))
(use (label_ref 48))
]) 331 {*tablejump_internal} (nil)
(expr_list:REG_DEAD (reg:DI 326 b6)
(nil)))
;; Registers live at end:  12 [r12] 32 [r34] 33 [r35] 34 [r36] 35 [r37] 36
[r38] 37 [r39] 38 [r40] 112 [r32] 113 [r33] 272 [p16] 273 [p17]
$72 = void


But the jump table follows right after this block:
;; Start of basic block 5, registers live: 12 [r12] 32 [r34] 33 [r35] 34 [r36]
35 [r37] 36 [r38] 37 [r39] 38 [r40] 112 [r32] 113 [r33] 272 [p16] 273 [p17]
(note 129 214 47 5 [bb 5] NOTE_INSN_BASIC_BLOCK)

(jump_insn 47 129 48 5 (parallel [
(set (pc)
(reg:DI 326 b6))
(use (label_ref 48))
]) 331 {*tablejump_internal} (nil)
(expr_list:REG_DEAD (reg:DI 326 b6)
(nil)))
;; End of basic block 5, registers live:
 12 [r12] 32 [r34] 33 [r35] 34 [r36] 35 [r37] 36 [r38] 37 [r39] 38 [r40] 112
[r32] 113 [r33] 272 [p16] 273 [p17]

;; Insn is not within a basic block
(code_label 48 47 49 11 "" [3 uses])

;; Insn is not within a basic block
(jump_insn 49 48 50 (addr_diff_vec:DI (label_ref:DI 48)
 [
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
(label_ref:DI 103)
]
(const_int 0 [0x0])
(const_int 0 [0x0])) -1 (nil)
(nil))

(barrier 50 49 103)


And rtl_delete_block (the cfgrtl hook for delete_basic_block) says:

  /* Include any jump table following the basic block.  */
  end = BB_END (b);
  if (tablejump_p (end, NULL, &tmp))
end = tmp;

So there we lose.

Part of the problem is (should I say now "as always"?) missing REG_LABEL notes:

(insn 185 35 186 3 (set (reg/f:DI 14 r14 [386])
(plus:DI (high:DI (label_ref:DI 48))
(reg:DI 1 r1))) 76 {*load_symptr_high} (nil)
(nil))

But even with a REG_LABEL note, this label is going to disappear AFAICT because 
can_delete_label_p will return true for it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574

[Bug libgcj/28579] New: [ecj] classpath build must use gcj

[tromey at gcc dot gnu dot org]

On the gcj-eclipse branch the classpath java->.class build should
use the gcj driver.  Currently it does not.


-- 
   Summary: [ecj] classpath build must use gcj
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28579

[Bug target/27566] [4.1/4.2 Regression] ICEs in final_scan_insn and reload_cse_simplify_operands for vectors with SPE

[dje at gcc dot gnu dot org]

--- Comment #5 from dje at gcc dot gnu dot org  2006-08-03 01:19 ---
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Do not reload a
SPE symbol_ref into a lo_sum address.

Index: rs6000.c
===
*** rs6000.c(revision 115281)
--- rs6000.c(working copy)
*** rs6000_legitimize_reload_address (rtx x,
*** 3421,3426 
--- 3421,3427 

if (GET_CODE (x) == SYMBOL_REF
&& !ALTIVEC_VECTOR_MODE (mode)
+   && !SPE_VECTOR_MODE (mode)
  #if TARGET_MACHO
&& DEFAULT_ABI == ABI_DARWIN
&& (flag_pic || MACHO_DYNAMIC_NO_PIC_P)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27566

[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2006-08-03 02:30 
---
Subject: Bug 28274

Author: reichelt
Date: Thu Aug  3 02:30:49 2006
New Revision: 115893

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115893
Log:
PR c++/28274
* decl.c (duplicate_decls): Call check_default_args here.
(start_preparsed_function): Do not call check_default_args.
* name-lookup.c (pushdecl_maybe_friend): Only call
check_default_args if duplicate_decls got bypassed.

* g++.dg/other/default5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/default5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274

[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2006-08-03 02:34 
---
Subject: Bug 28274

Author: reichelt
Date: Thu Aug  3 02:34:14 2006
New Revision: 115894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115894
Log:
PR c++/28274
* decl.c (duplicate_decls): Call check_default_args here.
(start_preparsed_function): Do not call check_default_args.
* name-lookup.c (pushdecl_maybe_friend): Only call
check_default_args if duplicate_decls got bypassed.

* g++.dg/other/default5.C: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/default5.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274

[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2006-08-03 02:41 
---
Subject: Bug 28274

Author: reichelt
Date: Thu Aug  3 02:41:33 2006
New Revision: 115895

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115895
Log:
PR c++/28274
* decl.c (duplicate_decls): Call check_default_args here.
(start_preparsed_function): Do not call check_default_args.
* name-lookup.c (pushdecl_maybe_friend): Only call
check_default_args if duplicate_decls got bypassed.

* g++.dg/other/default5.C: New test.

Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/default5.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/cp/name-lookup.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274

[Bug c++/27508] [4.0/4.1/4.2 regression] ICE on invalid destructor name

[reichelt at gcc dot gnu dot org]

--- Comment #8 from reichelt at gcc dot gnu dot org  2006-08-03 02:49 
---
Subject: Bug 27508

Author: reichelt
Date: Thu Aug  3 02:49:07 2006
New Revision: 115896

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115896
Log:
PR c++/27508
* parser.c (cp_parser_unqualified_id): Check for invalid scopes
when parsing destructor names.

* g++.dg/parse/dtor9.C: New test.
* g++.dg/parse/dtor10.C: New test.
* g++.dg/other/error7.C: Adjust error-marker.

Added:
trunk/gcc/testsuite/g++.dg/parse/dtor10.C
trunk/gcc/testsuite/g++.dg/parse/dtor9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/error7.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27508

[Bug c++/27508] [4.0/4.1/4.2 regression] ICE on invalid destructor name

[reichelt at gcc dot gnu dot org]

--- Comment #9 from reichelt at gcc dot gnu dot org  2006-08-03 02:54 
---
Subject: Bug 27508

Author: reichelt
Date: Thu Aug  3 02:54:07 2006
New Revision: 115897

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115897
Log:
PR c++/27508
* parser.c (cp_parser_unqualified_id): Check for invalid scopes
when parsing destructor names.

* g++.dg/parse/dtor9.C: New test.
* g++.dg/parse/dtor10.C: New test.
* g++.dg/other/error7.C: Adjust error-marker.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor10.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor9.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/error7.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27508

[Bug c++/27508] [4.0/4.1/4.2 regression] ICE on invalid destructor name

[reichelt at gcc dot gnu dot org]

--- Comment #10 from reichelt at gcc dot gnu dot org  2006-08-03 03:02 
---
Subject: Bug 27508

Author: reichelt
Date: Thu Aug  3 03:02:16 2006
New Revision: 115898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115898
Log:
PR c++/27508
* parser.c (cp_parser_unqualified_id): Check for invalid scopes
when parsing destructor names.

* g++.dg/parse/dtor9.C: New test.
* g++.dg/parse/dtor10.C: New test.
* g++.dg/other/error7.C: Adjust error-marker.

Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor10.C
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor9.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/error7.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27508

[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work

[reichelt at gcc dot gnu dot org]

--- Comment #7 from reichelt at gcc dot gnu dot org  2006-08-03 03:10 
---
Fixed on mainline, 4.1 branch, and 4.0 branch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|3.4.6 4.0.3 4.1.0 4.1.1 |3.4.6 4.0.3 4.1.0 4.1.1
   |4.2.0   |
  Known to work|3.3.6 3.4.0 3.4.5 4.0.2 |3.3.6 3.4.0 3.4.5 4.0.2
   ||4.0.4 4.1.2 4.2.0
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274

[Bug c++/27508] [4.0/4.1/4.2 regression] ICE on invalid destructor name

[reichelt at gcc dot gnu dot org]

--- Comment #11 from reichelt at gcc dot gnu dot org  2006-08-03 03:11 
---
Fixed on mainline, 4.1 branch, and 4.0 branch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27508

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2006-08-03 04:49 ---
Some progress has been.  Craig Powers suggested that the problem was
with PRESENT but perhaps a conversion function.  If I change HJ's code
to use the same type and kind type parameter, then everything works 
fine.  In gdb, I've found

(gdb) print *isym
$28 = {name = 0x8869b61 "__convert_i4_r4", 
  lib_name = 0x8869b61 "__convert_i4_r4", formal = 0x0, ts = {type = BT_REAL, 
   kind = 4, derived = 0x0, cl = 0x0}, elemental = 1, pure = 0, generic = 0, 
  specific = 0, actual_ok = 0, standard = 1, noreturn = 0, simplify = {

Note, the __convert function is marked as elemental.  I don't know why
this is so. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #6 from sgk at troutmask dot apl dot washington dot edu  
2006-08-03 05:09 ---
Subject: Re:  [4.2 Regression]: Optional argument failed

On Thu, Aug 03, 2006 at 04:49:33AM -, kargl at gcc dot gnu dot org wrote:
> 
> (gdb) print *isym
> $28 = {name = 0x8869b61 "__convert_i4_r4", 
>   lib_name = 0x8869b61 "__convert_i4_r4", formal = 0x0, ts = {type = BT_REAL, 
>kind = 4, derived = 0x0, cl = 0x0}, elemental = 1, pure = 0, generic = 0, 
>   specific = 0, actual_ok = 0, standard = 1, noreturn = 0, simplify = {
> 
> Note, the __convert function is marked as elemental.  I don't know why
> this is so. 
> 

OK, I understand the problem.  Even though the __convert functions
are not elemental fortran procedures, gfortran marks these as 
elemental to use the machinary to deal with both scalar and array
arguments.  The upshot, AFAICT, is that we need to special case
the __convert functions in resolve.c.

The following patch allows a mangled version of HJ's testcase to
compile.


Index: resolve.c
===
--- resolve.c   (revision 115827)
+++ resolve.c   (working copy)
@@ -1012,7 +1012,8 @@
&& arg->expr->symtree->n.sym->attr.optional
&& formal_optional
&& arg->expr->rank
-   && (set_by_optional || arg->expr->rank != rank)) 
+   && (set_by_optional || arg->expr->rank != rank)
+   && !(isym && isym->generic_id == GFC_ISYM_CONVERSION))
{
  gfc_error ("'%s' at %L is an array and OPTIONAL; it cannot "
 "therefore be an actual argument of an ELEMENTAL " 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548

[Bug c/28581] New: Illegal loading the address of a label with -O2

[inaoka dot kazuhiro at renesas dot com]

The label is placed on illegal address when only loading the address of a label
without jump into. (compile with -O2 option)


test_func()
{
func(&&here);
func1();
here:
func2();
}


-- 
   Summary: Illegal loading the address of a label with -O2
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: inaoka dot kazuhiro at renesas dot com
GCC target triplet: i386


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug fortran/25828] [f2003] ACCESS='STREAM' io support

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2006-08-03 06:05 ---
Subject: Bug number PR25828

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-08/msg00056.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25828

[Bug c/28581] Illegal loading the address of a label with -O2

[inaoka dot kazuhiro at renesas dot com]

--- Comment #1 from inaoka dot kazuhiro at renesas dot com  2006-08-03 
06:07 ---
Created an attachment (id=12001)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12001&action=view)
testcase

gcc -S -O2 label_address.c

label_address.s

.file   "label_address.c"
.text
.p2align 4,,15
.globl test_func
.type   test_func, @function
test_func:
.L2: <== NG
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
movl$.L2, (%esp)
callfunc
callfunc1
callfunc2
leave
.p2align 4,,4
ret
.size   test_func, .-test_func
.ident  "GCC: (GNU) 4.1.2 20060708 (prerelease) (Debian 4.1.1-8)"
.section.note.GNU-stack,"",@progbits


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[martin at mpa-garching dot mpg dot de]

--- Comment #7 from martin at mpa-garching dot mpg dot de  2006-08-03 06:22 
---
(In reply to comment #3)
> Andrew, I think it is a bug.  The language in section 12.4.1.5 is somewhat
> convoluted and the description of PRESENT() suggest that PRESENT is special.
> 
> From 12.4.1.5:
> 
>An optional dummy argument that is not present is subject to the
>following restrictions:
> 
>(3)  It shall not be supplied as an actual argument corresponding to
> a nonoptional dummy argument other than as the argument of the
> PRESENT intrinsic function.
> 
>(5)  If it is an array, it shall not be supplied as an actual argument
> to an elemental procedure unless an array of the same rank is
> supplied as an actual argument corresponding to a nonoptional dummy
> argument of that elemental procedure.

My understanding of this is that the error message given by gfortran is wrong,
even if an elemental procedure is called with the optional array. The clauses
only refer to an optional argument _that is not present_, but in the given
testcases the calls only happen if it is present.
I think that 12.1.4.5. can only describe a runtime error condition, and cannot
generally be detected at compile time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #8 from sgk at troutmask dot apl dot washington dot edu  
2006-08-03 06:26 ---
Subject: Re:  [4.2 Regression]: Optional argument failed

On Thu, Aug 03, 2006 at 06:22:10AM -, martin at mpa-garching dot mpg dot de
wrote:
> 
> My understanding of this is that the error message given by gfortran is wrong,
> even if an elemental procedure is called with the optional array. The clauses
> only refer to an optional argument _that is not present_, but in the given
> testcases the calls only happen if it is present.
> I think that 12.1.4.5. can only describe a runtime error condition, and cannot
> generally be detected at compile time.
> 

I just submitted a patch that appears to fix the problem.
The problem is __convert_* (ie internal gfortran functions)
are caught by the error checking.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

[martin at mpa-garching dot mpg dot de]

--- Comment #9 from martin at mpa-garching dot mpg dot de  2006-08-03 06:40 
---
(In reply to comment #8)
>
> I just submitted a patch that appears to fix the problem.
> The problem is __convert_* (ie internal gfortran functions)
> are caught by the error checking.
> 

Hmm, but my point was that even if gfortran thinks that the __convert_*
routines are elemental (as was mentioned in an earlier comment), it should
still
compile the code without problems, because it is proven that the optional
argument
actually exists when the __convert_* call is made.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28548