[Bug fortran/29670] New: [meta-bug] fortran interfaces

[franke dot daniel at gmail dot com]

As suggested in PR29652, a meta-bug for interfaces in fortran.


-- 
   Summary: [meta-bug] fortran interfaces
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franke dot daniel at gmail dot com


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

[Bug fortran/29580] integer -2147483648 out of range: bug or feature?

[kloedej at knmi dot nl]

--- Comment #6 from kloedej at knmi dot nl  2006-10-31 08:25 ---
A short additional remark on this item:
I just learned (thanks to Paul Poli) that the NAGware f95 compiler does behave
in the same way as gfortran, i.e. refusing to compile the constant -2147483648
in:

integer(KIND=4) :: i
i=-2147483648

an alternative formulation for the mentioned simple workaround (not using
huge()) that does work for all compilers I know is:

integer(KIND=4) :: i
i=-2147483647 -1 


-- 


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

[Bug fortran/25708] Module loading is not good at all

[paul dot richard dot thomas at cea dot fr]

--- Comment #5 from paul dot richard dot thomas at cea dot fr  2006-10-31 
08:29 ---
Subject: RE:  Module loading is not good at all

FX

 -Message d'origine-
 De : fxcoudert at gcc dot gnu dot org 
 [mailto:[EMAIL PROTECTED]
 Envoyé : mardi 31 octobre 2006 08:01

 I like that idea. I've looked at the code in symbol.c, and 
 don't see clearly
 how to get it done (where do you get the master symtree from, eg?)
 

I haven't really thought about this enough yet but.

(i) I think that a namespace will have to be built for each module.  This will
allow the initial part of read_module to be left completely unmodified. *grin*

(ii) The namespaces should be contained in a linked list or binary tree; the
structures should be something like

typedef struct gfc_module_namespace
{
  const char *name;
  struct gfc_module_namespace *next;
  maybe some attributes?;
}
gfc_module_namespace;

I think that a list should be sufficient, since numbers of modules are likely
to remain limited for real-life codes aren't they?  Or is your 25Mb monster
an indication that I am wrong?

(iii) As the modules get USEd, new symtrees are added to the current namespace
and I think that it is OK to point to the symbols in the module namespaces.
This would simplify derived type association a lot.  I have not the foggiest
idea what to do about interfaces; they are on my list of urgent things to try
to understand.  I am about to create a meta-bug of interface PRs. I had a
notion to look at modules after I had had a stab at that.

(There is a PR on doubly USEd interfaces that I had a stab at in the airport
last Friday - I got absolutely nowhere; even though I thought that I was
touching the right places, it had no effect on the fault!  This is one and the
same problem of doubly USEd variables that I fixed by explicitly going through
and checking each against the other.  To do likewise for interfaces requires
some understanding!  I note, however, that these problems are fixed in g95 and
there is no sign whatsoever of the corresponding fixes... It is a crying shame
that Andy Vaught is not on-side.) 

(iv) As at present, the symtree carries the local name and the symbol the true
name - that's why I think that the symbols can be shared.

Regards

Paul

(v) Clearly, a clean-up at the end of the compilation of the file will have to
be done but all the mechanisms to do that exist already.

As I say, the problems are a) interfaces, b) interfaces and c) interfaces.

Ciao

Paul


-- 


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

[Bug fortran/28885] ICE passing components of array of derived type

[drewmccormack at mac dot com]

--- Comment #8 from drewmccormack at mac dot com  2006-10-31 08:51 ---
Unfortunately, though the fix did work for the example code, it doesn't seem to
be general enough. In particular, if you change the example code to include
just one extra subroutine call, the same compiler error arises. So, a fix is
need that can handle any number of subroutine calls, not just one or two.

Here is new code demonstrating the error. It is simply the original code with
one extra subroutine call:

program test
  type t  
integer :: i
integer :: j
  end type
  type (t) :: a(5) 
  call sub('one',a%j)
  call sub('two',a%i)
  call sub('two',a%i)
contains
  subroutine sub(key,a)
integer, intent(out):: a(:) 
character(*),intent(in) :: key
a = 1   
  end subroutine
end program 


-- 

drewmccormack at mac dot com changed:

   What|Removed |Added

 CC||drewmccormack at mac dot com
 Status|RESOLVED|REOPENED
  GCC build triplet|gcc version 4.2.0 20060805  |gcc version 4.2.0 20061007
   |(experimental)  |(experimental)
 GCC target triplet|powerpc-apple-darwin8.7.0   |powerpc-apple-darwin8.8.0
 Resolution|FIXED   |


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

[Bug fortran/28885] ICE passing components of array of derived type

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2006-10-31 08:59 ---
(In reply to comment #8)
 Here is new code demonstrating the error. It is simply the original code with
 one extra subroutine call:

That is the same as PR 29565.
So closing this bug as fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29648] Inlining only done for contained procedures

[P dot Schaffnit at access dot rwth-aachen dot de]

--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de  
2006-10-31 09:13 ---

Right!

Thanks!


-- 


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

[Bug middle-end/29658] ICE while compiling Firefox 2.0

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2006-10-31 09:26 ---
works for me with g++-4.2 (GCC) 4.2.0 20061023 (prerelease).


-- 


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

[Bug target/24071] __gthread_active_p vs __gthread_once

[bkoz at gcc dot gnu dot org]

--- Comment #12 from bkoz at gcc dot gnu dot org  2006-10-31 09:34 ---

Thanks for fixing this for real Eric.

-benjamin


-- 


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

[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION

[bkoz at gcc dot gnu dot org]

--- Comment #14 from bkoz at gcc dot gnu dot org  2006-10-31 09:42 ---

Eric, it looks like you've got this fixed now: great news. Solaris test results
for 2.10, 2.9, and 2.8 looked fine for the last month and a half, so I'd
assumed this patch was not problematic.

As a side note, it's hard to deal with paging in and out WRT this bug report
over two months. If we're supposed to care about Solaris-2.5-7, then please,
post test results on a (at least) weekly basis.

-benjamin


-- 


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

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

--- Comment #26 from vincent at vinc17 dot org  2006-10-31 09:54 ---
(In reply to comment #25)
 As I think about it more, I'm leaning toward having a new function 
 mpfr_lgamma.
  This is because if we want this mpfr function to mimic the behavior of 
 lgamma,
 we need some mechanism to retrieve the value of signgam.  So maybe the
 interface you suggested at the bottom of this link would be best where we
 retrieve an int* from mpfr_lgamma to determine signgam:
 http://sympa.loria.fr/wwsympa/arc/mpfr/2006-10/msg00033.html

Yes, it's true that it is useful to have this value. But determining it
separately is quite easy, without taking a noticeable additional time in
average.


-- 


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

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[r dot emrich at de dot tecosim dot com]

--- Comment #1 from r dot emrich at de dot tecosim dot com  2006-10-31 
11:06 ---
(In reply to comment #0)
 
 jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
 

similiar problem here.

hppa2.0w-hp-hpux11.00
gcc-4.2.0 revison 118176

/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0/gcc/gcj
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0/hppa2.0w-hp-hpux11.00/libjava/
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0/gcc/
-fclasspath=
-fbootclasspath=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0
/hppa2.0w-hp-hpux11.00/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated
-fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c
@gnu-xml.list -o
 gnu-xml.o

jc1: out of memory allocating 4072 bytes after a total of 658085416 bytes
gmake[3]: *** [gnu-xml.lo] Error 1
gmake[3]: Leaving directory
`/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0/hppa2.0w-hp-hpux11.00/libjava'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0/hppa2.0w-hp-hpux11.00/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory
`/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2.0/gcc-4.2.0'
gmake: *** [all] Error 2


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[l_heldt at poczta dot onet dot pl]

--- Comment #8 from l_heldt at poczta dot onet dot pl  2006-10-31 11:12 
---
There is a similar problem in _M_detach_all() function. It iterates through
list of iterators without obtaining lock.


-- 


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

[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION

[ebotcazou at gcc dot gnu dot org]

--- Comment #15 from ebotcazou at gcc dot gnu dot org  2006-10-31 11:16 
---
 Eric, it looks like you've got this fixed now: great news. Solaris test
 results for 2.10, 2.9, and 2.8 looked fine for the last month and a half,
 so I'd assumed this patch was not problematic.

I think it is, up to Solaris 9, but the failure mode is not so blatant.

 As a side note, it's hard to deal with paging in and out WRT this bug report
 over two months. If we're supposed to care about Solaris-2.5-7, then please,
 post test results on a (at least) weekly basis.

I'd say that we (the GCC project) have to care about Solaris 7 and up only,
at this point.  I'm personally interested in Solaris 2.5.1 and 2.6 for some
reasons, but I will certainly not bug anyone about them.

And, yes, I try to post results on a weekly basis for all Solaris versions:
  http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01176.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01177.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01178.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01179.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01180.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01181.html

I don't have any for recent mainline though, but you probably have already
guessed why.


-- 


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

[Bug fortran/29670] [meta-bug] fortran interfaces

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2006-10-31 11:26 ---
(In reply to comment #0)
 As suggested in PR29652, a meta-bug for interfaces in fortran.

Oh thanks, Daniel - I was going to do it myself, so you have saved me a bit of
hassle.  We have a brief break from work (for All Saints, of all things!) so I
was going to try to understand where interfaces come from, and where they go to
when they are bad. I was just writing FX about it this morning, in fact...

Best regards

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-31 11:26:29
   date||


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

[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)

[razya at gcc dot gnu dot org]

--- Comment #4 from razya at gcc dot gnu dot org  2006-10-31 11:36 ---
Subject: Bug 29122

Author: razya
Date: Tue Oct 31 11:36:28 2006
New Revision: 118227

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118227
Log:
2006-10-31  Razya Ladklesky  [EMAIL PROTECTED]

* tree-inline.c (remap_decls): remap all TYPE_DECLs.
PR tree-optimization/29122
* tree-inline.c (tree_function_versioning): Update
DECL_ASSEMBLER_NAME
  for the new version.  Assign NULL to DECL_RTL of the new version.


Modified:
branches/ipa-branch/gcc/ChangeLog.ipa
branches/ipa-branch/gcc/tree-inline.c


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #9 from pcarlini at suse dot de  2006-10-31 11:38 ---
To be honest, I don't think this code has been designed with thread safety in
mind. Fixing it completely after the fact is going to be very complex, I'm
afraid. I'll try to spend some more time on those issues, but if Doug, the
original author, doesn't provide any special hint, I'm afraid we have to live
with that or even, for consistency, remove the minimal MT support currently
present and add something clear to the documentation.


-- 


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

[Bug fortran/29671] New: preprocessor statements must start in column 1

[franke dot daniel at gmail dot com]

Preprocessor statements (as if|else|endif|error|warning) must start in colum 1,
otherwise gfortran tries to handle them itself?!

$ cat pp.F90
PROGRAM test_preprocessor
 #error EEE ! whitespace is significant
END PROGRAM

$ gfortran-4.3 -g -Wall pp.F90
 In file pp.F90:3

 #error EEE
1
Error: Unclassifiable statement at (1)


$ cat pp.F90
PROGRAM test_preprocessor
#error EEE
END PROGRAM

$ gfortran-4.3 -g -Wall pp.F90
pp.F90:3: error: #error EEE


Filed this as fortran report since gcc bails out as expected and both run
(afaik) the same preprocessor:

$ cat pp.c
int main() {
  #error EEE /* whitespaces are not significant */
  return 0;
}

$ gcc-svn -g -Wall pp.c
pp.c:2:4: error: #error EEE


$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../svn/gcc/configure
--prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-svn --disable-nls
--enable-threads=posix --enable-shared --enable-bootstrap --with-system-zlib
--program-suffix=-svn --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.0 20061030 (experimental)


-- 
   Summary: preprocessor statements must start in column 1
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franke dot daniel at gmail dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #10 from pcarlini at suse dot de  2006-10-31 11:47 ---
... that said, if we don't care *at all* about performance, fixing MT-safety
bugs in the _Safe_sequence or _Safe_iterator functions it's easy, just use
everywhere the iterator_base_mutex. The nasty correctness problems are those
involving the templatized _Safe_iterator functions, which of course are not in
debug.cc.


-- 


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

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #16 from kreckel at ginac dot de  2006-10-31 11:48 ---
A quote from http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF:

While on the subject of miscreant compilers, we should remark their
increasingly common tendency to reorder operations that can be executed
concurrently by pipelined computers. C programmers may declare a variable
volatile to inhibit certain reorderings. A programmer's intention is thwarted
when an alleged 'optimization' moves a floating-point instruction past a
procedure-call intended to deal with a flag in the floating-point status word
or to write into the control word to alter trapping or rounding. Bad moves like
these have been made even by compilers that come supplied with such procedures
in their libraries. (See _control87 , _clear87 and _status87 in compilers for
Intel processors.) Operations’ movements would be easier to debug if they
were highlighted by the compiler in its annotated re-listing of the
source-code. Meanwhile, so long as compilers mishandle attempts to cope with
floating-point exceptions, flags and modes in the ways intended by IEEE
Standard 754, frustrated programmers will abandon such attempts and compiler
writers will infer wrongly that unexercised capabilities are unexercised for
lack of demand.


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #11 from pcarlini at suse dot de  2006-10-31 11:49 ---
(In reply to comment #10)
 ... that said, if we don't care *at all* about performance, fixing MT-safety
 bugs in the _Safe_sequence or _Safe_iterator functions it's easy,...

Of course I meant _Safe_sequence_base and _Safe_iterator_base, humpf.


-- 


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

[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)

[razya at il dot ibm dot com]

--- Comment #5 from razya at il dot ibm dot com  2006-10-31 12:08 ---
(In reply to comment #4)
 Subject: Bug 29122
 Author: razya
 Date: Tue Oct 31 11:36:28 2006
 New Revision: 118227
 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118227
 Log:
 2006-10-31  Razya Ladklesky  [EMAIL PROTECTED]
 * tree-inline.c (remap_decls): remap all TYPE_DECLs.
 PR tree-optimization/29122
 * tree-inline.c (tree_function_versioning): Update
 DECL_ASSEMBLER_NAME
   for the new version.  Assign NULL to DECL_RTL of the new 
 version.
 Modified:
 branches/ipa-branch/gcc/ChangeLog.ipa
 branches/ipa-branch/gcc/tree-inline.c

(In reply to comment #4)
 Subject: Bug 29122
 Author: razya
 Date: Tue Oct 31 11:36:28 2006
 New Revision: 118227
 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118227
 Log:
 2006-10-31  Razya Ladklesky  [EMAIL PROTECTED]
 * tree-inline.c (remap_decls): remap all TYPE_DECLs.
 PR tree-optimization/29122
 * tree-inline.c (tree_function_versioning): Update
 DECL_ASSEMBLER_NAME
   for the new version.  Assign NULL to DECL_RTL of the new 
 version.
 Modified:
 branches/ipa-branch/gcc/ChangeLog.ipa
 branches/ipa-branch/gcc/tree-inline.c

This was committed only on ipa branch (witth Hubicka's consent). This fix was
submitted for GCC4.3 and possibly for GCC4.2 
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01457.html


-- 


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

[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2006-10-31 12:19 ---
Subject: Bug number PR29122

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01457.html


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #12 from pcarlini at suse dot de  2006-10-31 12:19 ---
About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(),
thus only when the container itself is destructed. Therefore, I don't think it
may cause problems in practice.


-- 


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

[Bug fortran/29671] preprocessor statements must start in column 1

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2006-10-31 12:48 ---
The problem is that gfortran calls cpp with the -traditional-cpp option.

This causes some more modern constructs not to work and it also is the reason
behind your problem. (cf. PR 28662).

We need to use -traditional-cpp since some tokens in C are not
tokens in Fortran so you could get the wrong result. (A.P. in the other PR)

The solution is to modify cpp to know fortran tokens (when called with
-lang-fortran).

Note this problem is not limited to gfortran; e.g. the NAG f95 compiler uses
Sun's public-domain fpp (netlib.org/fortran/), which has similar problems.


-- 


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

[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2006-10-31 13:03 ---
Confirm my bug. See also 29671 (# must be in the first column).


-- 

burnus 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-10-31 13:03:00
   date||


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

[Bug fortran/29671] preprocessor statements must start in column 1

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2006-10-31 13:02 ---
Confirm and mark as enhancement.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-31 13:02:35
   date||


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

[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2006-10-31 12:54 ---
 This is a useful improvement to an enhancement, so I have marked it as
 enhancement.

I'd call improvement to an enhancement an euphemism as it produces wrong code
(uninitialized variables), albeit it is not easy to trigger this bug.
Fixes of an enhancement would be a better description.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[l_heldt at poczta dot onet dot pl]

--- Comment #13 from l_heldt at poczta dot onet dot pl  2006-10-31 13:12 
---
(In reply to comment #12)
 About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(),
 thus only when the container itself is destructed. Therefore, I don't think it
 may cause problems in practice.
 

Unfortunatelly it may. Suppose there are two threads: consumer/producer where
producer is creating container, taking iterator to the container and passing
the container to consumer thread.  Consumer thread is simply deallocating the
container - thus calling _M_detach_all function. At the same time iterator
destructor is called which causes SIGSEGV.

We actually encountered this problem - this is not taken from code review only.


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[l_heldt at poczta dot onet dot pl]

--- Comment #15 from l_heldt at poczta dot onet dot pl  2006-10-31 13:42 
---
(In reply to comment #14)
 (In reply to comment #13)
  We actually encountered this problem - this is not taken from code review 
  only.
 
 Again, adding a mutex to that those *_base functions it's trivial. Now, please
 start preparing reduced testcases for such issues, because apprently you 
 *know*
 how to do that. The approach No test case - no bug maybe can be considered
 naive as you say, on the other hand enforcing it eventually makes for sound
 software engineering, because would be even more naive to rely on submitter
 itself and no one else in the world to test a candidate fix, thus not being
 able to avoid regressions at a later stage within the project.
 

I tried to prepare a simple testcase but without any success. It seems to be
extremely hard to hit the moment when pointers are actually changed. Trivial
programs do not reveal the problem.


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #16 from pcarlini at suse dot de  2006-10-31 13:45 ---
(In reply to comment #15)
 I tried to prepare a simple testcase but without any success. It seems to be
 extremely hard to hit the moment when pointers are actually changed. Trivial
 programs do not reveal the problem.

Ok, but you should try harder, because often in the past we managed to prepare
complete testcases for races and generally MT issues too, which seemed very
tricky at the outset. 


-- 


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

[Bug rtl-optimization/27883] [4.0/4.1 regression] in schedule_insns, at sched-rgn.c:3038 on mips

[amylaar at gcc dot gnu dot org]

--- Comment #17 from amylaar at gcc dot gnu dot org  2006-10-31 14:34 
---
(In reply to comment #4)
 It is curious that life2 is running immediately before sched, instead of
 immediately after combine.  If we ran it immediately after combine, we could
 get rid of the REG_DEAD/REG_UNUSED support in distribute_notes, which is
 probably the most complicated, and most buggy, part of combine.  This would
 also speed up the compiler a little bit.

The combiner itself relies on REG_DEAD notes to find out what it can combine.
If you leave an invalid REG_DEAD note, it can lead to wrong code being emitted.
If you don't leave in valid REG_DEAD notes in their proper place, multi-step
instruction combinations will stop working - and with the three insn limit on
any single combination, this is likely to stop quite a lot of combinations.
Most combiner bridge patterns will become useless.


-- 


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

[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

[hjl at lucon dot org]

--- Comment #10 from hjl at lucon dot org  2006-10-31 15:02 ---
It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.


-- 


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

[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

[dberlin at dberlin dot org]

--- Comment #11 from dberlin at gcc dot gnu dot org  2006-10-31 15:05 
---
Subject: Re:  [Tree-ssa] alias analysis deficiency

Details, source, etc needed.


On 31 Oct 2006 15:02:02 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:


 --- Comment #10 from hjl at lucon dot org  2006-10-31 15:02 ---
 It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.



-- 


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

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

[howarth at nitro dot med dot uc dot edu]

--- Comment #13 from howarth at nitro dot med dot uc dot edu  2006-10-31 
14:14 ---
As I mentioned to Jerry in a private email, his suggestion of...

Index: io/write.c
===
--- io/write.c  (revision 118229)
+++ io/write.c  (working copy)
@@ -468,6 +468,7 @@ output_float (st_parameter_dt *dtp, cons
   int i;
   sign_t sign;
   double abslog;
+  long tmp_e;

   ft = f-format;
   w = f-u.real.w;
@@ -554,7 +555,8 @@ output_float (st_parameter_dt *dtp, cons
   internal_error (dtp-common, printf is broken);

   /* Read the exponent back in.  */
-  e = atoi (buffer[ndigits + 3]) + 1;
+  tmp_e = atoi (buffer[ndigits + 3]) + 1;
+  e = (int) tmp-e;

   /* Make sure zero comes out as 0.0e0.  */
   if (value == 0.0)

eliminates the failure in the nan_inf_fmt.f90 testcase on Darwin PPC at all
optimizations as well as -m64. The failure is also suppressed by the simple
placement of...

st_printf(buffer=%s, buffer);

in front of the existing call to atoi().


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[bkoz at gcc dot gnu dot org]

--- Comment #18 from bkoz at gcc dot gnu dot org  2006-10-31 14:37 ---
 I tried to prepare a simple testcase but without any success.

This is encouraging, that you attempted it. To be clear: we just need something
that we can use to reproduce it. Please try for a complex or big testcase then,
and we'll try to reduce it ourselves.

We have many testcases that reproduce races. See testsuite/threads.

-benjamin


-- 


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

Re: [Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

[Daniel Berlin]

Details, source, etc needed.


On 31 Oct 2006 15:02:02 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:



--- Comment #10 from hjl at lucon dot org  2006-10-31 15:02 ---
It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #14 from pcarlini at suse dot de  2006-10-31 13:23 ---
(In reply to comment #13)
 We actually encountered this problem - this is not taken from code review 
 only.

Again, adding a mutex to that those *_base functions it's trivial. Now, please
start preparing reduced testcases for such issues, because apprently you *know*
how to do that. The approach No test case - no bug maybe can be considered
naive as you say, on the other hand enforcing it eventually makes for sound
software engineering, because would be even more naive to rely on submitter
itself and no one else in the world to test a candidate fix, thus not being
able to avoid regressions at a later stage within the project.


-- 


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

[Bug target/24071] __gthread_active_p vs __gthread_once

[ebotcazou at gcc dot gnu dot org]

--- Comment #15 from ebotcazou at gcc dot gnu dot org  2006-10-31 18:02 
---
Hopefully put to rest on mainline and 4.2 branch.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2006-10-31 16:01 
---
(In reply to comment #3)
 coredumping is easy, simply call abort() or kill(0,SIGSEGV)

The usual signal to request a core dump is SIGQUIT.

 However, I'm more a fan of either coredumping

Same opinion here.

 (or, if someone wants to spend the time, of creating a real strack-tracing
 function as the comercial compilers [and gdb] have).

Using unwind is the way to go for a more serious solution. It's how java does
it, for example (with addr2line to get file and line information). I had it
working on x86 at some point:

http://www.eleves.ens.fr/home/coudert/unwind.diff

I think it's a good point for someone trying to work on that.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-10-30 12:24:41 |2006-10-31 16:01:05
   date||


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #17 from pcarlini at suse dot de  2006-10-31 14:30 ---
Created an attachment (id=12517)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12517action=view)
Draft patch for the issue in Comment #8 only

For the last issue, can you try this patch? If it works, then probably we can
incrementally commit something similar, because it's decently clean and the
performance should not be affected, even slightly improved.


-- 


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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[fxcoudert at gcc dot gnu dot org]

--- Comment #18 from fxcoudert at gcc dot gnu dot org  2006-10-31 16:46 
---
(In reply to comment #16)
 I understood that remainder (a, b) = a - round (a/b) * b, whereas
   mod (a, b) = a - int (a/b) * b
   and modulo (a, b) = a - floor (a/b) * b

Right you are, master. :)


-- 


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

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2006-10-31 15:54 ---
Nice idea.


coredumping is easy, simply call abort() or kill(0,SIGSEGV)
and make sure that ulimit -c (csh: limit core) shows a big enough number.
This is actually what NAG f95 does and has the advantage that one can easily
investigate later. (And the stdout/stderr message can easily get be lost.)

We probably should implement this option first.
-ftrace=coredump or similar, or a envionment variable?
This is simple: Replacing the sys_exit() by if(coredump_option) abort() else
sys_exit()  in lingfortran/runtime/error.c.


Providing a trace is rather difficult, especially obtaining the symbol
information (what function in which file and which line), especially when it
should work everywhere including some strange Unix systems or MingW.

Using the glibc one can use backtrace() and backtrace_symbols() to get e.g.
./a.out [0x40088a]
/lib64/libc.so.6 [0x2b6c713bd5b0]
However, this misses the symbol information such as the name of the routine
(e.g. main__) and especially line number and source file.

Using dlvsym one can obtain more information, but it is not part of POSIX.

Searching the internet, one can find e.g. the refdbg lib which does some
backtracing, or gdb, which of cause does it as well. Some suggest something
along the lines of (a) got the current process' pid, (b) wrote a little gdb
command script into a /tmp file which would attach to the process, bt, and
detach, (c) ran system (gdb --command=/tmp...) in the function, and (d)
removed the file from /tmp.


If one seriously wants to have this feature, gdb-6.5/gdb/stack.c is probably a
good starting point.

An alternative solution is to do it as g95 does: There Andy adds all needed
information to a linked list, which contains filename and line.
This does not seem to work for my example and it slows down the program, but is
easier and more portable than extracting the symbol information.

However, I'm more a fan of either coredumping (or, if someone wants to spend
the time, of creating a real strack-tracing function as the comercial compilers
[and gdb] have).


-- 


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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[pault at gcc dot gnu dot org]

--- Comment #14 from pault at gcc dot gnu dot org  2006-10-31 15:56 ---
Created an attachment (id=12518)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12518action=view)
A fix for the PR:

FX and Uros,

I believe that this correctly detects the presence of the built_in.  It also
does MODULO correctly, although I am not sure that I understand why anybody
would use this intrinsic knowingly!

I have not done a full regtest, nor checked the timing yet, but the testsuite
cases with MOD and MODULO in them all survive.

Paul 


-- 


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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[fxcoudert at gcc dot gnu dot org]

--- Comment #15 from fxcoudert at gcc dot gnu dot org  2006-10-31 16:05 
---
(In reply to comment #14)
 It also does MODULO correctly

Why not use remainder{f,,l}? Is it incorrect?

 although I am not sure that I understand why anybody
 would use this intrinsic knowingly!

Agreed :)


-- 


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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[pault at gcc dot gnu dot org]

--- Comment #17 from pault at gcc dot gnu dot org  2006-10-31 16:21 ---
The fortran version of Uros' #13:

  real(8) :: x
  real(8) :: t = 0.0
  x = 1000.0
  do while (x  0.0)
t = t + mod (x, 1.7e-8)
x = x - 1.0
  end do
  print *, t
end

Yields:

$ /irun/bin/gfortran -O2 -march=pentium -mfpmath=387 uros_test.f90

[EMAIL PROTECTED] /cygdrive/d/svn/pr24518
$ time ./a
  8.48368231765E-002

real0m0.344s
user0m0.327s
sys 0m0.015s

on a PIV running at 2.5GHz

Changing MOD = MODULO, the user time increases to 0.405s for the
implementation in the second attachment.

Paul


-- 


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

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2006-10-31 16:02 
---
Created an attachment (id=12519)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12519action=view)
Example of how to use unwind for backtrace purposes

The patch I was quoting in my previous comment; here, it will never disappear.


-- 


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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[paul dot richard dot thomas at cea dot fr]

--- Comment #16 from paul dot richard dot thomas at cea dot fr  2006-10-31 
16:14 ---
Subject: RE:  Intrinsic MOD incorrect for large arg1/arg2 and slow.

FX,

 
 --- Comment #15 from fxcoudert at gcc dot gnu dot org  
 2006-10-31 16:05 ---
 (In reply to comment #14)
  It also does MODULO correctly
 
 Why not use remainder{f,,l}? Is it incorrect?

I understood that remainder (a, b) = a - round (a/b) * b, whereas
  mod (a, b) = a - int (a/b) * b
  and modulo (a, b) = a - floor (a/b) * b

but I am ready to stand corrected on the first.  The latter two are taken from
the fortran standard.

Paul


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-31 16:32:28
   date||


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #19 from pcarlini at suse dot de  2006-10-31 17:01 ---
Created an attachment (id=12520)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12520action=view)
Draft patch using the _M_get_mutex idiom for _M_invalidate

This one, instead, using the _M_get_mutex idiom (similarly to pool_allocator,
for example), should be able to deal with the _M_invalidate issue too. Agreed,
in debug-mode performance isn't the main concern, still I'm a bit worried,
because we have got one single mutex for the entire STL. But I have no idea how
this problem can be solved at this stage, the ABI still frozen. Besides that
general issue, the approach should work, maybe locking is needed also for some
_Safe_sequence functions: in that case _Safe_iterator_base::_M_get_mutex would
be still usable, being public, or, to be cleaner, an _M_get_mutex method could
be added to _Safe_sequence_base too. In any case, I would rather wait for
testcases before touching _Safe_sequence...

Benjamin, what do you think?


-- 


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

[Bug target/24071] __gthread_active_p vs __gthread_once

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2006-10-31 17:55 
---
Subject: Bug 24071

Author: ebotcazou
Date: Tue Oct 31 17:54:58 2006
New Revision: 118259

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118259
Log:
PR target/24071
* gthr-posix.h (__gthread_active_p): New implementation on Solaris.
* gthr-posix95.h (__gthread_active_p): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gthr-posix.h
trunk/gcc/gthr-posix95.h


-- 


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

[Bug target/24071] __gthread_active_p vs __gthread_once

[ebotcazou at gcc dot gnu dot org]

--- Comment #14 from ebotcazou at gcc dot gnu dot org  2006-10-31 17:56 
---
Subject: Bug 24071

Author: ebotcazou
Date: Tue Oct 31 17:55:32 2006
New Revision: 118262

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118262
Log:
PR target/24071
* gthr-posix.h (__gthread_active_p): New implementation on Solaris.
* gthr-posix95.h (__gthread_active_p): Likewise.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/gthr-posix.h
branches/gcc-4_2-branch/gcc/gthr-posix95.h


-- 


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[l_heldt at poczta dot onet dot pl]

--- Comment #20 from l_heldt at poczta dot onet dot pl  2006-10-31 17:23 
---
(In reply to comment #16)
 (In reply to comment #15)
  I tried to prepare a simple testcase but without any success. It seems to be
  extremely hard to hit the moment when pointers are actually changed. Trivial
  programs do not reveal the problem.
 
 Ok, but you should try harder, because often in the past we managed to prepare
 complete testcases for races and generally MT issues too, which seemed very
 tricky at the outset. 
 

I think we are totally misunderstood here. I don't have time to prepare complex
test cases revealing problems not in my code. I have found the bug I even found
the cause of the bug and it is still not enough for you.

If you don't want to be informed about problems in stl then what is this
bugzilla for?

I have already made a workaround in my code to avoid the debug container in
certain situations so it's not me who will actually benefit from the fix.
I reported this issue to help other developers who might encounter similar
problem.
Because of version policies in my company probably I won't be even able to use
your fix.


-- 


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

[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

[hjl at lucon dot org]

--- Comment #9 from hjl at lucon dot org  2006-10-31 14:59 ---
FYI, the fix for this bug miscompiles gcc in SPEC CPU 2006 on both x86 and
x86-64.


-- 


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

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2006-10-31 
15:38 ---
Subject: Re:  jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes

  jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
  
 
 similiar problem here.
 
 hppa2.0w-hp-hpux11.00
 gcc-4.2.0 revison 118176

I've been trying to pin down when this was introduced.  This is
somewhat tricky.  Things seemed ok at revision 117843:
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01441.html.
Then, for other reasons the build of libjava was broken for
a couple of days.  Then, the 4.2 branch was created.

The problem appears to only be present in the 4.2 branch.  Given
that this is a apparently a garbage collection issue, it could be
that this failure isn't related to any specified patch, but is
caused by bad garbage collection limits.

Dave


-- 


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

[Bug target/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'

[sje at cup dot hp dot com]

--- Comment #5 from sje at cup dot hp dot com  2006-10-31 18:15 ---
I forgot to include the PR number in my ChangeLog entry but this defect is
fixed with the patch in comment #4.  It has been backported to the 4.0, 4.1,
and 4.2 branches as well as being checked in on the ToT.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/29673] New: no -fdump-tree-inlined output

[gcc-bugzilla at gcc dot gnu dot org]

`-fdump-tree-inlined' creates no files.

Environment:
System: Linux  2.2.19-7.1.asp.2.gin #1 Tue Jun 15 16:42:13 MSD 2004 i686
unknown
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure

How-To-Repeat:

List current directory.

Run with `-fdump-tree-inlined'.

List current directory.


-- 
   Summary: no -fdump-tree-inlined output
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 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=29673

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2006-10-31 18:37 ---
 Using unwind is the way to go for a more serious solution.
Looks nice as a starting point. (My biggest problem with developing this would
be to find out whether it works on strange machines like Sparc, Windows etc.)

 It's how java does it, for example (with addr2line to get file
 and line information).

[to spare others the searching] addr2line is part of binutils. Using binutils'
libbfd, resolving the symbols could be resolved compareably easily. (At least
it looks like this, glancing at binutils/addr2line.c).


Thus, in total I think I would like to have the following in gfortran:

- Support for coredumps (compile time? Environment variable? The latter
overwriting the former?)
[Advantage compile-time option: The core is there, if one needs it. Advantage
run-time option: One can quickly turn it on, if needed.]

- Traceback support more or less as outlined above (comment 4, comment 3),
which prints only the Hex address (similar to the unwind.diff, attachment
12519) or the backtrace_symbols() example in comment 3). One should mention the
addr2line program in the manpage/manual.

- Optionally, linking with libbfd and providing symbol-resolved traceback.


-- 


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

[Bug c/29674] New: strtok_r function prototype does not match function definition

[brandon at rioja dot us]

Sees:
When compiling using the -Wconversion flag the strtok_r the comppiler complains
with a 

warning: passing argument 2 of ‘__strtok_r_1c’ with different width due to
prototype

Expects:
No warning when the -Wconversion option is specified

System Info:
  gcc (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30)
  Linux brioja.netronome.com 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT  
 2006 i686 i686 i386 GNU/Linux
Also exists in:
  gcc34 (GCC) 3.4.6 20060404 (Red Hat 3.4.6-4)

Compile and run options:
[EMAIL PROTECTED] test]$ make  ./hello 
if gcc -DPACKAGE_NAME=\Hello\ Program\ -DPACKAGE_TARNAME=\hello\
-DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\Hello\ Program\ 1.0\
-DPACKAGE_BUGREPORT=\Author\ Of\ The\ Program\ \[EMAIL PROTECTED]\
-DPACKAGE=\hello\ -DVERSION=\1.0\  -I. -I.-Wconversion -g -O2 -MT
hello.o -MD -MP -MF .deps/hello.Tpo -c -o hello.o hello.c; \
then mv -f .deps/hello.Tpo .deps/hello.Po; else rm -f
.deps/hello.Tpo; exit 1; fi
hello.c: In function ‘main’:
hello.c:10: warning: passing argument 2 of ‘__strtok_r_1c’ with different width
due to prototype
gcc -Wconversion -g -O2   -o hello  hello.o  

[EMAIL PROTECTED] test]$ 

For source code hello.c:
#include unistd.h
#include stdio.h
#include string.h

int main()
{
  const char* delim = xy;
  char str[] = xyc;
  char *saved;
  printf(%s\n,strtok_r(str, delim, saved));
  return 0;
}

Works for strtok():
Regular strtok()'s function prototype matches its definiton.

#include unistd.h
#include stdio.h
#include string.h

int main()
{
  const char* delim = xy;
  char str[] = xyc;
  printf(%s\n,strtok(str, delim));
  return 0;
}

Note: 
Could the wrong function be being called? __strtok_r_1c sounds like a 1
character function.


-- 
   Summary: strtok_r function prototype does not match function
definition
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brandon at rioja dot us
 GCC build triplet: i686-redhat-linux-gnu
  GCC host triplet: i686-redhat-linux-gnu
GCC target triplet: i686-redhat-linux-gnu


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

Re: [Bug libfortran/29649] Force core dump on runtime library errors

[Andrew Pinski]

 - Support for coredumps (compile time? Environment variable? The latter
 overwriting the former?)
 [Advantage compile-time option: The core is there, if one needs it. Advantage
 run-time option: One can quickly turn it on, if needed.]
 
 - Traceback support more or less as outlined above (comment 4, comment 3),
 which prints only the Hex address (similar to the unwind.diff, attachment
 12519) or the backtrace_symbols() example in comment 3). One should mention 
 the
 addr2line program in the manpage/manual.
 
 - Optionally, linking with libbfd and providing symbol-resolved traceback.

Unless you want to make your program GPL, I would go against this.  This is why
for libgcj, they have not linked it in yet.

-- Pinski

[Bug libfortran/29649] Force core dump on runtime library errors

[pinskia at physics dot uc dot edu]

--- Comment #7 from pinskia at physics dot uc dot edu  2006-10-31 19:10 
---
Subject: Re:  Force core dump on runtime library errors

 - Support for coredumps (compile time? Environment variable? The latter
 overwriting the former?)
 [Advantage compile-time option: The core is there, if one needs it. Advantage
 run-time option: One can quickly turn it on, if needed.]
 
 - Traceback support more or less as outlined above (comment 4, comment 3),
 which prints only the Hex address (similar to the unwind.diff, attachment
 12519) or the backtrace_symbols() example in comment 3). One should mention 
 the
 addr2line program in the manpage/manual.
 
 - Optionally, linking with libbfd and providing symbol-resolved traceback.

Unless you want to make your program GPL, I would go against this.  This is why
for libgcj, they have not linked it in yet.

-- Pinski


-- 


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

[Bug c/29674] strtok_r function prototype does not match function definition

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-31 19:12 ---
__strtok_r_1c is due to glibc having a define for strtok_r so this is not a bug


-- 

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

[Bug bootstrap/29620] can not build libgcc.a on stage 1

[gin at mo dot msk dot ru]

--- Comment #3 from gin at mo dot msk dot ru  2006-10-31 19:17 ---
Subject: Re:  can not build libgcc.a on stage 1

Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is
certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of
4.1.1 release.


-- 


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

[Bug bootstrap/29620] can not build libgcc.a on stage 1

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2006-10-31 19:36 
---
 Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is
 certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of
 4.1.1 release.

It is not obsolete, it is not supported.  Sun did the same ages ago.


-- 


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

[Bug ada/27776] ICE on limited with and instantiation

[charlet at gcc dot gnu dot org]

--- Comment #3 from charlet at gcc dot gnu dot org  2006-10-31 19:41 ---
Fixed on mainline.

Arno


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

--- Comment #27 from ghazi at gcc dot gnu dot org  2006-10-31 20:08 ---
(In reply to comment #26)
 Yes, it's true that it is useful to have this value. But determining it
 separately is quite easy, without taking a noticeable additional time in
 average.

It's likely that I'll end up doing it, so would you please tell me how?
Thanks.


-- 


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

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

[fxcoudert at gcc dot gnu dot org]

--- Comment #18 from fxcoudert at gcc dot gnu dot org  2006-10-31 20:15 
---
Subject: Bug 29067

Author: fxcoudert
Date: Tue Oct 31 20:15:22 2006
New Revision: 118338

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118338
Log:
PR fortran/29067

* decl.c (gfc_set_constant_character_len): NULL-terminate the
character constant string.
* data.c (create_character_intializer): Likewise.
* expr.c (gfc_simplify_expr): NULL-terminate the substring
character constant.
* primary.c (match_hollerith_constant): NULL-terminate the
character constant string.

* gfortran.dg/pr29067.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr29067.f
Modified:
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/29627] partial unformatted reads shouldn't succeed

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2006-10-31 20:58 ---
Subject: Bug 29627

Author: tkoenig
Date: Tue Oct 31 20:58:26 2006
New Revision: 118341

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118341
Log:
2006-10-31  Thomas Koenig  [EMAIL PROTECTED]

PR libfortran/29627
* libgfortran.h: Add ERROR_SHORT_RECORD
* runtime/error.c (translate_error): Add case
for ERROR_SHORT_RECORD.
* io/transfer.c (read_block_direct):  Separate codepaths
for stream and record unformatted I/O.  Remove unneeded
tests for standard input, padding and formatted I/O.
If the record is short, read in as much data as possible,
then raise the error.

2006-10-31  Thomas Koenig  [EMAIL PROTECTED]

PR libfortran/29627
* gfortran.dg/unf_short_record_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/unf_short_record_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c


-- 


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

[Bug fortran/29677] New: minimally informative gfortran -fbounds-check

[mkeehan at lic dot co dot nz]

My boss teared my hair off with heavy sarcasm when we turned on -fbound-check.

The runtime executable proudly reported an array reference out of bounds.

My boss screamed Which bloody one?!

While I am very happy to know we have an array reference out of bounds
I can see his point. Could the error message say which array is out of bounds? 

gfortran 4.1.1


-- 
   Summary: minimally informative  gfortran -fbounds-check
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkeehan at lic dot co dot nz
  GCC host triplet: SLES 9 opteron
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)

[tobias dot burnus at physik dot fu-berlin dot de]

--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de  
2006-10-31 21:37 ---
Steve Lionel from Intel wrote
http://groups.google.com/group/comp.lang.fortran/tree/browse_frm/thread/062ce3447e5ef570/7e2c6b5723c3b228#doc_a7f0b804f755e27b

For a record length greater than 2,147,483,639 bytes, the record is
divided into subrecords. The subrecord can be of any length from 1 to
2,147,483,639, inclusive.

The sign bit of the leading length field indicates whether the record
is continued or not. The sign bit of the trailing length field
indicates the presence of a preceding subrecord. The position of the
sign bit is determined by the endian format of the file.

A subrecord that is continued has a leading length field with a sign
bit value of 1. The last subrecord that makes up a record has a leading
length field with a sign bit value of 0. A subrecord that has a
preceding subrecord has a trailing length field with a sign bit value
of 1. The first subrecord that makes up a record has a trailing length
field with a sign bit value of 0.


-- 

tobias dot burnus at physik dot fu-berlin dot de changed:

   What|Removed |Added

 CC||tobias dot burnus at physik
   ||dot fu-berlin dot de


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

[Bug fortran/29677] minimally informative gfortran -fbounds-check

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2006-10-31 21:38 ---
Upgrade to the a 4.2 pre-release version of gfortran or
the mainline version.  Please report back if you find
a problem.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/29677] minimally informative gfortran -fbounds-check

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-10-31 21:41 ---
The other thing is with debugging option such as -fbounds-check, you can also
use gdb to figure out which one.


-- 


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

[Bug fortran/29678] New: minimally informative gfortran -fbounds-check

[mkeehan at lic dot co dot nz]

My boss teared my hair off with heavy sarcasm when we turned on -fbound-check.

The runtime executable proudly reported an array reference out of bounds.

My boss screamed Which bloody one?!

While I am very happy to know we have an array reference out of bounds
I can see his point. Could the error message say which array is out of bounds? 

gfortran 4.1.1


-- 
   Summary: minimally informative  gfortran -fbounds-check
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkeehan at lic dot co dot nz
  GCC host triplet: SLES 9 opteron
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/29678] minimally informative gfortran -fbounds-check

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-31 21:48 ---


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


-- 

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

[Bug fortran/29677] minimally informative gfortran -fbounds-check

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-10-31 21:48 ---
*** Bug 29678 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

[hjl at lucon dot org]

--- Comment #12 from hjl at lucon dot org  2006-10-31 21:48 ---
Created an attachment (id=12521)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12521action=view)
A testcase

Here is a testcase. Both bad.s and good.s are compiled with -O2. The
difference in assembly output is

[EMAIL PROTECTED] xxx]$ diff -up bad.s good.s
--- bad.s   2006-10-31 13:22:44.0 -0800
+++ good.s  2006-10-31 13:22:44.0 -0800
@@ -31,14 +31,14 @@ add_fde_cfi:
pushq   %rbx
 .LCFI2:
movq%rdi, %rbx
-   je  .L36
+   je  .L35
movlfde_table_in_use(%rip), %eax
subl$1, %eax
leaq(%rax,%rax,4), %rax
leaq0(,%rax,8), %rbp
addqfde_table(%rip), %rbp
cmpb$0, (%rdi)
-   je  .L37
+   je  .L36
 .L16:
movq8(%rbp), %rsi
testq   %rsi, %rsi
@@ -46,7 +46,7 @@ add_fde_cfi:
movq%rbx, %rdi
callstrcmp
testl   %eax, %eax
-   je  .L38
+   je  .L20
 .L18:
movq%rbx, %rdi
callxstrdup
@@ -55,54 +55,50 @@ add_fde_cfi:
callnew_cfi
movq%rbx, 16(%rax)
movq24(%rbp), %rdx
-   leaq24(%rbp), %rsi
+   leaq24(%rbp), %rcx
movl$4, 8(%rax)
testq   %rdx, %rdx
-   movq%rdx, %rcx
-   je  .L24
+   je  .L23
.p2align 4,,7
-.L25:
-   movq%rcx, %rsi
-   movq(%rcx), %rcx
-   testq   %rcx, %rcx
-   jne .L25
-.L24:
-   movq%rax, (%rsi)
-.L21:
+.L30:
+   movq%rdx, %rcx
+   movq(%rdx), %rdx
testq   %rdx, %rdx
+   jne .L30
+.L23:
+   movq%rax, (%rcx)
+.L20:
+   movq24(%rbp), %rdx
leaq24(%rbp), %rax
-   je  .L28
+   testq   %rdx, %rdx
+   je  .L26
.p2align 4,,7
-.L32:
+.L31:
movq%rdx, %rax
movq(%rdx), %rdx
testq   %rdx, %rdx
-   jne .L32
-.L28:
+   jne .L31
+.L26:
movq%r12, (%rax)
popq%rbx
popq%rbp
popq%r12
ret
-.L38:
-   movq24(%rbp), %rdx
-   jmp .L21
-.L37:
+.L36:
calldwarf2out_cfi_label
movq%rax, %rbx
-   .p2align 4,,4
jmp .L16
-.L36:
+.L35:
movqcie_cfi_head(%rip), %rax
movl$cie_cfi_head, %edx
testq   %rax, %rax
je  .L15
.p2align 4,,7
-.L31:
+.L29:
movq%rax, %rdx
movq(%rax), %rax
testq   %rax, %rax
-   jne .L31
+   jne .L29
 .L15:
movq%r12, (%rdx)
popq%rbx
@@ -220,5 +216,5 @@ add_fde_cfi:
.uleb128 0x3
.align 8
 .LEFDE3:
-   .ident  GCC: (GNU) 4.3.0 20061023 (experimental) [trunk revision
117986]
+   .ident  GCC: (GNU) 4.3.0 20061023 (experimental) [trunk revision
117985]
.section.note.GNU-stack,,@progbits


-- 


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

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

--- Comment #28 from vincent at vinc17 dot org  2006-10-31 22:15 ---
(In reply to comment #27)
 It's likely that I'll end up doing it, so would you please tell me how?

According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if
[iff] x  0  remainder(floor(x), 2) != 0. But if x is a non-positive integer,
the sign of gamma(x) isn't defined. Handle these cases first.

The test x  0 is easy to do. In MPFR, you can compute floor(x) (or trunc(x))
with the precision min(PREC(x),max(EXP(x),MPFR_PREC_MIN)), but then, there's no
direct function to decide whether the result is even or odd (I thought we added
this, but this isn't the case). The solution can be to divide x by 2 (this is
exact, except in case of underflow) and call mpfr_frac directly. If the result
is between -0.5 and 0, then gamma(x) is negative. If the result is between -1
and -0.5, then gamma(x) is positive. So, a 2-bit precision for mpfr_frac should
be sufficient (as -0.5 is representable in this precision), but choose a
directed rounding (not GMP_RNDN) for that. Then you can just do a comparison
with -0.5; the case of equality with -0.5 depends on the chosen rounding (if
you obtain -0.5, then it is an inexact result since x is not an integer). For
instance, if you choose GMP_RNDZ, then a result  -0.5 means that gamma(x) is
negative, and a result = -0.5 means that gamma(x) is positive.


-- 


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

[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

[hjl at lucon dot org]

--- Comment #13 from hjl at lucon dot org  2006-10-31 22:22 ---
Created an attachment (id=12522)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12522action=view)
A smaller testcase

Here is a smaller testcase.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

  Attachment #12521|0   |1
is obsolete||


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

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2006-10-31 23:24 
---
Jack,

I don't think this is the final fix.  However, after you test that other
possibility I sent you I think I can finalize a patch.  If zero terminating
buffer does not solve the problem, then I think it confirms the real problem
and this is just a hack around.


-- 


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

[Bug rtl-optimization/29631] [4.1 regression] bug with promoted induction variable

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-10-31 23:34 
---
Subject: Bug 29631

Author: ebotcazou
Date: Tue Oct 31 23:34:05 2006
New Revision: 118346

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118346
Log:
PR rtl-optimization/29631
* loop.c (basic_induction_var): Add new parameter inner_mode.
PLUS: If set, convert the increment to it before sign-extending.
CONST_INT: Likewise.
SUBREG: Set it.
ASHIFTRT: Likewise.  Return 0 if flag_wrapv.


Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20061031-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/loop.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/29631] [4.1 regression] bug with promoted induction variable

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2006-10-31 23:38 
---
Should be fixed now.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2006-
   ||10/msg01750.html
 Status|ASSIGNED|RESOLVED
  Known to fail||3.4.0
 Resolution||FIXED


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

[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit

[aldot at gcc dot gnu dot org]

--- Comment #11 from aldot at gcc dot gnu dot org  2006-10-31 23:39 ---
Subject: Bug 29537

Author: aldot
Date: Tue Oct 31 23:38:58 2006
New Revision: 118347

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118347
Log:
fortran/ChangeLog:
2006-11-01  Bernhard Fischer  [EMAIL PROTECTED]

PR fortran/29537
* trans-common.c (gfc_trans_common): If the blank common is
in a procedure or program without a name then proc_name is null, so use
the locus of the common.
(gfc_sym_mangled_common_id): Fix whitespace.
* match.c (gfc_match_common): Emit warning about blank common in
block data.

testsuite/ChangeLog:
2006-11-01  Bernhard Fischer  [EMAIL PROTECTED]

PR fortran/29537
* gfortran.dg/blockdata_1.f90: Add warning about blank common in block
data.
* gfortran.dg/blockdata_2.f90: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/blockdata_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/trans-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/blockdata_1.f90


-- 


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

[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit

[aldot at gcc dot gnu dot org]

--- Comment #12 from aldot at gcc dot gnu dot org  2006-10-31 23:42 ---
(In reply to comment #10)

 Bernhard, 
 
 This is ok for trunk.

Thanks. Worth backporting this to 4.2 (and 4.1) in a week or two? 


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aldot at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-31 23:42:41
   date||


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

[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #13 from sgk at troutmask dot apl dot washington dot edu  
2006-10-31 23:47 ---
Subject: Re:  ICE in gfc_match_common for blank common in BLOCK DATA unit

On Tue, Oct 31, 2006 at 11:42:42PM -, aldot at gcc dot gnu dot org wrote:
 
  Bernhard, 
  
  This is ok for trunk.
 
 Thanks. Worth backporting this to 4.2 (and 4.1) in a week or two? 
 

Sure.  If you're willing to spend the time and effort to 
regression test the patch.  However, I fear 4.1 is going to
become like 4.0.x.  Too few people too many branches. 


-- 


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

[Bug fortran/29679] New: Inability to get shapes correct in initializations

[eedelman at gcc dot gnu dot org]

In this code, the shape of 'a1(1,1:3)' in the initialization of b1 should be 3,
but it is appearantly '1 3', i.e. we fail to remove the '1' from the
shape-list.

erik:~/gcc$ cat bug.f90
program init
implicit none
integer, parameter :: a1(2,6) = reshape([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 
 11, 12], [2,6])
integer :: b1(3) = a1(1,1:3)
end program init
erik:~/gcc$ gfortran bug.f90
 In file bug.f90:5

integer :: b1(3) = a1(1,1:3)
   1
Error: different shape for Array assignment at (1) on dimension 1 (3/1)


-- 
   Summary: Inability to get shapes correct in initializations
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: eedelman at gcc dot gnu dot org
ReportedBy: eedelman at gcc dot gnu dot org
OtherBugsDependingO 29630
 nThis:


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

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

[pcarlini at suse dot de]

--- Comment #21 from pcarlini at suse dot de  2006-10-31 23:53 ---
(In reply to comment #20)
 I think we are totally misunderstood here.

No, no, there is something *completely* different to it. Sorry, but I'm now
convinced that you are here with the *wrong* spirit, aren't technical matters
to divide us. At all. Did you ever read any of Stallman' papers? Try, just a
little  harder than you are willing to to do to help GCC improving, and you
will see that you got the Free Software spirit wrong:

  http://www.fsf.org/


-- 


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

[Bug tree-optimization/29680] New: Misscompilation of spec2006 gcc

[rakdver at gcc dot gnu dot org]

The fix for PR14784 causes misscompilation of gcc in spec2006, at -O2.  Some
discussion of the problem is in PR14784, I am moving it to a separate bug
report.


-- 
   Summary: Misscompilation of spec2006 gcc
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, alias
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux,x86_64-pc-linux


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

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

[rakdver at gcc dot gnu dot org]

--- Comment #1 from rakdver at gcc dot gnu dot org  2006-11-01 00:07 ---
Created an attachment (id=12523)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12523action=view)
The testcase.


-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

[rakdver at gcc dot gnu dot org]

--- Comment #2 from rakdver at gcc dot gnu dot org  2006-11-01 00:12 ---
The problematic piece of .alias5 dump:

  p_27 = fde_13-dw_fde_cfi;
  #   VUSE SMT.48_79;
  D.1763_23 = fde_13-dw_fde_cfi;
  if (D.1763_23 != 0B) goto L8; else goto L10;

  # p_18 = PHI p_30(9), p_27(8);
L10:;
  #   cie_cfi_head_82 = V_MAY_DEF cie_cfi_head_73;
  *p_18 = xcfi_22;

The store to *p_18 and the load of fde_13-dw_fde_cfi obviously alias,
however their virtual operands are disjoint.  I am trying to find out why this
happens.


-- 


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

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

[rakdver at gcc dot gnu dot org]

--- Comment #3 from rakdver at gcc dot gnu dot org  2006-11-01 00:49 ---
access_can_touch_variable determines that fde_13-dw_fde_cfi cannot touch
cie_cfi_head; the list of virtual operands of the load thus becomes empty, and
we insert SMT.48 for it.

On *p, we cannot eliminate cie_cfi_head, and since the condition for insertion
of SMT is formulated as

  ...
  ||none_added
  || (TREE_CODE (var) == SYMBOL_MEMORY_TAG
   for_clobber
   SMT_USED_ALONE (var)))

and for_clobber is only true on call operands, we do not insert SMT.  The lists
of virtual operands thus become disjoint.

Daniel, any idea how to fix this?  I do not quite understand the SMT_USED_ALONE
stuff.  The condition above looks suspicious to me, especially the test for
for_clobber -- why should we want to handle call virtual operands differently
from any others? Obviously, removing the for_clobber test would fix this
problem, but I am not really sure this would be the right solution.


-- 


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

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

[dberlin at dberlin dot org]

--- Comment #4 from dberlin at gcc dot gnu dot org  2006-11-01 01:29 ---
Subject: Re:  Misscompilation of spec2006 gcc


 --- Comment #3 from rakdver at gcc dot gnu dot org  2006-11-01 00:49 
 ---
 access_can_touch_variable determines that fde_13-dw_fde_cfi cannot touch
 cie_cfi_head; the list of virtual operands of the load thus becomes empty, and
 we insert SMT.48 for it.

 On *p, we cannot eliminate cie_cfi_head, and since the condition for insertion
 of SMT is formulated as

   ...
   ||none_added
   || (TREE_CODE (var) == SYMBOL_MEMORY_TAG
for_clobber
SMT_USED_ALONE (var)))

 and for_clobber is only true on call operands, we do not insert SMT.  The 
 lists
 of virtual operands thus become disjoint.
We should not insert the SMT here.
We are never supposed to use a bare SMT when it has aliases that we
can use (IE something has not been pruned).

In other words, we assume we can prune the same set of aliases
regardless of where the access occurs.  This *was* true before your
patch.


 Daniel, any idea how to fix this?  I do not quite understand the 
 SMT_USED_ALONE
 stuff.  The condition above looks suspicious to me, especially the test for
 for_clobber -- why should we want to handle call virtual operands 
 differently
 from any others?

SMT_USED_ALONE is used to eliminate the need for SMT operands on calls
when the only place the SMT is used is to be def'd at call sites (IE
it has no real uses).

The real problem here is that we can't get away with pruning some but
not all accesses to the same variables in the current tag scheme.

Obviously, removing the for_clobber test would fix this
 problem, but I am not really sure this would be the right solution.

It would not. The test does not exist in isolation, you'd have to
remove the whole block for that |, and that wouldn't fix your problem.

I will work around this problem by teaching PTA about casts from
nonpointers to pointers, which will cause it to end up with a nonlocal
var in the set.

However, this is going to lose precision in this particular instance.

Until our tagging system is based on load/store interference, and not
variables this name can access, we will always run into these issues.


-- 


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

[Bug middle-end/23470] a*a (for floats) is not considered always postive (-ffast-math only)

[sayle at gcc dot gnu dot org]

--- Comment #3 from sayle at gcc dot gnu dot org  2006-11-01 02:56 ---
Subject: Bug 23470

Author: sayle
Date: Wed Nov  1 02:56:45 2006
New Revision: 118355

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118355
Log:

PR middle-end/23470
* tree.h (tree_expr_nonnegative_p): Return bool instead of int.
* fold-const.c (tree_expr_nonnegative_p): Likewise.  Consider
pow(x,y) and powi(x,y) to be nonnegative if either x is nonnegative
or y is an even integer.

* gcc.dg/pr23470-1.c: New test case.


Added:
trunk/gcc/testsuite/gcc.dg/pr23470-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.h


-- 


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

[Bug tree-optimization/23452] Optimizing CONJG_EXPR (a) * a

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-11-01 04:30 ---
(In reply to comment #3)
 This is now fixed on mainline provided the user specifies -ffast-math.
 There are some complications where imagpart(z*~z) can be non-zero, if
 imagpart(z) is non-finite, such as an Inf or a NaN.  It's unclear from
 the fortran-95 standard whether gfortran is allowed to optimize this
 even without -ffast-math.

Well Fortran 95 does not have non-finite except with a TR and the IEEE fp
types, I forgot the number and the name


-- 


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

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2006-11-01 
04:33 ---
   I have pinned down the problem. On Darwin PPC with Xcode 2.4, at -O1 or
higher we have problems with the isfinite() macro from libgfortran.h. For the
nan_inf_fmt testcase it should always return 0, but
it doesn't at -O1 or higher. I think we are seeing the same glitch that was
fixed in python for gcc 4.2.
The current macro looks like...

#if !defined(isfinite)
#if !defined(fpclassify)
#define isfinite(x) ((x) - (x) == 0)
#else
#define isfinite(x) (fpclassify(x) != FP_NAN  fpclassify(x) != FP_INFINITE)
#endif /* !defined(fpclassify) */
#endif /* !defined(isfinite)  */

I think it we need to cast both x variables in the macro to unsigned long.


-- 


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

[Bug c/11377] fault or warn modifiable static in extern inline definition

[geoffk at gcc dot gnu dot org]

--- Comment #5 from geoffk at gcc dot gnu dot org  2006-11-01 04:47 ---
Subject: Bug 11377

Author: geoffk
Date: Wed Nov  1 04:47:30 2006
New Revision: 118356

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118356
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.

PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments.  Disallow overriding
of inline functions in a translation unit in C99.  Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables.  Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions.  Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline.  Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.

PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.

Added:
trunk/gcc/testsuite/gcc.dg/inline-13.c
trunk/gcc/testsuite/gcc.dg/inline-14.c
trunk/gcc/testsuite/gcc.dg/inline-15.c
trunk/gcc/testsuite/gcc.dg/inline-16.c
trunk/gcc/testsuite/gcc.dg/inline6.c
trunk/gcc/testsuite/gcc.dg/inline7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/c-tree.h
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/inline-10.c


-- 


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

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

[geoffk at gcc dot gnu dot org]

--- Comment #13 from geoffk at gcc dot gnu dot org  2006-11-01 04:47 ---
Subject: Bug 16622

Author: geoffk
Date: Wed Nov  1 04:47:30 2006
New Revision: 118356

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118356
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.

PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments.  Disallow overriding
of inline functions in a translation unit in C99.  Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables.  Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions.  Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline.  Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.

PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.

Added:
trunk/gcc/testsuite/gcc.dg/inline-13.c
trunk/gcc/testsuite/gcc.dg/inline-14.c
trunk/gcc/testsuite/gcc.dg/inline-15.c
trunk/gcc/testsuite/gcc.dg/inline-16.c
trunk/gcc/testsuite/gcc.dg/inline6.c
trunk/gcc/testsuite/gcc.dg/inline7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/c-tree.h
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/inline-10.c


-- 


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

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2006-11-01 04:48 
---
(In reply to comment #15)
 I think it we need to cast both x variables in the macro to unsigned long.

No, that would be incorrect.
Jack, can you attach the preprocessed source for write.c?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

[geoffk at gcc dot gnu dot org]

--- Comment #14 from geoffk at gcc dot gnu dot org  2006-11-01 04:48 ---
Subject: Bug 16622

Author: geoffk
Date: Wed Nov  1 04:48:15 2006
New Revision: 118357

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118357
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.

PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments.  Disallow overriding
of inline functions in a translation unit in C99.  Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables.  Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions.  Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline.  Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.

PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.

Modified:
trunk/gcc/doc/extend.texi


-- 


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

[Bug c/11377] fault or warn modifiable static in extern inline definition

[geoffk at gcc dot gnu dot org]

--- Comment #6 from geoffk at gcc dot gnu dot org  2006-11-01 04:48 ---
Subject: Bug 11377

Author: geoffk
Date: Wed Nov  1 04:48:15 2006
New Revision: 118357

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118357
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.

PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments.  Disallow overriding
of inline functions in a translation unit in C99.  Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables.  Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions.  Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline.  Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.

PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.

Modified:
trunk/gcc/doc/extend.texi


-- 


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

[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of

[geoffk at gcc dot gnu dot org]

--- Comment #9 from geoffk at gcc dot gnu dot org  2006-11-01 04:53 ---
Subject: Bug 15834

Author: geoffk
Date: Wed Nov  1 04:53:33 2006
New Revision: 118358

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118358
Log:
PR 15834
* config/darwin.h (NO_IMPLICIT_EXTERN_C): Define.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin.h


-- 


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

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2006-11-01 04:56 
---
Jack is right about one thing and I should have noticed this.  For that test
case we should never get into output_float where we are segfaulting.  The
handling of nan and inf are handled in the calling function write_float.  So
optimization is breaking something.


-- 


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