[Bug libfortran/37707] Namelist read of array of derived type incorrect

[burnus at gcc dot gnu dot org]

--- Comment #32 from burnus at gcc dot gnu dot org  2008-10-23 06:18 ---
(In reply to comment #31)
> Fixed on trunk, backport to 4.3?

I think it is simple enough to be OK.


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #31 from jvdelisle at gcc dot gnu dot org  2008-10-23 02:50 
---
Fixed on trunk, backport to 4.3?


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #30 from jvdelisle at gcc dot gnu dot org  2008-10-23 02:43 
---
Subject: Bug 37707

Author: jvdelisle
Date: Thu Oct 23 02:42:36 2008
New Revision: 141318

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141318
Log:
2008-10-22  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/37707
* gfortran.dg/namelist_18.f90: Update test.
* gfortran.dg/namelist_55.f90: New test.
* gfortran.dg/namelist_56.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_55.f90
trunk/gcc/testsuite/gfortran.dg/namelist_56.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_18.f90


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #29 from jvdelisle at gcc dot gnu dot org  2008-10-23 02:32 
---
Subject: Bug 37707

Author: jvdelisle
Date: Thu Oct 23 02:31:00 2008
New Revision: 141317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141317
Log:
2008-10-22  Jerry DeLisle  <[EMAIL PROTECTED]

PR libfortran/37707
* io/list_read.c (read_character): Remove code to look ahead in
namelist
reads to descriminate non-delimited strings from namelist objects.
* io/write.c (namelist_write): Delimit character strings with quote or
apostrophe, defaulting to quote.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/write.c


-- 


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

[Bug c++/35852] -Wconversion rejects bitwise negation and assignment, cannot cast around

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2008-10-23 01:48 ---
Marked as FIXED then. Thanks for the report.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37886] [graphite] ICE: Segmentation fault

[sebpop at gmail dot com]

--- Comment #4 from sebpop at gmail dot com  2008-10-23 01:31 ---
Subject: Re:  [graphite] ICE: Segmentation fault

On Wed, Oct 22, 2008 at 7:28 PM, grosser at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Proposed fix in gloog()
>
> I added a fix for this SEGFAULT. But now we fail with:
>
> copy_data.c: In function 'copy_data':
> copy_data.c:1: internal compiler error: in expand_scalar_variables_expr, at
> graphite.c:3617
>
> This is handled in Bug 37851.
>
> I would like to commit this fix and close this bug.
>

The fix looks good.  Please apply.

Sebastian


-- 


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

[Bug debug/37020] [4.4 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2008-10-23 00:56 
---
Confirmed fixed on AVR target.

Thanks Jakub!


-- 


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

[Bug bootstrap/37899] [4.4 Regression]: Gcc failed to bootstrap

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-23 00:50 ---
This looks like the same as PR 37893.


-- 


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

[Bug java/37900] New: [4.4 Regression] StringBuffer_1 failures

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 141275 gave

+FAIL: StringBuffer_1 -O3 -findirect-dispatch execution - source compiled test
+FAIL: StringBuffer_1 -O3 execution - source compiled test
+FAIL: StringBuffer_1 -findirect-dispatch execution - source compiled test
+FAIL: StringBuffer_1 execution - source compiled test

Revision 141264 is OK.


-- 
   Summary: [4.4 Regression] StringBuffer_1 failures
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/37899] New: [4.4 Regression]: Gcc failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 141305 gave:

libtool: compile:  /export/gnu/import/svn/gcc-test/bld/gcc/gcj
-B/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/
-B/export/gnu/import/svn/gcc-test/bld/gcc/ -ffloat-store -fomit-frame-pointer
-Usun -fclasspath= -fbootclasspath=../../../src-trunk/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch
-fno-indirect-classes
-fsource-filename=/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/classpath/tools/all-classes.lst
-g -O2 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF
classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip 
-fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o
jc1: internal compiler error: in java_read_sourcefilenames, at
java/jcf-parse.c:192
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [classpath/tools/libgcj_tools_la-tools.lo] Error 1

Revision 141300 is OK.


-- 
   Summary: [4.4 Regression]: Gcc failed to bootstrap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/37886] [graphite] ICE: Segmentation fault

[grosser at gcc dot gnu dot org]

--- Comment #3 from grosser at gcc dot gnu dot org  2008-10-23 00:28 ---
Created an attachment (id=16532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16532&action=view)
Proposed fix in gloog()

I added a fix for this SEGFAULT. But now we fail with:

copy_data.c: In function 'copy_data':
copy_data.c:1: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3617

This is handled in Bug 37851.

I would like to commit this fix and close this bug.


-- 


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

[Bug c++/37860] standard_layout: direct and copy initialization issues

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2008-10-22 23:07 ---

Can work around this by adding initializer_list ctor. 

  b(std::initializer_list __a)
  : t(*__a.begin()) { }


-- 


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

[Bug c++/37898] aggregates vs. defaulted deleted functions

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2008-10-22 22:59 ---

Breaking these out to separate bugs


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/37898] New: aggregates vs. defaulted deleted functions

[bkoz at gcc dot gnu dot org]

Aggregate defined in 8.5.1 as:

  An aggregate is an array or a class (Clause 9) with no user-provided
constructors (12.1), no private or protected non-static data members (Clause
11), no base classes (Clause 10), and no virtual functions (10.3).

Perhaps this is an aggregate:

struct aggregate
{
  int i;

  aggregate() = default;
  ~aggregate() = default;
  aggregate& operator=(const aggregate&) = delete;
  aggregate(const aggregate&) = delete;
};

>From 8.4, p 9
  A special member function is user-provided if it is user-declared
and not explicitly defaulted on its first declaration.

Conclude:
  // -> as explicitly defaulted on first decl, no user-provided ctors
  // -> this is an aggregate

Thus, this should work:


struct aggregate
{
  int i;

  // 8.4 p 9, 
  // A special member function is user-provided if it is user-declared
  // and not explicitly defaulted on its first declaration.
  // -> as explicitly defaulted on first decl, this is not user-provided. 
  // -> this is an aggregate
#if 1
  aggregate() = default;
  ~aggregate() = default;
  aggregate& operator=(const aggregate&) = delete;
  aggregate(const aggregate&) = delete;
#endif
};


int main()
{
  typedef aggregate test_type;

  // copy list initialization
  test_type t1 = { 1 };

  // copy list initialization smaller than size of array, array 
  test_type t2[4] = { 1, 2, 3 };
}

Instead, get:

%$bld/H-x86-gcc.20081020/bin/g++ -std=c++0x -c atomic_init_forms-5.cc
atomic_init_forms-5.cc: In function 'int main()':
atomic_init_forms-5.cc:25: error: no matching function for call to
'aggregate::aggregate()'
atomic_init_forms-5.cc:15: note: candidates are: aggregate::aggregate(const
aggregate&)
atomic_init_forms-5.cc:28: error: conversion from 'int' to non-scalar type
'main()::test_type' requested
atomic_init_forms-5.cc:28: error: conversion from 'int' to non-scalar type
'main()::test_type' requested
atomic_init_forms-5.cc:28: error: conversion from 'int' to non-scalar type
'main()::test_type' requested


-- 
   Summary: aggregates vs. defaulted deleted functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org


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

[Bug java/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2008-10-22 22:57 ---
can't see these with 141308: please could you recheck?


-- 


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

[Bug other/37897] decNumber functions break strict-aliasing rules

[janis at gcc dot gnu dot org]

-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bje at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |janis at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-22 22:38:06
   date||


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

[Bug other/37897] New: decNumber functions break strict-aliasing rules

[janis at gcc dot gnu dot org]

The decNumber package in GCC provides support for decimal floating point
arithmetic in the compiler and, for the DPD format, in libgcc's runtime support
for decimal float.  Some of the code in decNumber violates C's strict-aliasing
rules and has resulted in warnings for quite some time.  Some of that code has
different results since the addition of patch r136695, leading to the failure
of test gcc.dg/dfp/convert-int-max.c.  The code in question has undefined
behavior so I can't say that it is miscompiled, only that the results are
different.

I'm testing a patch that quiets all of the warnings about dereferencing
type-punned pointers with very few changes to the decNumber code, mostly
changes to data types and access macros.  This PR is to keep track of the
change because the decNumber code from GCC is also used by the GDB project and
a branch in EGLIBC.


-- 
   Summary: decNumber functions break strict-aliasing rules
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug c++/37896] New: standard_layout: array direct and copy initialization issues

[bkoz at gcc dot gnu dot org]

This is similar to PR/37860, but for array forms.

#include 

struct standard_layout_base
{
  int i;

  standard_layout_base() = default;
  ~standard_layout_base() = default;
  standard_layout_base& operator=(const standard_layout_base&) = delete;
  standard_layout_base(const standard_layout_base&) = delete;

  standard_layout_base(int __a): i(__a) { }
  standard_layout_base(std::initializer_list __a)
  : i(*__a.begin()) { }
};


int main()
{
  typedef standard_layout_base test_type;

  // copy list initialization
  test_type t1 = { 1 };

  // copy list initialization, array
  test_type t21[4] = { 1, 2, 3, 4 };

  // copy list initialization smaller than size of array, array 
  test_type t22[4] = { 1, 2, 3 };
}


-- 
   Summary: standard_layout: array direct and copy initialization
issues
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
 BugsThisDependsOn: 37860


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

[Bug c++/37860] standard_layout: direct and copy initialization issues

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2008-10-22 22:30 ---
Changed summary


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|default and delete used w/  |standard_layout: direct and
   |member functions vs.|copy initialization issues
   |initialization  |


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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

[hp at gcc dot gnu dot org]

--- Comment #5 from hp at gcc dot gnu dot org  2008-10-22 22:17 ---
Created an attachment (id=16531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16531&action=view)
Reduced test-case for updated cris.h at r141228. Compile with -O2.

After fixing REGNO_REG_CLASS (but still with the singleton version of
IRA_COVER_CLASSES), see the cris.h patch, I still get an ICE in IRA, during
build, compiling ldtoa.c from newlib:

dtoa2.c: In function 'emovo':
ldtoa2.c:24: error: unrecognizable insn:
(insn 144 57 140 4 ldtoa2.c:12 (set (reg:HI 13 r13)
(mem:HI (post_inc:SI (reg/v/f:SI 15 acr [orig:63 p.37 ] [63])) [2 S2
A8])) -1 (expr_list:REG_INC (reg/v/f:SI 15\
 acr [orig:63 p.37 ] [63])
(nil)))
ldtoa2.c:24: internal compiler error: in extract_insn, at recog.c:2027

The last dump file is from IRA.  It appears IRA (or reload) allocates ACR (reg
15) for an address with post-increment.  It's just that this register can't be
used for that addressing mode - which is one of the reasons it's in a separate
class.  This doesn't happen with the non-singleton IRA_COVER_CLASSES.


-- 


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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-10-22 22:05 ---
Created an attachment (id=16530)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16530&action=view)
Updated cris.h patch, reflecting corrected REGNO_REG_CLASS together with the
IRA_COVER_CLASSES.

I tried this updated cris.h patch as per previous comment together with
r141228, but it ICE's compiling newlib's ldtoa.c.  See next attachment.


-- 


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

[Bug tree-optimization/37894] [graphite] Polyhedron is not compiling (Summary)

[grosser at gcc dot gnu dot org]

--- Comment #1 from grosser at gcc dot gnu dot org  2008-10-22 21:39 ---
Update status details:

With "-O1 -fgraphite-identity" we have:

- No problems:

aermod.f90
ac.f90
air.f90 
doduc.f90
linpk.f90
mdbx.f90
tfft.f90

- Fail in expand_scalar_variables_expr() (Bug 37851):

bug.f90
capacita.f90
channel.f90
gas_dyn.f90
rnflow.f90

- Fail with SEGFAULT 11 in create_empty_loop_on_edge (Bug 37886):

fatigue.f90
induct.f90
protein.f90
test_fpu.f90

- Fail with SEGFAULT 11 in find_uses_to_rename_use 
nf.f90

With "-O2 -fgraphite-identity" we have some different bugs.


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-22 21:39:50
   date||


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

[Bug middle-end/37857] [graphite] Segmentation fault

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-10-22 21:32 ---
(In reply to comment #1)
> Created an attachment (id=16512)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16512&action=view) [edit]
> Reduced Test Case
> 

This test case does not work, as it is missing a module:

  USE energy
   1
Fatal Error: Can't open module file 'energy.mod' for reading at (1): No such
file or directory


-- 


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

[Bug c++/37582] [4.3 Regression] std::pow strange overload resolution

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-22 21:22 ---
Couldn't cmath just use:
   template
 inline
 typename __gnu_cxx::__promote_2<
-typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value
-&& __is_arithmetic<_Up>::__value,
+typename __gnu_cxx::__enable_if::__value)
+&& bool(__is_arithmetic<_Up>::__value),
 _Tp>::__type, _Up>::__type
 pow(_Tp __x, _Up __y)
 {
...
?  Though 4.4 cc1plus doesn't complain...


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org


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

[Bug inline-asm/37895] New: AVR inline assembly clobbers input value

[Rudolf dot Leitgeb at gmx dot at]

I carefully followed the instructions how to write proper inline assembly for
avr-gcc, however, the resulting code didn't work. I tracked down the problem
and came to the conclusion that gcc assigned wrong registers to the output
variable and therefore corrupted my input data.

Here's sample code, I tried to write a fast routine for multiplying a 16-bit
number with an 8 bit number, the result would be written to a 32 bit number:


static inline int32_t mul_16_8(uint16_t left, uint8_t right) {
int32_t result;
asm volatile(
"clr %C0;" "\n\t"
"clr %D0;" "\n\t"
"mul %A1, %2;" "\n\t"
"movw %A0, r0;" "\n\t"
"mul %B1, %2;" "\n\t"
"add %B0, r0;" "\n\t"
"adc %C0, r1;" "\n\t"
"clr __zero_reg__" "\n\t"
:"=&r" (result)
:"r" (left),"r" (right)
:"r0", "r1"
);
return result;
}

If I invoke this function from regular C code, such as

int32_t res = mul_16_8(0x1234, 0x56);

I get incorrect results. I believe this is the case because the "left" variable
is assigned to the same registers as "result", and "left" is overwritten during
the multiplication. According to several web pages the  "=&r" (result)
directive should prevent exactly this 

Since the bug reporting guide explicitly discourages from posting assembly code
generated by the compiler, I refrain from posting it here, although it might
help clarify this issue. I will post it upon request, though :)


Some extra information:

I don't use plain vanilla avr gcc, but the win avr version: WinAVR 20071221,
which is 4.2.2 plus some AVR specific patches (some bug fixes, extra device
support). Please let me know, if gcc-bugzilla is the wrong address for these
bugs!


-- 
   Summary: AVR inline assembly clobbers input value
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Rudolf dot Leitgeb at gmx dot at
 GCC build triplet: i686-unknown-linux
  GCC host triplet: i686-unknown-linux
GCC target triplet: avr


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

[Bug middle-end/37886] [graphite] ICE: Segmentation fault

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-10-22 21:18 ---
Here a backtrace for copy_data.c:

#0  0x08194e97 in create_empty_loop_on_edge (entry_edge=0x290c2ac8, 
initial_value=0x29066ce8, stride=0x29066d04, upper_bound=0x29066d04,
iv=0x29106ec8, 
iv_before=0xbfbfe780, outer=0x29106d10) at
../../../git/gcc/cfgloopmanip.c:684
#1  0x089d8e5c in graphite_create_new_loop (scop=0x8d320a0,
entry_edge=0x290c2ac8, 
stmt=0x8d33d00, ivstack=0xbfbfe880, outer=0x29106d10)
at ../../../git/gcc/graphite.c:3412
#2  0x089da203 in translate_clast (scop=0x8d320a0, context_loop=0x29106d10, 
stmt=0x8d33d00, next_e=0x290c2ac8, ivstack=0xbfbfe880)
at ../../../git/gcc/graphite.c:3824
#3  0x089d9fad in translate_clast (scop=0x8d320a0, context_loop=0x29106d10, 
stmt=0x8d8c5d0, next_e=0x290c2ac8, ivstack=0xbfbfe880)
at ../../../git/gcc/graphite.c:3777
#4  0x089dc222 in gloog (scop=0x8d320a0, stmt=0x8d8c5d0)
at ../../../git/gcc/graphite.c:4365
#5  0x089de401 in graphite_transform_loops () at
../../../git/gcc/graphite.c:5267


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-22 21:18:54
   date||


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

[Bug tree-optimization/37894] New: [graphite] Polyhedron is not compiling (Summary)

[grosser at gcc dot gnu dot org]

This is a summary bug to keep track of open bugs in compiling polyhedron with
graphite.

At the moment it compiles with -fgraphite, but fails with -fgraphite-identity.


The status in detail for graphite-branch and -fgraphite-identity:

- Without problems:

aermod.f90
ac.f90
air.f90 
doduc.f90
linpk.f90
mdbx.f90
tfft.f90

- Fail in expand_scalar_variables_expr() (Bug 37851):

bug.f90
capacita.f90
channel.f90
gas_dyn.f90
rnflow.f90

- Fail with SEGFAULT 11:

fatigue.f90
induct.f90
nf.f90
protein.f90
test_fpu.f90


-- 
   Summary: [graphite] Polyhedron is not compiling (Summary)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: grosser at gcc dot gnu dot org
ReportedBy: grosser at gcc dot gnu dot org
 BugsThisDependsOn: 37851


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

[Bug bootstrap/36908] bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"

[sebpop at gmail dot com]

--- Comment #5 from sebpop at gmail dot com  2008-10-22 21:08 ---
Subject: Re:  bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"

> Sebastian, can you please look at this?

Sorry for having missed this bug.  The problem here is that we end
with two identical loops, as we copy almost all the statements in both
loops.  The attached patch solves the problem by counting the number
of memory read and write operations per partition and compares it to
the total number of memory operations in the Reduced Dependence Graph.
Loop distribution is stopped when one of the partitions contains all
the memory ops.

Okay for trunk once it finishes regstrap?

Thanks,
Sebastian


--- Comment #6 from sebpop at gmail dot com  2008-10-22 21:08 ---
Created an attachment (id=16529)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16529&action=view)


-- 


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

[Bug java/37893] New: [4.4 Regression] ICE in java during bootstrap at revision 141303

[dominiq at lps dot ens dot fr]

At revision 141303, bootstrap failed with

...
libtool: compile:  /opt/gcc/i686-darwin/gcc/gcj
-B/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libjava/
-B/opt/gcc/i686-darwin/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-fclasspath= -fbootclasspath=../../../../gcc-4.4-work/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch
-fno-indirect-classes
-fsource-filename=/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libjava/classpath/tools/all-classes.lst
-g -O2 -m64 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF
classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip 
-fno-common -o classpath/tools/.libs/libgcj_tools_la-tools.o
jc1: internal compiler error: in java_read_sourcefilenames, at
java/jcf-parse.c:192

Last successful bootstrap r141279.


-- 
   Summary: [4.4 Regression] ICE in java during bootstrap at
revision 141303
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug middle-end/37882] [4.3/4.4 Regression] Bitfield miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-22 20:09 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37882] [4.3/4.4 Regression] Bitfield miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-10-22 20:09 ---
Subject: Bug 37882

Author: jakub
Date: Wed Oct 22 20:08:01 2008
New Revision: 141306

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141306
Log:
PR middle-end/37882
* fold-const.c (build_range_type): For 1 .. signed_max
range call build_nonstandard_inter_type if signed_type_for
returned a type with bigger precision.

* gcc.c-torture/execute/pr37882.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr37882.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37851] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-10-22 20:05 ---
Polyhedron also fails with this bug in, if you use -fgraphite-identity in the
graphite branch.

bug.f90: In function 'sw':
bug.f90:6: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3618

capacita.f90: In function 'cgstab':
capacita.f90:12: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3618

channel.f90: In function 'sw':
channel.f90:6: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3618

gas_dyn.f90: In function 'keel':
gas_dyn.f90:435: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3618

rnflow.f90: In function 'rnflow':
rnflow.f90:4478: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3618


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Jan dot Sjodin at amd dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-22 20:05:58
   date||


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

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-22 19:38 ---
This seem related to PR 33344.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-10-22 19:00 ---
I think either data->passed_type being passed always, or what I've posted,
should be correct.  emit_group_store is run on the hard register(s) in which it
is passed, so using data->nominal_type would be unexpected.

Eric, what do you think?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-22 
18:38 ---
Subject: Re:  [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in
emit_group_store, at expr.c:2084

> --- Comment #6 from jakub at gcc dot gnu dot org  2008-10-22 16:13 ---
> Could be also a dup of PR37316.

Yes, I also believe this to be the case.

Dave


-- 


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

[Bug middle-end/37882] [4.3/4.4 Regression] Bitfield miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-10-22 18:23 ---
Subject: Bug 37882

Author: jakub
Date: Wed Oct 22 18:21:55 2008
New Revision: 141303

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141303
Log:
PR middle-end/37882
* fold-const.c (build_range_type): For 1 .. signed_max
range call build_nonstandard_inter_type if signed_type_for
returned a type with bigger precision.

* gcc.c-torture/execute/pr37882.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr37882.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36254] wrong "control reaches end of non-void function" warning

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-10-22 18:19 ---
The return is generated because we generate one (if there is none) everytime we
reach the end of a function. This is used later to produce "control reaches end
of non-void function". The compiler-generated try-catch forces the creation of
this extra return. The problem is that we do not want to mark all generated
return with no_warning, because we will miss valid warnings. Not sure yet how
to detect which ones were generated because we naturally reach the end of a
function or they are forced because of compiler-generated code.


-- 


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

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-22 18:16 ---
Created an attachment (id=16528)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16528&action=view)
patch for phi-translation

Patch fixing the phi-translation deficiency, adding a simple optimization to
remove *& pairs.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu dot org]

struct X { int i; };

int foo (int x)
{
  struct X a;
  struct X b;
  struct X *p;
  a.i = 1;
  b.i = 2;
  if (x)
p = &a;
  else
p = &b;
  return p->i;
}

should be optimized to return 1 or 2, removing the loads on both paths.

One piece that is missing is that PHI-translation does not optimize the
reference ops vector after phi-translating the operands.  So we end up
looking up (*(&a)).i instead of a.i.  If you fix that we still have
mismatched virtual operands.  This will be fixed on the alias-improvements
branch.


-- 
   Summary: phi-translation and SCCVN do not optimize *&
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization, alias
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/37891] [graphite-branch] Invalid use of single_succ_edge in create_single_entry_edge

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2008-10-22 18:08 ---
Subject: Bug 37891

Author: spop
Date: Wed Oct 22 18:06:40 2008
New Revision: 141301

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141301
Log:
2008-10-22  Sebastian Pop  <[EMAIL PROTECTED]>

PR tree-optimization/37891
Reverted last commit.
* graphite.c (create_single_entry_edge): Set
EDGE_IRREDUCIBLE_LOOP and BB_IRREDUCIBLE_LOOP.


Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite.c


-- 


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

[Bug tree-optimization/37891] [graphite-branch] Invalid use of single_succ_edge in create_single_entry_edge

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2008-10-22 18:07 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/37891] [graphite-branch] Invalid use of single_succ_edge in create_single_entry_edge

[sebpop at gmail dot com]

--- Comment #1 from sebpop at gmail dot com  2008-10-22 18:04 ---
Subject: Re:  New: [graphite-branch] Invalid use of single_succ_edge in
create_single_entry_edge

> Commit 141283 introduced new code in create_single_entry_edge, that breaks
> polyhedron in linpk.f90, mdbx.f90, protein.f90, rnflow.f90, test_fpu.f90:

Let's fix this bug by reverting that patch: the fix for the other bug
should be in split_block instead of in graphite.c.

Sebastian


-- 


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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-10-22 18:02 ---
(In reply to comment #2)
> The problem is in that hard regs (like r10) which have class GENERAL_REGS 
> (from
> REGNO_REG_CLASS) are translated into ACR_REGS.

Oops, I guess I should make that NONACR_REGS; the documentation says the class
should be minimal.  I'll report back on this.


-- 


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

[Bug tree-optimization/37891] New: [graphite-branch] Invalid use of single_succ_edge in create_single_entry_edge

[grosser at gcc dot gnu dot org]

Commit 141283 introduced new code in create_single_entry_edge, that breaks
polyhedron in linpk.f90, mdbx.f90, protein.f90, rnflow.f90, test_fpu.f90:

The code added was:

 {
+  edge e = single_succ_edge (region->entry);
+  int e_flags = e->flags;
+  int b_flags = region->entry->flags;
+  bool irreducible_e = e_flags & EDGE_IRREDUCIBLE_LOOP;
+  bool irreducible_b = region->entry->flags & BB_IRREDUCIBLE_LOOP;
   edge forwarder = split_block_after_labels (region->entry);
+
+  if (irreducible_e)
+   forwarder->flags = e_flags;
+
+  if (irreducible_b)
+   forwarder->dest->flags = b_flags;
+
   region->entry = forwarder->dest;

It fails e.g. in:
linpk.f90: In function 'daxpy':
linpk.f90:290: internal compiler error: in single_succ_edge, at
basic-block.h:642


-- 
   Summary: [graphite-branch] Invalid use of single_succ_edge in
create_single_entry_edge
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grosser at gcc dot gnu dot org


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

[Bug c++/36391] Compilation never ends

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2008-10-22 17:05 ---
(In reply to comment #7)
> 
> testcase compiles on recent 4.3 with -m{32,64} -O{0..3} w/ boost-1.36.0.
> it needs ~1second/~120MB on my quad core box.
> 

Thanks Pawel! If you could test also a recent GCC 4.4 that would be perfect.
Anyway, this seems FIXED. Please reopen if you can reproduce the problem with a
recent GCC release (or trunk).


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug c++/36391] Compilation never ends

[pluto at agmk dot net]

--- Comment #7 from pluto at agmk dot net  2008-10-22 16:58 ---
(In reply to comment #6)
> I cannot compile this testcase with GCC 4.3.2 or a recent revision of GCC 
> 4.4. 
> 
> Could you recreate the prepocessed source with those compilers?
> 

testcase compiles on recent 4.3 with -m{32,64} -O{0..3} w/ boost-1.36.0.
it needs ~1second/~120MB on my quad core box.


-- 


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

[Bug c/30949] "incompatible pointer type" warning does not point to declaration

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-10-22 16:45 ---
This is FIXED in GCC 4.4

Thanks for the report.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/30949] "incompatible pointer type" warning does not point to declaration

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-10-22 16:34 ---
Subject: Bug 30949

Author: manu
Date: Wed Oct 22 16:33:17 2008
New Revision: 141298

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141298
Log:
2008-10-22  Manuel López-Ibáñez  <[EMAIL PROTECTED]>

PR c/30949
* c-typeck.c (convert_for_assignment): Do not give declaration's
location for builtins. Spell out which type was expected and which
was given.
testsuite/
* gcc.target/i386/sse-vect-types.c: Update.
* gcc.dg/simd-5.c: Update.
* gcc.dg/assign-warn-2.c: Update.
* gcc.dg/simd-2.c: Update.
* gcc.dg/simd-6.c: Update.
* gcc.dg/assign-warn-1.c: Update.
* gcc.dg/dfp/composite-type.c: Update.
* gcc.dg/simd-1.c: Update.
* gcc.dg/pr36997.c: Update.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/assign-warn-1.c
trunk/gcc/testsuite/gcc.dg/assign-warn-2.c
trunk/gcc/testsuite/gcc.dg/dfp/composite-type.c
trunk/gcc/testsuite/gcc.dg/pr36997.c
trunk/gcc/testsuite/gcc.dg/simd-1.c
trunk/gcc/testsuite/gcc.dg/simd-2.c
trunk/gcc/testsuite/gcc.dg/simd-5.c
trunk/gcc/testsuite/gcc.dg/simd-6.c
trunk/gcc/testsuite/gcc.target/i386/sse-vect-types.c


-- 


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

[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-22 16:28 ---
If the array has known bounds, we could say that accesses above bounds trap
and likely it wouldn't hurt much.  But for
extern const char *reg_names[];
where we don't know the bounds, we'd have to assume the worst, i.e. that all
indexes may trap.  I'm afraid that's going to penalize quite some code.


-- 


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

[Bug fortran/35820] internal compiler error with nested FORALL

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2008-10-22 16:27 ---
> > Confirm. While I do not get any crash like Dominique, valgrind shows that
> > there is a problem:
>
> How do you extract this diagnostic from valgrind?  I have never used it before
> but found it rolled into FC9.

Well, that is simple: Run gfortran with the -v option, search for the line
where f951 is called, copy that line and run

valgrind 

That's all what is needed, you might try some special options, but most of the
time the defaults are sufficient.
(Note: Whether writes/reads are diagnosed to be invalid depend on the exact
memory layout, sometimes small changes on a program make valgrind fail to
detect a problem, though most of the time the diagnosis is quite stable.)

==31901== Invalid write of size 8
==31901==at 0x470F8E: gfc_resolve_forall (resolve.c:6264)
==31901==by 0x47204C: resolve_code (resolve.c:6523)

The line in question is:

  /* Record the current FORALL index.  */
  var_expr[nvar] = gfc_copy_expr (fa->var);

To run f951 in the debugger, one simply run then
  gdb --args 


-- 


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

[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-10-22 16:13 ---
Could be also a dup of PR37316.


-- 


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

[Bug middle-end/37320] [4.4 Regression] gcc.dg/compat execute test fails

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-22 16:11 ---
My bet would be this is a dup of PR37316.  Can you try the patch in there and
see whether it fixes these?  If not, make sure all the tests are compiled with
-DDBG (or add #define DBG 1 to the start of struct-layout-1.h) and look at what
exact failures are reported in the log.


-- 


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

[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize

[sebpop at gmail dot com]

--- Comment #12 from sebpop at gmail dot com  2008-10-22 16:10 ---
Subject: Re:  [4.4 Regression] gcc-4.4 regression: incorrect code generation
with -O1 -ftree-vectorize

> common base.  Consider &s.c[1] and &s + i, obviously the accesses can
> overlap - would you still say so if the base address of the first one
> would be &s.c[0]?

Yes, in the case &s.c[1] versus &s.c[0], we still have to consider the
arrays to potentially overlap.

> (really the base address of a non-variable access is the access
> itself, right?  &s.c[1] in this case)

No, it cannot be &s.c[1] here.  The base object for arrays in structs
should be the struct itself.

The base address tells you what memory object is accessed with an
offset.  For structs, you are allowed to access any of their contents
using arithmetic.  For instance in:

struct s {
  int a[2];
  int c[20];
}

you could access s.c[10] from the address of struct s with: &s.a + 12.


-- 


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

Re: [Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize

[Sebastian Pop]

> common base.  Consider &s.c[1] and &s + i, obviously the accesses can
> overlap - would you still say so if the base address of the first one
> would be &s.c[0]?

Yes, in the case &s.c[1] versus &s.c[0], we still have to consider the
arrays to potentially overlap.

> (really the base address of a non-variable access is the access
> itself, right?  &s.c[1] in this case)

No, it cannot be &s.c[1] here.  The base object for arrays in structs
should be the struct itself.

The base address tells you what memory object is accessed with an
offset.  For structs, you are allowed to access any of their contents
using arithmetic.  For instance in:

struct s {
  int a[2];
  int c[20];
}

you could access s.c[10] from the address of struct s with: &s.a + 12.

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[drow at gcc dot gnu dot org]

--- Comment #8 from drow at gcc dot gnu dot org  2008-10-22 15:48 ---
Subject: Re:  [4.4 Regression] Small structs are not
passed correctly on hppa64-*-*

On Wed, Oct 22, 2008 at 03:37:09PM -, jakub at gcc dot gnu dot org wrote:
> Was the "I am reasonably sure it will only affect only E500" comment in
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00255.html
> meant for this patch or the other one?
> Clearly it makes a big difference.

It was meant for this patch; for the other, I was absolutely sure.
Your explanation makes sense to me.  I have the same questions you do,
too; I got completely lost in the different modes/types being dealt
with here.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-10-22 15:37 ---
Was the "I am reasonably sure it will only affect only E500" comment in
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00255.html
meant for this patch or the other one?
Clearly it makes a big difference.
I think the bug is that emit_group_store is called with NULL_TREE third
argument (the type) in the new assign_parm_remove_parallels function, while
previously
it has been called sometimes with NULL_TREE (if nominal_mode != passed_mode) or
nominal_type (if the modes are the same) or with passed_type in another part of
the routine.  And on PA BLOCK_REG_PASSING depends on the type, particularly has
different results if type is non-NULL and aggregate vs. NULL or non-aggregate.

--- function.c.jj10 2008-09-30 16:57:11.0 +0200
+++ function.c  2008-10-22 17:32:26.0 +0200
@@ -2436,7 +2436,9 @@ assign_parm_remove_parallels (struct ass
   if (GET_CODE (entry_parm) == PARALLEL && GET_MODE (entry_parm) != BLKmode)
 {
   rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
-  emit_group_store (parmreg, entry_parm, NULL_TREE,
+  emit_group_store (parmreg, entry_parm,
+   data->nominal_mode == data->passed_mode
+   ? data->passed_type : NULL_TREE,
GET_MODE_SIZE (GET_MODE (entry_parm)));
   entry_parm = parmreg;
 }
patch fixes this for me (at least, from eyeballing assembly and/or RTL from a
cross compiler), though I'm not sure if data->passed_type or data->nominal_type
should be used and whether the data->nominal_mode == data->passed_mode guard is
needed or not.


-- 


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

[Bug fortran/35820] internal compiler error with nested FORALL

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2008-10-22 15:30 ---
(In reply to comment #3)
> Confirm. While I do not get any crash like Dominique, valgrind shows that that
> there is a problem:
> 
> ==20532== Invalid write of size 8
> ==20532==at 0x463933: resolve_code (resolve.c:5902)
> ==20532==by 0x4661DB: gfc_resolve_blocks (resolve.c:5988)
> 
> ==20532== Invalid read of size 8
> ==20532==at 0x45B12E: gfc_resolve_assign_in_forall (resolve.c:5744)
> ==20532==by 0x463A5C: resolve_code (resolve.c:5833)
> 
> I cannot look at the source as the computer where I've build gfortran is
> currently off.

Tobias,

How do you extract this diagnostic from valgrind?  I have never used it before
but found it rolled into FC9.

Cheers

Paul  


-- 


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

[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-10-22 15:13 ---
Occurs on powerpc-rtems4.10 as well.

+===GNAT BUG DETECTED==+
| 4.4.0 20081014 (experimental) [trunk revision 141108]
(powerpc-unknown-rtems4.10) GCC error:|
| in vt_add_function_parameters, at var-tracking.c:3176|
| Error detected around a-clrefi.adb:526   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-22 15:13:42
   date||


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

[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers

[jamborm at gcc dot gnu dot org]

--- Comment #20 from jamborm at gcc dot gnu dot org  2008-10-22 15:09 
---
OK, here is the status regarding the trunk (4.4) and the test cases
posted here:

1. The test case in the bug description now works in the sense that
   funk is inlined even when not performing early inlining because
   both indirect inlining and copy propagation can help the inliner do
   this.  

2. When compiling the code from comment #10 with indirect inlining
   turned on (default on -O2) we end up with (taken from the
   "optimized" tree dump):

   a (int x)
   {
   :
 if (x != 0)
   goto ;
 else
   goto ;

   :
 f (); [tail call]
 goto ;

   :
 f (); [tail call]

   :
 return;
   }

   Which obviously might be optimized even further but this is no
   longer an inlining issue.

3. Finally,  let's look at code  from comment #11.   The function main
   still retains  one call  to foo(), specifically  the one  that came
   from function  call().  The reason is  that early cpp  does not see
   the index  being constant and  thus does not replace  the array_ref
   directly  with the  constant.   Arguments could  be  made that  cpp
   should be run  few more times at various  places (after ipa-cp, for
   example)  but IMHO  pass ordering  would need  bigger justification
   than this  artificial example and  this would be very  difficult to
   implement  while also  retaining the  three phase  division  of ipa
   passes for lto.

Because we  are done  with all  three examples as  far as  inlining is
concerned, I think this is fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/37890] New: Incorrect nesting for DW_TAG_imported_declaration

[swagiaal at redhat dot com]

This might be related:

the following code compiled with gcc version 4.3.0 20080428 (Red Hat 4.3.0-8):

namespace A{
  int x = 1;
}

int main()
{
  namespace B = A;

  return 0;
}

producdes the following debuginfo:

...
 <1><4f>: Abbrev Number: 5 (DW_TAG_subprogram)
<50>   DW_AT_external: 1
<51>   DW_AT_name: (indirect string, offset: 0x9): main 
<55>   DW_AT_decl_file   : 1
<56>   DW_AT_decl_line   : 6
<57>   DW_AT_type: <0x6f>   
<5b>   DW_AT_low_pc  : 0x40055c 
<63>   DW_AT_high_pc : 0x400567 
<6b>   DW_AT_frame_base  : 0x0  (location list)
 <1><6f>: Abbrev Number: 6 (DW_TAG_base_type)
<70>   DW_AT_byte_size   : 4
<71>   DW_AT_encoding: 5(signed)
<72>   DW_AT_name: int  
 <1><76>: Abbrev Number: 4 (DW_TAG_imported_declaration)
<77>   DW_AT_name: B
<79>   DW_AT_decl_file   : 1
<7a>   DW_AT_decl_line   : 8
<7b>   DW_AT_import  : <0x2d>   [Abbrev Number: 2 (DW_TAG_namespace)]
...

the the above die 0x76 should be a child of 0x4f not sibling. Similar nesting
is expected for lexical scopes of course.


-- 
   Summary: Incorrect nesting for DW_TAG_imported_declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: swagiaal at redhat dot com


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

[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-10-22 14:28 ---
trunk is also broken the same way.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.0   |4.3.0 4.4.0
Summary|[4.3 Regression] SEGV,  |[4.3/4.4 Regression] SEGV,
   |conditional execution   |conditional execution
   |proactively executed the|proactively executed the
   |false arm.  |false arm.


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-22 
14:28 ---
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

>Priority|P3  |P1

I haven't had a chance to look at this any further but this regression
is fixed by reverting the change(s) previously identified.

Dave


-- 


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

[Bug rtl-optimization/37889] [4.3 Regression] SEGV, conditional execution proactively executed the false arm.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-10-22 14:26 ---
Confirmed.  This is ifcvt at work, ce1 is buggy already (it probably thinks
accesses to reg_names cannot trap).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
  Component|middle-end  |rtl-optimization
   Target Milestone|--- |4.3.3


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

[Bug fortran/36091] false positive in bounds checking with forall

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-10-22 14:24 ---
I am not 100% sure that the following is due to the patch in comment #1, but
the following code segfaults (at the write) after having applied it:

  integer :: i(1) = 1
  integer :: foo(3)
  foo = 17
  print *, i, foo
  write(*,*) foo([1]), foo([1]+i), [1]+1
end


-- 


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

[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark

[vmakarov at redhat dot com]

--- Comment #9 from vmakarov at redhat dot com  2008-10-22 14:00 ---
The performance status is still the same.  But I am working on it and actually
biggest part of my work time (about 90%) I spent on performance problems
particular this one.  They are the most hard to solve.


-- 


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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

[vmakarov at redhat dot com]

--- Comment #2 from vmakarov at redhat dot com  2008-10-22 13:51 ---
The problem is in that hard regs (like r10) which have class GENERAL_REGS (from
REGNO_REG_CLASS) are translated into ACR_REGS.  Such translation results in
wrong register pressure calculation for ACR_REGS and failed assert.  IRA
translates classes which are not inside a cover class into the first
intersected cover class and that is ACR_REGS for GENERAL_REGS.  We could
translate to the biggest cover class but I am afraid it would be wrong for
other targets, e.g. INT_FLOAT_REGS for x86 would be translated into FLOAT_REGS
which is more costly than GENERAL_REGS.

So the right solution would be correct finding cover class of specific hard
register.  I hope I'll make a patch today and submit it for approval.

Thanks for reporting the problem and reducing the test.


-- 


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

[Bug tree-optimization/37868] [4.3 Regression] code that breaks TBAA is misoptimized even with -fno-strict-aliasing

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-10-22 13:49 ---
Backporting the fix turns out to be tricky...


-- 


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

[Bug web/1646] The GNATS query filters do not work correctly

[drow at gcc dot gnu dot org]

--- Comment #8 from drow at gcc dot gnu dot org  2008-10-22 13:31 ---
Subject: Bug 1646

Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/2175
PR gdb/2176

* Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS.
* Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS.
(EXTRA_BUILD_FLAGS): Correct typo.  Pass CPPFLAGS.
(HOST_EXPORTS): Pass CPPFLAGS.
(CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define.
(LDFLAGS_FOR_TARGET): Initialize from configure script.
(EXTRA_TARGET_FLAGS): Set CPPFLAGS.
* Makefile.in, configure: Regenerated.
* configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET,
and CPPFLAGS_FOR_BUILD.

libiberty/
* Makefile.in (CPPFLAGS): Define.
(FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/configure
trunk/configure.ac
trunk/libiberty/ChangeLog
trunk/libiberty/Makefile.in


-- 


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

[Bug other/2176] Printing unsigned long int with int format in dwarf2out.c

[drow at gcc dot gnu dot org]

--- Comment #4 from drow at gcc dot gnu dot org  2008-10-22 13:31 ---
Subject: Bug 2176

Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/2175
PR gdb/2176

* Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS.
* Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS.
(EXTRA_BUILD_FLAGS): Correct typo.  Pass CPPFLAGS.
(HOST_EXPORTS): Pass CPPFLAGS.
(CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define.
(LDFLAGS_FOR_TARGET): Initialize from configure script.
(EXTRA_TARGET_FLAGS): Set CPPFLAGS.
* Makefile.in, configure: Regenerated.
* configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET,
and CPPFLAGS_FOR_BUILD.

libiberty/
* Makefile.in (CPPFLAGS): Define.
(FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/configure
trunk/configure.ac
trunk/libiberty/ChangeLog
trunk/libiberty/Makefile.in


-- 


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

[Bug c++/921] 2.95.2 generates incorrect ref to static initialized char[] in classes. 2.8.1 works fine

[drow at gcc dot gnu dot org]

--- Comment #4 from drow at gcc dot gnu dot org  2008-10-22 13:31 ---
Subject: Bug 921

Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/2175
PR gdb/2176

* Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS.
* Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS.
(EXTRA_BUILD_FLAGS): Correct typo.  Pass CPPFLAGS.
(HOST_EXPORTS): Pass CPPFLAGS.
(CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define.
(LDFLAGS_FOR_TARGET): Initialize from configure script.
(EXTRA_TARGET_FLAGS): Set CPPFLAGS.
* Makefile.in, configure: Regenerated.
* configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET,
and CPPFLAGS_FOR_BUILD.

libiberty/
* Makefile.in (CPPFLAGS): Define.
(FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/configure
trunk/configure.ac
trunk/libiberty/ChangeLog
trunk/libiberty/Makefile.in


-- 


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

[Bug rtl-optimization/2175] fold in fold_const.c associates non-multiply expressions

[drow at gcc dot gnu dot org]

--- Comment #3 from drow at gcc dot gnu dot org  2008-10-22 13:31 ---
Subject: Bug 2175

Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/2175
PR gdb/2176

* Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS.
* Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS.
(EXTRA_BUILD_FLAGS): Correct typo.  Pass CPPFLAGS.
(HOST_EXPORTS): Pass CPPFLAGS.
(CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define.
(LDFLAGS_FOR_TARGET): Initialize from configure script.
(EXTRA_TARGET_FLAGS): Set CPPFLAGS.
* Makefile.in, configure: Regenerated.
* configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET,
and CPPFLAGS_FOR_BUILD.

libiberty/
* Makefile.in (CPPFLAGS): Define.
(FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/configure
trunk/configure.ac
trunk/libiberty/ChangeLog
trunk/libiberty/Makefile.in


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[amylaar at gcc dot gnu dot org]

--- Comment #41 from amylaar at gcc dot gnu dot org  2008-10-22 13:16 
---
(In reply to comment #0)

> 1) Hoists a register containing 0 out of the loop

Does the TARGET_RTX_COSTS set the cost to zero for the constant zero?



-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug fortran/36091] false positive in bounds checking with forall

[mikael dot morin at tele2 dot fr]

--- Comment #2 from mikael dot morin at tele2 dot fr  2008-10-22 12:52 
---
I forgot to say that it is regression tested on x86_64-unknown-linux-gnu


-- 


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

[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2008-10-22 12:57 ---
Does the execution failure still exist after my patch

2008-09-17  Joseph Myers  <[EMAIL PROTECTED]>

* expr.c (emit_group_store): Do not shift before moving via a
stack slot.

?


-- 


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

[Bug middle-end/37884] [4.4 Regression] Bootstrap failure due to miscompilation of tree-vrp.c

[krebbel at gcc dot gnu dot org]

--- Comment #1 from krebbel at gcc dot gnu dot org  2008-10-22 12:51 ---
The problem again (similar to PR37674) seems to be related to the
propagation of the hard reg conflict sets in ira_flattening.  The
conflict sets are only propagated to the parent allocno if the child
allocno uses the same pseudo.  This breaks the case below.

The miscompile is created by IRA when assigning hard reg r14 to pseudo
r295.  That way the call in L4 might be reached with the clobbered
value of r14 residing in r8.

Assigning r14 to r295 seems to be valid in loop L1 but it is not in
the nested loop L4 since L4 contains a call insn which clobbers r14.
The conflict of a147r315 with r14 is properly recorded but is not
propagated to L1 in ira_flattening.

r295 as well as r315 are created by change_loop as copies of r83 in L0.



 +-+
 |   ++|
 |   | bb 38  ||
 |   | r295=r7||
 |   ++|
 |a8r83   |  L0|
 +++
  |
 +++ +---+
 |v| |+---+  |
 | +-+ | |   +-+<-|bb 57  |  |
 | |bb 93|<+-+---|bb 71|  |r2=r8  |  |
 | +-+ | |   +-+->|clobber r14|  |
 ||| | ^  +---+  |
 ||| | | |
 |v| | | |
 |   +-+   | | | a147r315|
 |   | bb 50   |---+-+-+ |
 |   | r8=r295 |   | | L4|
 |   +-+   | +---+
 | |
 |   a57r295 L1|
 +-+


-- 

krebbel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |vmakarov at gcc dot gnu dot
   |dot org |org


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

[Bug fortran/36091] false positive in bounds checking with forall

[mikael dot morin at tele2 dot fr]

--- Comment #1 from mikael dot morin at tele2 dot fr  2008-10-22 12:49 
---
Created an attachment (id=16527)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16527&action=view)
patch solving the problem

This patch keeps the original array descriptor from gfc_conv_subref_array_arg
to gfc_trans_create_temp_array so that the temporary generated can have the
same bounds as the original, which is needed for bounds checking. 

However I'm wondering if this is the good way to solve the problem. 

I believe that the code generated for this:

forall (i=j:k) p(p(i)) = 1  ! bounds checking problem

should not be much different than the code generated for that:

p(p(j:k)) = 1  ! no bounds checking problem


-- 


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

[Bug target/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-10-22 12:11 ---
That sounds just too strict testcase matching, not expecting any kind of
reordering and .section directives not necessarily being emitted if an object
is emitted in the same section as the previous one.
FYI, on a x86_64-linux -> powerpc64-darwin cross, I see:
.globl __ZTV1f
.weak_definition __ZTV1f
.section __TEXT,__const_coal,coalesced
...
.globl __ZTI1f
.weak_definition __ZTI1f
...
.globl __ZTS1f
.weak_definition __ZTS1f
(all in the same section and __TEXT used everywhere, not __DATA).


-- 


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

[Bug middle-end/37889] SEGV, conditional execution proactively executed the false arm.

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-10-22 11:55 ---
A user reports that 4.2.3 worked.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.1.2   |4.2.3


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

[Bug tree-optimization/37868] [4.3 Regression] code that breaks TBAA is misoptimized even with -fno-strict-aliasing

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-10-22 11:46 ---
4.2 works, so this is a regression.  Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Known to work|4.4.0   |4.2.4 4.4.0
   Last reconfirmed|2008-10-18 22:42:54 |2008-10-22 11:46:45
   date||
Summary|code that breaks TBAA is|[4.3 Regression] code that
   |misoptimized even with -fno-|breaks TBAA is misoptimized
   |strict-aliasing |even with -fno-strict-
   ||aliasing
   Target Milestone|--- |4.3.3


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

[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-10-22 11:33 ---
Created an attachment (id=16526)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16526&action=view)
gcc44-pr37878.patch

Just for the record, after discussions on IRC the bug was identified in
word_offset_memref_operand.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16519|0   |1
is obsolete||


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

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

[earthengine at gmail dot com]

--- Comment #8 from earthengine at gmail dot com  2008-10-22 10:53 ---
Let me explain it more clearly.

Suppose I am building a toolchain to be running on a x86 Linux machine, and it
will generate code for mips Linux. With gcc 4.2.x, I can use

--host=i686-pc-linux-gnu --target=mips-linux-gnu

and it will work on both x86-64 marchines as well because the 4.2.x build
system will use i686-pc-linux-gnu as the --build parameter, and then it will be
a case of normal cross compile.

However, the previous configuration does not work under 4.3+. The reason is
under 4.3+ the build system will detect the --build parameter as well, so the
configuration will become

--build=x86_64-unknown-linux-gnu --host=i686-pc-linux-gnu
--target=mips-linux-gnu

This is a Canadian cross compile! Usually, to complete a Canadian cross
compile, we need the libstdc++ for mips-linux-gnu already because it can not
depending on the just-compiled compiler (it would not run on the build machine)
to compile this library.

This is why we have this problem. The solution is to explicitly use

--build=i686-pc-linux-gnu --host-pc-linux-gnu --target=mips-linux-gnu

to force a normal cross compile.


-- 


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

[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-10-22 10:50 ---
I'm not sure why this is suddenly a P5.
I'm unassigning myself, as Richard Sandiford has the ball (thank you again for
your effort) and is in progress of fixing the target prerequisites for de facto
the first part of the proposed patch.  See
 (mid-thread, but
containing the general parts of the patch).


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

[earthengine at gmail dot com]

--- Comment #7 from earthengine at gmail dot com  2008-10-22 10:31 ---
Hi, We have found the reason of this problem. The GCC 4.3+ serials can
automaticaly detect the --build parameter (i686-pc-linux-gnu, or something like
that). However, the previous version will use --host parameter if it has been
specified. In some case (especially mutilib-systems) when using configuring
without --build, then the build system will wrongly detect the --build
parameter, which will cause the libstdc++ to be detected should use a pre-build
version. This causes many problems.

We have solve it with explicitly specify the --build parameter. This should be
written to the manual, and then this issue can be closed.

Thank you.


-- 


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

[Bug middle-end/37882] [4.3/4.4 Regression] Bitfield miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-10-22 10:17 ---
Indeed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-10-21 16:15:25 |2008-10-22 10:17:51
   date||


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

asking new feature

[Fenyvesi Tamás]

Hi,

I'm trying to ask a new feature for gcc rater than reporting bugs now...
Missing this feature is more pressing on flash type microcontroller platforms 
like (more and more types of) low pin count ARM core (ARM7, Cortex-M3), 
Atmel/AVR and similars. However, more or less all the embedded area is involved.

It's known it's suboptimal to duplicate string constants at RAM for runtime. 
The main reason for my using iccavr rather than avrgcc is the ugly form of 
"sprintf(buf,PSTR("StringInProgramstore"));" instead of regular 
"sprintf(buf,"StringInProgramstore"));".

It would be very easy to remove this drawback by having some command line 
switch (tickbox on GUI's) arranging the default storage for string constants. 
Tick box name can be e.g. "strings remain in program store" or "strings in 
program store only".

This problem belongs to Harward/Neumann architecture difference rather than 
using nonvolatile memories so it might be benefical for any non-flash type (but 
still Harward) processors like DSP's, OMAP, etc. as well.


What about including this feature in mainline gcc?


Best regards,

Tamas

[Bug c++/31246] -Wunreachable-code warnings for compiler-generated code

[manu at gcc dot gnu dot org]

--- Comment #27 from manu at gcc dot gnu dot org  2008-10-22 08:35 ---
(In reply to comment #5)
> Note, however, that, as far as I can see, such try/catch are *not* in the
> library code proper, but *all* synthesized by the C++ front-end.

Does anyone has any idea where in the C++ front-end this is synthesized?


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[toon at moene dot indiv dot nluug dot nl]

--- Comment #28 from toon at moene dot indiv dot nluug dot nl  2008-10-22 
08:28 ---
Jerry, do you think your patch can be applied and this bug closed ?

As I wrote, it fixed the original problem from which I constructed the two test
cases.


-- 


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