[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[jkherciueh at gmx dot net]

--- Comment #3 from jkherciueh at gmx dot net  2007-10-19 10:13 ---
> Actually, the problem happens only for some specific values of the range, like
> eng.max() / 5.5, dividing by 2 or 10 is ok. Indeed, seems a binary arithmetic
> problem.

I conjecture that the problem happens if and only if the range size does not
divide evenly into eng.max(). In fact, the fractional part determines which
buckets get hit more often. If you do 4.3 instead of 5.5, the first 3 out of 10
or the first 6 ot out 20 buckets get the load. If this conjecture is correct,
it would be more accurate to say that the algorithm performs as promised only
for a small set of range sizes (the divisors of eng.max()) and is biased for
all other values.


-- 


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

[Bug fortran/33544] [4.3 only] Warning in TRANSFER intrinsic should be made optional

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-10-19 14:09 
---
Subject: Bug 33544

Author: jvdelisle
Date: Fri Oct 19 14:09:27 2007
New Revision: 129489

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

PR libfortran/33544
* gfortran.dg/transfer_check_1.f90: Adjust options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/transfer_check_1.f90


-- 


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

[Bug fortran/33817] New: the version of gdb included with gfortran-windows.exe does not work

[michael dot a dot richmond at nasa dot gov]

I installed http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe

I found that the version of gdb included with gfortran-windows.exe does not
work, but the version of gdb included with Cygwin does. When I type:

c:\progra~1\gfortran\bin\gfortran -g test.f90
c:\progra~1\gfortran\bin\gdb a

It prints:

c:/cygmnt/prj/pkg/src/gdb/mingw32/gdb/dwarf2read.c:985: gdb-internal-error:
read_comp_unit_head: dwarf from non elf file
An internal GDB error was detected.  This may make further
debugging unreliable.  Quit this debugging session? (y or n)

There are no errors if I type:

c:\cygwin\bin\gdb a


-- 
   Summary: the version of gdb included with gfortran-windows.exe
does not work
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug c/15685] printf("%s\n") optimized to puts also when parameter might be null

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2007-10-19 14:46 ---
Just for reference. Neither fprintf() nor sprintf() seem to follow the
behaviour of printf() in glibc 2.5.


-- 


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

[Bug c++/33819] New: Miscompiled shift of C++ bitfield

[ian at airs dot com]

When this test is compiled and run using -O2 with gcc 4.2 and with mainline, it
fails (tested on i686-pc-linux-gnu).  It succeeds with 4.1.

class s
{
public:
  s(long long aa) : a(aa), i1(0) { }
  long long id() const { return (this->a << 16) >> 16; }
  bool operator< (s sv) { return this->a < sv.id(); }
private:
  long long a : 48;
  int i1 : 16;
};
s g(1);
int
main(int, char**)
{
  if (g < (1LL << 38) - 1)
return 0;
  else
return 1;
}

I haven't pinned down the exact problem.  However, it appears to be due to the
fact that C++ creates the bitfield as a 48-bit signed integer type.  The left
shift is done in that 48-bit type, not in the long long type which should be
used.  The left shift and right shift in the 48 bit yield -1, which is
incorrect; it should yield ((1LL << 38) - 1).


-- 
   Summary: Miscompiled shift of C++ bitfield
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug c++/33821] New: function with ambiguous covariant return-type is not rejected

[peter dot pirkelbauer at tamu dot edu]

struct R1 {};
struct R2 : R1 {};
struct R3 : R1 {};
struct R4 : R2, R3 {};

struct A { virtual R1& foo(); };
struct B : virtual A { R2& foo(); };
struct C : virtual A { R3& foo(); };
struct D : B, C { R4& foo(); }; // should be rejected

R4 contains two subobjects of type R1. When D::foo is invoked in the context of
A (e.g.: in the following function bar) the cast from R4 to R1 is ambiguous.
Therefore D::foo should be rejected.

void bar(D& d)
{ A& a = d;
  R1& res = a.foo();
}


-- 
   Summary: function with ambiguous covariant return-type is not
rejected
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter dot pirkelbauer at tamu dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug ada/33820] Compilation error for "macrosub"

[Markus dot Elfring at web dot de]

--- Comment #1 from Markus dot Elfring at web dot de  2007-10-19 20:41 
---
I hope that the rest of my test result is fine, isn't it?

=== gcc Summary ===

# of expected passes42098
# of expected failures  127
# of unresolved testcases   1
# of untested testcases 28
# of unsupported tests  402
/home/elfring/Projekte/GNU/GCC/erzeugt/4.2.2/gcc/xgcc  version 4.2.2

make[2]: [check-gcc] Fehler 1 (ignoriert)
make[2]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.2.2/gcc'
make[1]: *** [check-gcc] Fehler 2
make[1]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.2.2'
make: *** [do-check] Fehler 2


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[hjl at lucon dot org]

--- Comment #23 from hjl at lucon dot org  2007-10-19 22:13 ---
Gcc 4.3 revision 129493 makes 437.leslie3d 25% faster than revision 129372 on
Intel Core 2 Duo 64bit. But it is still 13% slower than gcc 4.1 Red Hat.


-- 


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

[Bug libfortran/31256] Reading from /dev/zero hangs

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2007-10-19 22:01 
---
Not worth the effort.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug target/32889] [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926

[tbm at cyrius dot com]

--- Comment #6 from tbm at cyrius dot com  2007-10-19 21:33 ---
Here's the reduced testcase from delta.  I can try to reduce it further
manually
tomorrow.


typedef unsigned long int ulong;
typedef unsigned int uint;
typedef unsigned char uchar;
typedef unsigned long long int ulonglong;
typedef struct st_mi_state_info
{
  struct
  {
uchar file_version[4];
uchar header_length[2];
uchar base_pos[2];
  }
  header;
  ulong *rec_per_key_part;
}
MI_STATE_INFO;
typedef struct st_mi_base_info
{
  long max_data_file_length;
}
MI_BASE_INFO;
typedef struct st_mi_isam_share
{
  MI_STATE_INFO state;
  MI_BASE_INFO base;
  char *unique_file_name;
  ulong options;
}
MYISAM_SHARE;
extern uchar myisam_file_magic[], myisam_pack_file_magic[];
mi_open (const char *name, int mode, uint open_flags)
{
  int kfile;
  uint base_pos, info_length;
  char name_buff[512], org_name[512], index_name[512], data_name[512];
  char *disk_cache, *disk_pos, *end_pos;
  MYISAM_SHARE share_buff, *share;
  ulong rec_per_key_part[255 * 16];
  long max_key_file_length, max_data_file_length;
  my_realpath (name_buff, fn_format (org_name, name, "", "", 4), (0));
  if (!(test_if_reopen (name_buff)))
{
  share = &share_buff;
  share_buff.state.rec_per_key_part = rec_per_key_part;
  if ((kfile = my_open (name_buff, 0, (0))) < 0)
{
}
  if (memcmp
  ((char *) share->state.header.file_version,
   (char *) myisam_file_magic, 4))
{
  goto err;
}
  if (__builtin_strcmp (name_buff, org_name)
  || my_readlink (index_name, org_name))
__builtin_stpcpy (index_name, org_name);
  info_length =
(share->state.header.header_length[1]) +
(share->state.header.header_length[0]);
  base_pos =
(share->state.header.base_pos)[1] + (share->state.header.base_pos[0]);
  if (disk_cache = __builtin_alloca (128));
  my_seek (kfile, 0, 0, 0);
  if (!(open_flags & 4))
{
  goto err;
}
  my_read (kfile, disk_cache);
  mi_state_info_read (base_pos, share->state);
  max_data_file_length =
(share->options) ? (((ulonglong) 1 << (info_length)) -
1) : (mi_safe_mul ((ulonglong) 1 << (info_length))
  - 1);
mi_safe_mul ((ulonglong) 1 << (strlen (index_name)));
  share->base.max_data_file_length = max_data_file_length;
  my_multi_malloc (share->unique_file_name, 1);
}
err:return (0);
}


-- 


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

[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl

[tbm at cyrius dot com]

--- Comment #9 from tbm at cyrius dot com  2007-10-19 21:10 ---
(In reply to comment #8)
> Whether or not an ICE occurs depends to some extent
> on checking being enabled.  With checking enabled, I see this on 4.1
> and the trunk.
> 
> The ICE is here:
> 
>   result = expand_expr (exp, target, tmode,
> modifier == EXPAND_INITIALIZER
> ? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS);
> 
>   /* If the DECL isn't in memory, then the DECL wasn't properly
>  marked TREE_ADDRESSABLE, which will be either a front-end
>  or a tree optimizer bug.  */
>  gcc_assert (MEM_P (result));

Julien Cristau just reported an ICE with gcc 4.2 on hppa and I tracked it down
to the same piece of quote you're quoting above.  Note that my reduced testcase
produces an ICE with gcc 4.1, 4.2 and trunk.  Dave, can you take a look at it
please?

The following testcase requires -O:

paer% gcc-4.2 -c -O2 basematrix.cc
basematrix.cc: In member function ‘void S_BaseMatrix
>::_ZTv0_n12_N12S_BaseMatrixI7complexIdEE12MultTransAddES1_(Complex)’:
basematrix.cc:33: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6554
Please submit a full bug report,
with preprocessed source if appropriate.


Testcase:

/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */

template < typename _CharT > class basic_stringstream;
typedef basic_stringstream < char >stringstream;

template < typename _CharT > class basic_ios
{
};
template < typename _CharT > class basic_stringstream:
 virtual public basic_ios < _CharT >
{
};

template < typename _Tp > class complex;
template <> struct complex 
{
__complex__ double _M_value;
};
typedef complex < double >Complex;

class BaseMatrix
{
virtual void MultTransAdd (Complex s);
};
template < typename SCAL > class S_BaseMatrix:virtual public BaseMatrix
{
};
template < > class S_BaseMatrix < Complex >:virtual public BaseMatrix
{
virtual void MultTransAdd (Complex s);
};
void S_BaseMatrix < Complex >::MultTransAdd (Complex s) {
stringstream err;
}


-- 


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

[Bug c++/32252] [4.3 regression] ICE with variadic templates and arrays

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-10-19 20:27 ---
In fact at some point I'd like to open a discussion about what we consider a
*regression*. I mean, *regression* means to me, roughly, "something used to
work and now all of a sudden doesn't work anymore, we must quickly fix it!".
However, we mark PRs as [4.1/4.2/4.3 regression], and that very often means
something different! Because we often mark like that issues which date back to
3.4 or even 3.3! And that because we want only to mention active branches.
Overall, I think this approach may be very confusing. Another, smaller, issue
is that in case of ICEs on invalid should be more clear from the PR whether it
happens only in development builds, or not: the latter are definitely less
serious, IMO, at least now that we have "confused by earlier errors..."


-- 


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

[Bug target/33812] [4.3 Regression] Vectorizer testcases fail

[amodra at bigpond dot net dot au]

--- Comment #9 from amodra at bigpond dot net dot au  2007-10-19 23:51 
---
*** Bug 33806 has been marked as a duplicate of this bug. ***


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

 CC||dominiq at lps dot ens dot
   ||fr


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

[Bug middle-end/33806] [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin

[amodra at bigpond dot net dot au]

--- Comment #3 from amodra at bigpond dot net dot au  2007-10-19 23:51 
---


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


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/32252] [4.3 regression] ICE with variadic templates and arrays

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-19 23:48 ---
(In reply to comment #3)
> Another, smaller, issue is that in case of ICEs on invalid should be
> more clear from the PR whether it
> happens only in development builds, or not: the latter are definitely less
> serious, IMO, at least now that we have "confused by earlier errors..."

We do, that is the error-recovery keyword comes into play.  Hmm, this bug is
also an error recovery issue anyways (with the default settings) so marking it
as such.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||error-recovery, ice-on-
   ||invalid-code


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

[Bug tree-optimization/33434] [4.3 Regression] -fipa-cp miscompilation

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-10-20 00:18 ---
Try this one:
/* { dg-do run } */
/* { dg-options "-O3 -fipa-cp" } */

int k;

void f1 (int a, int b)
{
  if (a)
   {
 int c;
goto d;
do {
  k = 1;
d:
c = b--;
}while (c);
   }
  else
if (b != 1)
  __builtin_abort ();
}

int main (void)
{
  f1 (1, 1);
  if (k != 1)
__builtin_abort ();
  return 0;
}


-- 


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

[Bug target/33812] [4.3 Regression] Vectorizer testcases fail

[amodra at bigpond dot net dot au]

--- Comment #10 from amodra at bigpond dot net dot au  2007-10-20 00:08 
---
Prior to my patch:

.L.main1:
mflr 0
mr 12,1
std 0,16(1)
lis 0,0x
ori 0,0,4656
stdux 1,1,0
mfvrsave 0
stw 0,-4(12)
so we store vrsave at frame_top-4
...
lwz 12,-4(1)
li 3,0
mtvrsave 12
but here we restore from frame_top+0xfff...f4656-4
ld 1,0(1)
because the frame isn't popped until here.
ld 0,16(1)
mtlr 0
blr


-- 


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

[Bug tree-optimization/33434] [4.3 Regression] -fipa-cp miscompilation

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-20 00:05 ---
(In reply to comment #3)
> A regression hunt on powerpc-linux identified this patch:
HEHEHEHEHEHEHE.  Seriously this is funny.

Anyways try changing the code to be (which will not invoke my removal of the
"optimization"):
/* { dg-do run } */
/* { dg-options "-O3 -fipa-cp" } */

int k;

void f1 (int a, int b)
{
  if (a)
   {
 int c = b--;
while (c)
  k = 1;
   }
  else
if (b != 1)
  __builtin_abort ();
}

int main (void)
{
  f1 (1, 1);
  if (k != 1)
__builtin_abort ();
  return 0;
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-20 00:05:28
   date||


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

[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QList and const QList

[bangerth at dealii dot org]

--- Comment #4 from bangerth at dealii dot org  2007-10-19 23:54 ---
This is the shortest I can come up with:
--
template 
struct __attribute__((visibility("default"))) List {};

int bar(List args);
bool test(const List &);

int i = bar(List());

bool test(const List &) {}
-
tmp/bangerth> /tmp/bangerth/bin/gcc-mainline/bin/c++ -c x.cc
x.cc: In function 'bool test(const List&)':
x.cc:9: internal compiler error: canonical types differ for identical types
const List and const List
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

W.


-- 


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

[Bug debug/33822] [4.1/4.2/4.3 Regression] -g -O -mstrict-align causes an ICE in set_variable_part,

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-19 23:41 ---
Variable tracking is new for 4.0.0 so this is a regression from 3.4.x and it
ICEd in 4.0.2.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.4.6
Summary|-g -O -mstrict-align causes |[4.1/4.2/4.3 Regression] -g
   |an ICE in set_variable_part,|-O -mstrict-align causes an
   ||ICE in set_variable_part,
   Target Milestone|--- |4.2.3


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

[Bug debug/33822] New: -g -O -mstrict-align causes an ICE in set_variable_part,

[pinskia at gcc dot gnu dot org]

Compile the following code at -O -g -mstrict-align and you get an ICE in
set_variable_part:

void ProjectOverlay(const float localTextureAxis[2], char *lump) {
   const void *d = &localTextureAxis;
   int size = sizeof(float)*8 ;
   __builtin_memcpy( &lump[ 0 ], d, size );  
 }


-  CUT --
Yes this code is undefined but it should not ICE.


-- 
   Summary: -g -O -mstrict-align causes an ICE in set_variable_part,
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*


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

[Bug fortran/31259] ICE on elemental character function

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-10-19 23:21 
---
I see that this ICE has been fixed along the way.  For the test case in comment
#2 we still get three error messages, but this is because we do not disable
resolve.c and more than one code path gets taken.  There are more than one of
these situations.

I have experimented in the pass with fixes for this problem by disabling the
resolve phase when an error is encountered, but this leads to prolific
testsuite failures because we end up not doing a lot of error checking that is
by necessity, done in resolve.

Closing, since there is no ICE and it is invalid code.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/32889] [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2007-10-19 
22:16 ---
Subject: Re:  [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926

> #1  0x00601eac in delete_output_reload (insn=0x2b78f71e4140, j=1,
> last_reload_reg=21)
> at gcc-4.2/gcc/reload1.c:7932

Would you do the following for the failing assert?
p debug_rtx (insn)
p debug_rtx (i1)
p debug_rtx (substed)

If i1 or substed have been optimized away, you can get at them
in rtx_equal_p as using $r26 and $r25.

It's doubtful there will be a quick fix for this as the problem likely
isn't in the backend.

Dave


-- 


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

[Bug tree-optimization/30840] [4.3 Regression] ice for legal code with flags -O3 -fno-strict-aliasing

[janis at gcc dot gnu dot org]

--- Comment #16 from janis at gcc dot gnu dot org  2007-10-19 22:14 ---
A regression hunt on powerpc-linux using the testcase from comment #3
identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=119502

r119502 | dberlin | 2006-12-04 19:07:05 + (Mon, 04 Dec 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

--- Comment #1 from alexandre dot nunes at gmail dot com  2007-10-20 01:49 
---
Created an attachment (id=14374)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14374&action=view)
A complete testcase.

I compiled with gcc -ggdb3 file.c -o file, no optimization flags.


-- 


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

[Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

I have two structs (the unions are there for the sake of testing, it still
behaves the same without them):

#define ATTRIBUTE_PACKED_STRUCT __attribute__((gcc_struct,packed))
#include 
#include 

typedef union  ATTRIBUTE_PACKED_STRUCT
{
  struct ATTRIBUTE_PACKED_STRUCT {
uint8_t a:1,
b:7,
c:7;
uint16_t d:16;
uint8_t e:7;
uint8_t f:7;
uint16_t g:10;
uint16_t h:10;
uint16_t i:12;
uint8_t  j:7;
uint8_t k:8;
uint16_t l:15;
  };
  unsigned char values[14];
} test_struct;

typedef union  ATTRIBUTE_PACKED_STRUCT
{
  struct ATTRIBUTE_PACKED_STRUCT {
uint32_t a:1,
b:7,
c:7;
uint32_t d:16;
uint32_t e:7;
uint32_t f:7;
uint32_t g:10;
uint32_t h:10;
uint32_t i:12;
uint32_t  j:7;
uint32_t k:8;
uint32_t l:15;
  };
  unsigned char values[14];
} test_struct2;

These structs have the same effective size, i.e., removing them from the
unions, and having sizeof() applied to them yelds the 14 bytes size, but the
members dispostion differs, i.e. the 'e' member is a bit ahead in the first
struct (test_struct) than in the second. 

I didn't expect the type change to force an alignment. It that's standard
behaviour, then I would like to propose a documentation request; The ms_struct
alignment is described quite well on gcc's page, but gcc's default one isn't.

If that's not expected behaviour, then what would be? In case it is, could
someone please point me to a documentation source, i.e. an ISO C pointer or
whatever reasoning is behind this, if any?

Thanks.


-- 
   Summary: bitfields on packed struct aligns by a few bits if the
types differ
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug target/33812] [4.3 Regression] Vectorizer testcases fail

[amodra at bigpond dot net dot au]

--- Comment #8 from amodra at bigpond dot net dot au  2007-10-19 23:48 
---
I'm building a current powerpc64 compiler at the moment to verify, but I think
this is because rs6000_emit_epilogue is now generating mems with address
sp+offset where offset is too large.  Prior to my patch we restored altivec
regs and vrsave from the wrong address...

Fix is to move the block of code restoring vrsave to after we have restored the
old stack pointer.


-- 


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

[Bug fortran/31217] ICE using FORALL on character substrings

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2007-10-20 04:21 ---
Subject: Bug number PR31217

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/2007-10/msg01043.html


-- 


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

[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QList and const QList

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2007-10-19 23:32 ---
Created an attachment (id=14373)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14373&action=view)
smaller testcase, thanks to delta


-- 


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

[Bug c/33718] CHUNKSIZE IN SCHEDULE CLAUSE SHOULD NOT NEED SCOPING IF DEFAULT(NONE) PRESENT

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-10-20 04:08 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/33439] OpenMP: Incorrect error message for chunksize variable

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2007-10-20 04:08 ---
*** Bug 33718 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||geir at cray dot com


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

[Bug target/32889] [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926

[tbm at gcc dot gnu dot org]

--- Comment #5 from tbm at gcc dot gnu dot org  2007-10-19 21:31 ---
Confirmed.


-- 

tbm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2007-10-19 21:31:13
   date||
Summary|ICE in delete_output_reload,|[4.2 Regression] ICE in
   |at reload1.c:7926   |delete_output_reload, at
   ||reload1.c:7926


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

[Bug target/33812] [4.3 Regression] Vectorizer testcases fail

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2007-10-19 21:21 ---
After reverting the changes made in revision 129400 (otherwise revision 129491
+ gfortran patches), the gcc testsuite gives:

Target: powerpc-apple-darwin8

=== gcc tests ===

Schedule of variations:
unix

XPASS: gcc.dg/20020103-1.c scan-assembler-not LC[0-9]
FAIL: gcc.dg/initpri1.c execution test
FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times nasty_local 0
FAIL: gcc.dg/ssp-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(char\) .*with 
XPASS: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times Invalid sum 0
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31d.c scan-tree-dump-times
vectorization not profitable 1
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31d.c scan-tree-dump-times
vectorized 1 loops 0
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c scan-tree-dump-times
vectorization not profitable 1
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c scan-tree-dump-times
vectorized 1 loops 0
FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors)
FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times Alignment of
access forced using peeling 4
FAIL: gcc.target/powerpc/parity-1.c scan-assembler popcntb
FAIL: gcc.target/powerpc/popcount-1.c scan-assembler popcntb

=== gcc Summary ===

# of expected passes46942
# of unexpected failures13
# of unexpected successes   2
# of expected failures  166
# of untested testcases 35
# of unsupported tests  419
/opt/gcc/darwin_buildw/gcc/xgcc  version 4.3.0 20071019 (experimental) (GCC) 

This can be compared to

http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00869.html


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||amodra at bigpond dot net
   ||dot au


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

[Bug fortran/33818] [4.3 Regression] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-10-19 21:16 ---
I'm not completely sure which bug is triggered that, but the error occurs for
the expression
   character(len(str)) :: UpperCase

"str" is a dummy (of the interface function UpperCase) and despite being a
dummy it is not a dummy of the current entry function (which is "ExportZMX").

The check assumes: Dummy + not-dummy of current function => Dummy of another
Entry -> invalid.

The solution is to add a check whether the dummy in in the current name space
or not.

I could not find any bit in the patches which caused this, but my un-educated
guess would be http://gcc.gnu.org/viewcvs?view=rev&revision=127939 which added
some character substring fixes.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 129495)
+++ gcc/fortran/resolve.c   (working copy)
@@ -3935,7 +3935,7 @@ resolve_variable (gfc_expr *e)
   bool seen;

   /* If the symbol is a dummy...  */
-  if (sym->attr.dummy)
+  if (sym->attr.dummy && sym->ns == gfc_current_ns)
{
  entry = gfc_current_ns->entries;
  seen = false;
@@ -3952,7 +3952,7 @@ resolve_variable (gfc_expr *e)
  if (!seen)
{
  if (specification_expr)
-   gfc_error ("Variable '%s',used in a specification expression, "
+   gfc_error ("Variable '%s', used in a specification expression,
"
   "is referenced at %L before the ENTRY statement "
   "in which it is a parameter",
   sym->name, &cs_base->current->loc);


-- 


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

[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl

[tbm at cyrius dot com]

--- Comment #10 from tbm at cyrius dot com  2007-10-19 21:12 ---
I forgot to mention that this is on Linux (Debian).


-- 


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

[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QList and const QList

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-19 20:19:49
   date||


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

[Bug c++/31993] [4.3 regression] ICE with template class in variadic template class

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-10-19 20:07 ---
This isn't a regression.  The error is reported with a compiler from 20070210,
the day after support for variadic templates was added.


-- 


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

[Bug ada/33820] New: Compilation error for "macrosub"

[Markus dot Elfring at web dot de]

What is wrong with the following test after the current release was build on my
openSUSE 10.3 system?

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/home/elfring/Projekte/GNU/GCC/Quellen/4.2.2/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/home/elfring/Projekte/GNU/GCC/Quellen/4.2.2/gcc/testsuite/g++.dg/bprob/bprob.exp
...
gnatmake: "macrosub.adb" not found
 Failed to compile macrosub
make[2]: *** [check-acats] Fehler 1


-- 
   Summary: Compilation error for "macrosub"
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Markus dot Elfring at web dot de
 GCC build triplet: Linux Sonne 2.6.22.9-0.4-default #1 SMP 2007/10/05
21:32:04 UTC
  GCC host triplet: Linux Sonne 2.6.22.9-0.4-default #1 SMP 2007/10/05
21:32:04 UTC
GCC target triplet: Linux Sonne 2.6.22.9-0.4-default #1 SMP 2007/10/05
21:32:04 UTC


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

[Bug tree-optimization/33434] [4.3 Regression] -fipa-cp miscompilation

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2007-10-19 19:52 ---
A regression hunt on powerpc-linux identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=124353

r124353 | pinskia | 2007-05-02 17:47:06 + (Wed, 02 May 2007)


-- 


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

[Bug c++/32252] [4.3 regression] ICE with variadic templates and arrays

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-10-19 19:27 ---
(In reply to comment #1)
> This isn't a regression, variadic templates were added on 20070209 and this
> fails with a compiler from 20070210.

Well the ICE itself is a regression.
So the regression marker is used for the follow cases:
rejects-valid -> ICE
accepts-invalid -> ICE
works -> ICE
works -> wrong code
works -> wrong warning
And some other cases


-- 


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

[Bug c++/32252] [4.3 regression] ICE with variadic templates and arrays

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2007-10-19 19:24 ---
This isn't a regression, variadic templates were added on 20070209 and this
fails with a compiler from 20070210.


-- 


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

[Bug fortran/31608] wrong types in character array/scalar binop

[patchapp at dberlin dot org]

--- Comment #34 from patchapp at dberlin dot org  2007-10-20 04:22 ---
Subject: Bug number PR31608

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/2007-10/msg01072.html


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[patchapp at dberlin dot org]

--- Comment #24 from patchapp at dberlin dot org  2007-10-20 04:21 ---
Subject: Bug number PR32921

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/2007-10/msg01036.html


-- 


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

[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2007-10-19 21:54 ---
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code

Just looking again to this old bug...

The problem with VRP/DOM is that they just state equalities, and then
they apply the substitution without really looking at the direction in
which to apply the substitution: so half of the time the transform is
probably a win ;-)

If you look at the transform that VRP/DOM do for the original
testcase, i.e. with the condition:

  if (x != i)
abort ();

this is harmful, as VRP/DOM decides to replace i by x in the induction
variable i = i + 1, and we end with a code that is harder to analyze
later on.  Now, after reversing the operands in the condition,

  if (i != x)
abort ();

both VRP/DOM will just say let's replace x by i, and then everything
is okay, so it's a win ;-)

Here is a patch for VRP to avoid random substitutions of symbolic
expressions, although this might not be the best approach to solve
the problem.

Index: tree-vrp.c
===
--- tree-vrp.c  (revision 129493)
+++ tree-vrp.c  (working copy)
@@ -6000,7 +6000,8 @@ vrp_finalize (void)
   for (i = 0; i < num_ssa_names; i++)
 if (vr_value[i]
&& vr_value[i]->type == VR_RANGE
-   && vr_value[i]->min == vr_value[i]->max)
+   && vr_value[i]->min == vr_value[i]->max
+   && !symbolic_range_p (vr_value[i]))
   {
single_val_range[i].value = vr_value[i]->min;
do_value_subst_p = true;

DOM has a similar code, but is more intricated, and also probably more
careful sometimes, looking at the loop depth of the definition before
replacing it, for avoiding to undo a LICM.  I think that the code that
looks at the profitability of this transformation could be shared
between VRP and DOM.

Sebastian


-- 


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

[Bug target/32889] [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926

[tbm at cyrius dot com]

--- Comment #7 from tbm at cyrius dot com  2007-10-19 21:36 ---
Breakpoint 1, fancy_abort (file=0x7c02a8 "gcc-4.2/gcc/reload1.c", line=7932,
function=0x7c01f0 "delete_output_reload") at gcc-4.2/gcc/diagnostic.c:640
640 {
(gdb) where
#0  fancy_abort (file=0x7c02a8 "gcc-4.2/gcc/reload1.c", line=7932,
function=0x7c01f0 "delete_output_reload") at gcc-4.2/gcc/diagnostic.c:640
#1  0x00601eac in delete_output_reload (insn=0x2b78f71e4140, j=1,
last_reload_reg=21)
at gcc-4.2/gcc/reload1.c:7932
#2  0x00602d88 in do_output_reload (chain=0x9d6e30, rl=0x983be8, j=1)
at gcc-4.2/gcc/reload1.c:7128
#3  0x0060352d in emit_reload_insns (chain=0x9d6e30)
at gcc-4.2/gcc/reload1.c:7229
#4  0x0060732f in reload_as_needed (live_known=1)
at gcc-4.2/gcc/reload1.c:3997
#5  0x0060a3cf in reload (first=0x2b78f71bd140, global=1)
at gcc-4.2/gcc/reload1.c:1082
#6  0x006d4c57 in global_alloc () at gcc-4.2/gcc/global.c:626
#7  0x006d4ec2 in rest_of_handle_global_alloc ()
at gcc-4.2/gcc/global.c:2514
#8  0x00643678 in execute_one_pass (pass=0x949440)
at gcc-4.2/gcc/passes.c:881
#9  0x006437dc in execute_pass_list (pass=0x949440)
at gcc-4.2/gcc/passes.c:932
#10 0x006437ee in execute_pass_list (pass=0x947d00)
at gcc-4.2/gcc/passes.c:933
#11 0x00465d6e in tree_rest_of_compilation (fndecl=0x2b78f716e2a0)
at gcc-4.2/gcc/tree-optimize.c:462
#12 0x0040b168 in c_expand_body (fndecl=0x2b78f716e2a0)
at gcc-4.2/gcc/c-decl.c:6835
#13 0x006796b4 in cgraph_expand_function (node=0x2b78f71a9840)
at gcc-4.2/gcc/cgraphunit.c:1243
#14 0x00679ff5 in cgraph_optimize () at gcc-4.2/gcc/cgraphunit.c:1308
#15 0x0040ea72 in c_write_global_declarations ()
at gcc-4.2/gcc/c-decl.c:7950
#16 0x00625acf in toplev_main (argc=, argv=)
at gcc-4.2/gcc/toplev.c:1045
#17 0x2b78f6d014ca in __libc_start_main () from /lib/libc.so.6
#18 0x0040273a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb)


-- 


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

[Bug middle-end/32135] [4.3 Regression] bogus array-ref fold triggering array overflow warning

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2007-10-19 23:00 ---
The failure also shows up on powerpc-linux, where a regression hunt identified:

http://gcc.gnu.org/viewcvs?view=rev&rev=124403

r124403 | hubicka | 2007-05-04 00:40:20 + (Fri, 04 May 2007)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug ada/33820] Compilation error for "macrosub"

[Markus dot Elfring at web dot de]

--- Comment #2 from Markus dot Elfring at web dot de  2007-10-19 20:54 
---
By the way: There is another report on this specific issue with the topic "make
check on -CURRENT in lang/gnat-gcc41" by Petr Holub.
http://groups.google.de/group/mailing.freebsd.ports/msg/0aeb2c869f508d92


-- 


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

[Bug tree-optimization/33766] [4.1/4.2/4.3 Regression] ICE in bsi_for_stmt at tree-cfg.c when using -O1 -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2007-10-19 19:03 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #24 from spop at gcc dot gnu dot org  2007-10-19 19:03 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #23 from spop at gcc dot gnu dot org  2007-10-19 19:02 ---
Subject: Bug 24309

Author: spop
Date: Fri Oct 19 19:01:58 2007
New Revision: 129494

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

PR tree-optimization/23820
PR tree-optimization/24309
PR tree-optimization/33766
* testsuite/gcc.dg/tree-ssa/pr23820.c: New.
* testsuite/gcc.dg/tree-ssa/pr24309.c: New.
* testsuite/gcc.dg/tree-ssa/pr33766.c: New.
* testsuite/gcc.dg/tree-ssa/ltrans-3.c: XFAILed.
* tree-loop-linear.c (perfect_loop_nest_depth): New.
(linear_transform_loops): Use perfect_loop_nest_depth.
* lambda-code.c (perfect_nest_p): Outer loops in perfect nests 
should have a single condition: their exit.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23820.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24309.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr33766.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lambda-code.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ltrans-3.c
trunk/gcc/tree-loop-linear.c


-- 


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

[Bug tree-optimization/23820] ICE in lambda_loopnest_to_gcc_loopnest, at lambda-code.c:1982

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2007-10-19 19:02 ---
Subject: Bug 23820

Author: spop
Date: Fri Oct 19 19:01:58 2007
New Revision: 129494

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

PR tree-optimization/23820
PR tree-optimization/24309
PR tree-optimization/33766
* testsuite/gcc.dg/tree-ssa/pr23820.c: New.
* testsuite/gcc.dg/tree-ssa/pr24309.c: New.
* testsuite/gcc.dg/tree-ssa/pr33766.c: New.
* testsuite/gcc.dg/tree-ssa/ltrans-3.c: XFAILed.
* tree-loop-linear.c (perfect_loop_nest_depth): New.
(linear_transform_loops): Use perfect_loop_nest_depth.
* lambda-code.c (perfect_nest_p): Outer loops in perfect nests 
should have a single condition: their exit.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23820.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24309.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr33766.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lambda-code.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ltrans-3.c
trunk/gcc/tree-loop-linear.c


-- 


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

[Bug tree-optimization/33766] [4.1/4.2/4.3 Regression] ICE in bsi_for_stmt at tree-cfg.c when using -O1 -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2007-10-19 19:02 ---
Subject: Bug 33766

Author: spop
Date: Fri Oct 19 19:01:58 2007
New Revision: 129494

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

PR tree-optimization/23820
PR tree-optimization/24309
PR tree-optimization/33766
* testsuite/gcc.dg/tree-ssa/pr23820.c: New.
* testsuite/gcc.dg/tree-ssa/pr24309.c: New.
* testsuite/gcc.dg/tree-ssa/pr33766.c: New.
* testsuite/gcc.dg/tree-ssa/ltrans-3.c: XFAILed.
* tree-loop-linear.c (perfect_loop_nest_depth): New.
(linear_transform_loops): Use perfect_loop_nest_depth.
* lambda-code.c (perfect_nest_p): Outer loops in perfect nests 
should have a single condition: their exit.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23820.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24309.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr33766.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lambda-code.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ltrans-3.c
trunk/gcc/tree-loop-linear.c


-- 


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

Re: problem with one tree style builds

[DJ Delorie]

> I am on Fedora 7 with autoconf 2.61 with a checkout from
> yesterday off the trunk.  So I shouldn't have see it based
> upon that requirement.  What else could it be?

Did you re-generate all the configure's from all the configure.ac's?
The ones in CVS are all built with 2.59.

[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2007-10-19 17:53 ---
(In reply to comment #6)
> It is little bit sick, but what about implying -mfpmath=sse when
> -ftree-vectorize is used and SSE is available?

Then you will hit Core2 Duo, that shows the opposite in 32bit and 64bit mode:

-O3 -ffast-math -ftree-vectorize -funroll-loops -msse3 -m32 -mfpmath=387

user 0m22.785s

-O3 -ffast-math -ftree-vectorize -funroll-loops -msse3 -m32 -mfpmath=sse

user 0.27.886s

-O3 -ffast-math -ftree-vectorize -funroll-loops -msse3 -m64 -mfpmath=387

user 0m20.473s

-O3 -ffast-math -ftree-vectorize -funroll-loops -msse3 -m64 -mfpmath=sse

user 0.25.046s


-- 


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

Re: problem with one tree style builds

[DJ Delorie]

> http://sourceware.org/ml/newlib/2006/msg00472.html
> 
> Shouldn't this patch already be in the top level
> gcc/Makefile.in?

The right fix is to use autoconf 2.60 or later.

The patch you link to requires GNU make, and thus was rejected.

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[paolo at gcc dot gnu dot org]

--- Comment #7 from paolo at gcc dot gnu dot org  2007-10-19 17:36 ---
Subject: Bug 33815

Author: paolo
Date: Fri Oct 19 17:36:03 2007
New Revision: 129493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129493
Log:
2007-10-19  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/33815
* include/tr1_impl/random
(uniform_int<>::_M_call(_UniformRandomNumberGenerator&, result_type,
result_type, true_type)): Avoid the modulo (which uses the low-order
bits).

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1_impl/random


-- 


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

problem with one tree style builds

[Joel Sherrill]

Hi,

I switched my testing from gcc 4.2.x to the svn
trunk so I could submit things.  I ran into the
problem reported and fixed here:

http://sourceware.org/ml/newlib/2006/msg00472.html

Shouldn't this patch already be in the top level
gcc/Makefile.in?

--joel

Re: problem with one tree style builds

[DJ Delorie]

> What is the recommended procedure to regenerate them?

Not sure there is one.

> Shouldn't they be regenerated and committed in CVS?

No, because that changes the base requirements for all those packages.

[Bug target/33812] [4.3 Regression] Vectorizer testcases fail

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2007-10-19 16:39 ---
See comment#2 of PR33806. I did not tested the gcc side.


-- 


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

[Bug middle-end/33589] [4.3 regression] ICE on valid code at -O2: verify_flow_info failed

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-10-19 16:36 ---
The testcase also fails on powerpc-linux, where a regression hunt identified
the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=128701

r128701 | aaw | 2007-09-23 20:05:40 + (Sun, 23 Sep 2007)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aaw at gcc dot gnu dot org


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

[Bug middle-end/33806] [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-10-19 16:36 ---
I have reverted the changes made in revision 129400 and the reported errors
disappeared. Hence added Alan Modra to the cc list.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||amodra at bigpond dot net
   ||dot au


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

[Bug fortran/33817] the version of gdb included with gfortran-windows.exe does not work

[michael dot a dot richmond at nasa dot gov]

--- Comment #2 from michael dot a dot richmond at nasa dot gov  2007-10-19 
15:52 ---
http://gcc.gnu.org/wiki/GFortranBinariesWindows instructs me to "report any
bugs to the [EMAIL PROTECTED] mailing-list".

If I posted in the wrong place, I apologize.


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2007-10-19 15:36 
---
Subject: Bug 32921

Author: rguenth
Date: Fri Oct 19 15:36:05 2007
New Revision: 129491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129491
Log:
2007-10-19  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/33816
PR middle-end/32921
* stor-layout.c (layout_type): Assert that aggregates do not
have their alias sets set.
* alias.c (get_alias_set): Return alias set zero for incomplete
types, return the alias set of the element for incomplete array
types, but do not remember these.

* gfortran.dg/pr32921.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr32921.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33817] the version of gdb included with gfortran-windows.exe does not work

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-19 15:32 ---
gdb is a different project and we don't support binary packages anyways.  You
should report this bug to the person who makes the binary package.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/33814] Failure of gfortran n Mac Mini

[cbas25 at strath dot ac dot uk]

--- Comment #2 from cbas25 at strath dot ac dot uk  2007-10-19 15:25 ---
Thank you for the prompt response

I have taken your suggestion about including "-v" in the command line.
I have compiled the source of the program (strauss.f) with both the g77 nd
gfortran compilers.  Incidently the code has compiled succesfully on linux
systems both 32 bit and 64 bit.

With the added "-v" the results were as follows:

With g77:
Driving: /usr/local/bin/g77 -ffixed-form -ffixed-line-length-132 -fbounds-check
-ffortran-bounds-check -v -w -ff90 -o strauss strauss.f -lfrtbegin -lg2c
Reading specs from /usr/local/lib/gcc/i686-apple-darwin8.8.1/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --enable-languages=f77
Thread model: posix
gcc version 3.4.0
 /usr/local/libexec/gcc/i686-apple-darwin8.8.1/3.4.0/f771 strauss.f -fPIC
-quiet -dumpbase strauss.f -mtune=pentiumpro -auxbase strauss -w -version
-ffixed-form -ffixed-line-length-132 -fbounds-check -ffortran-bounds-check
-ff90 -o /var/tmp//ccT7pus3.s
GNU F77 version 3.4.0 (i686-apple-darwin8.8.1)
compiled by GNU C version 3.4.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -arch i386 -o /var/tmp//ccbScj9o.o /var/tmp//ccT7pus3.s
 /usr/local/libexec/gcc/i686-apple-darwin8.8.1/3.4.0/collect2 -arch i386
-dynamic -w -o strauss -lcrt1.o -lcrt2.o
-L/usr/local/lib/gcc/i686-apple-darwin8.8.1/3.4.0
-L/usr/local/lib/gcc/i686-apple-darwin8.8.1/3.4.0/../../.. /var/tmp//ccbScj9o.o
-lfrtbegin -lg2c -lgcc -lSystem |
 c++filt


With gfortran:
Driving: /usr/local/bin/gfortran -mmacosx-version-min=10.4 -ffixed-form
-ffixed-line-length-132 -fbounds-check -fmax-errors-0 -v -o strauss strauss.f90
-lgfortranbegin -lgfortran -shared-libgcc
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc-4.3-20070810/configure --enable-threads=posix
--enable-languages=fortran
Thread model: posix
gcc version 4.3.0 20070810 (experimental)
 f951 strauss.f90 -fPIC -quiet -dumpbase strauss.f90 -mmacosx-version-min=10.4
-mtune=generic -auxbase strauss -version -ffixed-form -ffixed-line-length-132
-fbounds-check -fmax-errors-0 -fintrinsic-modules-path finclude -o
/var/tmp//ccZtzWga.s
gfortran: error trying to exec 'f951': execvp: No such file or directory


-- 


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

[Bug fortran/33818] [Regression 4.3] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-10-19 15:15 ---
Slightly further reduced test:

subroutine ExportZMX(lu)
  implicit none
  integer :: lu
  interface
function UpperCase(str)
  character(*),intent(in) :: str
  character(len(str)) :: UpperCase ! Rejected
! character(1) :: UpperCase ! Works
end function UpperCase
  end interface
  character, parameter :: UNAME ='X'
  write(lu,'(a)') 'UNIT '//UpperCase(UNAME) ! Rejected
!  write(lu,'(a)') UpperCase(UNAME) ! Works
  entry ExportSEQ(lu)
end


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||


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

[Bug fortran/33818] [Regression 4.3] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-10-19 15:12 ---
It is not in gcc version 4.3.0 20070713.


-- 


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

[Bug fortran/33818] [Regression 4.3] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[tobi at gcc dot gnu dot org]

-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-19 15:10:44
   date||


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

[Bug fortran/33818] New: [Regression 4.3] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[burnus at gcc dot gnu dot org]

Reduced from http://gcc.gnu.org/ml/fortran/2007-10/msg00280.html

The following gives the bogus error:

  write(lu,'(a)') 'UNIT '//UpperCase(UNAME(1))
 1
Error: Variable 'str' is used at (1) before the ENTRY statement in which it is
a parameter

subroutine ExportZMX(lu)
  implicit real(selected_real_kind(15)) (a-h,o-z)
  character(*),parameter :: UNAME(1:1)=(/'XXX'/)
  write(lu,'(a)') 'UNIT '//UpperCase(UNAME(1))
  entry ExportSEQ(lu)
contains
  function UpperCase(str) result(res)
character(*),intent(in) :: str
character(len(str)) res
res=str
  end function
end


-- 
   Summary: [Regression 4.3]  Bogus error "Variable 'str' is used at
(1) before the ENTRY statement"
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/33544] [4.3 only] Warning in TRANSFER intrinsic should be made optional

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2007-10-19 14:10 
---
Fixed.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/33816] gimplification before build_array_type re-set alias set of arrays to zero

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-19 12:52 ---
The gcc.c-torture/execute/20001024-1.c testcase introduced with r37052 no
longer fails without the hack in layout_type.


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2007-10-19 12:27 
---
Subject: Bug 32921

Author: rguenth
Date: Fri Oct 19 12:27:25 2007
New Revision: 129487

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129487
Log:
2007-10-19  Richard Guenther  <[EMAIL PROTECTED]>

Revert
2007-10-19  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/32921
* tree.c (build_array_type): Do not re-layout unbound array
types.

* gfortran.dg/pr32921.f: New testcase.

Removed:
trunk/gcc/testsuite/gfortran.dg/pr32921.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2007-10-19 11:26 
---
Subject: Bug 32921

Author: rguenth
Date: Fri Oct 19 11:25:55 2007
New Revision: 129484

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129484
Log:
2007-10-19  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/32921
* tree.c (build_array_type): Do not re-layout unbound array
types.

* gfortran.dg/pr32921.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr32921.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2007-10-19 10:49 ---
To wit, this kind of change, you can certainly apply it to the 4.2.1 headers
as-is:

Index: random
===
--- random  (revision 129456)
+++ random  (working copy)
@@ -1607,7 +1607,8 @@
 {
  typedef typename __gnu_cxx::__add_unsigned::__type __utype;
- return result_type(__utype(__urng()) % (__max - __min + 1)) + __min;
+ return result_type((__max - __min + 1.0L) * __utype(__urng())
+/ (__urng.max() + 1.0L)) + __min;
}

   template


-- 


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

[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651

[brakiozor at caramail dot com]

--- Comment #5 from brakiozor at caramail dot com  2007-10-19 10:06 ---
yes, one of the way is to pass by an intermediate template type...
(I found it on the web)
but the compiler error could(and should) be fixed

#define TPL_TYPEOF_MUL(A,B) typename typeof_mul::type
#define TYPEOF_MUL(A,B) typeof_mul::type

template 
struct typeof_mul
{
typedef typeof(A()*B()) type;
};

template 
Y operator *(X& x, const Ty& y)
{
Y res(x);
//res *= y;
return res;
}


-- 


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

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-10-19 09:37 ---
Note that our implementation has nothing to do with the Boost one. The problem
happens when the range is big. Anyway, we know our implementation is naive in
this case, we'll look into it.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-19 09:37:59
   date||


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

[Bug libstdc++/33490] parallel v3: std::accumulate assumes iterators have std::iterator_traits declared

[singler at ira dot uka dot de]

--- Comment #4 from singler at ira dot uka dot de  2007-10-19 08:39 ---
There are other places in regular stl_algo.h where
iterator_traits::value_type is assumed, not only for concept checking, but
for actual functionality, e. g. 

  template
_OutputIterator
__unique_copy(_InputIterator __first, _InputIterator __last,
  _OutputIterator __result,
  input_iterator_tag, output_iterator_tag)
{
  // concept requirements -- taken care of in dispatching function
  typename iterator_traits<_InputIterator>::value_type __value = *__first;
  *__result = __value;
  while (++__first != __last)
if (!(__value == *__first))
  {
__value = *__first;
*++__result = __value;
  }
  return ++__result;
}



  template
void
__rotate(_RandomAccessIterator __first,
 _RandomAccessIterator __middle,
 _RandomAccessIterator __last,
 random_access_iterator_tag)
{
  // concept requirements
  __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
  _RandomAccessIterator>)

  if (__first == __middle || __last  == __middle)
return;

  typedef typename iterator_traits<_RandomAccessIterator>::difference_type
_Distance;
  typedef typename iterator_traits<_RandomAccessIterator>::value_type
_ValueType;

  const _Distance __n = __last   - __first;
  const _Distance __k = __middle - __first;
  const _Distance __l = __n - __k;

  if (__k == __l)
{
  std::swap_ranges(__first, __middle, __middle);
  return;
}

  const _Distance __d = std::__gcd(__n, __k);

  for (_Distance __i = 0; __i < __d; __i++)
{
  _ValueType __tmp = _GLIBCXX_MOVE(*__first);
...

  template
_ForwardIterator
stable_partition(_ForwardIterator __first, _ForwardIterator __last,
 _Predicate __pred)
{
  // concept requirements
  __glibcxx_function_requires(_Mutable_ForwardIteratorConcept<
  _ForwardIterator>)
  __glibcxx_function_requires(_UnaryPredicateConcept<_Predicate,
typename iterator_traits<_ForwardIterator>::value_type>)
  __glibcxx_requires_valid_range(__first, __last);

  if (__first == __last)
return __first;
  else
{
  typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType;
  typedef typename iterator_traits<_ForwardIterator>::difference_type
_DistanceType;

  _Temporary_buffer<_ForwardIterator, _ValueType> __buf(__first,
__last);
...

and many more...

-- Johannes


-- 


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

[Bug fortran/33818] [4.3 Regression] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2007-10-20 04:24 ---
Subject: Bug number PR 33818

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/2007-10/msg01188.html


-- 


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

Re: problem with one tree style builds

[Joel Sherrill]

DJ Delorie wrote:

http://sourceware.org/ml/newlib/2006/msg00472.html

Shouldn't this patch already be in the top level
gcc/Makefile.in?



The right fix is to use autoconf 2.60 or later.

  

I am on Fedora 7 with autoconf 2.61 with a checkout from
yesterday off the trunk.  So I shouldn't have see it based
upon that requirement.  What else could it be?

The patch you link to requires GNU make, and thus was rejected.
  

OK.

--joel

[Bug middle-end/32546] [4.3 Regression] 'warning: array subscript is above/below array bounds' on delete[]

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2007-10-19 17:48 ---
I can reproduce this on powerpc64-linux with a compiler from 20070630 but not
with anything after 30070731; can anyone else still reproduce the failure, or
has it been fixed?


-- 


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

[Bug fortran/33817] the version of gdb included with gfortran-windows.exe does not work

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-10-19 17:09 ---
> http://gcc.gnu.org/wiki/GFortranBinariesWindows instructs me to "report any
> bugs to the [EMAIL PROTECTED] mailing-list".
> 
> If I posted in the wrong place, I apologize.

Regarding GDB: You should either contact the packager, FX Coudert
(http://www.coudert.name/index.html.en) or write a bug report to the GDB
project . (Well, for GDB using their mailing list instead of reporting directly
a bug into their tracking system, is probably also the better idea as it might
turn out to be not a GDB problem.)

Asking at the [EMAIL PROTECTED] mailing list is also ok. (FX reads the email 
there as
well and someone else might have an idea. It is slightly besides the primary
scope of the fortran@ mailing list, but as the email volume is low, even more
off-topic emails get answered.)

GCC's Bugzilla, however, is only about bugs which are fixable in GCC - and GDB
is not included in the sources of GCC but a completely disjunct project.


-- 


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

[Bug tree-optimization/33458] [4.3 regression] ICE "PHI def is not a GIMPLE value"

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2007-10-19 16:42 ---
A regression hunt on powerpc-linux identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=126198

r126198 | rguenth | 2007-07-02 11:53:08 + (Mon, 02 Jul 2007)

This results in the ICE reported by the submitter.


-- 

janis 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=33458

[Bug middle-end/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94->1 -6651

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2007-10-19 16:34 ---
A regression hunt using the testcase added for comment #2 on powerpc-linux with
"-O2 -fstack-protector" identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=121780

r121780 | hubicka | 2007-02-09 22:49:30 + (Fri, 09 Feb 2007)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug middle-end/33779] [4.3 Regression] folds unsigned multiplication == 0 to true

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2007-10-19 16:31 ---
A regression hunt for the first testcase on powerpc-linux identified the
following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=120649

r120649 | ian | 2007-01-10 21:07:38 + (Wed, 10 Jan 2007)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at gcc dot gnu dot org


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

[Bug middle-end/33816] gimplification before build_array_type re-set alias set of arrays to zero

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-10-19 16:27 ---
This is now fixed.  Still the world waits for gimplifying after the FE finished
all of its business.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/33816] gimplification before build_array_type re-set alias set of arrays to zero

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-10-19 15:36 ---
Subject: Bug 33816

Author: rguenth
Date: Fri Oct 19 15:36:05 2007
New Revision: 129491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129491
Log:
2007-10-19  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/33816
PR middle-end/32921
* stor-layout.c (layout_type): Assert that aggregates do not
have their alias sets set.
* alias.c (get_alias_set): Return alias set zero for incomplete
types, return the alias set of the element for incomplete array
types, but do not remember these.

* gfortran.dg/pr32921.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr32921.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33818] [Regression 4.3] Bogus error "Variable 'str' is used at (1) before the ENTRY statement"

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-10-19 15:07 ---
The bug is not present in 4.2.2, and appeared before revision 129038.


-- 


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

[Bug middle-end/33816] New: gimplification before build_array_type re-set alias set of arrays to zero

[rguenth at gcc dot gnu dot org]

The testcase from PR32921 shows that we end up with an alias set of zero for
real8[0:] because in both functions this type is used in casts.  When the
first function is gimplified the gimplifier asks if the cast is a useless
type conversion which in turn calls get_alias_set which sets the alias set.
Once the second function is lowered to GIMPLE, the array-type gets re-built
using build_array_type which calls layout_type:

  if (!COMPLETE_TYPE_P (t))
layout_type (t);

[because the type looks incomplete]

which in turn globally re-sets the alias set to zero

  /* If an alias set has been set for this aggregate when it was incomplete,
 force it into alias set 0.
 This is too conservative, but we cannot call record_component_aliases
 here because some frontends still change the aggregates after
 layout_type.  */
  if (AGGREGATE_TYPE_P (type) && TYPE_ALIAS_SET_KNOWN_P (type))
TYPE_ALIAS_SET (type) = 0;
}

causing effectively wrong gimplification of the first function and pessimizatio
of alias analysis.


-- 
   Summary: gimplification before build_array_type re-set alias set
of arrays to zero
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, missed-optimization
  Severity: blocker
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 32921
 nThis:


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

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-10-19 10:46 ---
I'm going to commit to mainline a stop-gap solution. If you could confirm, as I
believe, that it's at least an improvement, we can have it in 4_2-branch too.


-- 


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

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug fortran/31306] ICE with implicit character variables

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2007-10-20 05:45 ---
Subject: Bug number PR31306

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/2007-10/msg01207.html


-- 


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

[Bug tree-optimization/23820] ICE in lambda_loopnest_to_gcc_loopnest, at lambda-code.c:1982

[spop at gcc dot gnu dot org]

--- Comment #12 from spop at gcc dot gnu dot org  2007-10-19 19:02 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

Re: problem with one tree style builds

[Joel Sherrill]

DJ Delorie wrote:

I am on Fedora 7 with autoconf 2.61 with a checkout from
yesterday off the trunk.  So I shouldn't have see it based
upon that requirement.  What else could it be?



Did you re-generate all the configure's from all the configure.ac's?
The ones in CVS are all built with 2.59.
  

No.  Not unless gcc_update does it.

What is the recommended procedure to regenerate them?

Shouldn't they be regenerated and committed in CVS?

--joel

[Bug fortran/33544] [4.3 only] Warning in TRANSFER intrinsic should be made optional

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-10-19 14:06 
---
Subject: Bug 33544

Author: jvdelisle
Date: Fri Oct 19 14:06:05 2007
New Revision: 129488

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

PR fortran/33544
* simplify.c (gfc_simplify_transfer): Only warn for short transfer when
-Wsurprising is given.
* invoke.texi: Document revised behavior.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/simplify.c


-- 


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

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2007-10-19 11:26 ---
Actually, would be:

Index: random
===
--- random  (revision 129456)
+++ random  (working copy)
@@ -1607,7 +1607,8 @@
 {
  typedef typename __gnu_cxx::__add_unsigned::__type __utype;
- return result_type(__utype(__urng()) % (__max - __min + 1)) + __min;
+ return result_type((__max - __min + 1.0L) * __utype(__urng())
+/ (__utype(__urng.max()) + 1.0L)) + __min;
}

   template


-- 


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

[Bug libstdc++/33815] tr1::uniform_int isn't uniform

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-10-19 09:40 ---
Actually, the problem happens only for some specific values of the range, like
eng.max() / 5.5, dividing by 2 or 10 is ok. Indeed, seems a binary arithmetic
problem.


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2007-10-19 12:40 
---
Complete mess.  Can of worms.  Unassigning.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth 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=32921

[Bug bootstrap/33824] New: Improve configuration documentation

[Markus dot Elfring at web dot de]

The configuration option "--enable-languages" is explained in the following
documents.
- "Installing GCC: Configuration"
  http://gcc.gnu.org/install/configure.html

- "Installing all the GCC compilers while building LFS" by Randy McMurchy
 
http://www.linuxfromscratch.org/hints/downloads/files/all_of_gcc_during_lfs.txt

I would appreciate if it will also be mentioned by the script.
... /4.2.2/configure --help | grep enable-languages

Would you like to add any more help descriptions to the script?
http://gcc.gnu.org/viewcvs/trunk/configure.ac?revision=129122&view=markup


-- 
   Summary: Improve configuration documentation
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Markus dot Elfring at web dot de


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2007-10-19 16:28 
---
Actually, the fix for PR33816 might have fixed this.


-- 


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

[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QList and const QList

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-10-19 16:39 ---
The error also occurs on powerpc64-linux with -m64, where a regression hunt
identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=128488

r128488 | jason | 2007-09-14 06:07:25 + (Fri, 14 Sep 2007)


-- 

janis 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=33620