[Bug target/25218] [4.0 Regression] ICE : in compensate_edge, at reg-stack.c:2795

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2006-02-20 07:59 ---
(In reply to comment #4)
> ICE on valid; P1.

Still present with 'gcc version 4.0.3 20060219 (prerelease)':

gcc -c -m32 -O3 test.c
test.c: In function ‘drotmg’:
test.c:20: internal compiler error: in compensate_edge, at reg-stack.c:2795

BTW, is there any way for me to change the 'Last confirmed' field ? Since that
is the purpose of this comment. To add some more info, this is the stack trace
of cc1 that leads to the abort:

#4  0x006714fb in compensate_edge (e=0x2a959776c0, file=0x0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/reg-stack.c:2795
#5  0x00671bff in convert_regs_2 (file=0x0, block=0x0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/reg-stack.c:2865
#6  0x00672186 in reg_to_stack (file=0x0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/reg-stack.c:3086
#7  0x006c2e23 in rest_of_compilation () at
/scratch/vondele/gcc_40_branch/gcc/gcc/passes.c:391
#8  0x00457465 in execute_pass_list (pass=0x9833c0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/tree-optimize.c:526
#9  0x004576db in tree_rest_of_compilation (fndecl=0x2a9595eea0)
at /scratch/vondele/gcc_40_branch/gcc/gcc/tree-optimize.c:661
#10 0x00412ec8 in c_expand_body (fndecl=0x2a9595eea0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/c-decl.c:6613
#11 0x006e9e38 in cgraph_expand_function (node=0x2a959689c0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/cgraphunit.c:835
#12 0x006eac2b in cgraph_optimize () at
/scratch/vondele/gcc_40_branch/gcc/gcc/cgraphunit.c:1708
#13 0x00414ba2 in c_write_global_declarations () at
/scratch/vondele/gcc_40_branch/gcc/gcc/c-decl.c:7613
#14 0x006a9806 in toplev_main (argc=Variable "argc" is not available.
) at /scratch/vondele/gcc_40_branch/gcc/gcc/toplev.c:1023
#15 0x002a95688e5d in __libc_start_main () from /lib64/tls/libc.so.6
#16 0x0040267a in _start () at ../sysdeps/x86_64/elf/start.S:96


-- 


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

[Bug middle-end/19543] [4.1 only] fortran LOGICAL*8 not consistently distinguished from 32 bit integers

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch
  Known to fail||4.1.0 4.2.0
  Known to work||4.2.0
Summary|fortran LOGICAL*8 not   |[4.1 only] fortran LOGICAL*8
   |consistently distinguished  |not consistently
   |from 32 bit integers|distinguished from 32 bit
   ||integers
   Target Milestone|--- |4.1.1


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

[Bug target/26347] hidden weak extern functions fail regardless of existence on alpha/linux

[vapier at gentoo dot org]

--- Comment #3 from vapier at gentoo dot org  2006-02-20 05:43 ---
i originally asked on the binutils lists and was informed it's a gcc bug:
http://sourceware.org/ml/binutils/2006-02/msg00237.html


-- 


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

[Bug tree-optimization/26376] New: K+R style function compiled with -qipa-pta ICEs

[anton at samba dot org]

After seeing -qipa-pta appear, I thought id give it a spin :) Looks like the
test case below fails, but only when using K+R style functions.

$ /home/anton/toolchain/install/bin/gcc -v
Using built-in specs.
Target: powerpc-linux Configured with: /home/anton/toolchain/gcc/gcc/configure
--build=powerpc-linux --host=powerpc-linux --target=powerpc-linux
--enable-targets=powerpc64-linux --enable-languages=c,c++,fortran
--prefix=/home/anton/toolchain/install
Thread model: posix
gcc version 4.2.0 20060220 (experimental)

$ cat foo.c
#if 1
void foo(a)
 void (*a)();
{
(*a)();
}
#else
void foo(void (*a)())
{
(*a)();
}
#endif

$ /home/anton/toolchain/install/bin/gcc -c -O3 -fipa-pta foo.c
foo.c: In function 'foo': foo.c:6: internal compiler error: in
find_func_aliases, at tree-ssa-structalias.c:3321
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: K+R style function compiled with -qipa-pta ICEs
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux


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

[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2006-02-20 05:11 
---
(In reply to comment #15)
> With my reduced testcase (well s/long long/long/), we get:
>   D.1552_8 = -a_7;
> a_7: [0, +INF]  EQUIVALENCES: { } (0 elements)
Shouldn't that just be marked as varying instead as a_7 is unsigned?

Likewise for the orginal testcase in this bug.


-- 


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

[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2006-02-20 05:09 
---
With my reduced testcase (well s/long long/long/), we get:
  D.1552_8 = -a_7;
a_7: [0, +INF]  EQUIVALENCES: { } (0 elements)
D.1552_8: [0, 1]  EQUIVALENCES: { } (0 elements)

on the mainline, while in 4.1.0 we got:
  D.1293_8 = -a_7;
a_7: VARYING
D.1293_8: VARYING


-- 


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

[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2006-02-20 05:00 
---
Also forgot to mention my testcase is indepenent of 64 bitness of the target.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|alphaev68-linux-gnu |
   GCC host triplet|alphaev68-linux-gnu |
 GCC target triplet|alphaev68-linux-gnu |


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

[Bug tree-optimization/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2006-02-20 04:59 
---
I forgot to mention with my reduced non ivopts depending testcase this makes
this indepenent of those two bugs.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |tree-optimization


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2006-02-20 04:58 
---
Here is a testcase independent of IV-OPTs:
void abort(void);
int printf(const char *format, ...);

__attribute__((noinline))
void gen_rtx_CONST_INT(long long x) {
if (-x > 10)
abort();
}
__attribute__((noinline))
int alpha_expand_prologue(long frame_size)
{
unsigned long long a;
int probed;
if (frame_size <= 1)  return;
unsigned long long b = -2;
a = -2;
do {
int a1 = a;
probed = -a1;
printf("probed = %d, frame_size = %ld\n",
   probed, frame_size);
gen_rtx_CONST_INT (a1);
a -= 2;
a1 = -a;
probed = a1;
} while (probed < frame_size);
}

int main(void) {
alpha_expand_prologue(10);
return 0;
}

-

I tried this on 4.1.0 and could not reproduce it there, though my 4.1.0 is from
20060208.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  BugsThisDependsOn|25985, 26304|


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

[Bug c/26367] multiple levels of __builtin_expect

[acahalan at gmail dot com]

--- Comment #4 from acahalan at gmail dot com  2006-02-20 04:11 ---
It's interesting that you say "__builtin_expect gives the same probability on
all targets". I'm not exactly sure what you mean, but I'll guess that you mean
it states that the condition will be true X% of the time.

If so, X should be documented. Also: approximately X% or minimum X%?

BTW, it seems that this X value might not be correct for all architectures. I
guess that would be a different bug though, and the problem may have been fixed
by now.

It would be nice to have more than one level, including at least "100% certain"
and two other levels.


-- 


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

[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5

[roger at eyesopen dot com]

--- Comment #13 from roger at eyesopen dot com  2006-02-20 04:10 ---
Many thanks to Mark, Richard and David!  This is now fixed on both mainline and
the gcc-4_1-branch in time for the 4.1 release.  On mips-sgi-irix6.5, for the
4.1 branch I now see the following (which is much better than before!)
=== gfortran Summary ===
# of expected passes11578
# of unexpected failures18
# of expected failures  12
# of unsupported tests  26


-- 

roger at eyesopen dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/26369] value expectation attribute

[acahalan at gmail dot com]

--- Comment #2 from acahalan at gmail dot com  2006-02-20 04:00 ---
VRP (value range propagation, if I guess right) doesn't always have the data it
needs. Commonly, people split projects into multiple files and do not use
-fwhole-program to compile the project. This seems to be the norm actually.

(Heck, are there _any_ projects using -fwhole-program? Perhaps gcc itself?)

VRP won't do very much to catch errors in the code. I'd like gcc to actually
block assignment of illegal values when it can determine that the problem
exists.


-- 


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[roger at eyesopen dot com]

--- Comment #11 from roger at eyesopen dot com  2006-02-20 03:52 ---
Hmmm.  Looks like the problem is in .088t.vrp2

We have
unsigned int D.1981;
unsigned int D.1982;
D.1982_9 = -D.1981_1;

D.1981_1: [0, +INF]  EQUIVALENCES: { } (0 elements)
D.1982_9: [0, 1]  EQUIVALENCES: { } (0 elements)

Seems like a bug in the interval arithmetic of NEGATE_EXPR for unsigned types.
- [0, (unsigned)-1] seems to be converted to [0, 1]!!?  I hope this helps.


-- 


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

[Bug c/26367] multiple levels of __builtin_expect

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-20 03:51 ---
Oh, did I forgot __builtin_expect gives the same probability on all targets,
just some use it more than others.


-- 


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

[Bug c/26367] multiple levels of __builtin_expect

[acahalan at gmail dot com]

--- Comment #2 from acahalan at gmail dot com  2006-02-20 03:49 ---
I gave two examples. (you may assume I want code to run fast)

I first saw this feature proposed on the linux-kernel mailing list when there
was some argument over whether or not __builtin_expect() should be used in a
particular location. For one architecture it was good (i386 if I remember
right), but for another architecture (ARM if I remember right) it was bad. The
problem is that the behavior change is appropriate at X% likelyhood on one
architecture, and Y% likelyhood on a different architecture. X and Y are not
documented.

So somebody wished that __builtin_expect() would take an argument to specify
probability. I agree.

For each change of compiler behavior (setting an instruction bit, moving code
out of line, making unlikely code as if -Os were specified...) there is an
architecture-specific probability level at which it makes sense.

A more awkward way to expose this would be as a predefined preprocessor symbol
that specifies the architecture-specific likelyhood at which __builtin_expect()
may be useful. It's a bit nicer to just let the programmer give a 3rd argument.


-- 


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

[Bug c/26372] opposite of may_alias attribute

[acahalan at gmail dot com]

--- Comment #4 from acahalan at gmail dot com  2006-02-20 03:29 ---
There have been times when I could not prove to myself that __restrict would be
safe (it may have been), yet I knew that the char pointer would not alias with
non-char pointers.

(sorry to not have a nice chunk of code handy -- I just discovered where to
report gcc bugs and missing features, so I had a backlog of things that have
bothered me over the years)


-- 


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

[Bug c/26371] dead variable attributes

[acahalan at gmail dot com]

--- Comment #2 from acahalan at gmail dot com  2006-02-20 03:18 ---
For variables that are commonly used in a large project, you sure wouldn't want
to be putting conditional code all over the place if you could avoid it. The
choice could be something like:

a. put #if TARGET_WANTS_XXX in 12345 locations
b. put if(TARGET_WANTS_XXX) in 12345 locations
c. just live with lots of bloat
d. make use of this proposed feature in 1 location


-- 


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[roger at eyesopen dot com]

--- Comment #10 from roger at eyesopen dot com  2006-02-20 03:11 ---
Analyzing the code in comment #5, this looks like a bad interaction between
ivopts and vrp.  Either of -fno-ivopts or -fno-tree-vrp cures the problem.
But it looks like the output of .084t.ivopts is reasonable.


-- 

roger at eyesopen dot com changed:

   What|Removed |Added

 CC||roger at eyesopen dot com


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

[Bug target/26347] hidden weak extern functions fail regardless of existence on alpha/linux

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-20 02:26 ---
 /tmp/cco53Air.o: In function `_start': relocation truncated to fit: GPRELHIGH

Are you sure that this is not a binutils bug?


-- 


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

[Bug libgcj/26351] Native Momory Leak in ResourceBundle

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 02:24 ---
Hmm, natStackTrace.cc was removed with:
2005-03-10  Bryce McKinlay  <[EMAIL PROTECTED]>

New Stack Trace infrastructure.


So maybe this has been fixed for 4.1.0.

Also are you sure that it is leaking or just not being free right away?

I get the following behavior on powerpc-darwin on the mainline:
1294336/2060288
868352/2060288
425984/2060288
1650688/2060288
1318912/2060288
884736/2060288
450560/2060288
12288/2060288
1347584/2060288

See how it goes down and then back up?


-- 


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

[Bug c/26367] multiple levels of __builtin_expect

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 02:15 ---
Can you give an example of why you need these builtins?


-- 


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

[Bug debug/26364] [4.0/4.1/4.2 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.3


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

[Bug middle-end/26363] disabling switch() default

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 02:13 ---
I don't see why there needs to be an attribute or even cause that much missed
optimization?  GCC should be able to find that the default is not taken via VRP
but does not currently but that is a different bug that has been filed already.


-- 


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

[Bug c/26370] anon union/struct at top level

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-02-20 02:10 ---
GCC now has theories about extensions, dont' add them.


-- 


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

[Bug c/26369] value expectation attribute

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 02:09 ---
I don't understand why this is useful really as GCC now has VRP which will find
most of this information and remove code which is useless.


-- 


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

[Bug c/26366] __builtin_expect needs better documentation

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-20 02:06 ---
x86 is forgiving because there is no such bit that is used (well except for the
prescott and GCC disables it because it was a wash and used up space).


-- 


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

[Bug c/26372] opposite of may_alias attribute

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-20 02:04 ---
Can you give an example of where this is useful and why not instead improve GCC
for your code gen issues?


-- 


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

[Bug c/26371] dead variable attributes

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 02:02 ---
Can you show an example how to use these variables?  I don't understand why you
cannot use if(TARGET_WANTS_XXX)
instead of #if TARGET_WANTS_XXX.


-- 


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

[Bug middle-end/19543] fortran LOGICAL*8 not consistently distinguished from 32 bit integers

[sayle at gcc dot gnu dot org]

--- Comment #11 from sayle at gcc dot gnu dot org  2006-02-20 00:34 ---
Subject: Bug 19543

Author: sayle
Date: Mon Feb 20 00:34:12 2006
New Revision: 111294

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

PR middle-end/19543
* varasm.c (compare_constant) : Integer constants are
only equivalent if the have both the same mode and precision.

* gfortran.dg/logical_1.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/logical_1.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c


-- 


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

[Bug rtl-optimization/26375] [4.2 Regression] Swing modulo scheduling results in ICE

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-20 00:31 ---
Janis can you do a regression hunt for this bug?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug rtl-optimization/26375] [4.2 Regression] Swing modulo scheduling results in ICE

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-20 00:26 ---
Nothing changed on the tree level with this loop.


-- 


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

[Bug rtl-optimization/26375] [4.2 Regression] Swing modulo scheduling results in ICE

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 00:25 ---
Confirmed, this worked with "4.2.0 20060127" and does not with "4.2.0
20060218".


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|powerpc64-linux |powerpc-*-*
   Last reconfirmed|-00-00 00:00:00 |2006-02-20 00:25:37
   date||
Summary|Swing modulo scheduling |[4.2 Regression] Swing
   |results in ICE  |modulo scheduling results in
   ||ICE
   Target Milestone|--- |4.2.0


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

[Bug tree-optimization/26375] New: Swing modulo scheduling results in ICE

[anton at samba dot org]

I tried using -fmodulo-sched and managed to get an ICE. The test case is based
on some gzip code.

$ ~/toolchain/install/bin/gcc -v
Using built-in specs.
Target: powerpc-linux
Configured with: /home/anton/toolchain/gcc/gcc/configure --build=powerpc-linux
--host=powerpc-linux --target=powerpc-linux --enable-targets=powerpc64-linux
--enable-languages=c,c++,fortran --prefix=/home/anton/toolchain/install
Thread model: posix
gcc version 4.2.0 20060219 (experimental)

$ cat foo.c
unsigned int foo(unsigned int code, int len)
{
unsigned int res = 0;
do {
res |= code & 1;
} while (--len > 0);
return res;
}

$ ~/toolchain/install/bin/gcc -O3 -fmodulo-sched -c foo.c foo.c: In function
'foo':
foo.c:8: internal compiler error: in add_deps_for_def, at ddg.c:243
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

It only ICE's with -m32, -m64 compiles OK.


-- 
   Summary: Swing modulo scheduling results in ICE
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux


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

[Bug c/26370] anon union/struct at top level

[acahalan at gmail dot com]

--- Comment #4 from acahalan at gmail dot com  2006-02-19 23:20 ---
Here is an example of something that is seriously awkward to do in C.

Suppose I want to ensure that several variables end up in the same cache line.
I'd like to do it this way:

struct {
  short s1;
  short s2;
  unsigned offset;
  long long ll;
}__attribute__ ((aligned(32)));

Without anon union support, I have to come up with a useless name. For exactly
the same reasons why people like anon structs within structs, I want an struct
here. It's just plain ugly to prefix every variable usage withsome garbage like
 "u42.".


-- 


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

[Bug c/26370] anon union/struct at top level

[acahalan at gmail dot com]

--- Comment #3 from acahalan at gmail dot com  2006-02-19 23:09 ---
Here is an example of something that fundamentally can not be done in plain C.

Suppose I have a large project with a badly-named global variable. When I
compile with -Wshadow, I get lots of complaints. I'd like to rename the global
incrementally. Renaming the variable in one step is too painful because of the
size of the project, which might involve 3rd-party modules and various
development forks. So I have a mess, and I'd like to rename the variable.

I could put the badly-named variable in a union with a better-named variable.
Then  I change what I can find. Then I use __attribute__((deprecated)) to mark
the old name. After some time has passed, I no longer need the old name.

I can't do this with a #define because that would clobber local variables and
struct members. I might get a conflict.

There may be linker tricks that would work, but dealing with the build system
can be dreadful. (I've seen some build systems that might make you cry.)


-- 


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

[Bug c/26369] value expectation attribute

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/26365] [3.4/4.0/4.1/4.2 Regression] ICE in finish_class_member_access_expr, at cp/typeck.c

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-19 23:06 ---
Reduced testcase:

class Exchange{ };

struct optional
{
  Exchange const* operator-> () const {}
};
namespace pcrxsd {
  template< typename T, typename V> inline T fundamentalBaseCast() {  }
  void setInfo(optional &a)
  {
a->pcrxsd::fundamentalBaseCast
  }
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
   ||4.2.0
  Known to work||3.2.3
   Last reconfirmed|-00-00 00:00:00 |2006-02-19 23:06:29
   date||
Summary|ICE in  |[3.4/4.0/4.1/4.2 Regression]
   |finish_class_member_access_e|ICE in
   |xpr, at cp/typeck.c |finish_class_member_access_e
   ||xpr, at cp/typeck.c
   Target Milestone|--- |4.0.3


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

[Bug c/26370] anon union/struct at top level

[acahalan at gmail dot com]

--- Comment #2 from acahalan at gmail dot com  2006-02-19 23:02 ---
Given that we have anon unions, and given that unions can exist at top level
and function level, this is a very logical extension. It lifts an annoying and
arbitrary restriction.

>From the user's point of view, this doesn't add anything. It removes an
inconsistancy.

You could say that nobody NEEDS anon unions at all, yet they were found useful.
The practice of adding useful-but-not-required stuff started before C was even
called C.


-- 


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[falk at debian dot org]

--- Comment #9 from falk at debian dot org  2006-02-19 22:46 ---
This bug was introduced with:

r75 | law | 2006-02-17 05:15:32 +0100 (Fri, 17 Feb 2006) | 33 lines

* tree-vrp.c (set_value_range_to_nonnegative): New function.
(vrp_expr_computes_nonnegative, ssa_name_nonnegative_p): Likewise.
(ssa_name_nonzero_p): Likewise.
(get_value_range): Return NULL if VRP is not running.
(extract_range_from_expr): Fallback to tree_expr_XXX_p if
VRP routines do not discover a range.
(vrp_finalize): Clear VR_VALUE to indicate VRP is not running.
* tree.h (ssa_name_nonzero_p, ssa_name_nonnegative_p): Prototype.
* fold-const.c (tree_expr_nonzero_p): For SSA_NAMEs, query VRP.
(tree_expr_nonnegative_p): Similarly.
* tree-ssa-dom.c (nonzero_vars, nonzero_vars_stack): Remove.
(restore_nonzero_vars_to_original_value): Remove.
(unsafe_associative_fp_binop): Remove.
(tree_ssa_dominator_optimize): Remove initialization and
finalization of nonzero_vars and nonzero_vars_stack.
(dom_opt_initialize_block): No longer push marker on
nonzero_vars_stack.
(dom_opt_finalize_block): No longer call
restore_nonzero_vars_to_original_value.
(record_equivalences_from_phis): No longer look for
nonzero PHI arguments.
(cprop_into_successor_phis): No longer propagate nonzero
property into PHI arguments.  Lose unused argument.  Caller
updated.
(record_equivalences_from_stmt): No longer record nonzero
values for SSA_NAMEs.
(lookup_avail_expr): No longer use nonzero_vars.

* gcc.dg/tree-ssa/vrp24.c: Update expected output.
* gcc.dg/tree-ssa/vrp26.c: New test.


-- 

falk at debian dot org changed:

   What|Removed |Added

 CC||law at gcc dot gnu dot org


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

[Bug middle-end/26334] [4.1 Regression] ICE in lhd_set_decl_assembler_name

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2006-02-19 22:36 ---
Subject: Bug 26334

Author: jakub
Date: Sun Feb 19 22:36:39 2006
New Revision: 111285

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111285
Log:
PR middle-end/26334
* gcc.dg/20060218-1.c: Moved to...
* gcc.target/i386/20060218-1.c: ... here.  New test.

Added:
branches/redhat/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/20060218-1.c
  - copied unchanged from r111284,
branches/redhat/gcc-4_1-branch/gcc/testsuite/gcc.dg/20060218-1.c
Removed:
branches/redhat/gcc-4_1-branch/gcc/testsuite/gcc.dg/20060218-1.c
Modified:
branches/redhat/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/26374] Compile failure on long double

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-02-19 22:24 ---
(In reply to comment #5)
> hmm, I guess I'm find with resolving this as duplicate to 19779, even though I
> don't understand why this is only an issue on PPC for me..

It is because the long double format used on PPC is IBM's 128bit long double
which is two doubles basicially added together.


-- 


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

[Bug target/26374] Compile failure on long double

[mueller at gcc dot gnu dot org]

--- Comment #5 from mueller at gcc dot gnu dot org  2006-02-19 22:20 ---
hmm, I guess I'm find with resolving this as duplicate to 19779, even though I
don't understand why this is only an issue on PPC for me..


-- 


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

[Bug target/26374] Compile failure on long double

[mueller at gcc dot gnu dot org]

--- Comment #4 from mueller at gcc dot gnu dot org  2006-02-19 22:04 ---
yes, full configure line: 

Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,java --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp
--enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --without-system-libunwind --enable-secureplt
--with-long-double-128 --host=powerpc64-suse-linux


-- 


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

[Bug target/26374] Compile failure on long double

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2006-02-19 22:03 ---
I'm not sure 1.0l/42 is a valid constant initializer.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|19779   |


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

[Bug target/26374] Compile failure on long double

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-19 22:02 ---
Which is PR 19779.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||19779


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

[Bug c/26370] anon union/struct at top level

[falk at debian dot org]

--- Comment #1 from falk at debian dot org  2006-02-19 22:02 ---
In the past, it has been de-facto gcc policy to add only language extensions
that do something that fundamentally cannot be done in ISO C. So it would be
quite unlikely that this would be accepted. In addition to that, I think it's
a horrible idea, creating all kinds of ambiguity headaches for the compiler
maintainers, and making the code unreadable.

If others agree, we can maybe close this bug.


-- 


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

[Bug target/26374] Compile failure on long double

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-19 22:01 ---
This is actually because the middle-end does not constant fold 128bit IBM long
double.  I am assuming you are using -mlong-double-128.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|powerpc-unknown-linux   |
 GCC target triplet||powerpc-*-*
Summary|Compile failure on long |Compile failure on long
   |double  |double


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

[Bug ada/26373] Ada ICE in gnat_to_gnu_entity, at ada/decl.c:289

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2006-02-19 22:01 ---
Confirmed present on 4.0, 4.1, 4.2.

$ gcc -c z.adb
+===GNAT BUG DETECTED==+
| 4.0.2 (i686-pc-linux-gnu) in gnat_to_gnu_entity, at ada/decl.c:287   |
| Error detected at crypto-types-big_numbers.ads:309:41|

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/guerby/work/gcc/version-4.1/configure
--prefix=/home/guerby/work/gcc/install/install-4.1-20060214T231126
--enable-languages=c,ada,c++,fortran,java,treelang,objc --enable-__cxa_atexit
--disable-nls --enable-threads=posix --disable-multilib --enable-checking
Thread model: posix
gcc version 4.1.0 20060214 (prerelease)
$ gcc -c z.adb
+===GNAT BUG DETECTED==+
| 4.1.0 20060214 (prerelease) (i686-pc-linux-gnu) GCC error:   |
| in gnat_to_gnu_entity, at ada/decl.c:289 |
| Error detected at crypto-types-big_numbers.ads:309:41
[crypto-types-elliptic_curves.ads:27:4]|

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/guerby/work/gcc/version-head/configure
--prefix=/home/guerby/work/gcc/install/install-head-20060216T221656
--enable-languages=c,ada,c++,fortran,java,treelang,objc --enable-__cxa_atexit
--disable-nls --enable-threads=posix --disable-multilib --enable-checking
Thread model: posix
gcc version 4.2.0 20060216 (experimental)
$ gcc -c z.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20060216 (experimental) (i686-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/decl.c:289 |
| Error detected at crypto-types-big_numbers.ads:309:41
[crypto-types-elliptic_curves.ads:27:4]|


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i486-pc-linux-gnu   |i686-pc-linux-gnu
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2006-02-19 22:01:20
   date||
Summary|Ada95: error during generic |Ada ICE in
   |instantiation (code=116)|gnat_to_gnu_entity, at
   ||ada/decl.c:289


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

[Bug target/26374] New: Compile failure on long double

[mueller at gcc dot gnu dot org]

=== Cut ===
static const double  coeff[] = { 1.0l/42 };
=== Cut ===

gives: 

testcase.c:1: error: initializer element is not constant
testcase.c:1: error: (near initialization for ‘coeff[0]’)


-- 
   Summary: Compile failure on long double
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
  GCC host triplet: powerpc-unknown-linux


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

[Bug c++/26365] ICE in finish_class_member_access_expr, at cp/typeck.c

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-19 21:48 ---
Reducing (that means I can reproduce this ICE).


-- 


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

[Bug c/26366] __builtin_expect needs better documentation

[acahalan at gmail dot com]

--- Comment #2 from acahalan at gmail dot com  2006-02-19 21:48 ---
Nope, at least if the documentation  at
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html is what you refer to.

It would be good to document how strong the expectation is for each
architecture. Apparently the differences are dramatic.

There are the other issues too. I can't tell from the documentation if it is
useful to do as in my first example. (giving known bits and min/max) Would the
compiler remember what I told it? (if not, it should, but that needs a
different bug number)


-- 


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

[Bug ada/26373] Ada95: error during generic instantiation (code=116)

[crypto at shortie dot inka dot de]

--- Comment #1 from crypto at shortie dot inka dot de  2006-02-19 21:43 
---
Created an attachment (id=10879)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10879&action=view)
This tar archive contains source code to trigger the bug


-- 


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

[Bug c/8268] no compile time array index checking

[mueller at gcc dot gnu dot org]

--- Comment #31 from mueller at gcc dot gnu dot org  2006-02-19 21:42 
---
I see many false positives and negatives with the -Warray-bounds patch. I
haven't closely investigated the false positives yet, but one of the false
negatives is this: 

=== Cut ===
struct bla {

  bla();

  int* foo[3];
};


bla::bla()
{
  foo[3] = 0;
}
=== Cut ===

this one is caught by my patch. 


-- 


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

[Bug c/26372] opposite of may_alias attribute

[acahalan at gmail dot com]

--- Comment #2 from acahalan at gmail dot com  2006-02-19 21:40 ---
No, __restrict is too strong. It also, last I heard, couldn't be applied to a
type.

(if restrict was right, then using it on an int would be redundant)


-- 


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

[Bug ada/26373] New: Ada95: error during generic instantiation (code=116)

[crypto at shortie dot inka dot de]

# gcc -O1 z.adb
+===GNAT BUG DETECTED==+
| 3.3.5 (Debian 1:3.3.5-13) (i486-pc-linux-gnu) Gigi abort, Code=116   |
| Error detected at crypto-types-big_numbers.ads:309:41|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc-3.3 or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| concatenated together with no headers between files. |
+==+

#gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)


-- 
   Summary: Ada95: error during generic instantiation (code=116)
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: crypto at shortie dot inka dot de
 GCC build triplet: i486-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=26373

[Bug libfortran/21303] [4.1 only] L edit descriptor without a width

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|"Positive width required in |[4.1 only] L edit descriptor
   |format string"  |without a width
   Target Milestone|--- |4.1.1


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

[Bug c/26372] opposite of may_alias attribute

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-19 21:31 ---
__restrict it is called.


-- 


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

[Bug libfortran/21303] "Positive width required in format string"

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2006-02-19 21:31 
---
Subject: Bug 21303

Author: fxcoudert
Date: Sun Feb 19 21:31:02 2006
New Revision: 111281

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111281
Log:
PR libfortran/21303

* gfortran.h (notification): New enumeration.
(gfc_notification_std): Prototype for the new function.
* error.c (gfc_notification_std): New function.
* io.c (check_format): Handle the case of a L format descriptor
without a width.

* runtime/error.c (notification_std): New function.
* libgfortran.h (notification): New enumeration.
* io/io.h (notification_std): Prototype for the new function. 
* io/format.c (parse_format_list): Handle the case of a L format
descriptor without a width.

* gcc/testsuite/gfortran.dg/fmt_l.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_l.f90
Modified:
trunk/gcc/fortran/error.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/libgfortran/io/format.c
trunk/libgfortran/io/io.h
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c


-- 


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

[Bug c/26372] New: opposite of may_alias attribute

[acahalan at gmail dot com]

This would be for char of course.

When -fno-strict-aliasing is in effect, the proposed attribute should be able
to reenable strict aliasing for any type.


-- 
   Summary: opposite of may_alias attribute
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug c/26371] New: dead variable attributes

[acahalan at gmail dot com]

A large project may have a configurable build to allow optional features. Fully
eliminating a feature may require #ifdef all over the place, making the code
ugly and unmaintainable. Example: you want an OS kernel to support an embedded
systems build that lacks the normal user ID handling.

If members of a struct could be marked as being useless, then the compiler's
dead code elimination could often take the place of adding #ifdef all over the
place.

Useful attributes would be something like this:

a. readas(x)   When used as an rvalue, you get x.
b. nomem(x)Does not take up space. Address reads as x.
c. writeas(x)  When used as an lvalue, store x.
d. nowrite Don't bother storing to this location.

(you'd never use more than one of the last three)


-- 
   Summary: dead variable attributes
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug c/26370] New: anon union/struct at top level

[acahalan at gmail dot com]

I think an anon union or struct ought to work at top level or in any block.
It's nice for data layout, to reduce cache footprint, page faults, etc.

Here is a silly example:

union {
  int i;
  float f;
};
int foo(arg){
  f = arg;
  return i;
}


-- 
   Summary: anon union/struct at top level
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug c/26369] New: value expectation attribute

[acahalan at gmail dot com]

Something used roughly like this:

unsigned foo __attribute__((
  min(5),  // value will never be below this
  max(0x007fff04),  // value will never be above this
  set(0x0004),  // these bits will always be set
  clear(0xff82),  // these bits will never be set
  likely_min(100),  // the value is rarely below this
  likely_max(12345),  // the value is rarely above this
  likely_set(0x0604),  // these bits are usually set
  likely_clear(0xf032)  // these bits are usually clear
)) = 100;

The idea is that I tell gcc that my variable (or type) is certain or likely to
have various values. This lets me avoid marking up lots and lots of code with
__builtin_expect. I can just mark the variable or type.

A bit of error checking can be done too. It would be invalid to pass a value
that never exceeds 1 to a function whose argument is marked as always having
bit 4 set. The compiler could catch this and halt with an error.


-- 
   Summary: value expectation attribute
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly

[jvdelisle at gcc dot gnu dot org]

--- Comment #20 from jvdelisle at gcc dot gnu dot org  2006-02-19 20:31 
---
Final patch waiting for review/approval:

http://gcc.gnu.org/ml/fortran/2006-02/msg00421.html


-- 


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

[Bug c/26367] New: multiple levels of __builtin_expect

[acahalan at gmail dot com]

My expectation may be:

a. certain (OK if the code crashes when I lie)
b. strong
c. weak

This could be expressed as an optional 3rd argument to state the estimated
probability. Alternately, stuff like __builtin_expect_strongly() could be used.

I'd like to use this to inform gcc that certain bit patterns or value ranges
are impossible. The main hope is that gcc can optimize switch() better by
letting all the can't-happen cases do undefined behavior. Math should be better
too, for example not needing to worry about the sign bit (more instruction
choice, etc.) if I tell gcc that it will never be set.


-- 
   Summary: multiple levels of __builtin_expect
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug c/26366] __builtin_expect needs better documentation

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-19 20:25 ---
I thought the documention said only to use __builtin_expect when you know that
in almost 100% of the time it is going to be true (or false).


-- 


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

[Bug c++/26365] ICE in finish_class_member_access_expr, at cp/typeck.c

[cees at pcraster dot nl]

--- Comment #1 from cees at pcraster dot nl  2006-02-19 20:25 ---
Created an attachment (id=10878)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10878&action=view)
the source giving the ICE

g++ -c calc_astsymbolinfo.ii
gives the ICE,
g++ --version:

g++ (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)


-- 


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

[Bug c/26366] New: __builtin_expect needs better documentation

[acahalan at gmail dot com]

I can't tell if it would be useful to do this:

x = get_x();
__builtin_expect(x&MASK,KNOWNBITS);
__builtin_expect(x<=KNOWNMAX,1);
__builtin_expect(x>=KNOWNMIN,1);
// code which uses x would follow this

Given two booleans that are 2/3 likely, the chance of both is 4/9 likely. So
maybe it is appropriate to do this:

if(__builtin_expect((__builtin_expect(x,1) && __builtin_expect(y,1)), 0))

Yes? No?

Suppose that I am quite certain of how likely something will be, and that I
care deeply about optimization. At what point should I mark my code with
__builtin_expect()? The obvious choice is whenever the liklihood is not exactly
50%, but I hear that this varies by architecture. ARM supposedly uses a very
strong branch prediction bit that forces a major stall when the expectation is
wrong, while x86 is not so punishing. No hint of this is in the documentation.


-- 
   Summary: __builtin_expect needs better documentation
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug debug/26364] [4.1/4.2 regression]: Uninlined function is marked as inlined

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-19 20:18 ---
Next time don't attach a tar ball, please.


-- 


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

[Bug c++/26365] New: ICE in finish_class_member_access_expr, at cp/typeck.c

[cees at pcraster dot nl]

incorrect code gives ICE


-- 
   Summary: ICE in finish_class_member_access_expr, at cp/typeck.c
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cees at pcraster dot nl


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

[Bug fortran/25395] equivalence to common block array broken

[tobi at gcc dot gnu dot org]

--- Comment #1 from tobi at gcc dot gnu dot org  2006-02-19 20:15 ---
Confirmed, I think Paul Thomas is looking into this.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-19 20:15:34
   date||


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

[Bug debug/26364] [4.1/4.2 regression]: Uninlined function is marked as inlined

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2006-02-19 20:15 ---
Created an attachment (id=10877)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10877&action=view)
A testcase

This is the preprocess Linux kernel code for gcc 4.1 and 4.2. There are many
static functions, like pageout, have DWARF2 info like:

<1><9aee>: Abbrev Number: 78 (DW_TAG_subprogram)
 DW_AT_sibling : <9bd1>
 DW_AT_name: (indirect string, offset: 0x44b6): pageout
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 318
 DW_AT_prototyped  : 1
 DW_AT_type: <8df5>
 DW_AT_inline  : 1  (inlined)

where pageout isn't inlined at all. Gcc 3.4.6 generates:

 <1><8eb1>: Abbrev Number: 84 (DW_TAG_subprogram)
 DW_AT_sibling : <8fe0>
 DW_AT_name: (indirect string, offset: 0x4182): pageout
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 295
 DW_AT_prototyped  : 1
 DW_AT_type: <84b0>
 DW_AT_low_pc  : 0x318
 DW_AT_high_pc : 0x3e4
 DW_AT_frame_base  : 1 byte block: 54   (DW_OP_reg4)


-- 


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

[Bug debug/26364] [4.1/4.2 regression]: Uninlined function is marked as inlined

[pinskia at gcc dot gnu dot org]

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


-- 


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

[Bug debug/26364] New: [4.1/4.2 regression]: Uninlined function is marked as inlined

[hjl at lucon dot org]

Gcc 4.1/4.2 generates wrong DWARF info when it fails to inline a static
function.


-- 
   Summary: [4.1/4.2 regression]: Uninlined function is marked as
inlined
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
 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=26364

[Bug c++/26291] [3.4/4.0/4.1/4.2 regression] Invalid ellipsis in operator not diagnosed

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/26334] [4.1 Regression] ICE in lhd_set_decl_assembler_name

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2006-02-19 20:01 ---
Subject: Bug 26334

Author: jakub
Date: Sun Feb 19 20:01:26 2006
New Revision: 111279

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111279
Log:
PR middle-end/26334
* gcc.dg/20060218-1.c: Moved to...
* gcc.target/i386/20060218-1.c: ... here.  New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/20060218-1.c
  - copied unchanged from r111277, trunk/gcc/testsuite/gcc.dg/20060218-1.c
Removed:
trunk/gcc/testsuite/gcc.dg/20060218-1.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/26363] New: disabling switch() default

[acahalan at gmail dot com]

If I have listed every possible case for a switch, there is no need for a
default. The compiler generates this default anyway though, even if I don't
specify it. I'd like a way to eliminate this, such that an unhandled case
becomes undefined behavior that may well involve a crash.

(the same should of course be true if the compiler can determine for itself
that other values are impossible -- this might already work)

Perhaps this could be done via a stronger form of __builtin_expect(), which
would have plenty of other uses. This wouldn't be all that easy to use though.
Better would be something like:

default:
__not_reached;


Another reasonable way would be:

switch __no_default(foo)

That way, a #define could put those keywords together into something like
SWITCH.


NOTE: I set the component to "c" because Bugzilla forced me to choose. I intend
for this to cover all C-like languages, not just C.


-- 
   Summary: disabling switch() default
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com


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

[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2006-02-19 19:50 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-02-19 19:36 ---
This looks more related to PR 26304.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||26304


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

[Bug target/26350] ICE in extract_insn, at recog.c:2084, -fPIC -mlong-double-128

[mmitchel at gcc dot gnu dot org]

--- Comment #10 from mmitchel at gcc dot gnu dot org  2006-02-19 19:31 
---
Subject: Bug 26350

Author: mmitchel
Date: Sun Feb 19 19:31:22 2006
New Revision: 111276

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111276
Log:
PR target/26350
* config/rs6000/rs6000.md (extenddftf2): Force 0.0 to validized
MEM for ABI_V4 pic.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.md


-- 


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

[Bug fortran/20938] Dependency checking fails for equivalences

[paulthomas2 at wanadoo dot fr]

--- Comment #4 from paulthomas2 at wanadoo dot fr  2006-02-19 19:25 ---
Subject: Re:  Dependency checking fails for equivalences

tobi,

>--- Comment #3 from tobi at gcc dot gnu dot org  2006-02-19 18:56 ---
>I might be a little late, given that you already posted a patch which
>completely fixes this issue
>, but I thought of fixing
>this back before we had the in_equivalence attribute, by simply assuming that
>the RHS and the LHS are dependent if both are members of equivalences.  I'm not
>convinced that this pathological case is worth all the effort.  Nevertheless
>I'll review your patch during the next 48 hours.
>  
>
Thanks - I gave thought to the same fix. It has its advantages; like 
avoiding a quadratic term.  However, it will cause temporaries to 
sprout, where none are necessary.

The effort was not that great; similar code exists in match.c that I 
adapted.  I could not quite see how to combine them into one function, 
though.

Paul


-- 


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[falk at debian dot org]

--- Comment #7 from falk at debian dot org  2006-02-19 18:58 ---
not really ice-on-valid-code nor memory-hog, those were only due to miscompiled
xgcc


-- 

falk at debian dot org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code, memory-  |
   |hog |


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

[Bug fortran/20938] Dependency checking fails for equivalences

[tobi at gcc dot gnu dot org]

--- Comment #3 from tobi at gcc dot gnu dot org  2006-02-19 18:56 ---
I might be a little late, given that you already posted a patch which
completely fixes this issue
, but I thought of fixing
this back before we had the in_equivalence attribute, by simply assuming that
the RHS and the LHS are dependent if both are members of equivalences.  I'm not
convinced that this pathological case is worth all the effort.  Nevertheless
I'll review your patch during the next 48 hours.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2006-02-19 18:56 ---
Also fails on AMD64.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-19 18:56:19
   date||


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[falk at debian dot org]

--- Comment #5 from falk at debian dot org  2006-02-19 18:19 ---
The problem apparently comes from using negation on an induction variable,
in a context where widening is needed:

[EMAIL PROTECTED]:/tmp% cat alpha.c
void abort(void);
int printf(const char *format, ...);

__attribute__((noinline))
void gen_rtx_CONST_INT(long x) {
if (-x > 10)
abort();
}

__attribute__((noinline))
int alpha_expand_prologue(long frame_size)
{
int probed;
for (probed = 1; probed < frame_size; probed += 2) {
printf("probed = %d, frame_size = %ld\n",
   probed, frame_size);
gen_rtx_CONST_INT (-probed);
}
}

int main(void) {
alpha_expand_prologue(10);
return 0;
}


[EMAIL PROTECTED]:/tmp% /src/gcc-2006.02.19/build/prev-gcc/xgcc
-B/src/gcc-2006.02.19/build/prev-gcc/ -g -O2 alpha.c && ./a.out 
probed = 1, frame_size = 10
probed = 3, frame_size = 10
probed = 5, frame_size = 10
probed = 7, frame_size = 10
probed = 9, frame_size = 10
probed = 11, frame_size = 10
zsh: abort (core dumped)  ./a.out


[EMAIL PROTECTED]:/tmp% /src/gcc-2006.02.19/build/prev-gcc/xgcc
-B/src/gcc-2006.02.19/build/prev-gcc/ -g -O2 -fno-ivopts alpha.c && ./a.out 
probed = 1, frame_size = 10
probed = 3, frame_size = 10
probed = 5, frame_size = 10
probed = 7, frame_size = 10
probed = 9, frame_size = 10


-- 


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

[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.

[eedelman at gcc dot gnu dot org]

--- Comment #9 from eedelman at gcc dot gnu dot org  2006-02-19 17:23 
---
Subject: Bug 26201

Author: eedelman
Date: Sun Feb 19 17:23:07 2006
New Revision: 111270

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111270
Log:
fortran/
2006-02-19  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/26201
* intrinsic.c (gfc_convert_type_warn): Call
gfc_intrinsic_symbol() on the newly created symbol.

testsuite/
2006-02-19  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/26201
* gfortran.dg/convert_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/convert_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug regression/26355] defining static members of specialized template classes doesn't work

[vz-gcc at zeitlins dot org]

--- Comment #5 from vz-gcc at zeitlins dot org  2006-02-19 16:50 ---
In reply to comment 4: I do realize that adding an initializer fixes the
problem. But what to do if the static member is an object of a class which only
has a default ctor? E.g.

enum V { V1, V2, V3 };

struct Int { Int() : x(0) { } int x; };
template  struct Data { static Int Value; };

template struct Data;
template <> Int Data::Value;

int main() { return Data::Value.x; }


How to fix this example to link?

Note that the above (with or without the explicit instantiation) is just fine
for Intel and Comeau compilers (and g++ < 4 of course) but not g++ 4.


-- 


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

[Bug regression/26355] defining static members of specialized template classes doesn't work

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2006-02-19 16:38 ---
You need to add an initializer to make

template <> int Data::Value;

a definition.  Otherwise it's just an explicit specialization decl.  Or
if you do not want to specialize for V1, use

template  int Data::Value;


-- 


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-02-19 16:30 ---
[11:22] < mellum> The Alpha bootstrap bug seems to be due to
alpha_expand_prologue being miscompiled
[11:23] < mellum> there's a loop
[11:24] < mellum> for (probed = 4096; probed < frame_size; probed += 8192) {
[11:24] < mellum> fprintf(stderr, "probed = %d, frame_size = %ld\n", probed,
frame_size);
[11:24] < mellum> and this gives
[11:24] < mellum> probed = 4096, frame_size = 4112
[11:24] < mellum> probed = 12288, frame_size = 4112
[11:24] < mellum> probed = 20480, frame_size = 4112
[11:24] < mellum> etc so the loop exit isn't taken
[11:24] < mellum> does this look like a known problem?

>From that description, this looks like PR 25985.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|26348   |25985
   Target Milestone|--- |4.2.0


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

[Bug fortran/25089] Contained function and namelist names clash.

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2006-02-19 16:26 ---
Fixed on trunk - ready for 4.1 as soon as it reopens.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/25054] nonconstant bounds array cannot appear in a namelist

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-02-19 16:24 ---
Fixed on trunk - ready for 4.1 just as soon as it reopens.

Paul 


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name, at tree-into-ssa.c:466

[dorit at il dot ibm dot com]

--- Comment #10 from dorit at il dot ibm dot com  2006-02-19 16:10 ---
so maybe if an SFT has may-aliases then new_type_alias should add the
may-aliases of the SFT as may-aliases of the new tag, instead of adding the SFT
as a may-alias of the new tag. ?

There's a comment in new_type_alias that's quite worrying:
"/* The following is based on code in add_stmt_operand to ensure that the
 same defs/uses/vdefs/vuses will be found"
So this code depends on code in add_stmt_operand, that may have changed by
now... 

Related or not, there's another bug in new_type_alias in PR26359.


-- 

dorit at il dot ibm dot com changed:

   What|Removed |Added

 CC||victork at il dot ibm dot
   ||com


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[falk at debian dot org]

--- Comment #3 from falk at debian dot org  2006-02-19 15:57 ---
(In reply to comment #2)
> I wonder if this is related to at all PR 26348.

Probably not, because it already happens without any options (forgot to mention
that).


-- 

falk at debian dot org changed:

   What|Removed |Added

   Target Milestone|4.2.0   |---


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-19 15:38 ---
I wonder if this is related to at all PR 26348.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||26348


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

[Bug bootstrap/26361] [4.2 regression] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code,
   ||memory-hog
Summary|bootstrap failure on Alpha: |[4.2 regression] bootstrap
   |xgcc runs out of memory |failure on Alpha: xgcc runs
   |compiling libiberty/md5.c   |out of memory compiling
   ||libiberty/md5.c
   Target Milestone|--- |4.2.0


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

[Bug bootstrap/26361] bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[falk at debian dot org]

--- Comment #1 from falk at debian dot org  2006-02-19 15:34 ---
Apparently, it is triggered by the attempt to emit a stack probe, as in:

void f(char *p);

void md5_stream(void) {
char buf[4096-15];
f(buf);
}

(doesn't happen with 4096-16, because then no stack probe is needed).


-- 


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

[Bug tree-optimization/26359] [4.2 Regression] Over optimization of loop when using -ftree-vectorize

[dorit at il dot ibm dot com]

--- Comment #2 from dorit at il dot ibm dot com  2006-02-19 15:34 ---
The problem is that during dce the call to is_hidden_global_store returns false
cause the tag is not marked as global/static.

This seems to fix it:

Index: tree-ssa-alias.c
===
*** tree-ssa-alias.c(revision 110911)
--- tree-ssa-alias.c(working copy)
*** new_type_alias (tree ptr, tree var)
*** 2638,2643 
--- 2638,2651 
add_may_alias (tag, al);
}
  }
+ 
+   /* CHECKME:
+   DECL_CONTEXT (tag) = DECL_CONTEXT (var);
+   TREE_PUBLIC  (tag) = TREE_PUBLIC (var);
+   TREE_READONLY (tag) = TREE_READONLY (var);
+   */
+   MTAG_GLOBAL (tag) = DECL_EXTERNAL (var);
+   TREE_STATIC (tag) = TREE_STATIC (var);
  }

but I don't know if it's the right thing to do in the general case.


-- 

dorit at il dot ibm dot com changed:

   What|Removed |Added

 CC||dorit at il dot ibm dot com,
   ||victork at il dot ibm dot
   ||com


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

[Bug fortran/25089] Contained function and namelist names clash.

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2006-02-19 15:24 ---
Subject: Bug 25089

Author: pault
Date: Sun Feb 19 15:24:26 2006
New Revision: 111268

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111268
Log:
2005-02-19  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/25054
* resolve.c (is_non_constant_shape_array): New function.
(resolve_fl_variable): Remove code for the new function and call it.
(resolve_fl_namelist): New function.  Add test for namelist array
with non-constant shape, using is_non_constant_shape_array.
(resolve_symbol): Remove code for resolve_fl_namelist and call it.

PR fortran/25089
* match.c (match_namelist): Increment the refs field of an accepted
namelist object symbol.
* resolve.c (resolve_fl_namelist): Test namelist objects for a conflict
with contained or module procedures.

2005-02-19  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/25054
* gfortran.dg/namelist_5.f90: New test.

PR fortran/25089
* gfortran.dg/namelist_4.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_4.f90
trunk/gcc/testsuite/gfortran.dg/namelist_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25054] nonconstant bounds array cannot appear in a namelist

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-02-19 15:24 ---
Subject: Bug 25054

Author: pault
Date: Sun Feb 19 15:24:26 2006
New Revision: 111268

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111268
Log:
2005-02-19  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/25054
* resolve.c (is_non_constant_shape_array): New function.
(resolve_fl_variable): Remove code for the new function and call it.
(resolve_fl_namelist): New function.  Add test for namelist array
with non-constant shape, using is_non_constant_shape_array.
(resolve_symbol): Remove code for resolve_fl_namelist and call it.

PR fortran/25089
* match.c (match_namelist): Increment the refs field of an accepted
namelist object symbol.
* resolve.c (resolve_fl_namelist): Test namelist objects for a conflict
with contained or module procedures.

2005-02-19  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/25054
* gfortran.dg/namelist_5.f90: New test.

PR fortran/25089
* gfortran.dg/namelist_4.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_4.f90
trunk/gcc/testsuite/gfortran.dg/namelist_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/26362] New: ICE on the autovect-branch (gfortran example)

[magnus_os at yahoo dot se]

gfortran-autovect -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/autovect
--program-suffix=-autovect --enable-threads=posix
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0-autovect 20060214 (experimental)


gfortran-autovect -O3 -Wunused -fautomatic -mfpmath=sse -msse -mmmx -msse2
-ftree-vectorize -ftree-vectorizer-verbose=2 -c xyz1.for xyz1.for: In function
‘xyz1’:
xyz1.for:1: internal compiler error: in make_ssa_name, at tree-ssanames.c:129
Please submit a full bug report,


  SUBROUTINE XYZ1
C
  IMPLICIT DOUBLE PRECISION ( A - H, O - Z ), INTEGER ( I - N )
C
  COMMON /ABC/ MMSAD( 250 ), MCAI( 500 )
C
  DIMENSION JTMP( 750 ), KTMP( 750 )
  DIMENSION MTMP( 750 ), LTMP(750)
C
  IF ( IJK .LT. KJI )  THEN
 DO 500 JKL = 1, ILS
IF ( MTMP(JKL) .LT. 0 ) THEN
   IJK = IJK + 1
   MTMP(JKL) = IJK
END IF
 500 CONTINUE
C
 MMS = 0
 DO 1000 JKL = 1, ILS
MMS = MMS + 2
JTMP(JKL) = MMSAD(JKL)
KTMP(JKL) = MCAI(MMS-1)
LTMP(JKL) = MCAI( MMS )
 1000CONTINUE
C
 DO 9000 JKL = 1, ILS
KF1 = MTMP(JKL)
MMS = KF1 + KF1
MMSAD(KF1)  = JTMP(JKL)
MCAI(MMS-1) = KTMP(JKL)
MCAI( MMS ) = LTMP(JKL)
 9000CONTINUE
C
  END IF
C
  RETURN
  END


-- 
   Summary: ICE on the autovect-branch (gfortran example)
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: magnus_os at yahoo dot se


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

[Bug bootstrap/26361] New: bootstrap failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c

[falk at debian dot org]

% ../configure --enable-languages=c && nice make bootstrap
[...]
/src/gcc-2006.02.19/build/./prev-gcc/xgcc
-B/src/gcc-2006.02.19/build/./prev-gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../libiberty/../include  -W -Wall -pedantic -Wwrite-strings
-Wstrict-prototypes -Wc++-compat ../../libiberty/md5.c -o md5.o
virtual memory exhausted: Cannot allocate memory
make[3]: *** [md5.o] Error 1
make[3]: Leaving directory `/src/gcc-2006.02.19/build/libiberty'

see also log at
http://buildd.debian.org/fetch.php?pkg=gcc-snapshot&arch=alpha&ver=20060218-2&stamp=1140318890&file=log

must have been introduced between 2006-02-01 and 2006-02-18


-- 
   Summary: bootstrap failure on Alpha: xgcc runs out of memory
compiling libiberty/md5.c
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
 GCC build triplet: alphaev68-linux-gnu
  GCC host triplet: alphaev68-linux-gnu
GCC target triplet: alphaev68-linux-gnu


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