[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-05-19 07:31 ---
Created an attachment (id=17891)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17891&action=view)
gcc45-pr40174.patch

thr->release is owned by thread, not team, and is initialized by the thread, so
it should be each thread that destroys it as well, not the team.

Can you please try this patch instead?  It makes no difference on Linux,
because gomp_sem_destroy is empty inline, so I can't verify it easily.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/35623] RTL check failure in arm_const_double_rtx

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-05-19 08:24 ---
(In reply to comment #1)
> I've been bootstrapping trunk pretty regularly for arm-linux-gnueabi on the
> compile farm (though not building with latest libc) and haven't seen such a
> problem .

Note that the bug report is for OABI. I cannot reproduce it with EABI gcc-4.2.4
or gcc-4.3.4-20090517 on the preprocessed test case.


-- 


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

[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2009-05-19 09:11 ---
(In reply to comment #3)
> HJL is right, we should use the _r functions if available, if not we must
> protect the calls with a mutex.

Janne, if mutexes are added, could you also add a note to the docs of that
these function(s) may be a serialization point in OMP applications? Something
similar to RANDOM_NUMBER:

"Please note, this RNG is thread safe if used within OpenMP directives, i.e.,
its state will be consistent while called from multiple threads. However, the
KISS generator does not create random numbers in parallel from multiple
sources, but in sequence from a single source. If an OpenMP-enabled application
heavily relies on random numbers, one should consider employing a dedicated
parallel random number generator instead."

Thanks.

 Daniel


-- 


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

[Bug middle-end/40194] New: fortran rules for optimizing

[jv244 at cam dot ac dot uk]

The return value of this function is known at compile time, but from looking at
dump-tree-optimized this seems not to be optimized as such.

INTEGER FUNCTION F1()
  INTEGER :: I1
  INTEGER, TARGET :: I2
  INTEGER, POINTER :: IP

  INTERFACE
SUBROUTINE S(I1,I2)
  INTEGER,INTENT(IN) :: I1
  INTEGER, POINTER :: IP
END SUBROUTINE S
  END INTERFACE

  I1=1
  I2=1
  IP=>I2
  CALL S(I1,IP)
  IP=2

  F1=I1
END FUNCTION F1

F1=1 can be infered from the fact that it is an intent(in) argument of S (so
the value cant be changed within S), and the fact that I1 does not have the
target attributed, so can not be 'aliased' with the pointer IP.


-- 
   Summary: fortran rules for optimizing
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-05-19 10:01 ---
OK, updated testcase, while the argument still holds for the previous code,
this was the intended code, and the generated code is even worse:

INTEGER FUNCTION F1()
  INTEGER :: I1
  INTEGER, TARGET :: I2
  INTEGER, POINTER :: IP

  INTERFACE
SUBROUTINE S(I1,IP)
  INTEGER,INTENT(IN) :: I1
  INTEGER, POINTER :: IP
END SUBROUTINE S
  END INTERFACE

  I1=1
  I2=1
  IP=>I2
  CALL S(I1,IP)
  IP=2

  F1=I1
END FUNCTION F1


-- 


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

[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'

[to dot my dot trociny at gmail dot com]

--- Comment #2 from to dot my dot trociny at gmail dot com  2009-05-19 
10:06 ---
The patch works for me.

Actually, calling mutex_destroy in gomp_thread_start() before return was the
first my solution and it solved my problem too. But I am not very familiar with
libgomp so I was not completely sure if it was safe to release mutex then (I
did not do deep investigations how this mutex is used). Releasing it in
gomp_team_end(), when all other structures associated with team threads are
freed, looked safer for me :-). But it looks as I shouldn't have been so
paranoid. Thank you.


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-05-19 10:14 ---
the context of the report is 

http://gcc.gnu.org/ml/gcc/2009-05/msg00465.html

in particular, fortran variables are often not 'addressable' in the sense that
seems to be important of the gcc optimizers


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-19 10:20 ---
Does

SUBROUTINE S(I1,IP)
  INTEGER,INTENT(IN) :: I1
  INTEGER, POINTER :: IP
END SUBROUTINE S

allow that S stores the pointer to I1 to global memory?

I think that the easiest way to improve Fortran code generation is to _not_
pass INTENT(IN) arguments by reference but by value (at least for scalar
types).  Maybe the FE can use DECL_BY_REFERENCE and the middle-end that
to derive non-clobber/escape status.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-19 10:39 ---
Hmm, DECL_BY_REFERENCE is set too often.  Maybe in addition set/check
TREE_READONLY.


-- 


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

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[arjen dot verweij at tass-safe dot com]

--- Comment #8 from arjen dot verweij at tass-safe dot com  2009-05-19 
10:59 ---
We use xlf 10.1.0.0 5724-M1300 on AIX and there is no problem there. The V10
manual[x] also prohibits it, but I don't see the V12 manual stating they broke
backwards compatability, so I will assume that it works just fine with V12.

[x]
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlf101a.doc/xlfopg/smpdirdetails.htm

For your reference, we compile code in violation of the OpenMP standard just
fine on:

hpparisc: HP-UX f90 20030609 (172812) B3907DB/B3909DB B.11.01.67 PHSS_28996 HP
F90 v2.6.7
hpia64: HP-UX f90 B.11.23.22 PHSS_32711/PHSS_32712
ibm on g5: xlf 10.1.0.0 5724-M1300
linux24 ia32: Intel Fortran Version 8.1 Build 20050702Z
linux24 ia64: Intel Fortran Itanium compiler Version 9.0 Build 20050912
linux24_x86_64: PGI compiler pgf90 6.1-2
linux26-x86_64: PGI compiler pgf90 6.1-2
linux24-em64t: Intel Fortran Compiler ifort 9.1
sgi64r10k: Fortran 77, 7.4.3m

We also compile on win32 and win64 but I don't have the compiler specifics atm.
I have tried to figure out how it came to be that so many compilers are not
compliant, but I can't find a good source.


(In reply to comment #7)
I looked at other
> compilers and while IBM does not seem to allow it [1], Intel does not write
> anything about it [2] and for sun I couldn't find anything.
> [1]
> http://publib.boulder.ibm.com/infocenter/lnxpcomp/v101v121/topic/com.ibm.xlf121.linux.doc/proguide/threadprivate.html


-- 


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

[Bug fortran/40195] New: ICE when compiling a file located in another directory

[francois dot jacq at irsn dot fr]

D:\test\bin>gfortran -c ..\source\t2.f90
Fatal Error: Can't delete module file 'm.mod': Permission denied
gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See  for instructions.

File ..\source\t2.f90 :

MODULE m
END MODULE


-- 
   Summary: ICE when compiling a file located in another directory
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: francois dot jacq at irsn dot fr
 GCC build triplet: 20090421 (experimental) [trunk revision 146519]
  GCC host triplet: Window XP i386 MinGW
GCC target triplet: GNU Fortran (GCC) 4.5.0


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

[Bug target/40129] M16C invalid shift count used by pack_d -> ashldi3

[eightdot at hotmail dot com]

--- Comment #5 from eightdot at hotmail dot com  2009-05-19 11:23 ---
i agree but could find in which release they are first included..
but already fixed in what i now use (4.3.3)...


-- 

eightdot at hotmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/40196] New: F2003: Type parameter inquiry: str%len, a%kind

[burnus at gcc dot gnu dot org]

Type parameter inquiry:

str%len   is equivalent to   len(str)
  a%kind  is equivalent to   kind(a)

The real fun part starts with user-defined kinds, e.g.

type tp(dim)
  integer, KIND :: dim
  real :: dist(dim)
end type tp
type(tp) :: t(5)

print *, t%dist%dim


Quote from F2008 but F2003 should be the same:

"A type parameter inquiry is used to inquire about a type parameter of a data
object. It applies to both intrinsic and derived types.

R616  type-param-inquiry   is   designator % type-param-name

C622 (R616) The type-param-name shall be the name of a type parameter of the
declared type of the object designated by the designator.

A deferred type parameter of a pointer that is not associated or of an
unallocated allocatable variable shall not be inquired about."


-- 
   Summary: F2003: Type parameter inquiry: str%len, a%kind
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  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=40196

[Bug fortran/40196] F2003: Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-05-19 11:36 ---
Another related item are complex parts; contrary to the type parameter inquiry
above, those are lvalues and can be assigned to. (Again a F2003 feature, quote
is however from F2008.)

"R615  complex-part-designator  is  designator % RE
or  designator % IM

 C621 (R615) The designator shall be of complex type.

 If complex-part-designator is designator%RE it designates the real part of
 designator. If it is designator%IM it designates the imaginary part of
 designator. The type of a complex-part-designator is real, and its kind and
 shape are those of the designator.

 NOTE 6.6
  The following are examples of complex part designators:

   impedance%re !-- Same value as REAL(impedance)
   fft%im   !-- Same value as AIMAG(fft)
   x%im = 0.0   !-- Sets the imaginary part of X to zero"


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|F2003: Type parameter   |F2003: Type parameter
   |inquiry: str%len, a%kind|inquiry (str%len, a%kind)
   ||and Complex parts (z%re,
   ||z%im)


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2009-05-19 11:54 ---
(In reply to comment #3)
> Does
> 
> SUBROUTINE S(I1,IP)
>   INTEGER,INTENT(IN) :: I1
>   INTEGER, POINTER :: IP
> END SUBROUTINE S
> 
> allow that S stores the pointer to I1 to global memory?

this is not a very Fortran-ish way to express this, and I'm not very C-ish, but
the answer is no (I don't think you can obtain the address of I1 in S1 using
standard conforming Fortran, and certainly there is no guarantee at all that
you get the address of I1 in F1). Even if you get the address of I1, no way
you're allowed to change the value of I1, either in S1, or in any subroutine
called subsequently.

The important thing is not so much that (I believe), but the fact that Fortran
guarantees that in the caller where I1 is defined (i.e. F1), nothing else can
alias that variable.

> I think that the easiest way to improve Fortran code generation is to _not_
> pass INTENT(IN) arguments by reference but by value (at least for scalar
> types).

I believe that his is some kind of misunderstanding. It is not because the FE
generates some code that is call by reference that his is actually what the
rules are. AFAICT, it would be equally valid for a Fortran implementation to
copy in and copy out the data (i.e. the address of the variable in the caller
is of no importance in the callee).

I think it would be worthwhile to discuss this once with the group of
gcc-people that know both Fortran and the middle-end really well (I hope this
is a non-zero subset :-)


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-05-19 12:04 ---
The intel compiler passes I1 by value:

..___tag_value_f1_.1:   #1.18
subq  $24, %rsp #1.18
..___tag_value_f1_.3:   #
lea   12(%rsp), %rcx#15.3
movq  %rcx, (%rsp)  #15.3
lea   8(%rsp), %rdi #16.8
movl  $1, %edx  #13.3
xorl  %eax, %eax#16.8
movl  %edx, 8(%rsp) #13.3
movl  %edx, 12(%rsp)#14.3
lea   (%rsp), %rsi  #16.8
call  s_#16.8
# LOE rbx rbp r12 r13 r14 r15
..B1.2: # Preds ..B1.1
movq  (%rsp), %rdx  #17.3
movl  8(%rsp), %eax #20.1
movl  $2, (%rdx)#17.3
addq  $24, %rsp #20.1
..___tag_value_f1_.4:   #
ret #20.1

even though it's code generation is funny at -O2 ...


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-19 12:10 ---
Hm, no.  It doesn't pass it by value.


-- 


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

[Bug target/40197] New: Spu fortran does not build

[meissner at linux dot vnet dot ibm dot com]

Spu.h needs to define PTRDIFF_TYPE, since fortran now uses this in compiling
trans-types.  SIZE_TYPE probably should also be defined.

gcc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -fno-common  -DHAVE_CONFIG_H -I.
-Ifortran -I/home/meissner/fsf-src/trunk/gcc
-I/home/meissner/fsf-src/trunk/gcc/fortran
-I/home/meissner/fsf-src/trunk/gcc/../include
-I/home/meissner/fsf-src/trunk/gcc/../libcpp/include
-I/home/meissner/fsf-install-ppc64/gmp-4.2.2/include
-I/home/meissner/fsf-install-ppc64/mpfr-2.4.0/include
-I/home/meissner/fsf-src/trunk/gcc/../libdecnumber
-I/home/meissner/fsf-src/trunk/gcc/../libdecnumber/dpd -I../libdecnumber   
/home/meissner/fsf-src/trunk/gcc/fortran/trans-types.c -o fortran/trans-types.o
In file included from
/home/meissner/fsf-src/trunk/gcc/fortran/trans-types.c:335:
/home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def: In function
‘init_c_interop_kinds’:
/home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def:58: error:
‘PTRDIFF_TYPE’ undeclared (first use in this function)
/home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def:58: error: (Each
undeclared identifier is reported only once
/home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def:58: error: for each
function it appears in.)
make[2]: *** [fortran/trans-types.o] Error 1


-- 
   Summary: Spu fortran does not build
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: spu-elf


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

[Bug target/40197] Spu fortran does not build

[meissner at linux dot vnet dot ibm dot com]

--- Comment #1 from meissner at linux dot vnet dot ibm dot com  2009-05-19 
12:35 ---
Created an attachment (id=17892)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17892&action=view)
Define PTRDIFF_TYPE, SIZE_TYPE.


-- 


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

[Bug tree-optimization/40198] New: No rule to make target `proto', needed by `native'. Stop.

[wuddja at yahoo dot de]

Compiling GCC-4.5.0:trunk or 20090514 fails on my System

Gentoo
Intel Atom N270

With following log message:



> tmp-mlib.h; \
fi
echo '#include "tree.def"' > tmp-all-tree.def
echo timestamp > s-gtyp-input
lsf=""; for f in $lsf; do \
echo "#include \"$f\""; \
done | sed
's|/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/||' >
tmp-specs.h
echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def
/bin/sh
/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/../move-if-change
tmp-specs.h specs.h
i686-pc-linux-gnu-gcc -c  -O -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-styl$
835 übersetzte Meldungen, 2830 ungenaue Ãbersetzungen, 3424 unübersetzte
Meldungen.
make[3]: *** Keine Regel vorhanden, um das Target »proto«,
  benötigt von »native«, zu erstellen.  Schluss.
make[3]: *** Warte auf noch nicht beendete Prozesse...
/bin/sh
/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/../move-if-change
tmp-mlib.h multilib.h
echo '#include "c-common.def"' >> tmp-all-tree.def
echo timestamp > s-specs
ltf="/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/ada/gcc-interface/ada-tree.def
/var/tmp/portage/sys-de$
  echo "#include \"$f\""; \
done | sed
's|/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/||' >>
tmp-all-tree.def
echo timestamp > s-mlib
6332 übersetzte Meldungen, 564 ungenaue Ãbersetzungen, 193 unübersetzte
Meldungen.
/bin/sh
/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/../move-if-change
tmp-all-tree.def all-tree.def
echo timestamp > s-alltree
7089 übersetzte Meldungen.
/bin/sh
/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/gcc/../move-if-change
tmp-optionlist optionlist
echo timestamp > s-options
make[3]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/gcc'
make[2]: *** [all-stage1-gcc] Fehler 2
make[2]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build'
make[1]: *** [stage1-bubble] Fehler 2
make[1]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build'
make: *** [bootstrap] Fehler 2



Same on my Core2 Duo machine.


-- 
   Summary: No rule to make target `proto', needed by `native'.
Stop.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wuddja at yahoo dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: -march=prescott -O2 -pipe -fomit-frame-pointer


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

[Bug c/40199] New: crash when using -std=gnu99, no crash without -std=gnu99

[vvv at vsu dot ru]

Compiling the following program causes gcc to crash when using the -std=gnu99
option, but there is no crash without this option. I need to use this option
because the program uses language features such as loop initial declarations
which require passing -std=c99 or -std=gnu99 option.

=
typedef unsigned long long uint64_t;
int test(uint64_t result, uint64_t multiplier) {
  if (result > (18446744073709551615) / multiplier)
return 1;
  else
return 2;
}
=

$ /usr/local/gcc-4.4.0/bin/gcc -v -save-temps -std=gnu99 -c bug.c 
Using built-in specs.
Target: powerpc-ibm-aix4.3.3.0
Configured with: /mnt/gcc-4.4.0/configure --prefix=/usr/local/gcc-4.4.0
--enable-languages=c,c++ --disable-nls --disable-shared --disable-multilib
--with-float=hard --with-cpu=powerpc
Thread model: aix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-c' '-mcpu=powerpc'
'-mhard-float'
 /usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/cc1 -E -quiet -v
bug.c -mcpu=powerpc -mhard-float -std=gnu99 -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/../../../../powerpc-ibm-aix4.3.3.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/gcc-4.4.0/include
 /usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/include
 /usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-c' '-mcpu=powerpc'
'-mhard-float'
 /usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/cc1
-fpreprocessed bug.i -quiet -dumpbase bug.c -mcpu=powerpc -mhard-float -auxbase
bug -std=gnu99 -version -o bug.s
GNU C (GCC) version 4.4.0 (powerpc-ibm-aix4.3.3.0)
compiled by GNU C version 4.4.0, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 069cba7204d31344321186fb361b8726
bug.c:3:17: warning: integer constant is so large that it is unsigned
bug.c: In function 'test':
bug.c:3: internal compiler error: in gen_lowpart_general, at rtlhooks.c:59
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ ls -l
total 24
-rw-r--r--   1 vvv  noc  175 May 19 17:51 bug.c
-rw-r--r--   1 vvv  noc  237 May 19 17:56 bug.i
-rw-r--r--   1 vvv  noc   57 May 19 17:56 bug.s

$ cat bug.i
# 1 "bug.c"
# 1 ""
# 1 ""
# 1 "bug.c"
typedef unsigned long long uint64_t;
int test(uint64_t result, uint64_t multiplier) {
  if (result > (18446744073709551615) / multiplier)
return 1;
  else
return 2;
}

$ cat bug.s
.file   "bug.c"
.csect .text[PR]
.toc
.csect .text[PR]

Compiling the same file without the -std=gnu99 option works:

$ /usr/local/gcc-4.4.0/bin/gcc -v -save-temps -c bug.c 
Using built-in specs.
Target: powerpc-ibm-aix4.3.3.0
Configured with: /mnt/gcc-4.4.0/configure --prefix=/usr/local/gcc-4.4.0
--enable-languages=c,c++ --disable-nls --disable-shared --disable-multilib
--with-float=hard --with-cpu=powerpc
Thread model: aix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mcpu=powerpc' '-mhard-float'
 /usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/cc1 -E -quiet -v
bug.c -mcpu=powerpc -mhard-float -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/../../../../powerpc-ibm-aix4.3.3.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/gcc-4.4.0/include
 /usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/include
 /usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mcpu=powerpc' '-mhard-float'
 /usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/cc1
-fpreprocessed bug.i -quiet -dumpbase bug.c -mcpu=powerpc -mhard-float -auxbase
bug -version -o bug.s
GNU C (GCC) version 4.4.0 (powerpc-ibm-aix4.3.3.0)
compiled by GNU C version 4.4.0, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 069cba7204d31344321186fb361b8726
bug.c:3:17: warning: integer constant is so large that it is unsigned
bug.c: In function 'test':
bug.c:3: warning: this decimal constant is unsigned only in ISO C90
bug.c:3: warning: integer constant is too large for 'long' type
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mcpu=powerpc' '-mhard-float'
 as -u -mppc -o bug.o bug.s
COMPILER_PATH=/usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/:/usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/4.4.0/:/usr/local/gcc-4.4.0/libexec/gcc/powerpc-ibm-aix4.3.3.0/:/usr/local/gcc-4.4.0/lib/gcc/powerpc-ibm-aix4.3.3.0

[Bug fortran/40197] [4.5 Regression] Spu fortran does not build

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-19 14:36 ---
Actually http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01181.html is a better
patch since PTRDIFF_TYPE and SIZE_TYPE are documented to have defaults.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||05/msg01181.html
 Status|UNCONFIRMED |NEW
  Component|target  |fortran
 Ever Confirmed|0   |1
   Keywords||build, patch
   Last reconfirmed|-00-00 00:00:00 |2009-05-19 14:36:54
   date||
Summary|Spu fortran does not build  |[4.5 Regression] Spu fortran
   ||does not build
   Target Milestone|--- |4.5.0


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

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

[theresa dot adelt at greselius dot net]

--- Comment #11 from theresa dot adelt at greselius dot net  2009-05-19 
15:45 ---
Hello!

I need help, too.

I want to compile with g95 the following easy program:

program prim
! Testet, ob eine gegebene Zahl prim
integer :: kandidat, teiler, rest
kandidat = 7099
do teiler = 2, kandidat - 1
rest = MOD(kandidat, teiler)
if (rest == 0) THEN
write(*,*)kandidat, ' ist nicht Teiler'
  teiler, 'ist ein Teiler'
stop
end if
end do
write(*,*)kandidat, 'ist prim.'
stop
end program prim


It is about testing if a number is a prime number or not.


The following error appeared:

In file prim.f:9

  teiler, 'ist ein Teiler'
 1
Error: Unclassifiable statement at (1)


What is wrong? Why is 'teiler' not classifiable, even though I write teiler=2?


I would be happy, if anybody could help me.


Thanks a lot.

Wishes from Germany.

Theresa


-- 

theresa dot adelt at greselius dot net changed:

   What|Removed |Added

 CC||theresa dot adelt at
   ||greselius dot net


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

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

[tobi at gcc dot gnu dot org]

--- Comment #12 from tobi at gcc dot gnu dot org  2009-05-19 15:55 ---

Add an ampersand (&)

(In reply to comment #11)
> write(*,*)kandidat, ' ist nicht Teiler' &
   here  ^^

and be sure to read the section on continuation lines in your Fortran text.


-- 


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

[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-05-19 16:09 ---
I have no problems with 4.5 revision 147705 on Linux/ia32. If you
still have problems, please post the English version of the error
messages.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |WAITING
  Component|tree-optimization   |bootstrap
 GCC target triplet|-march=prescott -O2 -pipe - |
   |fomit-frame-pointer |


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

[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2009-05-19 16:15 ---
Subject: Re:  No rule to make target `proto', needed by
 `native'.  Stop.

protoize and unprotoize were removed in 4.5 having been deprecated in 4.4 
- either some reference did not get removed, or an old build command is 
still being used that referenced them.  The commands used to configure and 
build GCC seem more relevant here than the English error message.


-- 


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[jeff at schwabcenter dot com]

--- Comment #5 from jeff at schwabcenter dot com  2009-05-19 16:36 ---
Whoa whoa whoa...  The behavior seemed correct before.  vector
shouldn't even be legal.  Shouldn't the compiler to catch such a mistake?


-- 

jeff at schwabcenter dot com changed:

   What|Removed |Added

 CC||jeff at schwabcenter dot com


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-05-19 16:42 
---
I think that, in any case, we cannot do anything wrong here: we are simply
restoring an implementation detail of the previous implementations, which, as a
side effect, allows to compile this specific kind of snippet. Indeed, other
implementations also swallow it. So, let's take the legal issues aside, and
move on. If you figure specific details telling it's illegal just add it, as a
note, but certainly diagnostic is not required.


-- 


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

[Bug c++/40200] New: ''gcc file.cpp -o file.cpp'' Kills the code

[_paul at bk dot ru]

Command
gcc file.cpp -o file.cpp
leads to overwriting of the code by the compiled version
I propose error or backup of the overwritten file if it is equal to the sourse
file. 

This happened just now. I was in deep debug. 
While it didn't compile - no problem. 
As soon as I finished with all compile errors - I lost the code.

This is not the first time I tried to do such a dumb thing. But earlier I
stopped myself. To great regret - not now.


-- 
   Summary: ''gcc file.cpp -o file.cpp'' Kills the code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: _paul at bk dot ru


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[jeff at schwabcenter dot com]

--- Comment #7 from jeff at schwabcenter dot com  2009-05-19 17:09 ---
I understand the desire for backward compatibility, but are the semantics
actually the same?  Are the vector values arrays, or do they decay to pointers?
 Section 23.1 says standard container elements have to be CopyConstructible and
assignable, but raw arrays are neither.

Is there at least some flag to re-enable the diagnostic?  If you're saying this
is a necessary evil for reasons of backward compatibility, then I understand,
but in my opinion, this is a step backward that will confuse newcomers like
Brian and hurt cross-compatibility.  Speaking strictly as a GCC user, I don't
see any reason to reduce the compiler's ability to deduce an obvious mistake
with ill-defined semantics.


-- 


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-05-19 17:12 
---
This is not going to change again. We had this behaviour forever until 4.3.x
and all the major implementations outside GCC behave the same as GCC now (and
before the change of behavior).


-- 


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

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2009-05-19 17:14 ---
Created an attachment (id=17893)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17893&action=view)
Failing test case


-- 


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

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2009-05-19 17:17 ---
Created an attachment (id=17894)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17894&action=view)
Driver for failing test case (identical to c_f_pointer_shape_tests_2_driver.c)

$ gfortran c_f_pointer_shape_tests_4_driver.c c_f_pointer_shape_tests_4.f03
$ ./a.out
Aborted
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc/branches/fortran-dev/configure
--prefix=/home/ig25 --enable-languages=c,fortran --enable-maintainer-mode
Thread model: posix
gcc version 4.5.0 20090506 (experimental) (GCC)

The reason this fails is fairly obvious if you look at the code:  In
c_f_pointer_u0, there's

  for (i = 0; i < shapeSize; i++)
{
  /* Lower bound is 1, as specified by the draft.  */
  f_ptr_out->dim[i].lbound = 1;
  /* Have to allow for the SHAPE array to be any valid kind for
 an INTEGER type.  */
#ifdef HAVE_GFC_INTEGER_1
  if (GFC_DESCRIPTOR_SIZE (shape) == 1)
f_ptr_out->dim[i].ubound = ((GFC_INTEGER_1 *) (shape->data))[i];

which ignores the (sad) fact that shape could have a stride not equal
to one.  I found this when trying to convert this part to the array access
macros.


-- 


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

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2009-05-19 17:18 ---
Since I'm working in this area anyway, I might as well take this.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-19 17:18:27
   date||


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[jeff at schwabcenter dot com]

--- Comment #9 from jeff at schwabcenter dot com  2009-05-19 17:32 ---
OK.  Thanks for the explanation.  Are the semantics documented somewhere?


-- 


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

[Bug fortran/40201] New: DATE_AND_TIME returns GMT hour sometimes with OpenMP

[longb at cray dot com]

Test case:
program testhour
use omp_lib
integer :: h(1000), h1(1000), bins(0:23), v(8)

call omp_set_num_threads(4)

print *, "Running on",omp_get_max_threads(),"threads
and",omp_get_num_procs(),"procs."

!$omp parallel do schedule(STATIC,250)
do i=1,1000
   call date_and_time(values=v)
   h(i) = v(5)
end do
!$omp end parallel do

   print *, "date_and_time hour:"
   bins = 0
   do i=1,1000
  bins(h(i)) = bins(h(i)) + 1
   end do
   do i=0,23
  if (bins(i) > 0) print *, "For",bins(i),"calls, hour =",i
   end do


end program testhour

Compile with -fopenmp, and run on 4 threads:

> aprun -n1 -d4 ./dattest
 Running on   4 threads and   1 procs.
 date_and_time hour:
 For 707 calls, hour =  13
 For 293 calls, hour =  18
Application 2721423 resources: utime 0, stime 0


This was run in US Central Daylight time zone.  Most of the time, the correct
hour (13) was returned, but a sizable number of times, the hour correct for GMT
was returned instead. It looks like the conversion from GMT to the local time
zone sometimes fails when the routine is concurrently called from more that one
thread.

I wrote a similar program that called the system localtime() routine instead,
as well as localtime_r(), and both consistently returned the correct hour.

The same code compiled with either the Cray or PGI compiler consistently
returns the same hour for every iteration.


-- 
   Summary: DATE_AND_TIME returns GMT hour sometimes with OpenMP
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
  GCC host triplet: Linux, x86-64
GCC target triplet: Linux, x86-64 (quad-core Opteron)


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-05-19 17:38 
---
Look closely at the patch I committed, I changed *nothing* of the actual
behavior of the containers. Thus the semantics is exactly the same as before,
only, the destructor in not called explicitly anymore on such element type,
because the destructor is trivial.


-- 


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

[Bug fortran/40201] DATE_AND_TIME returns GMT hour sometimes with OpenMP

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-05-19 17:47 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-05-19 17:47 ---
*** Bug 40201 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[coleb at eyesopen dot com]

--- Comment #11 from coleb at eyesopen dot com  2009-05-19 17:57 ---
(In reply to comment #10)
> Look closely at the patch I committed, I changed *nothing* of the actual
> behavior of the containers. Thus the semantics is exactly the same as before,
> only, the destructor in not called explicitly anymore on such element type,
> because the destructor is trivial.
> 

Yup, even though you can declare a vector, you can't do anything useful
with it. 

typedef float cl_float4[4] __attribute__((aligned(16)));

#include 

int main()
{
  std::vector vals(1);
  cl_float4 a = {1.0f, 2.0f, 3.0f, 4.0f};
  vals.push_back(a);
}

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_algobase.h:412:
error: ISO C++ forbids assignment of arrays

Does seem strange to allow vector to be compilable, but eh, lesson
learned, stay away from array types in C++. 


-- 


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[jeff at schwabcenter dot com]

--- Comment #12 from jeff at schwabcenter dot com  2009-05-19 18:07 ---
What he said.  I'm perusing your patch, and I appreciate that you removed an
artificial restriction.  The right place to catch this is up front, in a
concept check, rather than in _Destroy; since I'm not about to add the check
myself, I'm hardly in a position to criticize.  The diagnostic did have the
nice property of catching a real, semantic error, though, and it seems a shame
to let a known error go unreported.


-- 


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

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2009-05-19 18:19 
---
It's life, you know ;)


-- 


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

[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2009-05-19 18:20 ---
Subject: Bug 40184

Author: paolo
Date: Tue May 19 18:20:47 2009
New Revision: 147714

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147714
Log:
2009-05-19  Paolo Carlini  

PR libstdc++/40184
* include/bits/locale_classes.h (locale::facet::_S_lc_ctype_c_locale):
Declare...
* config/locale/gnu/c_locale.cc: ... and define.
* config/locale/generic/c_locale.cc: Define.
* src/localename.cc (locale::_Impl::_Impl(const char*, size_t)):
Use it.
* testsuite/22_locale/locale/cons/40184.cc: New.

Added:
trunk/libstdc++-v3/testsuite/22_locale/locale/cons/40184.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/locale/generic/c_locale.cc
trunk/libstdc++-v3/config/locale/gnu/c_locale.cc
trunk/libstdc++-v3/include/bits/locale_classes.h
trunk/libstdc++-v3/src/localename.cc


-- 


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

[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-05-19 18:24 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

[manu at gcc dot gnu dot org]

--- Comment #25 from manu at gcc dot gnu dot org  2009-05-19 19:29 ---
Subject: Bug 40172

Author: manu
Date: Tue May 19 19:29:27 2009
New Revision: 147717

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147717
Log:
2009-05-19  Manuel López-Ibáñez  

PR c/40172
gcc/
* c.opt (Wlogical-op): Disabled by default.
* c-opt (c_common_post_options): Do not enable Wlogical-op with
Wextra.
* doc/invoke.texi (Wlogical-op): Likewise.
testsuite/
* gcc.dg/pr40172.c: Add -Wlogical-op to dg-options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-opts.c
trunk/gcc/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr40172.c


-- 


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

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

[manu at gcc dot gnu dot org]

--- Comment #26 from manu at gcc dot gnu dot org  2009-05-19 20:29 ---
The case in toplev.c cannot be fixed without tracking macro expansions somehow,
but I wonder why it warns (multiple times!) for this case:

> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
> collectively
> exhaustive tests is always true
> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
> collectively
> exhaustive tests is always true
> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
> collectively
> exhaustive tests is always true
> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
> collectively
> exhaustive tests is always true

David, could you produce a testcase?

Anyway, moved out of Wextra, so bootstrap should be fixed now.


-- 


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

[Bug c++/40202] New: warning about passing non-POD objects through �...� should include name and location of declaration being called

[jason dot orendorff at gmail dot com]

void f(...);

struct X {
X();
};

void g() {
X x;
f(x);
}

nonpod.cpp: In function ‘void g()’:
nonpod.cpp:9: warning: cannot pass objects of non-POD type ‘struct X’ through
‘...’; call will abort at runtime

Someone I know is currently trying to fix this warning in a very large
application with a complex build system.  Clearly something weird is going on. 
A pointer to the file and line of the function declaration would help eliminate
some possibilities at least, and possibly pinpoint the problem.


-- 
   Summary: warning about passing non-POD objects through ‘...’
should include name and location of declaration being
called
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot orendorff at gmail dot com


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

64 bit linux build problem for gcc 4.4.0

[Aharon Robbins]

Hi. After several tries and a modicum of googling, I found that

CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib

was the magic incantation to get gcc to get into the second stage of
the boostrap.  This is on a Fedora Core 10 system.

This seems to be an old issue; google turns things up dating back to
2003.  I suspect that x86_64 systems are only going to be more popular
with time; the build process on those systems needs to be as easy as
for 32 bit systems.

Thanks,

Arnold Robbins
(the gawk guy :-)

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

[ddaney at caviumnetworks dot com]

--- Comment #27 from ddaney at caviumnetworks dot com  2009-05-19 20:58 
---
Subject: Re:  [4.5 Regression]  Revision 147596 breaks bootstrap

manu at gcc dot gnu dot org wrote:
> --- Comment #26 from manu at gcc dot gnu dot org  2009-05-19 20:29 ---
> The case in toplev.c cannot be fixed without tracking macro expansions 
> somehow,
> but I wonder why it warns (multiple times!) for this case:
> 
>> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
>> collectively
>> exhaustive tests is always true
>> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
>> collectively
>> exhaustive tests is always true
>> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
>> collectively
>> exhaustive tests is always true
>> ../../trunk/gcc/config/mips/sb1.md:159: error: logical �or� of 
>> collectively
>> exhaustive tests is always true
> 
> David, could you produce a testcase?
> 

It is in insn-attrtab.c, which is machine generated.

I since the fatal warning is now disabled, it should be fine.

The problem with insn-attrtab.c is that it is generated from the .md 
files and then includes all the target macros.  So for this file you 
should probably never use -Wlogical-ops as filters that try to eliminate 
things in macros will fail.  The whole file is conceptually one big macro.


-- 


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

[Bug c++/40203] New: asprintf() and vasprintf() missing in header file

[vincenzo dot romano at notorand dot it]

The asprintf() and vasprintf() prototypes are declared in  header
file.
The  should be the "adapted" version of the same file for C++ language.
Nonetheless those two prototypes are missing.
Quoting from the :

/** @file include/cstdio
 *  This is a Standard C++ Library file.  You should @c #include this file
 *  in your programs, rather than any of the "*.h" implementation files.
 *
 *  This is the C++ version of the Standard C Library header @c stdio.h,
 *  and its contents are (mostly) the same as that header, but are all
 *  contained in the namespace @c std (except for names which are defined
 *  as macros in C).
 */


-- 
   Summary: asprintf() and vasprintf() missing in  header
file
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincenzo dot romano at notorand dot it


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

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #28 from hjl at gcc dot gnu dot org  2009-05-19 21:17 ---
Subject: Bug 40172

Author: hjl
Date: Tue May 19 21:17:00 2009
New Revision: 147719

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147719
Log:
2009-05-19  H.J. Lu  

PR c/40172
* gcc.dg/pr40172.c: Renamed to ...
* gcc.dg/pr40172-1.c: This.

* gcc.dg/pr40172-2.c: New.
* gcc.dg/pr40172-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr40172-1.c
  - copied unchanged from r147718, trunk/gcc/testsuite/gcc.dg/pr40172.c
trunk/gcc/testsuite/gcc.dg/pr40172-2.c
trunk/gcc/testsuite/gcc.dg/pr40172-3.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr40172.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #29 from hjl at gcc dot gnu dot org  2009-05-19 21:24 ---
Subject: Bug 40172

Author: hjl
Date: Tue May 19 21:24:23 2009
New Revision: 147720

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147720
Log:
2009-05-19  H.J. Lu  

Backport from mainline:
2009-05-19  H.J. Lu  

PR c/40172
* gcc.dg/pr40172-1.c: New.
* gcc.dg/pr40172-2.c: Likewise.
* gcc.dg/pr40172-3.c: Likewise.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40172-1.c
  - copied unchanged from r147719, trunk/gcc/testsuite/gcc.dg/pr40172-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40172-2.c
  - copied unchanged from r147719, trunk/gcc/testsuite/gcc.dg/pr40172-2.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40172-3.c
  - copied, changed from r147719, trunk/gcc/testsuite/gcc.dg/pr40172-3.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/40198] No rule to make target `proto', needed by `native'. Stop.

[wuddja at yahoo dot de]

--- Comment #3 from wuddja at yahoo dot de  2009-05-19 21:28 ---
ok lets take a look at my config flags

/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.0-pre
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.0-pre/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.0-pre
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.0-pre/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.0-pre/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --enable-cld --disable-libgcj
--with-arch=i686 --enable-languages=c,c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo SVN
--without-ppl --without-cloog --disable-ppl-version-check
--disable-cloog-version-check

is there something wrong?
which flag is deprecated since 4.4?
Do someone have a svn comment or something for me?


-- 


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

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-19 22:02 ---
Both asprintf and vasprintf are extensions to the C (and the C++) standard so
...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-19 22:04 ---
So are you asking to print out 'x' here? 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||diagnostic


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

[Bug c/40204] New: segfault with bitfields in structs

[gcc-bugzilla at gcc dot gnu dot org]

Compiling the following (nonsense but valid) code triggers an internal
compiler error.

Environment:
System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009 
i686 GNU/Linux

How-To-Repeat:
Compile the following:

-- snip --
struct s {
unsigned int a : 4;
unsigned int b : 28;
};

void f()
{
char c;
struct s s;
s.a = (c >> 4) & ~(1<<4);
}
-- snip --

$ gcc -Wall -c bug.c 
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See  for instructions.


--- Comment #1 from michael at walle dot cc  2009-05-19 22:16 ---
Fix:
not known


-- 
   Summary: segfault with bitfields in structs
   Product: gcc
   Version: 3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at walle dot cc


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

[Bug fortran/40019] LEADZ and TRAILZ give wrong results

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||05/msg01267.html
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2009-05-19 22:24:12
   date||


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

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-05-19 22:25 
---
Indeed, these are extensions and certainly the C++ standard doesn't say must be
made available in namespace std:: via . Actually, I think this PR is a
duplicate...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-05-19 22:27 
---
Indeed...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libstdc++/40203] asprintf() and vasprintf() missing in header file

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-05-19 22:27 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/39542] doesn't contain vasprintf() and asprintf()

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-05-19 22:27 
---
*** Bug 40203 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||vincenzo dot romano at
   ||notorand dot it


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

Re: 64 bit linux build problem for gcc 4.4.0

[Jerry DeLisle]

Aharon Robbins wrote:

Hi. After several tries and a modicum of googling, I found that

CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib

was the magic incantation to get gcc to get into the second stage of
the boostrap.  This is on a Fedora Core 10 system.

This seems to be an old issue; google turns things up dating back to
2003.  I suspect that x86_64 systems are only going to be more popular
with time; the build process on those systems needs to be as easy as
for 32 bit systems.

Thanks,

Arnold Robbins
(the gawk guy :-)


Aharon,

I have been building gcc for several years now with no issues on x86-64 and on 
Fedora Core 10 ever since it was released.  What exactly has been your problem?


Its been as easy as 123.  I have never had to set CCFLAGS or disable-multilib.

Jerry

[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4/4.5

[jvdelisle at gcc dot gnu dot org]

--- Comment #16 from jvdelisle at gcc dot gnu dot org  2009-05-20 00:16 
---
Subject: Bug 37754

Author: jvdelisle
Date: Wed May 20 00:16:38 2009
New Revision: 147725

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147725
Log:
2009-05-19  Jerry DeLisle  

PR libfortran/37754
* io/write_float.def: Simplify format calculation.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def


-- 


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

[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong

[rakdver at gcc dot gnu dot org]

--- Comment #9 from rakdver at gcc dot gnu dot org  2009-05-20 00:34 ---
Subject: Bug 40087

Author: rakdver
Date: Wed May 20 00:33:54 2009
New Revision: 147727

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147727
Log:
PR tree-optimization/40087
* tree-ssa-loop-niter.c (number_of_iterations_ne_max,
number_of_iterations_ne): Rename never_infinite argument.
(number_of_iterations_lt_to_ne, number_of_iterations_lt,
number_of_iterations_le): Handle pointer-type ivs when
exit_must_be_taken is false.
(number_of_iterations_cond):  Do not always assume that
exit_must_be_taken if the control variable is a pointer.

* gcc.dg/tree-ssa/pr40087.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr40087.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c


-- 


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[dave dot korn dot cygwin at gmail dot com]

--- Comment #56 from dave dot korn dot cygwin at gmail dot com  2009-05-20 
04:25 ---
Created an attachment (id=17895)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895&action=view)
Target option and autoconf test to enable aligned common support.

Currently putting the attached through a bootstrap and test cycle.

This adds a configure time GAS feature check for the 3-operand form aligned
.comm pseudo-op, and a target-specific command-line switch -mpe-aligned-commons
which is enabled or disabled by default depending on the status returned from
the configure check.

It doesn't yet address disabling use of commons when no alignment support is
available.  That can be done as a follow-on patch.


-- 


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

[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-05-20 06:01 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00310.html


-- 


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