[Bug preprocessor/28022] New: Incorrect pedwarn for , expression in #if in c99 mode

[sabre at nondot dot org]

This testcase:

#if 1 , 0
#endif

Should not warn with -std=c99 -pedantic.  It currently does due to an inverted
conditional.  This (cpplib/expr.c:1376):

default: /* case CPP_COMMA: */
  if (CPP_PEDANTIC (pfile) && (!CPP_OPTION (pfile, c99)
   || !pfile->state.skip_eval))
cpp_error (pfile, CPP_DL_PEDWARN,
   "comma operator in operand of #if");

should be:

  if (CPP_PEDANTIC (pfile) && !(CPP_OPTION (pfile, c99)
   || pfile->state.skip_eval))

-Chris


-- 
   Summary: Incorrect pedwarn for , expression in #if in c99 mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org


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

[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2006-06-14 05:28 ---
.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction

[sayle at gcc dot gnu dot org]

--- Comment #11 from sayle at gcc dot gnu dot org  2006-06-14 04:35 ---
Subject: Bug 21210

Author: sayle
Date: Wed Jun 14 04:35:29 2006
New Revision: 114634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114634
Log:

PR c++/21210
* typeck2.c (build_functional_cast): Use cp_convert to construct
non-aggregate initializers instead of the user-level build_c_cast.

* g++.dg/init/complex1.C: New test case.


Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/complex1.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/typeck2.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|3.4.0 4.2.0 |3.4.0 4.2.0 4.1.2
Summary|[4.0/4.1 Regression] Trouble|[4.0 Regression] Trouble
   |with __complex__ types  |with __complex__ types
   |default construction|default construction
   Target Milestone|4.1.2   |4.0.4


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

[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-14 04:19 ---
*** Bug 28020 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


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

[Bug objc++/28020] [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-14 04:19 ---
Actually this has been failing since the testcase was added and Objective-C++
was added.

This is a dup of bug 23716.

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


-- 

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=28020

[Bug c++/27227] [4.0/4.1/4.2 Regression] rejects valid code with some extern "C"

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3

[whaley at cs dot utsa dot edu]

--- Comment #14 from whaley at cs dot utsa dot edu  2006-06-14 02:40 ---
OK, I got access to some older machines, and it appears that Core is the only
architecture that likes gcc 4's code.  More precisely, I have confirmed that
the following architectures run significantly slower using gcc4 than gcc 3:
Pentium-D, P4e, Pentium III, PentiumPRO, Athlon-64 X2, Opteron.

Any help appreciated,
Clint


-- 


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static

[mmitchel at gcc dot gnu dot org]

--- Comment #8 from mmitchel at gcc dot gnu dot org  2006-06-14 02:16 
---
Diego --

Your last comment was cut off.  

However, no, COMPLETE_TYPE_P does not imply that we know the size of the type,
and it can't ever imply that, in C++.  For a type with virtual bases, we don't
know what the size of the object will be; in fact, we don't know wehther the
object will be located in a contiguous block of memory.

So, no front end change will avoid this problem.

-- Mark


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug c++/26559] [4.0/4.1/4.2 Regression] ICE with __builtin_constant_p in template argument

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug libgomp/27254] FAIL: libgomp.fortran/reduction6.f90

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2006-06-14 00:59 ---
Patch here: .


-- 


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

[Bug libfortran/27964] Wrong line ends on windows (XP)

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2006-06-14 00:32 
---
My XP box died.  I can't do much with this now.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug c++/22592] -fvisibility-inlines-hidden broken differently

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2006-06-13 23:28 ---
Either 20218 is a bug or this is.  It seems to me that 20218 is the bug.

If you declare a function to be hidden, you are asserting that it will be
defined in the current DSO.  From the GCC documentation:

"Two declarations of an object with hidden linkage refer to the same object
if they are in the same shared object."

Calling this function directly is a correct optimization, the bug is that you
fail to define it (by defining the key method) in the same DSO.

If this class is imported from a library, it shouldn't have hidden linkage; the
library's namespace should have explicit default linkage.


-- 


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[hhinnant at apple dot com]

--- Comment #9 from hhinnant at apple dot com  2006-06-13 22:02 ---
(In reply to comment #8)

Thanks.  That not only makes sense to me now, but it passes the test. :-)


-- 


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[pinskia at physics dot uc dot edu]

--- Comment #8 from pinskia at physics dot uc dot edu  2006-06-13 21:47 
---
Subject: Re:  lack of guard variables for explicitly instantiated template
static data

> 
> 
> 
> --- Comment #7 from hhinnant at apple dot com  2006-06-13 21:41 ---
> (In reply to comment #6)
> > Subject: Re:  lack of guard variables for explicitly instantiated template
> > static data
> > 
> > > #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)
> > >   \
> > > || DECL_ONE_ONLY 
> > > (decl) \
> > > || DECL_WEAK (decl) \
> > > ||
> > > (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
> > >   || (! DECL_EXPLICIT_INSTANTIATION (decl) \
> > >   && ! DECL_TEMPLATE_SPECIALIZATION (decl)
> > > 
> > > ?
> > 
> > The latter.
> 
> Thanks.  But this doesn't pass the test case on darwin.  I'm not familiar
> enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC.  Could 
> you
> double check the above.  The "!" in front of DECL_EXPLICIT_INSTANTIATION looks
> especially suspicious to me.

You want the opposite of that like:
(TARGET_WEAK_NOT_IN_ARCHIVE_TOC && (DECL_EXPLICIT_INSTANTIATION (decl) ||
DECL_TEMPLATE_SPECIALIZATION (decl)))

I was quoting the case when DECL_WEAK would be set on the decl.
TARGET_WEAK_NOT_IN_ARCHIVE_TOC is only defined to 1 for darwin.  

-- Pinski


-- 


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

Re: [Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[Andrew Pinski]

> 
> 
> 
> --- Comment #7 from hhinnant at apple dot com  2006-06-13 21:41 ---
> (In reply to comment #6)
> > Subject: Re:  lack of guard variables for explicitly instantiated template
> > static data
> > 
> > > #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)
> > >   \
> > > || DECL_ONE_ONLY 
> > > (decl) \
> > > || DECL_WEAK (decl) \
> > > ||
> > > (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
> > >   || (! DECL_EXPLICIT_INSTANTIATION (decl) \
> > >   && ! DECL_TEMPLATE_SPECIALIZATION (decl)
> > > 
> > > ?
> > 
> > The latter.
> 
> Thanks.  But this doesn't pass the test case on darwin.  I'm not familiar
> enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC.  Could 
> you
> double check the above.  The "!" in front of DECL_EXPLICIT_INSTANTIATION looks
> especially suspicious to me.

You want the opposite of that like:
(TARGET_WEAK_NOT_IN_ARCHIVE_TOC && (DECL_EXPLICIT_INSTANTIATION (decl) || 
DECL_TEMPLATE_SPECIALIZATION (decl)))

I was quoting the case when DECL_WEAK would be set on the decl.
TARGET_WEAK_NOT_IN_ARCHIVE_TOC is only defined to 1 for darwin.  

-- Pinski

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[hhinnant at apple dot com]

--- Comment #7 from hhinnant at apple dot com  2006-06-13 21:41 ---
(In reply to comment #6)
> Subject: Re:  lack of guard variables for explicitly instantiated template
> static data
> 
> > #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  
> > \
> > || DECL_ONE_ONLY (decl) 
> > \
> > || DECL_WEAK (decl) \
> > ||
> > (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
> >   || (! DECL_EXPLICIT_INSTANTIATION (decl) \
> >   && ! DECL_TEMPLATE_SPECIALIZATION (decl)
> > 
> > ?
> 
> The latter.

Thanks.  But this doesn't pass the test case on darwin.  I'm not familiar
enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC.  Could you
double check the above.  The "!" in front of DECL_EXPLICIT_INSTANTIATION looks
especially suspicious to me.


-- 


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[pinskia at physics dot uc dot edu]

--- Comment #6 from pinskia at physics dot uc dot edu  2006-06-13 21:24 
---
Subject: Re:  lack of guard variables for explicitly instantiated template
static data

> #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  \
> || DECL_ONE_ONLY (decl) \
> || DECL_WEAK (decl) \
> ||
> (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
>   || (! DECL_EXPLICIT_INSTANTIATION (decl) \
>   && ! DECL_TEMPLATE_SPECIALIZATION (decl)
> 
> ?

The latter.

-- Pinski


-- 


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

Re: [Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[Andrew Pinski]

> #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  \
> || DECL_ONE_ONLY (decl) \
> || DECL_WEAK (decl) \
> ||
> (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
>   || (! DECL_EXPLICIT_INSTANTIATION (decl) \
>   && ! DECL_TEMPLATE_SPECIALIZATION (decl)
> 
> ?

The latter.

-- Pinski

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[hhinnant at apple dot com]

--- Comment #5 from hhinnant at apple dot com  2006-06-13 21:23 ---
(In reply to comment #4)
>For Darwin we do not want explicit instantiations to be
>linkonce.  */
> 
> 
> This is why this testcase fails on darwin.
> We should instead of just adding DECL_EXPLICIT_INSTANTIATION, check
> TARGET_WEAK_NOT_IN_ARCHIVE_TOC.
> 
> (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC
>   || (! DECL_EXPLICIT_INSTANTIATION (decl)
>   && ! DECL_TEMPLATE_SPECIALIZATION (decl)))
> 
> This is a darwin only issue.

I'm having trouble deciding exactly what you mean.  Is this what you mean:

#define NEEDS_GUARD_P(decl) (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
  || (! DECL_EXPLICIT_INSTANTIATION (decl) \
  && ! DECL_TEMPLATE_SPECIALIZATION (decl)))

Or do you mean:

#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  \
|| DECL_ONE_ONLY (decl) \
|| DECL_WEAK (decl) \
||
(!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \
  || (! DECL_EXPLICIT_INSTANTIATION (decl) \
  && ! DECL_TEMPLATE_SPECIALIZATION (decl)

?


-- 


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

[Bug objc++/28020] [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2006-06-13 20:30 ---
Actually, this shows up with 20060530.  It was introduced some time between
20060218 and 20051124.  Unfortunately I don't have any compiler version
inbetween these dates around so I cannot narrow it down further.


-- 


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

[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2006-06-13 20:26 ---
The solution is "don't do -fschedule-insns on x86".

Unless you first add heuristics in the scheduler to keep a better eye on
register pressure, and fix the many known bugs in scheduling for x86.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug objc++/28020] New: [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067

[tbm at cyrius dot com]

A number of obj-c++ test cases fail with an ICE now (this didn't happen with
20060530):

FAIL: obj-c++.dg/comp-types-10.mm (internal compiler error)
...
FAIL: obj-c++.dg/try-catch-9.mm (internal compiler error)

(sid)955:[EMAIL PROTECTED]: ..atch/gcc-snapshot-20060613] ./build/gcc/g++ -c -O2
src/gcc/testsuite/obj-c++.dg/comp-types-10.mm
src/gcc/testsuite/obj-c++.dg/comp-types-10.mm: In function '(static
initializers for src/gcc/testsuite/obj-c++.dg/comp-types-10.mm)':
src/gcc/testsuite/obj-c++.dg/comp-types-10.mm:19: internal compiler error: tree
check: expected class 'type', have 'exceptional' (error_mark) in
setup_one_parameter, at tree-inline.c:1067
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: [4.2 regression] expected class 'type', have
'exceptional' (error_mark) in setup_one_parameter, at
tree-inline.c:1067
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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

[Bug c++/28015] Nonspecific error messages

[philippe at fornux dot com]

--- Comment #2 from philippe at fornux dot com  2006-06-13 20:17 ---
I was compiling a big project and I ended up with this error message.  I just
tried to compile the same file by preprocessing it first (-E) and I don't have
the error anymore.

Actually I think some dependent file got included twice.  That will explain the
error messages refering to the same locations; therefore it not a compiler
problem but some improper "#ifndef" preprocessor handling in the header files
on my Redhat system.

I will investigate and let you know if I come up with something.


Bests,
Phil


-- 


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

[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, ra
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 19:48:14
   date||


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

[Bug fortran/28004] Warn if intent(out) dummy variable is not set

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2006-06-13 19:45 ---
Tobias,

I presented a patch for this problem and for detected unassigned r-values that
was rejected.  I don't know what to say; I think that it's a bug, in principle,
but the standard does not require it.

Paul


-- 


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

[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-13 19:45 ---
Yes, yes we know, this is the nth bug about this issue.

This looks like PR 9085.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||9085
  GCC build triplet|i386-apple-darwin8.7.2  |
   GCC host triplet|i386-apple-darwin8.7.2  |
 GCC target triplet|i386-apple-darwin8.7.2  |i?86-*
Summary|ICE: x86 scheduler upsets   |register allocator does not
   |local reg alloc |reschedule for x86 imull


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

[Bug rtl-optimization/28019] ICE: x86 scheduler upsets local reg alloc

[stuart at apple dot com]

--- Comment #1 from stuart at apple dot com  2006-06-13 19:44 ---
Created an attachment (id=11663)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11663&action=view)
Testcase

Attaching (same) testcase.


-- 


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

[Bug rtl-optimization/28019] New: ICE: x86 scheduler upsets local reg alloc

[stuart at apple dot com]

Scheduler hoists an x86 IMUL (clobbers %eax) ahead of the first reference to a
parameter passed in %eax.

% /Volumes/sandbox/stuart/gcc.fsf.pure.debug.obj/gcc/cc1 reduce.c  -quiet
-mtune=generic -O2 -fschedule-insns
reduce.c: In function '_perfInitPerfTable':
reduce.c:43: error: unable to find a register to spill in class 'AREG'
reduce.c:43: error: this is the insn:
(insn:HI 21 83 9 2 (parallel [
(set (reg/v:SI 5 di [orig:66 maxNvClk ] [66])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (mem/s:SI
(plus:SI (reg/v/f:SI 1 dx [orig:71 thisPerf ] [71])
(const_int 80 [0x50])) [7
.MaxNvclkAllowed+0 S4 A32]))
(zero_extend:DI (reg:SI 3 bx [78])))
(const_int 32 [0x20]
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 189 {*umulsi3_highpart_insn} (nil)
(expr_list:REG_DEAD (reg/v/f:SI 1 dx [orig:71 thisPerf ] [71])
(expr_list:REG_DEAD (reg:SI 3 bx [78])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (scratch:SI)
(nil))
reduce.c:43: internal compiler error: in spill_failure, at reload1.c:1911
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Here is the testcase:

typedef unsigned long U32;
typedef U32 U032;
typedef struct RMTIMEOUT {
}
NODE, *PNODE;
typedef struct OBJP OBJP, *POBJP;
typedef struct OBJPERF *POBJPERF;
typedef struct _def_ext_y_gen_params {
  U032 G;
}
YFREQ, *PYFREQ;
typedef void PerfInitPerfTables (POBJP, POBJPERF);
typedef struct _perf_level {
  YFREQ Y;
}
PERF_LEVEL, *PPERF_LEVEL;
typedef struct _perf_table {
  PERF_LEVEL Levels[10];
}
PERF_TABLE, *PPERF_TABLE;
struct OBJPERF {
  PERF_TABLE lowPower;
  PERF_TABLE fullPower;
  U032 MaxyAllowed;
  PerfInitPerfTables *perfInitPerfTables;
};
static PerfInitPerfTables perfInitPerfTables;
void constructObjPerf(POBJPERF thisPerf, U032 thisPublicHalID) {
  thisPerf->perfInitPerfTables = perfInitPerfTables;
}
static U032 _perfInitPerfTable(POBJP pP, POBJPERF thisPerf, PPERF_TABLE
pPerfTable, U032 startEntry, U032 flagMask, U032 flagVal) {
  U032 i, matchingLevels = 0;
  U032 maxY, maxMY;
  maxY = thisPerf->MaxyAllowed / (10 * 1000);
  for (i = 0;
   i < 10;
   i++) {
if (DevinitGetPerfLevelEntry(pP, startEntry + i, &pPerfTable->Levels[i]) !=
0x) break;
if (maxY) {
  if (pPerfTable->Levels[i].Y.G > maxY)
pPerfTable->Levels[i].Y.G = maxY;
}
  }
}
static void perfInitPerfTables(POBJP pP, POBJPERF thisPerf) {
  U032 i, data, levelsFound;
  levelsFound = _perfInitPerfTable(pP, thisPerf, &thisPerf->lowPower, 0,
(1<<(0)), 0);
  levelsFound = _perfInitPerfTable(pP, thisPerf, &thisPerf->fullPower,
levelsFound, (1<<(0)), 1);
}


-- 
   Summary: ICE: x86 scheduler upsets local reg alloc
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
 GCC build triplet: i386-apple-darwin8.7.2
  GCC host triplet: i386-apple-darwin8.7.2
GCC target triplet: i386-apple-darwin8.7.2


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-06-13 19:37 ---

   For Darwin we do not want explicit instantiations to be
   linkonce.  */


This is why this testcase fails on darwin.
We should instead of just adding DECL_EXPLICIT_INSTANTIATION, check
TARGET_WEAK_NOT_IN_ARCHIVE_TOC.

(!TARGET_WEAK_NOT_IN_ARCHIVE_TOC
  || (! DECL_EXPLICIT_INSTANTIATION (decl)
  && ! DECL_TEMPLATE_SPECIALIZATION (decl)))

This is a darwin only issue.


-- 

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-06-13 19:37:25
   date||


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

[Bug fortran/28005] gfortran: mathmul produces wrong result

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2006-06-13 19:33 ---
Tobias,

Thanks for the recent batch of reports; this one, in particular, which is not
at all good!

I am heavily committed with a few other bugs; I'll see if FX or Thomas have the
time.  Otherwise I'll drop everything for this one.

Paul


-- 

pault 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-06-13 19:33:28
   date||


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

[Bug c++/28018] [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-06-13 19:28 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103#c56


-- 


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

[Bug c++/28018] [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275

[tbm at cyrius dot com]

--- Comment #2 from tbm at cyrius dot com  2006-06-13 19:25 ---
(In reply to comment #1)
> Confirmed, I reported this in the bug report which changed this testcase.

Which PR is that?  I searched and couldn't find anything, and neither did 'svn
log' show a recent change to the test case.


-- 


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

[Bug c++/28018] [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-06-13 19:19 ---
Confirmed, I reported this in the bug report which changed this testcase.


-- 

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
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 19:19:49
   date||
   Target Milestone|--- |4.2.0


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-06-13 19:18 ---
   || DECL_ONE_ONLY (decl) || DECL_WEAK (decl) \

Actually those looks should include what is defined for Darwin.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|darwin ppc  |
 GCC target triplet||*-darwin


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-13 19:15 ---
(In reply to comment #1)
> This works on x86-linux-gnu on the mainline.

Oh and in 3.3.3.


-- 


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

[Bug fortran/27980] Wrong allocation for zero-sized function result

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2006-06-13 19:15 ---
Subject: Bug number PR 27980

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-06/msg00708.html


-- 


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

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-06-13 19:14 ---
This works on x86-linux-gnu on the mainline.


-- 


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

[Bug c++/28018] New: [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275

[tbm at cyrius dot com]

I get the following error in the test suite:

FAIL: g++.dg/ext/complit1.C (internal compiler error)
FAIL: g++.dg/ext/complit1.C (test for excess errors)

This is fairly new.  20060530 worked.  The error is:

/home/tbm/x.c: In constructor 'Foo::Foo(int, int)':
/home/tbm/x.c:14: error: ISO C++ forbids assignment of arrays
/home/tbm/x.c: In constructor 'Foo::Foo(int, int)':
/home/tbm/x.c:14: internal compiler error: in emit_move_insn, at expr.c:3275
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

How odd.  20060530 seems to fail as well but I cannot remember seeing the test
failure when I built 20060530.


-- 
   Summary: [4.2 regression] g++.dg/ext/complit1.C fails: in
emit_move_insn, at expr.c:3275
   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 cyrius dot com
 GCC build triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/28017] New: lack of guard variables for explicitly instantiated template static data

[hhinnant at apple dot com]

I was passed a test case consisting of two translation units:

// test.h

#include 

class A
{
public:

A()
{
mString = new char[2];
std::cout << "new: mString has value " << (void*) mString << std::endl;
}

~A()
{
std::cout << "delete: mString has value " << (void*) mString <<
std::endl;
delete [] mString;
}

void f()
{
}

private:

char* mString;
};


template
class Test
{
public:

Test()
{
sA.f();
}

private:
static A sA;
};

template
A Test::sA;

// test.cpp

#include "test.h"

template class Test;

int foo()
{
return 0;
}

// main.cpp

#include "test.h"

int foo();

int main()
{
Test theTest;
foo();
return 0;
}

When compiled with something like:

g++ -o test test.cpp main.cpp

the test shows evidence of the static Test::sA being
constructed/destructed twice:

new: mString has value 0x5002d0
new: mString has value 0x500300
delete: mString has value 0x500300
delete: mString has value 0x500300

The desired output should be more like:

new: mString has value 0x5002d0
delete: mString has value 0x5002d0

Further inspection reveals that the guard variable for this static is not being
generated in test.cpp because of the explicit instantiation there (tested on
Apple's gcc 4.0.1).

I am wondering if an appropriate fix might be in:

gcc/cp/decl2.c, in function start_static_initialization_or_destruction

Change the if statement that looks like:

  if (TREE_PUBLIC (decl) && (DECL_COMMON (decl)
 || DECL_ONE_ONLY (decl)
 || DECL_WEAK (decl)))
{
  tree guard_cond;

to:

  if (TREE_PUBLIC (decl) && (DECL_COMMON (decl)
 || DECL_ONE_ONLY (decl)
 || DECL_WEAK (decl)
 || DECL_EXPLICIT_INSTANTIATION (decl)))
{
  tree guard_cond;

I looked in the mainline decl2.c and found the same logic in the macro
NEEDS_GUARD_P.  Here I'm suggesting changing:

#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  \
|| DECL_ONE_ONLY (decl) \
|| DECL_WEAK (decl)))

to:

#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl)  \
|| DECL_ONE_ONLY (decl) \
|| DECL_WEAK (decl) \
||
DECL_EXPLICIT_INSTANTIATION (decl)))


-- 
   Summary: lack of guard variables for explicitly instantiated
template static data
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
  GCC host triplet: darwin ppc


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

[Bug fortran/22210] gfc_conv_array_initializer weirdness

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-06-13 18:55 ---
(In reply to comment #7)
> Where did this one go to? Can we close it?

It is still funny looking code. I might take a look this weekend or on June 27
when I am traveling to the GCC summit.


-- 


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

[Bug c++/28016] [4.2 Regression] emitting template constant

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-06-13 18:52 ---
It is only static const variables which are miss handled.


-- 


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

[Bug c++/28016] [4.2 Regression] GCC 4.2 emitting static template constants as global symbols?

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-13 18:49 ---
Confirmed.
(In reply to comment #1)

> template
> const bool scalar_divides_assign::computed = true;

For this case above, nothing should be emitted.


-- 

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
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||link-failure, wrong-code
  Known to work||4.1.0
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 18:49:08
   date||
Summary|GCC 4.2 emitting static |[4.2 Regression] GCC 4.2
   |template constants as global|emitting static template
   |symbols?|constants as global symbols?
   Target Milestone|--- |4.2.0


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

[Bug c++/28016] GCC 4.2 emitting static template constants as global symbols?

[bredelin at ucla dot edu]

--- Comment #1 from bredelin at ucla dot edu  2006-06-13 18:30 ---
Here is some source code that exhibits the problem:
 begin a.C -
template
struct scalar_divides_assign {
  static const bool computed ;
};

template
const bool scalar_divides_assign::computed = true;
- end --

To see the problem do 
$ g++-4.2 -c a.C
$ nm a.o | grep computed
 D _ZN21scalar_divides_assignIT_T0_E8computedE

This symbol shouldn't be emitted, or at least not in this way.


-- 


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

[Bug c++/28016] New: GCC 4.2 emitting static template constants as global symbols?

[bredelin at ucla dot edu]

I have some software that uses the BOOST matrix library UBLAS (1.33.1).  This
software compiles and links with GCC 4.1.1 (Debian Linux system - GNU ld) but
gives linking errors with GCC 4.2:

substitution.o:(.data+0x0): multiple definition of
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
alignment.o:(.data+0x0): first defined here

Here is from the definition of the static const member of a template class in
boost/numeric/ublas/functional.hpp:

template
struct scalar_divides_assign:
public scalar_binary_assign_functor {
  ... stuff ...
};

template
const bool scalar_divides_assign::computed = true;

GCC 4.2, but not 4.1 actually emits this constant in the global data section. 
With 4.2:

$ nm alignment.o | grep divides
0180 t
_GLOBAL__I__ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
 D
_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE

With 4.1 neither of these two symbols (or is it one symbol, mentioned twice?)
is emitted.


-- 
   Summary: GCC 4.2 emitting static template constants as global
symbols?
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bredelin at ucla dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/21210] [4.0/4.1 Regression] Trouble with __complex__ types default construction

[sayle at gcc dot gnu dot org]

--- Comment #10 from sayle at gcc dot gnu dot org  2006-06-13 18:06 ---
Subject: Bug 21210

Author: sayle
Date: Tue Jun 13 18:06:00 2006
New Revision: 114618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114618
Log:

PR c++/21210
* typeck2.c (build_functional_cast): Use cp_convert to construct
non-aggregate initializers instead of the user-level build_c_cast.

* g++.dg/init/complex1.C: New test case.


Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/complex1.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/typeck2.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/28014] space-optimized divide used inconsistently

[amylaar at gcc dot gnu dot org]

--- Comment #3 from amylaar at gcc dot gnu dot org  2006-06-13 18:05 ---
Fixed.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/28014] space-optimized divide used inconsistently

[amylaar at gcc dot gnu dot org]

--- Comment #2 from amylaar at gcc dot gnu dot org  2006-06-13 17:45 ---
Subject: Bug 28014

Author: amylaar
Date: Tue Jun 13 17:44:56 2006
New Revision: 114616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114616
Log:
PR target/28014:

gcc:
* config/sh/t-sh (LIB1ASMFUNCS): Add _udiv_qrnnd16
* config/sh/sh.c (print_operand): Add !SHMEDIA functionality to 'M'.
* config/sh/lib1funcs.h (SL, SL1): Define.
* config/sh/lib1funcs.asm (__udiv_qrnnd16): New hidden function.
* longlong.h (__sh__): Define umul_ppmm, udiv_qrnnd and sub_ddmmss.
* config/sh/t-sh ($(T)unwind-dw2-Os-4-200.o): New rule.
(OBJS_Os_4_200): New variable.
($(T)libgcc-Os-4-200.a): Use it.
* sh.md (udivsi3): For TARGET_DIVIDE_CALL_TABLE, avoid function call
when dividing 1 and/or by 0.

gcc/testsuite:
* g++.dg/eh/div.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/eh/div.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/lib1funcs.asm
trunk/gcc/config/sh/lib1funcs.h
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/config/sh/t-sh
trunk/gcc/longlong.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/27998] character arrays: warn if erray constructor values have different lengths

[pault at gcc dot gnu dot org]

-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 17:25:48
   date||


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

[Bug fortran/27996] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)

[pault at gcc dot gnu dot org]

-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 17:24:13
   date||


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

[Bug tree-optimization/28003] [4.2 Regression] optimizer bug

[dberlin at gcc dot gnu dot org]

--- Comment #6 from dberlin at gcc dot gnu dot org  2006-06-13 17:15 ---
So it should have been marked global, and should alias the global var, but
apparently the global var doesn't pop into it's alias set


-- 


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

[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros

[sje at cup dot hp dot com]

--- Comment #6 from sje at cup dot hp dot com  2006-06-13 16:54 ---
The new _Pragma1.C and _Pragma6.c tests are failing on ia64-hp-hpux11.23
because that platform does not define HANDLE_PRAGMA_PACK_PUSH_POP.  Presumably
there are other platforms that also do not define this and will also fail these
tests.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2006-06-13 
16:44 ---
Geoff,
Does any other os, that uses gcc, version libgcc_s in the manner that Apple
does?
Simply not setting MACOSX_DEPLOYMENT_TARGET during the build of gcc 4.2 doesn't
make the problem go away. The resulting libstdc++.6.dylib and libgcc_s.1.dylib
libraries
have _Unwind_GetIPInfo symbols whereas libgcc_s.10.4.dylib and
libgcc_s.10.5.dylib
don't. This precludes safely using MACOSX_DEPLOYMENT_TARGET  at all with gcc
4.2.
I know you said you won't assign this to yourself until it happens to you.
However it
isn't happening to you because you don't want it to. Apple really needs to deal
with the
breakage caused by their decision to version libgcc_s.
Jack


(In reply to comment #2)
> Clearly, we cannot add any symbols to the 10.4 libgcc_s.  10.4 has already
> shipped, and we do not have a time travel device.
> 
> By default, gcc compiles for the earliest OS version it knows about.  For C++,
> that means 10.3.9/10.4.  This is best for users.
> 
> Thus, by default, you cannot use any new symbols in libgcc_s.
> 
> The problem occurs because libstdc++ wants to use the new symbol by default.  
> I
> can think of a bunch of solutions to the problem:
> 1. Have libstdc++ use autoconf to detect the presence of the new symbol and 
> use
> it only if it exists.
> 2. Decide that the purpose of libstdc++ is to be installed only on new (not 
> yet
> existing) system versions, and pass appropriate flags to the compiler to make
> this happen.  Of course, this might make testing hard for people still using
> 10.4.
> 3. Decide that libstdc++ and libgcc go together, and hack libstdc++'s link to
> use libgcc_s.1.dylib directly.  Apple doesn't do this internally, we're
> shipping 4.0.0 libstdc++ and 4.0.1 libgcc.   Apple's libstdc++ is binary
> incompatible with FSF libstdc++ (in small but important ways) and so the 
> effect
> of this might be that no-one can use FSF libstdc++ or FSF libgcc on Darwin at
> all.
> 4. Declare that we don't care.  The problem right now affects only people with
> the MACOSX_DEPLOYMENT_TARGET environment variable set which they probably
> shoudn't have set while building FSF GCC.
> 
> I think we should go for (1), although (4) has certain advantages...
> 


-- 


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

[Bug c++/28015] Nonspecific error messages

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-06-13 16:37 ---
I cannot reproduce this with a simple:
struct timespec {};
#include 


-- 


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

[Bug c++/28015] New: Nonspecific error messages

[philippe at fornux dot com]

Greetings:

I am trying to compile an application and I am getting error massages like the
following one.  Obviously the "previous definition" doesn't point to the first
definition of "struct timespec" but to the redundant definition.  This is
therefore pretty useless:

/usr/include/time.h:119: error: redefinition of `struct timespec'
/usr/include/time.h:119: error: previous definition of `struct timespec'



Phil


-- 
   Summary: Nonspecific error messages
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe at fornux dot com


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

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[soete dot joel at tiscali dot be]

--- Comment #20 from soete dot joel at tiscali dot be  2006-06-13 15:43 
---
(In reply to comment #19)
> Fixed, but we may want the patch on 4.0 too.
> 
Curious I didn't notice this pb gcc-4.0?


-- 


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

[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'

[dberlin at gcc dot gnu dot org]

--- Comment #13 from dberlin at gcc dot gnu dot org  2006-06-13 15:22 
---
Some year we'll have to use the control dependence graph to see if all the
conditions are the same :)


-- 


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

[Bug target/28014] space-optimized divide used inconsistently

[amylaar at gcc dot gnu dot org]

--- Comment #1 from amylaar at gcc dot gnu dot org  2006-06-13 15:21 ---
Created an attachment (id=11661)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11661&action=view)
test case

This testcase goes in testsuite/g++.dg/eh .


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amylaar at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


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

[Bug tree-optimization/27830] [4.1 regression] ICE: verify_stmts failed (invalid operand to unary operator)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.1.2 4.2.0 |4.1.2
  Known to work|4.1.0   |4.1.0 4.2.0 3.4.0
Summary|[4.1/4.2 regression] ICE:   |[4.1 regression] ICE:
   |verify_stmts failed (invalid|verify_stmts failed (invalid
   |operand to unary operator)  |operand to unary operator)
   Target Milestone|4.2.0   |4.1.2


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

[Bug target/28014] New: space-optimized divide used inconsistently

[amylaar at gcc dot gnu dot org]

sh-elf has space optimized division functions for -m4 / -m4-single, which are
provided in a separate library, which is used when statically linking with -Os
.
However, libgcc itself constains some references to the divide functions.  If
these functions have not been used by something else earlier, the references
are satisifed from within libgcc.
This is a missed space optimization, but worse, libgcc.a has a module which
defines both signed and unsigned divide, while libgcc-Os-4-200.a provides
them in two separate modules.
If one of the symbols is pulled in early from libgcc-Os-4-200.a, and the other
satisfied later from within libgcc.a, the first symbol ends up being defined
twice.

I propose to fix this by putting a copy of the unwinder code into
libgcc-Os-4-200.a, which will make the only reference to signed divide
from libgcc.a irrelevant, and by providing an sh udiv_qrnnd definition in
longlong.h and optimizing 1U/0 away in sh.md, which will get rid of the
references to unsigned divide in libgcc.a


-- 
   Summary: space-optimized divide used inconsistently
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization, link-failure
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf


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

[Bug bootstrap/22541] Building into empty PREFIX causes broken limits.h to be installed

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-13 14:54 ---
Fixed in 4.1.2 and the mainline.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.2


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

[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties

[dnovillo at redhat dot com]

--- Comment #4 from dnovillo at redhat dot com  2006-06-13 14:49 ---
Subject: Re:  gimplifying "return CONSTANT" creates
 unneeded temporaties

dann at godzilla dot ics dot uci dot edu wrote on 06/13/06 10:42:
> --- Comment #3 from dann at godzilla dot ics dot uci dot edu  2006-06-13 
> 14:42 ---
> One of the issues with this PR and also 27800, 27809 and 27810 is that this
> extra work/memory allocation done for a number of functions that are never
> used: like all the inline functions present in the glibc headers. These
> functions are thrown out after gimplification...
> 
We need to strike a balance between the potential memory savings due to
a more streamlined GIMPLE and the effort needed to get it.

We should avoid anything that requires the gimplifier to build complex
dataflow and/or duplicate existing optimizations.


-- 


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

[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties

[dann at godzilla dot ics dot uci dot edu]

--- Comment #3 from dann at godzilla dot ics dot uci dot edu  2006-06-13 
14:42 ---
One of the issues with this PR and also 27800, 27809 and 27810 is that this
extra work/memory allocation done for a number of functions that are never
used: like all the inline functions present in the glibc headers. These
functions are thrown out after gimplification...


-- 


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

[Bug bootstrap/22541] Building into empty PREFIX causes broken limits.h to be installed

[bernds at gcc dot gnu dot org]

--- Comment #4 from bernds at gcc dot gnu dot org  2006-06-13 14:39 ---
Subject: Bug 22541

Author: bernds
Date: Tue Jun 13 14:39:42 2006
New Revision: 114611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114611
Log:
PR bootstrap/22541
From Dan Kegel <[EMAIL PROTECTED]>:
* Makefile.in: Strip "dir/../" combinations from SYSTEM_INCLUDE_DIR.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/Makefile.in


-- 


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

[Bug tree-optimization/28003] [4.2 Regression] optimizer bug

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-13 14:26 ---
(In reply to comment #4)
> The only thing i can think of is that SMT.68 is not marked global.
> Is it?

Some how I missed that before:
SMT.68, UID 2839, struct reduced_cell_two_fold_info, is aliased, is addressable


-- 


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

[Bug tree-optimization/27809] inefficient gimplification of globals

[dberlin at gcc dot gnu dot org]

--- Comment #4 from dberlin at gcc dot gnu dot org  2006-06-13 14:26 ---
gimplification is almost certainly the wrong place to be doing the kind of
dataflow we'd need to determine where we could insert load/save pairs of
globals.
Really.


-- 


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

[Bug tree-optimization/27809] inefficient gimplification of globals

[dann at godzilla dot ics dot uci dot edu]

--- Comment #3 from dann at godzilla dot ics dot uci dot edu  2006-06-13 
14:22 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Hmm, it should have produced G.3, G.n, at least I would have thought.
> > 
> 
> No, we intentionally use the same variable for the lexically identical
> expressions, see internal_get_tmp_var/lookup_tmp_var.  Original intention was
> to make PRE and other redundancy elimination optimization passes more 
> efficient
> (this was essential especially for the old SSAPRE pass that used lexical
> equality of expressions to check for redundancies).  These reasons are no
> longer relevant, but keeping the code saves a significant amount of memory and
> compile time (I tried removing the code a few months ago, but since it slows
> down compilation by some 1-2%, I never bothered with posting the patch).

Using the same variable is surely good, wouldn't it be even better to not
create the redundant "G.2 = G" assignments in this PR?


-- 


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

[Bug middle-end/27896] inefficient lowering for return

[dann at godzilla dot ics dot uci dot edu]

--- Comment #2 from dann at godzilla dot ics dot uci dot edu  2006-06-13 
14:18 ---
Add Diego to the CC list as per his request.


-- 

dann at godzilla dot ics dot uci dot edu changed:

   What|Removed |Added

 CC||dnovillo at redhat dot com


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

[Bug middle-end/28010] [4.1/4.2 regression] ICE because of fold_rtx endless recursion

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-13 14:14 ---
Looking at the reduced testcase here, it looks even more the same as PR 27616.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||27616


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

[Bug tree-optimization/27809] inefficient gimplification of globals

[rakdver at gcc dot gnu dot org]

--- Comment #2 from rakdver at gcc dot gnu dot org  2006-06-13 14:09 ---
(In reply to comment #1)
> Hmm, it should have produced G.3, G.n, at least I would have thought.
> 

No, we intentionally use the same variable for the lexically identical
expressions, see internal_get_tmp_var/lookup_tmp_var.  Original intention was
to make PRE and other redundancy elimination optimization passes more efficient
(this was essential especially for the old SSAPRE pass that used lexical
equality of expressions to check for redundancies).  These reasons are no
longer relevant, but keeping the code saves a significant amount of memory and
compile time (I tried removing the code a few months ago, but since it slows
down compilation by some 1-2%, I never bothered with posting the patch).


-- 


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

[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV

[mirko dot bruzzone at primeur dot com]

--- Comment #6 from mirko dot bruzzone at primeur dot com  2006-06-13 13:59 
---
(In reply to comment #5)
> Subject: Re:  Problem: gcc 4.0.3 on Unix_SV
> 
> mirko dot bruzzone at primeur dot com wrote:
> > gt-c-pragma.h:46: parse error before `__attribute__'
> 
> gt-c-pragma.h uses attribute unused in a parameter list, before the 
> parameter type.  Like so:
>void sub (__attribute__ ((unused)) int i) { }
> This is a syntax that gcc-2.7.2 doesn't support.  It was added later. 
> You could try hacking this out, but it might be simpler to try baby 
> steps.  Use 2.7.2 to compile gcc-2.95.3, use 2.95.3 to compile 
> gcc-3.3.4, use 3.3.4 to compile gcc-4.x.
> 
> I see that 2.95.3 supports this syntax, so it might be able to compile 
> gcc-4.x, but there may also be other problems, so going from 2.95.e to a 
> 3.x release, and then to a 4.x release is more likely to work.
> 
> We could probably fix this with some ifdefs, but gcc-2.7.2 is so old 
> that it doesn't seem worth the hassle.  Plus there are probably other 
> issues that haven't been noticed yet.
> 

Thank you very much for your reply.
I tried with success to compile gcc 2.95, but when I try to compile gcc 3.3.4
with gcc 2.95, I see this error:

gcc   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long   -DHAVE_CONFIG_H
-DGENERATOR_FILE  -o gengenrtl \
 gengenrtl.o ../libiberty/libiberty.a
./gengenrtl -h > tmp-genrtl.h
Segmentation Fault - core dumped
make[1]: *** [s-genrtl] Error 139
make[1]: Leaving directory `/usr1/bruzzonem/obj334/gcc'
make: *** [all-gcc] Error 2


So, could you help me again?

all the best.


-- 


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

[Bug tree-optimization/28003] [4.2 Regression] optimizer bug

[dberlin at dberlin dot org]

--- Comment #4 from dberlin at gcc dot gnu dot org  2006-06-13 13:29 ---
Subject: Re:  [4.2 Regression] optimizer bug

pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-13 04:41 
> ---
> Hmm, we get after dce, just:
>   reduced_cell_two_folds[26] = {};
> 
> And DCE removes:
>   this_616 = &reduced_cell_two_folds[26].u;
> 
>   #   SMT.68_1055 = V_MAY_DEF ;
>   this_616->elems[0] = 1;
>   #   SMT.68_1056 = V_MAY_DEF ;
>   this_616->elems[1] = 0;
>   #   SMT.68_1057 = V_MAY_DEF ;
>   this_616->elems[2] = 0;
> ...
>   this_621 = &reduced_cell_two_folds[26].h;
> ...
>   #   SMT.68_1058 = V_MAY_DEF ;
>   this_621->elems[0] = 2;
>   #   SMT.68_1059 = V_MAY_DEF ;
>   this_621->elems[1] = 1;
>   #   SMT.68_1060 = V_MAY_DEF ;
>   this_621->elems[2] = 1;
> 
> 
> Which does not make sense.  Nothing is special in alias shows what is going
> wrong.
> 
> 

The only thing i can think of is that SMT.68 is not marked global.
Is it?


-- 


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

Re: [Bug tree-optimization/28003] [4.2 Regression] optimizer bug

[Daniel Berlin]

pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-13 04:41 
> ---
> Hmm, we get after dce, just:
>   reduced_cell_two_folds[26] = {};
> 
> And DCE removes:
>   this_616 = &reduced_cell_two_folds[26].u;
> 
>   #   SMT.68_1055 = V_MAY_DEF ;
>   this_616->elems[0] = 1;
>   #   SMT.68_1056 = V_MAY_DEF ;
>   this_616->elems[1] = 0;
>   #   SMT.68_1057 = V_MAY_DEF ;
>   this_616->elems[2] = 0;
> ...
>   this_621 = &reduced_cell_two_folds[26].h;
> ...
>   #   SMT.68_1058 = V_MAY_DEF ;
>   this_621->elems[0] = 2;
>   #   SMT.68_1059 = V_MAY_DEF ;
>   this_621->elems[1] = 1;
>   #   SMT.68_1060 = V_MAY_DEF ;
>   this_621->elems[2] = 1;
> 
> 
> Which does not make sense.  Nothing is special in alias shows what is going
> wrong.
> 
> 

The only thing i can think of is that SMT.68 is not marked global.
Is it?

[Bug tree-optimization/28003] [4.2 Regression] optimizer bug

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2006-06-13 13:11 
---
Confirmed.

Shorter testcase (should return 0, but returns 1):


struct A
{
  int i, j[9];
  A() : i(1) { j[0]=j[1]=j[2]=j[3]=j[4]=j[5]=j[6]=j[7]=j[8]=0; }
};

struct B
{
  A a;
};

B b[] =
{
  {}, {}, {}, {}, {}, {}, {}, {}, {}, {},
  {}, {}, {}, {}, {}, {}, {}, {}, {}, {},
  {}, {}, {}, {}, {}
};

int main()
{
  return 1 - b[sizeof(b)/sizeof(B) - 1].a.i;
}



-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||monitored
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 13:11:58
   date||


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

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[bonzini at gnu dot org]

--- Comment #19 from bonzini at gnu dot org  2006-06-13 13:06 ---
Fixed, but we may want the patch on 4.0 too.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.1.0   |4.1.1
  Known to work|4.0.4 4.2.0 |4.0.4 4.1.2 4.2.0
 Resolution||FIXED


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

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[bonzini at gcc dot gnu dot org]

--- Comment #18 from bonzini at gnu dot org  2006-06-13 13:05 ---
Subject: Bug 27733

Author: bonzini
Date: Tue Jun 13 13:05:39 2006
New Revision: 114610

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114610
Log:
2006-06-13  Paolo Bonzini  <[EMAIL PROTECTED]>

PR middle-end/27733
* expmed.c (struct alg_hash_entry): Fix type of field T
to match synth_mult argument.
(NUM_ALG_HASH_ENTRIES): Make it bigger for 64-bit HOST_WIDE_INT.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/expmed.c


-- 


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

[Bug java/1305] [JSR133] GCJ ignores volatile modifier

[aph at gcc dot gnu dot org]

--- Comment #8 from aph at gcc dot gnu dot org  2006-06-13 12:52 ---
Note that this patch has some problems.  In particular, it doesn't work with
BC-compiled code.  Also, on x86 it doesn't insert memory barrier instructions,
but this is arguably a bug in __sync_synchronize() rather than a problem with
this patch.


-- 


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

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

--- Comment #14 from aph at gcc dot gnu dot org  2006-06-13 12:44 ---
Subject: Bug 27908

Author: aph
Date: Tue Jun 13 12:43:56 2006
New Revision: 114609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114609
Log:
2006-06-09  Andrew Haley  <[EMAIL PROTECTED]>

PR java/1305
PR java/27908
* builtins.c (initialize_builtins): Add __sync_synchronize().
* class.c (add_field): Mark volatile fields.
* java-gimplify.c (java_gimplify_expr): Call new functions to
handle self-modifying exprs and COMPONENT_REFs.
(java_gimplify_component_ref): New.
(java_gimplify_modify_expr): Add handling for volatiles.


Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/builtins.c
trunk/gcc/java/class.c
trunk/gcc/java/java-gimplify.c


-- 


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

[Bug java/1305] [JSR133] GCJ ignores volatile modifier

[aph at gcc dot gnu dot org]

--- Comment #7 from aph at gcc dot gnu dot org  2006-06-13 12:44 ---
Subject: Bug 1305

Author: aph
Date: Tue Jun 13 12:43:56 2006
New Revision: 114609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114609
Log:
2006-06-09  Andrew Haley  <[EMAIL PROTECTED]>

PR java/1305
PR java/27908
* builtins.c (initialize_builtins): Add __sync_synchronize().
* class.c (add_field): Mark volatile fields.
* java-gimplify.c (java_gimplify_expr): Call new functions to
handle self-modifying exprs and COMPONENT_REFs.
(java_gimplify_component_ref): New.
(java_gimplify_modify_expr): Add handling for volatiles.


Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/builtins.c
trunk/gcc/java/class.c
trunk/gcc/java/java-gimplify.c


-- 


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

[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2006-06-13 11:53 ---
The inliner needs this temporary appearantly.  Otherwise you'll get

bar ()
{
  int D.1524;

:
  if (D.1524 != 0) goto ; else goto ;

:;
  abort ();

:;
  return;

}

out of

inline int foo () { return 0; }
void bar()
{
  if (foo())
abort ();
}

i.e. it misses to initialize the temporary with the result.  Otherwise you
can play with variants of the following patch:

Index: gimplify.c
===
*** gimplify.c  (revision 114599)
--- gimplify.c  (working copy)
*** gimplify_return_expr (tree stmt, tree *p
*** ,1116 
--- ,1124 
if (!result_decl
|| aggregate_value_p (result_decl, TREE_TYPE (current_function_decl)))
  result = result_decl;
+   else if (/*is_gimple_formal_tmp_reg (TREE_OPERAND (ret_expr, 1))
+||*/ is_gimple_min_invariant (TREE_OPERAND (ret_expr, 1))
+  /*is_gimple_val (TREE_OPERAND (ret_expr, 1))*/)
+ {
+   TREE_OPERAND (stmt, 0) = TREE_OPERAND (ret_expr, 1);
+ 
+   return GS_ALL_DONE;
+ }
else if (gimplify_ctxp->return_temp)
  result = gimplify_ctxp->return_temp;
else


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/28010] [4.1/4.2 regression] ICE because of fold_rtx endless recursion

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2006-06-13 11:53 
---
Confirmed.

Shorter testcase (crashes with or without -m32):


struct A
{
  char c;
  __SIZE_TYPE__ i, j;
};

int foo(struct A* p)
{
  if ((char*)p != (char*)p + p->i)
return 2;
  if (p->j)
return 1;
  return 2;
}



-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
   Severity|normal  |major
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, monitored
   Last reconfirmed|-00-00 00:00:00 |2006-06-13 11:53:06
   date||
   Target Milestone|--- |4.1.2


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

[Bug target/28011] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified

[saito at densan dot co dot jp]

--- Comment #1 from saito at densan dot co dot jp  2006-06-13 10:43 ---
Created an attachment (id=11660)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11660&action=view)
testcase

This testcase is very large because this file already includes header files and
this came from firefox's build.


-- 


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

[Bug target/28011] New: [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified

[saito at densan dot co dot jp]

g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified.
I did following tests. In the case of 1, wrong code was generated.

1. sh4-linux-g++ -S -O -fno-exceptions testcase.cc
2. sh4-linux-g++ -S -O2 -fno-exceptions testcase.cc

Source code is as follows but I will attach the testcase.
  PRBool dummy;
asm("POST:");
  return target->DispatchEvent(event, aDefaultAction ? aDefaultAction :
&dummy);

The result of case 1.
#APP
POST:
#NO_APP
mov.w   .L76,r0
mov.w   .L79,r3
add r14,r3
mov.l   @(r0,r3),r4
mov.l   @r4,r1
mov.l   @(20,r1),r2
mov.l   @r8,r5
mov.l   @(44,r3),r1
tst r1,r1
bf  .L27
mov.w   .L66,r1# .L66:  .short  -188
mov.w   .L79,r3# .L79:  .short  188
add r14,r3
add r1,r3
mov.l   r3,@(44,r3)  # this code is wrong because 44 is not right value
.L27:# the value should be 232 - (188 - 188) but not 232 - 188
mov.w   .L68,r0# .L68:  .short  232
mov.l   @(r0,r14),r6
jsr @r2
nop

The result of case 2. It seems that this case is right.
#APP
POST:
#NO_APP
mov.w   .L62,r3
mov.l   @r13,r5
add r14,r3
mov.l   @(0,r3),r4
mov.l   @(44,r3),r2
mov.l   @r4,r1
tst r2,r2
mov.l   @(20,r1),r1
bt  .L34
.L27:
mov.w   .L58,r0
mov.l   @(r0,r14),r6
jsr @r1
nop
mov r0,r9
.L24:
mov.l   .L63,r1
jsr @r1
mov r8,r4
...
.L34:
mov.w   .L67,r2
mov.w   .L68,r0
add r14,r2
mov.l   r2,@(r0,r14)
bra .L27
nop


-- 
   Summary: [SH] g++ generates wrong code, if '-fno-exceptions' and
'-O' options are specified
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saito at densan dot co dot jp
 GCC build triplet: sh4-linux
  GCC host triplet: sh4-linux
GCC target triplet: sh4-linux


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

[Bug middle-end/28010] New: [4.1/4.2 regression] ICE because of fold_rtx endless recursion

[jakub at gcc dot gnu dot org]

typedef struct
{
  unsigned int addr;
  unsigned int next;
  unsigned int prev;
} list;

static inline list *
shift (list * l, unsigned na)
{
  return (list *) ((char *) l + na);
}

static inline int
is_valid (list * l)
{
  return shift (l, l->prev)->next == (l->addr);
}

static inline int
not_empty (list * l)
{
  return shift (l, l->next) != l;
}

void aaa (void);

void
func (list * l)
{
  unsigned int a = l->addr;

  while (1)
{
  while (not_empty (l))
aaa ();
  if (is_valid (l))
aaa ();
}
}

ICEs with -O1 -m32 and above.  Might be related to PR27616, but without
debugging/fixing one of these that's hard to say.


-- 
   Summary: [4.1/4.2 regression] ICE because of fold_rtx endless
recursion
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i?86-linux


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

[Bug c++/27894] [4.1/4.2 Regression] "internal compiler error: Segmentation fault" with -O

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2006-06-13 09:21 ---
Subject: Bug 27894

Author: jakub
Date: Tue Jun 13 09:21:30 2006
New Revision: 114607

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114607
Log:
PR middle-end/27793
* cp-tree.h (cxx_int_tree_map): New struct.
(struct language_function): Add extern_decl_map field.
* name-lookup.c (pushdecl_maybe_friend): Add x -> t mapping
to cp_function_chain->extern_decl_map hash table instead of
copying over DECL_UID.
* cp-gimplify.c (cxx_int_tree_map_eq, cxx_int_tree_map_hash): New
functions.
(cp_genericize_r): Remap DECL_EXTERN local decls using
cp_function_chain->extern_decl_map hash table.
* decl.c (finish_function): Clear extern_decl_map.

PR c++/26757
PR c++/27894
* g++.dg/tree-ssa/pr26757.C: New test.
* g++.dg/tree-ssa/pr27894.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr26757.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr27894.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/26757] C++ front-end producing two DECLs with the same UID

[jakub at gcc dot gnu dot org]

--- Comment #28 from jakub at gcc dot gnu dot org  2006-06-13 09:21 ---
Subject: Bug 26757

Author: jakub
Date: Tue Jun 13 09:21:30 2006
New Revision: 114607

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114607
Log:
PR middle-end/27793
* cp-tree.h (cxx_int_tree_map): New struct.
(struct language_function): Add extern_decl_map field.
* name-lookup.c (pushdecl_maybe_friend): Add x -> t mapping
to cp_function_chain->extern_decl_map hash table instead of
copying over DECL_UID.
* cp-gimplify.c (cxx_int_tree_map_eq, cxx_int_tree_map_hash): New
functions.
(cp_genericize_r): Remap DECL_EXTERN local decls using
cp_function_chain->extern_decl_map hash table.
* decl.c (finish_function): Clear extern_decl_map.

PR c++/26757
PR c++/27894
* g++.dg/tree-ssa/pr26757.C: New test.
* g++.dg/tree-ssa/pr27894.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr26757.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr27894.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong

[jakub at gcc dot gnu dot org]

--- Comment #20 from jakub at gcc dot gnu dot org  2006-06-13 09:21 ---
Subject: Bug 27793

Author: jakub
Date: Tue Jun 13 09:21:30 2006
New Revision: 114607

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114607
Log:
PR middle-end/27793
* cp-tree.h (cxx_int_tree_map): New struct.
(struct language_function): Add extern_decl_map field.
* name-lookup.c (pushdecl_maybe_friend): Add x -> t mapping
to cp_function_chain->extern_decl_map hash table instead of
copying over DECL_UID.
* cp-gimplify.c (cxx_int_tree_map_eq, cxx_int_tree_map_hash): New
functions.
(cp_genericize_r): Remap DECL_EXTERN local decls using
cp_function_chain->extern_decl_map hash table.
* decl.c (finish_function): Clear extern_decl_map.

PR c++/26757
PR c++/27894
* g++.dg/tree-ssa/pr26757.C: New test.
* g++.dg/tree-ssa/pr27894.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr26757.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr27894.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #17 from mkuvyrkov at gcc dot gnu dot org  2006-06-13 09:03 
---
I tested this fix on a cross from i386-pc-linux-gnu and it did well on those
three tests.  Can, please, someone check if the regressions gone on hppa?


-- 


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

[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #16 from mkuvyrkov at gcc dot gnu dot org  2006-06-13 09:01 
---
Subject: Bug 26807

Author: mkuvyrkov
Date: Tue Jun 13 09:00:52 2006
New Revision: 114606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114606
Log:
2006-06-13  Maxim Kuvyrkov  <[EMAIL PROTECTED]>

PR middle-end/26807
* haifa-sched.c (check_cfg): Handle special case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c


-- 


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

[Bug debug/26754] [4.0/4.1 Regression] Wrong debug info for variable accessed non-locally

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2006-06-13 08:56 
---
Fixed on mainline.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] Wrong
   |Wrong debug info for|debug info for variable
   |variable accessed non-  |accessed non-locally
   |locally |
   Target Milestone|4.0.4   |4.2.0


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

[Bug debug/26754] [4.0/4.1/4.2 Regression] Wrong debug info for variable accessed non-locally

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-06-13 08:55 
---
Subject: Bug 26754

Author: ebotcazou
Date: Tue Jun 13 08:55:40 2006
New Revision: 114605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114605
Log:
PR debug/26754
* gimplify.c (declare_tmp_vars): Rename into declare_vars.
Add debug_info parameter.  Chain the vars to the BLOCK instead
of the BIND_EXPR if debug info are requested for them.
(pop_gimplify_context): Adjust for above change.
(gimple_add_tmp_var): Likewise.
* tree-gimple.h (declare_tmp_vars): Rename into declare_vars.
Add bool parameter.
* tree-nested.c (convert_nonlocal_reference): Adjust for above change.
(convert_local_reference): Likewise.
(get_local_debug_decl): Set DECL_IGNORED_P on the original variable.
(finalize_nesting_tree_1): Request that debug info be emitted
for debug_var_chain.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/tree-gimple.h
trunk/gcc/tree-nested.c


-- 


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

[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #6 from mkuvyrkov at gcc dot gnu dot org  2006-06-13 08:51 
---
Subject: Bug 27863

Author: mkuvyrkov
Date: Tue Jun 13 08:50:53 2006
New Revision: 114604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114604
Log:
2006-06-13  Maxim Kuvyrkov  <[EMAIL PROTECTED]>

* haifa-sched.c (unlink_other_notes, unlink_line_notes): Fix the patch
for PR target/27863.

2006-06-13  Maxim Kuvyrkov  <[EMAIL PROTECTED]>

* gcc.c-torture/compile/20060609-1.c: New test.

PR target/27863
* gcc.c-torture/compile/pr27863.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20060609-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr27863.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/28007] sse autovectorizer emits wrong code involving shifts

[uros at kss-loka dot si]

--- Comment #5 from uros at kss-loka dot si  2006-06-13 07:44 ---
Similar problem was solved for gcc-4.1 in PR target/22480.


-- 


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

[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2006-06-13 07:24 
---
Fixed.


-- 

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=27536

[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2006-06-13 07:24 
---
Subject: Bug 27536

Author: rguenth
Date: Tue Jun 13 07:23:59 2006
New Revision: 114601

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

PR middle-end/27536
* except.c (output_ttype): Expand type with EXPAND_INITIALIZER.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/except.c


-- 


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

[Bug tree-optimization/27830] [4.1/4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator)

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2006-06-13 07:22 ---
Subject: Bug 27830

Author: rguenth
Date: Tue Jun 13 07:22:04 2006
New Revision: 114600

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

PR tree-optimization/27830
* tree-inline.c (copy_body_r): For copying the operand
of an ADDR_EXPR make sure to fold &* afterwards.

* g++.dg/tree-ssa/pr27830.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr27830.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


-- 


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

[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include

[tbm at cyrius dot com]

--- Comment #2 from tbm at cyrius dot com  2006-06-13 07:17 ---
Created an attachment (id=11659)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11659&action=view)
command line causing problem

Here's a sample command line showing the problem.  Removing the -I/usr/include
makes it work.


-- 


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

[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2006-06-13 07:13 ---
Created an attachment (id=11658)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11658&action=view)
alpha-linux-gnu/libjava/config.log


-- 


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

[Bug libgcj/28009] New: libjava cannot be cross-built; X_CFLAGS includes /usr/include

[tbm at cyrius dot com]

libjava fails to cross-build because the Makefile includes an -I/usr/include. 
Removing that makes it work.  I've seen this a number of times now, i386 to
alpha-linux, i386 to m68-linux, etc.  The problem is this in the Makefile:
X_CFLAGS =  -I/usr/include
and X_CFLAGS is part of AM_CXXFLAGS which is where it causes the problem.

I configured gcc with:
/home/tbm/scratch/gcc/configure --disable-bootstrap \
  --enable-languages=c,c++,java --target=alpha-linux-gnu


-- 
   Summary: libjava cannot be cross-built; X_CFLAGS includes
/usr/include
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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