[Bug fortran/32315] DATA with implied-do: Bounds checks missing

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-06-14 06:43 ---
Using
data ( string(i) ,i=-3,1 ) / &
'A', 'B', 'C', 'D', 'E' /
gives even an ICE.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code


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

[Bug fortran/32331] New: Better error message for variable bond of DATA implied do

[burnus at gcc dot gnu dot org]

subroutine test(n)
character(len=20), dimension(n) :: string
data ( string(i) ,i=1,n ) / &
'A', 'B', 'C', 'D', 'E' /
end subroutine

gives currently:
data ( string(i) ,i=1,n ) / &
 1
Error: iterator end at (1) does not simplify

which is unclear, how about something like:

ifort: Error: x.f90, line 3: This symbol must be a defined parameter or an
argument of an inquiry function that evaluates to a compile-time constant.  
[N]
or
NAG f95: Error: Static array STRING cannot have variable bounds


-- 
   Summary: Better error message for variable bond of DATA implied
do
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  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=32331

[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

[spark at gcc dot gnu dot org]

--- Comment #11 from spark at gcc dot gnu dot org  2007-06-14 03:53 ---
(In reply to comment #10)
> Subject: Re:  [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> 
> > It's my turn to ask: so what information does hppa_can_use_return_p
> > need to make the decision ?
> 
> We need to know that the return pointer (r2) is not used and that
> the function is a leaf function (i.e., that the incoming value in
> r2 is unchanged).  Calls clobber r2.
> 
> Dave

Sounds like the following patch would work:

diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
 {
   return (reload_completed
  && (compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- && df_hard_reg_used_count (2) == 1
+ && DF_REG_DEF_COUNT (2) == 0
  && ! frame_pointer_needed);
 }


This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).


-- 


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

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

[dannysmith at users dot sourceforge dot net]

--- Comment #50 from dannysmith at users dot sourceforge dot net  
2007-06-14 03:21 ---
(In reply to comment #37)
> I think basically you are messed up untill Cygwin switches to dwarf2
> exceptions.
> 
This is now (=gcc 4.3) possible by adding --disable-sjlj-exceptions to
configure.
Can we close with milestone gcc-4.3.0?
Danny


-- 


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

[Bug other/32330] New: Inconsistent DFP round/exception fuctions

[hjl at lucon dot org]

gcc/testsuite/gcc.dg/dfp/dfp-except.h has

extern void __dfp_clear_except (int);
#define DFP_CLEAR_EXCEPT(M) __dfp_clear_except(M)
extern int __dfp_test_except (int);
#define DFP_TEST_EXCEPT(M) __dfp_test_except(M)

However, libdecnumber/decExcept.h has

void __dfp_clear_except (void);
int __dfp_test_except (int);
void __dfp_raise_except (int);

They don't argee.

Also,libdecnumber/decRound.h has

extern void __dfp_set_round (int);
extern int __dfp_get_round (void);

Shouldn't DFP implement something similar to the ones in ,
except with __dfp_ prefix?


-- 
   Summary: Inconsistent DFP round/exception fuctions
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pinskia at gmail dot com]

--- Comment #7 from pinskia at gmail dot com  2007-06-14 02:56 ---
Subject: Re:  Thread race segfault in std::string::append with -O and -s

> bug 21334 seems to deal with multiple threads accessing the same shared object
> at the same time.  However, the sample code provided here involves separate
> private objects so there should not be any such issues.  If it is not possible
> to assume that separate threads can access unrelated STL objects at the same
> time, then this would imply that all STL operations (regardless of the object)
> must be serialized!

The empty string is the same object really.

-- Pinski


-- 


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

Re: [Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[Andrew Pinski]

bug 21334 seems to deal with multiple threads accessing the same shared object
at the same time.  However, the sample code provided here involves separate
private objects so there should not be any such issues.  If it is not possible
to assume that separate threads can access unrelated STL objects at the same
time, then this would imply that all STL operations (regardless of the object)
must be serialized!


The empty string is the same object really.

-- Pinski

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[jlawson-gcc at bovine dot net]

--- Comment #6 from jlawson-gcc at bovine dot net  2007-06-14 02:42 ---
bug 21334 seems to deal with multiple threads accessing the same shared object
at the same time.  However, the sample code provided here involves separate
private objects so there should not be any such issues.  If it is not possible
to assume that separate threads can access unrelated STL objects at the same
time, then this would imply that all STL operations (regardless of the object)
must be serialized!


-- 


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

[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2007-06-14 02:16 ---
This was fixed by:
2007-06-12  Seongbae Park  <[EMAIL PROTECTED]>
   * gcse.c (cpro_jump): Don't emit barrier in cfglayout mode.

As the barrier was being created by gcse (before the merge of df branch). 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/32322] pointers to overloaded methods not correctly resolved

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-14 01:30 ---
Can you provide the preprocessed source?


-- 


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

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pinskia at gcc dot gnu dot org]

--- Comment #41 from pinskia at gcc dot gnu dot org  2007-06-14 01:27 
---
*** Bug 32261 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||appfault at hotmail dot com


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-14 01:27 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gmail dot com]

--- Comment #18 from pinskia at gmail dot com  2007-06-14 01:14 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

On 14 Jun 2007 01:09:16 -, dougkwan at google dot com
<[EMAIL PROTECTED]> wrote:
> Unless the compiler can prove that f() does not save the pointer to c
> and use it later, it cannot share a stack slot for c & c1. This is
> true regardless of any block scoping in the source. Yeah, it looks
> like accessing c outside of the first block was undefined but I was
> told me that GIMPLE promote c & c1 all the function scope.

Yes but I don't think GIMPLE does that, it might promote register
based ones but not addressable ones (as mentioned before).

Really if we change the stack sharing, we are going to cause a large
number of regressions, I already have some regressions between 4.0 and
4.1 due to stack sharing changes with two large structs not being in
the same slot even though we can put them there with one having an
offset.
And yes I still need to file that bug.

-- Pinski


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #17 from dougkwan at google dot com  2007-06-14 01:09 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

Unless the compiler can prove that f() does not save the pointer to c
and use it later, it cannot share a stack slot for c & c1. This is
true regardless of any block scoping in the source. Yeah, it looks
like accessing c outside of the first block was undefined but I was
told me that GIMPLE promote c & c1 all the function scope.

-Doug

14 Jun 2007 01:02:48 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]>:
>
>
> --- Comment #16 from pinskia at gcc dot gnu dot org  2007-06-14 01:02 
> ---
> The problem is that it needs also source style scoping also:
> take:
> int f(int *a);
> int g(int b)
> {
>   {
> int c;
> f(&c);
>   }
>   {
> int c1;
> f(&c1);
>   }
> }
>
> Without source based ones, we don't know if c/c1 can ever be shared.
> I have code here at Sony where we actually depend on this behavior with large
> structs (and arrays).
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2007-06-14 01:02 
---
The problem is that it needs also source style scoping also:
take:
int f(int *a);
int g(int b)
{
  {
int c;
f(&c);
  }
  {
int c1;
f(&c1);
  }
}

Without source based ones, we don't know if c/c1 can ever be shared.
I have code here at Sony where we actually depend on this behavior with large
structs (and arrays).


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #15 from dougkwan at google dot com  2007-06-14 00:59 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

Then the stack local sharing code is very broken. It should do a real
live-range analysis instead of using block scoping information form
the source tree.

-Doug

14 Jun 2007 00:52:45 -, pinskia at gmail dot com
<[EMAIL PROTECTED]>:

> It can't because the debugging information will be messed up.
>


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gmail dot com]

--- Comment #14 from pinskia at gmail dot com  2007-06-14 00:52 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

On 14 Jun 2007 00:46:28 -, dougkwan at google dot com
<[EMAIL PROTECTED]> wrote:
> Yes, I saw the code there yesterday and I was wondering if the block
> scope got fixed up somehow.

It can't because the debugging information will be messed up.

-- Pinski


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #13 from dougkwan at google dot com  2007-06-14 00:46 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

Yes, I saw the code there yesterday and I was wondering if the block
scope got fixed up somehow.

14 Jun 2007 00:42:23 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]>:
>
>
> --- Comment #11 from pinskia at gcc dot gnu dot org  2007-06-14 00:42 
> ---
> Look at the code in cfgexpand.c, expand_used_vars, this looks at the source
> blocks.


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2007-06-14 00:42 
---
This code has been there since 4.0.0 so this has been true since then.


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2007-06-14 00:42 
---
Look at the code in cfgexpand.c, expand_used_vars, this looks at the source
blocks.


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #10 from dougkwan at google dot com  2007-06-14 00:35 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

Talked to Dan Berlin and Diego Novillo here at Google. They told me
that all locals are promoted to function scope.

In generally, the tree passes can do abitrary transformation like
hoisting or loop invariant motion that can move a variable out of its
original block scope.

If we keep the scopes around. There must be code to fix up all block
scoping information before the tree passes end. It may be just a
matter to find why the scope of dest is not fixed up properly.

14 Jun 2007 00:28:27 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]>:

>
> Who said that?  We keep around the scopes, how else do we get stack sharing in
> the first place?  Also you cannot turn off stack sharing because that would
> cause some programs no longer to be useful (LLVM is one, the stack would just
> blow up).
>


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2007-06-14 00:28 ---
(In reply to comment #8)
> Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
> code
> 
> I thought like you do initially. But then I was told that in gimple
> everything is promoted to function scope. So dest is not out of scope.

Who said that?  We keep around the scopes, how else do we get stack sharing in
the first place?  Also you cannot turn off stack sharing because that would
cause some programs no longer to be useful (LLVM is one, the stack would just
blow up).


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #8 from dougkwan at google dot com  2007-06-14 00:14 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

I thought like you do initially. But then I was told that in gimple
everything is promoted to function scope. So dest is not out of scope.

-Doug

13 Jun 2007 21:53:15 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]>:
>
>
> --- Comment #7 from pinskia at gcc dot gnu dot org  2007-06-13 21:53 
> ---

> Is that really true?  The underlying issue is sinking the store is causing the
> variables to in the same "scope".  I think that is the real underlying issue
> and nothing to do with local stack sharing.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug c/32329] Use of option "-fwhole-program" needs to exclude option "-c" in spec file

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-13 23:50 ---
Read the documentation, use `externally_visible' as the docs say to.

There is nothing here really except you did not read the docs at all, even
though you quoted them :).


-- 

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

[Bug c/32329] New: Use of option "-fwhole-program" needs to exclude option "-c" in spec file

[rob1weld at aol dot com]

The bug report is about the use of the option "-fwhole-program".


When I compiled a program (crlibm-0.18beta1.tar.gz , described in bug report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180 ) I found that GCC 4.2.0 with 
option "-O2" produced code that was _slightly_ faster than GCC 4.3.0 with 
option "-O3" (on this _one_ particular program).

I set out to make GCC 4.3.0 produce better results and read the info file for
gcc. I added a huge list of options intending to whittle them down a few at a
time. I did eventually get a huge speedup, but this bug report is not about
benchmarking.


This is about the option "-fwhole-program". I had it on the huge list and it
caused problems. The docs for "-fwhole-program" say this:

`-fwhole-program'
 Assume that the current compilation unit represents whole program
 being compiled.  All public functions and variables with the
 exception of `main' and those merged by attribute
 `externally_visible' become static functions and in a affect gets
 more aggressively optimized by interprocedural optimizers.  While
 this option is equivalent to proper use of `static' keyword for
 programs consisting of single file, in combination with option
 `--combine' this flag can be used to compile most of smaller scale
 C programs since the functions and variables become local for the
 whole combined compilation unit, not for the single source file
 itself.


Problem:

Using "-fwhole-program" to compile "C" files that are then archived into a
library produces a library without any functions to call.


/usr/test/bin/gcc -O0 -std=c89  -g -fgcse-sm -fgcse-las -fgcse-after-reload
-fsee -ftree-loop-linear -ftree-loop-im -fivopts -ftree-vectorize -ftracer
-fvariable-expansion-in-unroller -fweb -fwhole-program -ffast-math
-finline-limit=2400 -fmodulo-sched -Winline -march=athlon-xp -fgnu89-inline
-finline-functions-o crlibm_testval  test_val.o test_common.o
../libcrlibm.a -lmpfr -lmpfr -lgmp -lgmp -lm 
test_val.o: In function `main':
/root/downloads/crlibm/tests/test_val.c:114: undefined reference to
`crlibm_init'
test_common.o: In function `rand_for_pow_perf':
/root/downloads/crlibm/tests/test_common.c:326: undefined reference to `log_rn'
/root/downloads/crlibm/tests/test_common.c:327: undefined reference to `log_rn'
test_common.o: In function `test_init':
/root/downloads/crlibm/tests/test_common.c:604: undefined reference to `exp_ru'
/root/downloads/crlibm/tests/test_common.c:606: undefined reference to `exp_rd'
...


Would we need to specify every single file in the library PLUS the final file
we would link to the library to produce an executable using "-fwhole-program" ?

Another way of saying that is _IF_ you use "-fwhole-program" you can not use
the "-c" option since you must link everything. 



Example:

Yes:
gcc "-fwhole-program" file_1.c file_2.c file_3.c file_4.c -o result


No:
gcc "-fwhole-program" -c file_1.c file_2.c 
gcc "-fwhole-program" -c file_3.c file_4.c
ar cru library.a file_1.o file_2.o file_3.o file_4.o 
gcc "-fwhole-program" file_5.c -o result -lrary
file_1.c:000: undefined reference to `xyz'
...



If there are circumstances where it can NOT be used it should be documented.
The docs say it can be used on multiple files.

If "-fwhole-program" and "-c" can not be used together the "spec" file should
make the options mutually exclusive.


The "-fwhole-program" option _could_ be used for libraries if it respected
a tag like "extern" that meant that the function would be called from outside
the current compilation unit. 

A new GNU extension is needed, something like "antistatic" or "declare" to
tell the "-fwhole-program" option to leave the ABI alone and work on everything
else. Here is a puny example:


void usage(){
  fprintf (stderr, "\nUsage: [-v] file\n");
  exit (EXIT_SUCCESS);
}

char* do_something(FILE* f, char* line) {
}

antistatic void ABI_check_program(int x) {
  if (x) 
usage();
  else 
do_something("test", 3);
}


If we compiled the above example with the proposed GNU extension and
used "-fwhole-program" as an option to gcc then the only visible
function would be ABI_check_program(), the rest would disappear.

That would allow "-fwhole-program" to have more uses (libraries or sections of
programs not intended to interact with each other _except_ through a common
file). It could be used to "protect" libraries from people looking in the .h
file and going around the ABI to make direct calls (possibly inadvertantly due
to similar spelling).


-- 
   Summary: Use of option "-fwhole-program" needs to exclude option
"-c" in spec file
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com


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

[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c

[rob1weld at aol dot com]

--- Comment #15 from rob1weld at aol dot com  2007-06-13 23:39 ---
>Can you provide a working patch?

Soon. I am trying to fix the math inaccurcy in GCC 4.3.0 and merge a a new math
library. You can try sticking that oneliner into your configure if your in a
rush.


-- 


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

[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code

[tdragon at tdragon dot net]

--- Comment #5 from tdragon at tdragon dot net  2007-06-13 22:47 ---
Is it possible that an optimization enabled by -O2 *assumes* that hashitem()
will conform with strict aliasing by not dereferencing that argument, and thus
optimizes those lines away? (Not the case.) If this is what is happening and is
the correct behavior, then this is in fact user error and I'm sorry to have
wasted your time.


-- 


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

[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code

[tdragon at tdragon dot net]

--- Comment #4 from tdragon at tdragon dot net  2007-06-13 22:36 ---
(In reply to comment #2)
> Though we could have an alias violation if you don't cast back in hashitem to
> the correct type of the argument.
hashitem() uses the type as punned to HASHDATA* (where HASHDATA is a struct
with a single member of type char*). However, by implementation hashitem() will
never assign a new address that doesn't point to the same type as what was
passed -- in this case, it will only ever assign another BINDING*.


-- 


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

[Bug c++/31903] [4.3 Regression] typeinfo of classes in anon namespace isn't being marked static

[geoffk at gcc dot gnu dot org]

--- Comment #10 from geoffk at gcc dot gnu dot org  2007-06-13 22:31 ---
I think this problem is limited to just typeinfo.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |geoffk at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-05-12 14:30:49 |2007-06-13 22:31:14
   date||
Summary|[4.3 Regression] unwanted   |[4.3 Regression] typeinfo of
   |anonymous namespacing   |classes in anon namespace
   |linkage |isn't being marked static


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

[Bug tree-optimization/32328] 4.2.0: -O2 causes skipped code

[tdragon at tdragon dot net]

--- Comment #3 from tdragon at tdragon dot net  2007-06-13 22:27 ---
(In reply to comment #2)
> Do you mean the last two stores to b:
>  b->time = time;
>  b->progress = found ? 4 : 2;
Yes, those two lines are the ones that are wrongly skipped.


-- 


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

[Bug rtl-optimization/32328] 4.2.0: -O2 causes skipped code

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-06-13 22:21 ---
Do you mean the last two stores to b:
 b->time = time;
 b->progress = found ? 4 : 2;

Though we could have an alias violation if you don't cast back in hashitem to
the correct type of the argument.  This is still a bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||alias, wrong-code
  Known to fail||4.2.0 4.3.0
   Target Milestone|--- |4.2.1


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

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

[echristo at apple dot com]

--- Comment #7 from echristo at apple dot com  2007-06-13 22:16 ---
Um. Right. :)

The new version is fine if it works.


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2007-06-13 21:53 ---
(In reply to comment #6)
> Fixing alias analysis in 4.2.0 will make this problem go away but it
> does not change the underlying issue in the stack local sharing code.

Is that really true?  The underlying issue is sinking the store is causing the
variables to in the same "scope".  I think that is the real underlying issue
and nothing to do with local stack sharing.


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #6 from dougkwan at google dot com  2007-06-13 21:50 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

Fixing alias analysis in 4.2.0 will make this problem go away but it
does not change the underlying issue in the stack local sharing code.

13 Jun 2007 21:42:01 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]>:
>
>
> --- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-13 21:42 
> ---
> (In reply to comment #2)
> > The address of dest has been passed to memcpy() and the alias analysis
> > considers the varaible to escape. So potentially foo() can see the value of
> > dest if memcpy() stash the pointer somewhere. This is impossible but the
> > compiler cannot prove this so it has to be conservative and treat foo() as a
> > potential reader of dest.
> We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have
> changed it (dest) to be non ADDRESSABLE but it is not for some reason.
>
> I think may_alias is messed up in 4.2.0.  Also sink maybe should not be 
> sinking
> stores.
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
>What|Removed |Added
> 
>   Known to work|4.3.0   |4.3.0 4.1.1
> Summary|Incorrect stack sharing |[4.2 Regression] Incorrect
>|causing removal of live code|stack sharing causing
>||removal of live code
>Target Milestone|--- |4.2.1
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-13 21:42 ---
(In reply to comment #2)
> The address of dest has been passed to memcpy() and the alias analysis
> considers the varaible to escape. So potentially foo() can see the value of
> dest if memcpy() stash the pointer somewhere. This is impossible but the
> compiler cannot prove this so it has to be conservative and treat foo() as a
> potential reader of dest.
We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have
changed it (dest) to be non ADDRESSABLE but it is not for some reason.

I think may_alias is messed up in 4.2.0.  Also sink maybe should not be sinking
stores.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.3.0   |4.3.0 4.1.1
Summary|Incorrect stack sharing |[4.2 Regression] Incorrect
   |causing removal of live code|stack sharing causing
   ||removal of live code
   Target Milestone|--- |4.2.1


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

[Bug middle-end/32327] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-13 21:37 ---
On the trunk, dest is changed to be non addressable in alias5, why is it not
doing it in 4.2?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.0
  Known to work||4.3.0


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

[Bug middle-end/32327] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-06-13 21:32 ---
No, it should be marked as non escaping later on.


-- 


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

[Bug middle-end/32327] Incorrect stack sharing causing removal of live code

[dougkwan at google dot com]

--- Comment #2 from dougkwan at google dot com  2007-06-13 21:25 ---
The address of dest has been passed to memcpy() and the alias analysis
considers the varaible to escape. So potentially foo() can see the value of
dest if memcpy() stash the pointer somewhere. This is impossible but the
compiler cannot prove this so it has to be conservative and treat foo() as a
potential reader of dest.


-- 


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

[Bug middle-end/32327] Incorrect stack sharing causing removal of live code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-13 21:20 ---
Why is the store to dest not being removed?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c   |middle-end
   Keywords||wrong-code


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

[Bug c/32328] 4.2.0: -O2 causes skipped code

[tdragon at tdragon dot net]

--- Comment #1 from tdragon at tdragon dot net  2007-06-13 21:19 ---
Created an attachment (id=13701)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13701&action=view)
Preprocessed example source


-- 


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

[Bug c/32328] New: 4.2.0: -O2 causes skipped code

[tdragon at tdragon dot net]

When the attached file is compiled with a mingw32 build of GCC 4.2.0 using the
-O2 option (gcc -O2 -c timestamp2.i), lines 159 and 160 are never executed when
running the program that uses this file. Since the hashitem function modifies
the variable b which is passed to it by-address, leaving those statements out
is definitely not a valid optimization. Compiling without -O2 (gcc -c
timestamp2.i) gives the correct result. Sorry I can't read assembler, or I'd
try to narrow things down more.

This is a regression from 4.1.2, which works correctly with or without -O2. If
it helps, the GCC binaries I use (and sources) can be downloaded at
http://hosted.filefront.com/tldragon7.


-- 
   Summary: 4.2.0: -O2 causes skipped code
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdragon at tdragon dot net
 GCC build triplet: i386-pc-mingw32
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


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

[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert 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-06-13 20:54:10
   date||
Summary|Accepts invalid |Accepts invalid
   |character(len(a)),dimension(|character(len(a)),dimension(
   |1) :: a |1) :: a


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

[Bug fortran/32179] Ensure that ss->string_length is always set [TODO item]

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert 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-06-13 20:52:58
   date||


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

[Bug fortran/32315] DATA with implied-do: Bounds checks missing

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||27766
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:51:44
   date||


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

[Bug fortran/32317] [bounds checking] No warning on bad arguments with explicit interface

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||27766
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-unknown-linux-gnu|
   Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:51:01
   date||
Summary|No warning on bad arguments |[bounds checking] No warning
   |with explicit interface |on bad arguments with
   ||explicit interface


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

[Bug fortran/32289] mips version of gfortran produces internal compiler error

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-06-13 20:49 
---
(In reply to comment #9)
> I don't see the point of these questions though.  After all, I confirmed your
> bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3.  So the remaining
> question is whether this will be fixed in 4.1 (which I doubt).

No, this will not be fixed. Thanks for the bugreport anyway, Michael, and I
hope you can get your GCC-4.3 build working. (If you need technical help doing
so, you can ask on the [EMAIL PROTECTED] mailing-list.)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  GCC build triplet||mips-linux
   GCC host triplet||mips-linux
 GCC target triplet||mips-linux
   Keywords||ice-on-valid-code
  Known to fail||4.1.2
  Known to work||4.2.1 4.3.0
 Resolution||WONTFIX


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

[Bug fortran/32155] Unresolved external __gfortran_os_error in program that manipulates strings

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-06-13 20:45 
---
Hard to tell what is going wrong. I've been building and using compilers on
i386-darwin with no problem. Please contact the people behind HPC MacOS X to
see if they can help you using this compiler, or download our own
(http://gcc.gnu.org/wiki/GFortranBinaries#MacOS)

If you find indication that the bug is indeed with GCC itself, or can reproduce
it on your system using a freshly built compiler, please reopen this PR or file
a new one.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug fortran/32203] Support the vendor intrinsic function TIMEF

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert 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-06-13 20:41:20
   date||
Summary|Support the vendor intrinsic|Support the vendor intrinsic
   |function  timef()   |function TIMEF


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

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

[daney at gcc dot gnu dot org]

--- Comment #6 from daney at gcc dot gnu dot org  2007-06-13 20:39 ---
Created an attachment (id=13700)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13700&action=view)
Revised patch.

I don't know what I was thinking with the first version of the patch :-(  The
new version I think is more likely to be correct.


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #13696|0   |1
is obsolete||


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

[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math

[ubizjak at gmail dot com]

--- Comment #25 from ubizjak at gmail dot com  2007-06-13 20:20 ---
RFC patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00916.html


-- 


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

[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-06-13 20:14 ---
Fixed in 4.3.
As it is neither a regression nor a wrong-code bug, it will not be fixed for
4.2.1 or 4.1.3.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-06-13 20:12 ---
Subject: Bug 32323

Author: burnus
Date: Wed Jun 13 20:12:40 2007
New Revision: 125684

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125684
Log:
2007-06-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/32323
* interface.c (has_vector_section): New.
(compare_actual_formal): Check for array sections with vector
subscript.

2007-06-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/32323
* gfortran.dg/actual_array_vect_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/actual_array_vect_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee

[dje at gcc dot gnu dot org]

--- Comment #6 from dje at gcc dot gnu dot org  2007-06-13 20:00 ---
>From IRC:

see.c:2732 makes a copy of an insn and then hacks on it with validate_change
(and it's close relatives).  This copy has a basic_block, even though it is not
in the insn stream, as well as the same insn_uid as the old insn.  
zadeck This is very bad for df.  df assumes that insns have a null block until
they are inserted into the insn stream and it also uses the insn_uid as the
index into tables for the side info.  I can fix part of the problem by nulling
out the bb for the clone, but i need to give it a shiney new uid (or else use
some properly supported function to make a copy of an insn.

This is very bad for df.  df assumes that insns have a null block until they
are inserted into the insn stream and it also uses the insn_uid as the index
into tables for the side info.  I can fix part of the problem by nulling out
the bb for the clone, but i need to give it a shiney new uid (or else use some
properly supported function to make a copy of an insn.
it links the copy into the insn chain by hand

better would be to skip the make_insn_raw, and just call emit_insn_before at
the appropriate moment
that is, copy the pattern, not the whole insn
and pass the pattern to emit_insn_before

it leaves the 2 insn sequence hanging in mid air until later in the pass it may
or may not replace the old insn with the new sequence

that's why god invented start_sequence/end_sequence--so that you can build and
handle sequences of insns


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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

[Bug c/32327] New: Incorrect stack sharing causing removal of live code

[dnovillo at gcc dot gnu dot org]

Given the following code:

--
typedef unsigned int size_t;
typedef unsigned long long uint64;

extern "C" {
extern void *memcpy (void *__restrict __dest,
  __const void *__restrict __src, size_t __n) /*throw ()*/;
}

extern void foo (void* p);

inline uint64
ghtonll(uint64 x)
{
 // __r is allocated the same stack slot as dest below
 union { unsigned long long int __ll;
 unsigned long int __l[2]; } __w, __r;
 __w.__ll = x;
 __r.__l[0] = (
   {
 register unsigned int __v;
 __asm__ __volatile__ ("bswap %0" : "=r" (__v) :
   "0" ((unsigned int) (__w.__l[1])));
 __v; });

 __r.__l[1] = (
   {
 register unsigned int __v;
 __asm__ __volatile__ ("bswap %0" : "=r" (__v) :
   "0" ((unsigned int) (__w.__l[0])));
 __v; });

 return __r.__ll;
}

inline uint64
double_2_uint64 (const double *source)
{
 uint64 dest;  // allocated the same stack slot as __r above
 memcpy(&dest, source, sizeof(dest));
 return dest;
}

inline void
KeyFromUint64(uint64 fp) {
 uint64 norder;
 norder = ghtonll (fp);
 foo((char*)(&norder));
}

void
KeyFromDouble(double x) {
 uint64 n = double_2_uint64 (&x);
 if (n >= 42) {
   n += 1;
 }

 KeyFromUint64(n);
}
---

Here is what gcc -O2 -fdump-tree-all (version 4.2) in at the end of the tree
passes.
Please take note of the assignment to dest after that of norder.

;; Function void KeyFromDouble(double) (_Z13KeyFromDoubled)

void KeyFromDouble(double) (x)
{
 uint64 n.50;
 char * norder.2;
 uint64 norder;
 register unsigned int __v;
 register unsigned int __v;
 union ._0 __r;
 union ._0 __w;
 uint64 dest;
 uint64 n;

:
 n.50 = VIEW_CONVERT_EXPR(x);
 if (n.50 > 41) goto ; else goto ;

:;
 n = n.50;
 goto  ();

:;
 n = n.50 + 1;

:;
 __w.__ll = n;
 __asm__ __volatile__("bswap %0":"=r" __v:"0" __w.__l[1]);
 __r.__l[0] = __v;
 __asm__ __volatile__("bswap %0":"=r" __v:"0" __w.__l[0]);
 __r.__l[1] = __v;
 norder = __r.__ll;
 norder.2 = (char *) &norder;
 dest = n.50;
 foo (norder.2);
 return;

}

Here is part of the RTL expansion:

(insn 45 43 47 9 (set (mem/c/i:DI (plus:SI (reg/f:SI 54 virtual-stack-vars)
   (const_int -8 [0xfff8])) [3 norder+0 S8 A32])
   (reg/v:DI 64 [ __r ])) -1 (nil)
   (nil))

(insn 47 45 49 9 (parallel [
   (set (reg:SI 59 [ norder.2 ])
   (plus:SI (reg/f:SI 54 virtual-stack-vars)
   (const_int -8 [0xfff8])))
   (clobber (reg:CC 17 flags))
   ]) -1 (nil)
   (nil))

(insn 49 47 51 9 (set (mem/c/i:DI (plus:SI (reg/f:SI 54 virtual-stack-vars)
   (const_int -8 [0xfff8])) [3 dest+0 S8 A32])
   (reg/v:DI 58 [ n.50 ])) -1 (nil)
   (nil))

Both dest & norder are assigned the same memory location
(virtual-stack-vars - 8). So later lifeness analysis thinks that the
first assignment is dead and it removes it. norder contains results of
bswap but gcc cannot remove the asm statement. However, since the
output of the asms are dead so they both got eax as the output
register.


-- 
   Summary: Incorrect stack sharing causing removal of live code
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

[daney at gcc dot gnu dot org]

--- Comment #5 from daney at gcc dot gnu dot org  2007-06-13 19:44 ---
Unfortunatly the patch causes an ICE compiling crtstuff.c.  I will have to
adjust it a bit...


-- 


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

[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2007-06-13 19:30 ---
Subject: Bug number PR32323

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


-- 


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

[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2007-06-13 19:27 
---
*** Bug 32326 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joel at gcc dot gnu dot org


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

[Bug c/32326] ICE when -g specified

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-13 19:27 ---
> It does not occur targeting 
I doubt those use dwarf2/3 :).

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary|ICE when -g specified   |ICE when -g specified


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

[Bug c/32326] New: ICE when -g specified

[joel at gcc dot gnu dot org]

This may be a duplicate of PR 28868

a.c
=
typedef struct a1 {
  int x;
} a1_t __attribute__((may_alias));
=

a.c:3: internal compiler error: in splice_child_die, at dwarf2out.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccI0138Q.out file, please attach this to
your bugreport.


It does not occur targeting 

tic4x-rtems with gcc 3.4.6
avr-rtems with gcc 4.0.3
mingw with gcc 4.1.2 
i386-rtems with gcc 4.1.2
i386-rtems with gcc 4.2.0

It occurs with many gcc versions and targets:

gcc 4.1.1 Fedora Core 6 - i686-pc-linux-gnu
gcc 4.1.1 RTEMS - arm, h8300, i386, m68k, mips, powerpc, sh, sparc
gcc 4.1.2 RTEMS - arm, bfin, h8300, m68k, mips, powerpc, sh, sparc
gcc 4.2.0 RTEMS - arm, bfin, h8300, m68k, mips, powerpc, sh, sparc


-- 
   Summary: ICE when -g specified
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cross target


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

[Bug target/32325] [4.3 Regression] cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
  Component|c++ |target
   Keywords||build, ice-on-valid-code
Summary|cc1plus ICE configuring |[4.3 Regression] cc1plus ICE
   |libstdc++ on Tru64 UNIX |configuring libstdc++ on
   |V5.1B: SEGV in  |Tru64 UNIX V5.1B: SEGV in
   |rtl_verify_flow_info|rtl_verify_flow_info
   Target Milestone|--- |4.3.0
Version|unknown |4.3.0


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

[Bug c++/32325] New: cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info

[gcc-bugzilla at gcc dot gnu dot org]

During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:

checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1

config.log reveals:

configure:13794: checking for exception model to use
configure:13838:  /vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src/.libs
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
/vol/gcc/alpha-dec-osf5.1b/include -isystem
/vol/gcc/alpha-dec-osf5.1b/sys-include -c -S  conftest.cc >&5
configure: In function 'void foo()':
configure:13836: error: end insn 27 for block 7 not found in the insn stream
configure:13836: error: head insn 24 for block 7 not found in the insn stream
configure:13836: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
configure:13841: $? = 1
configure:13870: error: unable to detect exception model

This happens with the following conftest.cc:

struct S { ~S(); };
void bar();
void foo()
{
  S s;
  bar();
}

 % ./cc1plus conftest.cc
 void foo()
Analyzing compilation unit
Performing interprocedural optimizations
   Assembling functions:
 void foo()
conftest.cc: In function 'void foo()':
conftest.cc:7: error: end insn 27 for block 7 not found in the insn stream
conftest.cc:7: error: head insn 24 for block 7 not found in the insn stream
conftest.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Running gdb reveals

Program received signal SIGSEGV, Segmentation fault.
rtl_verify_flow_info () at /vol/gcc/src/gcc-dist/gcc/cfgrtl.c:2005
(gdb) where
#0  rtl_verify_flow_info () at /vol/gcc/src/gcc-dist/gcc/cfgrtl.c:2005
#1  0x000120516638 in verify_flow_info () at
/vol/gcc/src/gcc-dist/gcc/cfghooks.c:245
#2  0x000120618934 in commit_edge_insertions () at
/vol/gcc/src/gcc-dist/gcc/cfgrtl.c:1467
#3  0x000120415bcc in alpha_gp_save_rtx () at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.c:4784
#4  0x0001206406fc in gen_exception_receiver () at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.md:7019
#5  0x000120314dc8 in finish_eh_generation () at
/vol/gcc/src/gcc-dist/gcc/except.c:1633
#6  0x000120314f98 in rest_of_handle_eh () at
/vol/gcc/src/gcc-dist/gcc/except.c:3985
#7  0x000120421978 in execute_one_pass (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1124
#8  0x000120421c48 in execute_pass_list (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1177
#9  0x000120421c5c in execute_pass_list (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1178
#10 0x0001204fef44 in tree_rest_of_compilation (fndecl=0x0) at
/vol/gcc/src/gcc-dist/gcc/tree-optimize.c:406
#11 0x0001202535c8 in c_expand_body (fndecl=0x140137d80) at
/vol/gcc/src/gcc-dist/gcc/c-common.c:4331
#12 0x0001201ea958 in expand_body (fn=0x18de60) at
/vol/gcc/src/gcc-dist/gcc/cp/semantics.c:3136
#13 0x000120423f60 in cgraph_expand_function (node=0x18de60) at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1073
#14 0x000120427400 in cgraph_optimize () at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1142
#15 0x00012015e054 in cp_write_global_declarations () at
/vol/gcc/src/gcc-dist/gcc/cp/decl2.c:3305
#16 0x0001204432e0 in toplev_main (argc=1, argv=0x0) at
/vol/gcc/src/gcc-dist/gcc/toplev.c:1064
#17 0x00012029fe98 in main (argc=1075019136, argv=0x11fffbb30) at
/vol/gcc/src/gcc-dist/gcc/main.c:35
(gdb) p x
$1 = 0x0

I.e. rtl_verify_flow_info dereferences a NULL pointer.  This happens only
on alpha-dec-osf5.1b, alpha-dec-osf4.0f is unaffected.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap as described above.


-- 
   Summary: cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B:
SEGV in rtl_verify_flow_info
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


http://gcc.gnu.org/bugzil

[Bug fortran/32323] Accepts invalid vector subscript actual argument for intent(out) dummy argument

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-06-13 18:03 ---
Thanks for finding this bug! I think it is the following in the Fortran 2003
standard:

"12.4.1.2 Actual arguments associated with dummy data objects"
"If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT), the actual
argument shall be definable."
"If the actual argument is an array section having a vector subscript, the
dummy argument is not definable and shall not have the INTENT (OUT), INTENT
(INOUT), VOLATILE, or ASYNCHRONOUS attributes."

Thus we also also need to check for VOLATILE instead of
INTENT(IN)/INTENT(INOUT).

Note that array sections without vector subscripts such as
   call aa(w(3:1))
are allowed!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-unknown-linux-gnu|
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2007-06-13 18:03:56
   date||
   Target Milestone|--- |4.3.0


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

[Bug c/32324] unsigned long long operator << and integer literals

[andrew dot stubbs at st dot com]

--- Comment #2 from andrew dot stubbs at st dot com  2007-06-13 18:00 
---
As it happens, I encountered your real problem quite recently. :)

"(int)(1<<31)" is undefined (C99 standard 6.5.7/4).

This modified version gives the same result both ways:

int main (){
   unsigned long long a = 18446744065119617024llu;
   /* results expected to be identical */
#ifdef EXPECTED
   unsigned int b = ((unsigned int)(1<<31));
   a = a / b;
#else
   a = a / ((unsigned int)(1<<31));
#endif

   return a;
}


-- 


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

[Bug other/32263] Document the required versions of glibc and binutils

[appfault at hotmail dot com]

--- Comment #5 from appfault at hotmail dot com  2007-06-13 17:56 ---
Ok well, I'll take your word on that, since I can't really tell where gcc and
ld end and glibc begins.  It's perhaps glibc that is in need of better
documentation then.  However if I file such a zilla I suspect it will quickly
be marked duplicate of http://sources.redhat.com/bugzilla/show_bug.cgi?id=333
...


-- 


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

[Bug rtl-optimization/32283] Missed induction variable optimization

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-06-13 17:53 ---
Look at PR 17108 also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||17108


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

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[kargl at gcc dot gnu dot org]

--- Comment #18 from kargl at gcc dot gnu dot org  2007-06-13 17:52 ---
> The libm library is the least accurate and on average the fastest; though not
> fastest for every function instance. The most accurate is always CRLibm,
> sometimes it is fastest. The MPFR library is second most accurate and from 50
> to over 300 times slower than CRLibm.

You've shown nothing to validate that crlibm is more accurate than mpfr.
So how did you do this measurement?


-- 


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

[Bug c++/32261] Thread race segfault in std::string::append with -O and -s

[appfault at hotmail dot com]

--- Comment #4 from appfault at hotmail dot com  2007-06-13 17:38 ---
Yes in addition to the issue of adding a test case, it is quite unsettling to
not know what might have fixed it.  Reopening pending response to comment 2 and
comment 3.


-- 

appfault at hotmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list

[jconner at apple dot com]

--- Comment #7 from jconner at apple dot com  2007-06-13 17:09 ---
(In reply to comment #6)
> I see that PR25505 caused a bunch of code generation regressions.
> On i?86, with -O2 -m32:
> ...

When you say regressions, I assume you mean size/performance, not correctness,
right?  If so, that's to be expected, as the previous tree-nrv implementation
was being overly permissive, and the new implementation is conservatively
pessimistic, as the comments indicate.  If I have introduced anything
incorrect, please let me know and I'd be glad to take a look.  Thanks!


-- 


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

[Bug c/32324] unsigned long long operator << and integer literals

[gcc at axel-naumann dot de]

--- Comment #1 from gcc at axel-naumann dot de  2007-06-13 16:50 ---
Created an attachment (id=13699)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13699&action=view)
Test case as stated in the report.


-- 


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

[Bug c/32324] New: unsigned long long operator << and integer literals

[gcc at axel-naumann dot de]

The result of the division of 18446744065119617024llu by the result of (1<<31)
is wrong on a 32bit platform.

Reproduce:  gcc s.c && ./a.out
should have exit code 0 but doesn't.

Expected:   gcc -DEXPECTED s.c && ./a.out
has exit code 0 as expected.


gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
[lxbuild021] /afs/cern.ch/user/a/axel/tmp/gccconv >
/afs/cern.ch/sw/lcg/contrib/gcc/4.1.2/slc4_ia32_gcc34/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /build/LCG/gcc-4.1.2/configure
--prefix=/afs/cern.ch/sw/lcg/contrib/gcc/4.1.2/slc4_ia32_gcc34
Thread model: posix
gcc version 4.1.2


uname -a
Linux lxbuild021.cern.ch 2.6.9-42.0.10.EL.cernsmp #1 SMP Thu Mar 1 15:11:46 CET
2007 i686 i686 i386 GNU/Linux


I'll give the .c instead of .i because it shows the expected result and has no
#includes:

int main (){
   unsigned long long a = 18446744065119617024llu;
   /* results expected to be identical */
#ifdef EXPECTED
   int b = ((int)(1<<31));
   a = a / b;
#else
   a = a / ((int)(1<<31));
#endif
   return a;
}


-- 
   Summary: unsigned long long operator << and integer literals
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at axel-naumann dot de
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug fortran/32323] New: Accepts invalid vector subscript actual argument for intent(out) dummy argument

[terry at chem dot gu dot se]

[EMAIL PROTECTED] cat run.f90
module mod
implicit none
contains
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
end module mod

program ff
use mod
implicit none
integer,dimension(10)::w
w=1
call aa(w((/3,2,1/)))
write(*,*)w
end

[EMAIL PROTECTED] gfortran -v -Wall -W --std=f95 --pedantic -O -fbounds-check
run.f90
Driving: gfortran -v -Wall -W -std=f95 -pedantic -O -fbounds-check run.f90
-lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=fortran
Thread model: posix
gcc version 4.2.0 20070501 (prerelease)
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 run.f90 -quiet
-dumpbase run.f90 -mtune=generic -auxbase run -O -Wall -W -pedantic -std=f95
-version -fbounds-check -I
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccFuwYwj.s
GNU F95 version 4.2.0 20070501 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20070501 (prerelease).
GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112193
 as --traditional-format -V -Qy -o /tmp/ccIcA5Sy.o /tmp/ccFuwYwj.s
GNU assembler version 2.17.50 (x86_64-linux-gnu) using BFD version 2.17.50
20070103 Ubuntu
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2 --eh-frame-hdr
-m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../.. /tmp/ccIcA5Sy.o
-lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o
/usr/lib/../lib64/crtn.o
[EMAIL PROTECTED] ./a.out
   3
   1   1   1   1   1   1   
   1   1   1   1



For those that care, both ifort and g95 correctly identify this as invalid
code.

(Maybe I can get one right today!  ;-)


-- 
   Summary: Accepts invalid vector subscript actual argument for
intent(out) dummy argument
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/32317] No warning on bad arguments with explicit interface

[terry at chem dot gu dot se]

--- Comment #3 from terry at chem dot gu dot se  2007-06-13 16:23 ---
(In reply to comment #2)
> Neither SUN nor Intel fortran compilers issue such a warning.
> 

Indeed.  That does not imply that gfortran shouldn't, though.  Hence the
enhancement request.


-- 


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

[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot org
   Keywords||ice-on-valid-code
Summary|ICE in df_refs_verify   |[4.3 Regression] ICE in
   ||df_refs_verify with -fgcse-
   ||sm
   Target Milestone|--- |4.3.0


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

[Bug fortran/32317] No warning on bad arguments with explicit interface

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-06-13 16:17 ---
Neither SUN nor Intel fortran compilers issue such a warning.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug fortran/32319] Bad automatic array argument

[terry at chem dot gu dot se]

--- Comment #2 from terry at chem dot gu dot se  2007-06-13 16:10 ---
Ah.  Of course explicit interfaces are required for automatic array arguments.

My Fortran-Fu seems to be deserting me at the moment.  :-(


-- 

terry at chem dot gu dot se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/32319] Bad automatic array argument

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2007-06-13 15:57 ---
If you would provide an explicit interface for AA, the binary would not
segfault:

$> cat pr32319.f90
program ff
  implicit none
  integer,dimension(4)::w
  w=1
  write(*,*)w
  call aa(w(2:3))
  write(*,*)w
contains
  subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
  end subroutine aa
end

$> gfortran-svn pr32319.f90 && ./a.out
   1   1   1   1
   2
   1   0   0   1


Without explicit interface, the binary produced by ifort crashes the same way
as the one generated by gfortran, sunf95 issues this message on the original
code:

$> sunf95 -w4 pr32319.f90

call aa(w(1:5))
^
"pr32319.f90", Line = 13, Column = 1: ERROR: Procedure "AA" is defined at line
1 (pr32319.f90).  It must have an explicit interface specified.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2007-06-13 15:57 ---
(In reply to comment #2)
> The generic implementation, including for SSE, is 
>   isgreater (abs(f), FLT_MAX)
> For isfinite, use islessequal instead.  For isnan, one can use 
>   isunordered(f, f)
> For isnormal, it'd be
>   isgreaterequal(abs(f), FLT_MIN) & islessequal(abs(f), FLT_MAX)
> which is less likely to be friendly to inline.

I'd like to do this, but how does one generate FLT_MAX et al. from the
middle-end?


-- 


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

[Bug bootstrap/32312] [4.3 regression] bootstrap failure on sparc-sun-solaris2.10

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2007-06-13 15:45 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html

by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00842.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/32321] ICE in df_refs_verify

[tsarkov at cs dot man dot ac dot uk]

--- Comment #1 from tsarkov at cs dot man dot ac dot uk  2007-06-13 15:42 
---
Created an attachment (id=13697)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13697&action=view)
Preprocessed sources

Code that triggers ICE


-- 


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

[Bug c++/32322] New: pointers to overloaded methods not correctly resolved

[mavdzee at yahoo dot co dot uk]

In a template-context, pointers to overloaded methods are not correctly
resolved. the following main.cpp does not compile on gcc 4.1.2, however it does
compile on version 3.4.6:

#include 
#include 
#include 
#include 

namespace mi = boost::multi_index;

struct field_ts
{
  int ts() const { return 10; }
  void ts(const int &arg) {  }
};;

template 
struct mi_key
{
  typedef typename mi::composite_key<
field_ts,
mi::const_mem_fun
   > type;
};

mi_key::type  key;

int main (int argc, char **argv)
{
  return 0;
}

I get the following error-message:

main2.cpp: In instantiation of ‘mi_key’:
main2.cpp:26:   instantiated from here
main2.cpp:23: error: invalid use of ‘field_ts::ts’ to form a
pointer-to-member-function
main2.cpp:23: note:   a qualified-id is required

The compiler should do this automatically without you having
to disambiguate the overload, see 14.3.2/5:

"For a non-type template-parameter of type pointer to member
function, no conversions apply. If the template-argument represents
a set of overloaded member functions, the matching member
function is selected from the set (13.4)."


-- 
   Summary: pointers to overloaded methods not correctly resolved
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mavdzee at yahoo dot co dot uk


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

[Bug middle-end/32321] New: ICE in df_refs_verify

[tsarkov at cs dot man dot ac dot uk]

>gcc-4.3 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-checking --prefix=/opt/gcc
--enable-shared --enable-threads --program-suffix=-4.3 --enable-__cxa_atexit
--disable-nls --with-mpfr=/usr/local
--enable-languages=c,c++,objc,obj-c++,treelang,fortran
Thread model: posix
gcc version 4.3.0 20070612 (experimental)

>gcc-4.3 -c -O2 -fgcse-sm bdd_kernel.c
bdd_kernel.c: In function 'bdd_noderesize':
bdd_kernel.c:27: internal compiler error: in df_refs_verify, at df-scan.c:4092
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: ICE in df_refs_verify
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsarkov at cs dot man dot ac dot uk
 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=32321

[Bug objc++/32320] New: [4.1 regression] ICE with invalid template parameter

[uhle1982 at yahoo dot com]

+++ This bug was initially created as a clone of Bug #27668 +++

The following invalid code snippet triggers an ICE since GCC 3.4.0:

==
template struct A {};

template void foo(A);
==

bug.cc:1: error: expected nested-name-specifier before 'class'
bug.cc:1: error: two or more data types in declaration of 'parameter'
bug.cc:1: error: 'struct T' is not a valid type for a template constant
parameter
bug.cc:3: error: type/value mismatch at argument 1 in template parameter list
for 'template, void  > struct A'
bug.cc:3: error:   expected a constant of type 'int', got 'int'
bug.cc:3: internal compiler error: in value_dependent_expression_p, at
cp/pt.c:12489
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1 regression] ICE with invalid template parameter
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uhle1982 at yahoo dot com
 GCC build triplet: same
  GCC host triplet: Seize
GCC target triplet: like


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

[Bug fortran/32319] New: Bad automatic array argument

[terry at chem dot gu dot se]

[EMAIL PROTECTED] cat run.f90 
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa

program ff
implicit none
integer,dimension(10)::w
w=1
write(*,*)w
call aa(w(1:5))
write(*,*)w
end

[EMAIL PROTECTED] gfortran -Wall -W -fbounds-check -O --std=f95 --pedantic -v
run.f90
Driving: gfortran -Wall -W -fbounds-check -O -std=f95 -pedantic -v run.f90
-lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=fortran
Thread model: posix
gcc version 4.2.0 20070501 (prerelease)
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 run.f90 -quiet
-dumpbase run.f90 -mtune=generic -auxbase run -O -Wall -W -pedantic -std=f95
-version -fbounds-check -I
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/cc6lORdO.s
GNU F95 version 4.2.0 20070501 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20070501 (prerelease).
GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112193
 as --traditional-format -V -Qy -o /tmp/ccyEdACx.o /tmp/cc6lORdO.s
GNU assembler version 2.17.50 (x86_64-linux-gnu) using BFD version 2.17.50
20070103 Ubuntu
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2 --eh-frame-hdr
-m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../.. /tmp/ccyEdACx.o
-lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o
/usr/lib/../lib64/crtn.o
[EMAIL PROTECTED] ./a.out 
   1   1   1   1   1   1   
   1   1   1   1
 -1762200976
Segmentation fault

This has really surprised me, as I'd swear I've used this construct recently. 
So much so, I even went and upgraded my gcc just to test it!

(In case anyone cares, I was in the process of testing some of the implications
of not having PR32317 implemented with array sections and vector subscripts and
the like.  Clearly, I never got that far!)


-- 
   Summary: Bad automatic array argument
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug ada/32318] New: GNAT.Calendar.Time_IO "%c" incorrectly claims to be reporting the time zone

[bauhaus at futureapps dot de]

The spec file explains that the picture "%c" stands for
locale's date and time (including the time zone).
However, the replacement picture doesn't include %z (which
isn't supported AFAICS.)

from the spec:
--  %c   locale's date and time (Sat Nov 04 12:02:33 EST 1989)

from the body:
  when 'c' =>
  case Padding is
 when Zero =>
Result := Result & Image (Date, "%a %b %d %T %Y");


$ ./testtime 
Wed Jun 13 17:17:41 2007

(This has lead to a time shift when some application, such as a MTA,
interprets the time WRT a different default time zone, such as UTC.)

with GNAT.Calendar.Time_IO;
with Ada.Calendar;
with Ada.Text_IO;

procedure testtime is
begin
   Ada.Text_IO.Put_Line
  (GNAT.Calendar.Time_IO.Image (Ada.Calendar.Clock, "%c"));
end;

The code is present in trunk, Rev 125413


-- 
   Summary: GNAT.Calendar.Time_IO "%c" incorrectly claims to be
reporting the time zone
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bauhaus at futureapps dot de
GCC target triplet: i486-linux-gnu


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

[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2007-06-13 15:22 ---
I see that PR25505 caused a bunch of code generation regressions.
On i?86, with -O2 -m32:
_Complex double foo (_Complex double x)
{
  return __builtin_cexp (x);
}
generated code got much worse, similarly:
elemental function specific__exp_c8 (parm)
   complex (kind=8), intent (in) :: parm
   complex (kind=8) :: specific__exp_c8
   specific__exp_c8 = exp (parm)
end function
In the above 2 cases, dest_safe_for_nrv_p is called on an SSA_NAME.  At least
in
these cases it should be safe to use SSA_NAME_VAR, shouldn't it?
A different testcase that regressed is:
struct P
{
  long long l;
  int a;
  unsigned int b;
  P(long long x) : l(x) {}
};

P foo (P);
P bar (P);

P foo (P x)
{
  P y = P (-1LL);
  y = bar (x);
  return y;
}

Here dest_safe_for_nrv_p is passed a RESULT_DECL and is again something
that ought to be optimized out, but is not any longer.

static bool
dest_safe_for_nrv_p (tree dest, location_t *loc)
{
  subvar_t subvar;

  while (handled_component_p (dest))
dest = TREE_OPERAND (dest, 0);

  if (! SSA_VAR_P (dest))
return false;

  if (TREE_CODE (dest) == SSA_NAME)
dest = SSA_NAME_VAR (dest);

  if (is_call_clobbered (dest))
return false;
  for (subvar = get_subvars_for_var (dest); subvar; subvar = subvar->next)
if (is_call_clobbered (subvar->var))
  return false;
  return true;
}

handles all of these (i.e. doesn't regress on any of them).  I have verified
that
it e.g. refuses to NRV optimize:
struct P
{
  long long l;
  int a;
  unsigned int b;
  P(long long x) : l(x) {}
};

P foo (P);
P bar (P);
void baz (P *);

P foo (P x)
{
  P y = P (-1LL);
  baz (&y);
  y = bar (x);
  return y;
}
because the RESULT_DECL escapes.
It regresses on the initial testcase from this bugreport, so it would mean
writing a different bugfix (most probably in calls.c, check that the target
doesn't overlap with the arguments being pushed), but it might very well be
worth it.


-- 


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

[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2007-06-13 15:00 ---
I goofed - the previous does not fix it at all.

I hope that I am not too late to stop folk from building with this patch.

Cheers

Paul

PS Compiling the subroutines separately or padding out the first aux32 both fix
the problem, so I think that the patch is touching the right place.  That is,
the union type that is joined to the top level has some information missing
about its size, when a resize occurs.  I just need to figure out what it is:)


-- 


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

[Bug bootstrap/18388] bootstrapping failing on HP-UX 11.23/IA64

[ckirshen at gnupower dot net]

--- Comment #2 from ckirshen at gnupower dot net  2007-06-13 14:37 ---
This problem definitely exists on both hpux 11v2 and 11v3, even when passing in
--with-gnu-as and --with-as.  I'm trying this on gcc-3.4.3 and gcc-3.4.6


-- 


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

[Bug gcov-profile/32316] internal compiler error: Segmentation fault

[patrick dot pastoor at onespin-solutions dot com]

--- Comment #2 from patrick dot pastoor at onespin-solutions dot com  
2007-06-13 14:26 ---
I am really sorry. But I think there is no possiblity to upload a preprocessed
source here


-- 


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

[Bug fortran/32317] No warning on bad arguments with explicit interface

[terry at chem dot gu dot se]

--- Comment #1 from terry at chem dot gu dot se  2007-06-13 13:43 ---
(Whoops.  Mixed up output in that last post.  Only 8 reals are printed in
reality.  My bad.)


-- 


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

[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2

[dir at lanl dot gov]

--- Comment #9 from dir at lanl dot gov  2007-06-13 13:39 ---
   Your Welcome Paul,

  With a little luck, the fix for this will cure the remaining problems that I
have been having with my programs when optimization is turned on.


-- 


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

[Bug fortran/32317] New: No warning on bad arguments with explicit interface

[terry at chem dot gu dot se]

Even when an explicit interface is known, no warnings are generated when array
argument bounds (available to the compiler) don't match.  Consider the
following:

module mod
implicit none

contains

subroutine a(n,v)
integer,intent(in)::n
real,dimension(n),intent(in)::v
write(*,*)v
end subroutine a

subroutine b
real,dimension(5)::v
v=0
call a(8,v(1:4))
end subroutine b

end module mod

When b is being compiled the interface to a is known, yet no warnings are
generated of the obvious mismatch in the arguments (run.f90 just calls b):

$ gfortran -Wall -W -c --std=f2003 --pedantic -fbounds-check -O case.f90
$ gfortran -Wall -W --std=f2003 --pedantic -fbounds-check -O run.f90 case.o
$ ./a.out 
   0.00   0.00   0.00   0.00   0.00  
0.00 -1.1411260E-37  1.5604860E-41 -5.1655852E-38  1.5604860E-41
-6.3728095E-38  1.5604860E-41   0.00   0.00  5.8804453E-39  
0.00  4.2038954E-45   0.00  5.8809218E-39   0.00
-6.3728095E-38  1.5604860E-41 -8.5373851E-38  1.5604860E-41  5.8801398E-39

While this construct is probably legal as a hang-on from crappy old fortran, I
can't think of a situation when giving explicit bounds like this where simply
overrunning would be the desired effect.  A warning would be nice.

(I was going to also complain that -fbouns-check didn't come up with anything,
but then I saw PR 27989.)


-- 
   Summary: No warning on bad arguments with explicit interface
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl

[rask at sygehus dot dk]

--- Comment #7 from rask at sygehus dot dk  2007-06-13 13:36 ---
Looking at this again, I don't think the transformation I'm making with the
splitter is valid, because I'm making up a zero extension which wasn't there to
begin with. The upper part could have been non-zero before the instruction.
As to the original example, it should be possible to optimize

 addl%eax, %edx
 cmpl%edx, %eax
 ja  .L7
into
 addl%eax, %edx
 jc  .L7

with a CCmode expressing that the carry flag is set if %edx is smaller than
%eax.


-- 


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

[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2007-06-13 
13:28 ---
Subject: Re:  [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

> It's my turn to ask: so what information does hppa_can_use_return_p
> need to make the decision ?

We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value in
r2 is unchanged).  Calls clobber r2.

Dave


-- 


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

[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-13 13:24 ---
Sorry if I was not clear before.  This is the correct fix for the testcase but
not the bug itself.  Users could accidently use the %q0 and then get the ICE.


-- 


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

[Bug gcov-profile/32316] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-13 13:14 ---
Can you attach the preprocessed source?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c++ |gcov-profile


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

[Bug rtl-optimization/32283] Missed induction variable optimization

[pranav dot bhandarkar at gmail dot com]

--- Comment #5 from pranav dot bhandarkar at gmail dot com  2007-06-13 
12:36 ---
Which RTL pass should take care of such induction variable optimization in 4.3
? For e.g In 4.1, It was old-loop that was doing it.


-- 


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

[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2007-06-13 12:26 ---
This fixes it but is, as yet unregtested.  I'll do the business tonight and
will commit as 'obvious', if all is well.

Thanks, Dale!

Paul

Index: gcc/fortran/trans-common.c
===
--- gcc/fortran/trans-common.c  (révision 125645)
+++ gcc/fortran/trans-common.c  (copie de travail)
@@ -366,7 +366,8 @@ build_common_decl (gfc_common_head *com,
   if (strcmp (com->name, BLANK_COMMON_NAME))
gfc_warning ("Named COMMON block '%s' at %L shall be of the "
 "same size", com->name, &com->where);
-  DECL_SIZE_UNIT (decl) = size;
+ /*The declaration must be laid out once more and resized.  */
+ relayout_decl (decl);
 }
  }


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-12 15:03:55 |2007-06-13 12:26:43
   date||


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

[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2007-06-13 12:08 
---
Can you provide a working patch?


-- 


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

[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2007-06-13 11:55 ---
(In reply to comment #2)
> > Sorry about the breakage. Does it work for you if you change the testcase 
> > as follows?:
> 
> Yes it will fix it but note there is still a bug in the ia64 back-end anyways
> so this bug should not be closed as being fixed after the patch gets applied.

No, it is correct fix. We should avoid % modifiers in target-independant tests.
The failure is simply due to the fact that %q is not supported in ia64 (please
look in config/ia64/ia64.c, around line 4500).


-- 


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

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[joseph at codesourcery dot com]

--- Comment #17 from joseph at codesourcery dot com  2007-06-13 11:30 
---
Subject: Re:  Paranoia UCB GSL TestFloat libm tests fail
 - accuracy of recent gcc math poor

I previously suggested to the crlibm authors that they consider assigning 
it to the FSF for contribution to libgcc-math 
.  I don't know 
if anything has happened on that since then.


-- 


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