[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2008-04-13 09:39 ---
CC-ing Benjamin...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

[Bug target/35921] Con/de-structor definition fails to override dllimport declaration

[dannysmith at users dot sourceforge dot net]

--- Comment #3 from dannysmith at users dot sourceforge dot net  2008-04-13 
09:39 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01048.html


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dannysmith at users dot
   |dot org |sourceforge dot net
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-13 09:39:48
   date||


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

[Bug java/35257] jar: internal error: java.lang.NullPointerException bootstrapping libjava

[gerald at pfeifer dot com]

--- Comment #4 from gerald at pfeifer dot com  2008-04-13 10:34 ---
Seems it was an openSUSE-specific issue that no longer reproduces with
the current codebase, thus closing this.


-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/35661] __attribute__((cold)) generates wrong code

[zuxy dot meng at gmail dot com]

--- Comment #4 from zuxy dot meng at gmail dot com  2008-04-13 12:18 ---
The MinGW port has no idea of the unlikely text section ever since r80564, so
it's likely that the fix should be applied to any release branch pulled after
r80564; although before 4.3.0 the bug only affects profile feedback.


-- 


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

[Bug libstdc++/35922] New: std::unordered_map missing in debug mode

[piotr dot rak at gmail dot com]

g++-4.4.0-alpha20080328 -v --save-temps -std=c++0x -D_GLIBCXX_DEBUG
unordered_m.cc 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/paludis/sys-devel-gcc-4.4.0_alpha20080328/work/gcc-4.4-20080328/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20080328
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20080328
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20080328/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20080328/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj
--with-arch=i686 --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.4.0_alpha20080328'
Thread model: posix
gcc version 4.4.0-alpha20080328  (experimental) (Gentoo 4.4.0_alpha20080328) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-D_GLIBCXX_DEBUG'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/cc1plus -E -quiet -v
-D_GNU_SOURCE -D_GLIBCXX_DEBUG unordered_m.cc -mtune=generic -march=i686
-std=c++0x -fpch-preprocess -o unordered_m.ii
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/libffi
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include/g++-v4

/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include/g++-v4/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include/g++-v4/backward
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-D_GLIBCXX_DEBUG'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.0-alpha20080328/cc1plus -fpreprocessed
unordered_m.ii -quiet -dumpbase unordered_m.cc -mtune=generic -march=i686
-auxbase unordered_m -std=c++0x -version -o unordered_m.s
GNU C++ (Gentoo 4.4.0_alpha20080328) version 4.4.0-alpha20080328 
(experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0-alpha20080328  (experimental), GMP
version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ad33fd151be46b0162e8ac35c976ec10
unordered_m.cc: In function 'int main()':
unordered_m.cc:4: error: 'unordered_map' is not a member of 'std'
unordered_m.cc:4: error: expected primary-expression before 'int'
unordered_m.cc:4: error: expected `;' before 'int'

Note: this happends too when using g++-4.4.0-alpha20080328
Works fine when inluded as 


-- 
   Summary: std::unordered_map missing in debug mode
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot rak at gmail dot com
 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=35922

[Bug libstdc++/35922] std::unordered_map missing in debug mode

[piotr dot rak at gmail dot com]

--- Comment #1 from piotr dot rak at gmail dot com  2008-04-13 13:41 ---
Created an attachment (id=15470)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15470&action=view)
Simple testcase


-- 


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

[Bug libstdc++/35922] std::unordered_map missing in debug mode

[piotr dot rak at gmail dot com]

--- Comment #2 from piotr dot rak at gmail dot com  2008-04-13 13:45 ---
(In reply to comment #0)

> Note: this happends too when using g++-4.4.0-alpha20080328
That should be g++-4.3.0-alpha20080118, sorry.


-- 


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

[Bug middle-end/35838] [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2008-04-13 
14:09 ---
Subject: Re:  [4.4 Regression] FAIL:
22_locale/num_get/get/char/16.cc execution test, and 76 others

Attatched .ii file generated on hppa-unknown-linux-gnu.

Dave


--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2008-04-13 
14:09 ---
Created an attachment (id=15471)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15471&action=view)


-- 


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

[Bug libstdc++/35922] std::unordered_map missing in debug mode

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2008-04-13 15:17 ---
Benjamin, can you have a look? Seems just an extension of libstdc++/30085: it
seems we can certainly have debug mode for std::unordered_* too (besides
std::tr1::unordered_*) 


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-13 15:17:10
   date||


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

[Bug fortran/35916] problem running gfortran 4.4.0 in Vista

[DHConsultancy at skynet dot be]

--- Comment #3 from DHConsultancy at skynet dot be  2008-04-13 16:11 ---
Subject: Re:  problem running gfortran 4.4.0 in Vista

I used your second option with the batch file as follows:
- I renamed gfortran.exe to gfortran4.0.0.exe
- I put a one-line batch file gfortran.bat in directory
  C:\Program Files\gfortran\bin  content is:
"C:\Program Files\gfortran\bin\gfortran4.4.0" %1 %2 %3 %4 %5 %6 %7 %8 %9

That seems to do the trick for now, and it means I don't have the modify 
my make files.

An obvious limitations is that this allows only for 9 command line 
parameters.

Nevertheless, I think I can live with this for a while until a patch is 
available, thank you very much.


I am very impressed with the bug tracking system, and the team that 
handles it. I've posted some Vista problems before, which have been 
dealt with very promptly, resulting in an almost immediate new release.

Nevertheless, may I make a few suggestions?

- please keep the installers for the previous stable versions available, 
so that it is possible to regress to a version that worked; on the Wiki 
pages, only the last version is available, and that usually is an 
experimental one. Maybe I missed something and older versions are still 
available somewhere, but then this is not obvious.

- Much to my regret and undoubtedly to many others as well, Vista is 
here to stay; I didn't even have the option to install XP on my new 
laptop, and XP distribution will cease more or less soon anyway.
So I would strongly suggest to perform the same severe testing for Vista 
as you undoubtedly do for XP.



I am trying to convince my international colleagues to switch from g77 
to gfortran. Many of them still use g77, even though it is no longer 
supported or even officially distributed (you wouldn't believe what some 
of them do to install g77!).
However, some large Fortran libraries which were built a decade or so 
ago for g77, are still very much in use, with very little chance of them 
ever being updated. I have tried to build one of these from source, with 
the provided make files, using gfortran, but gave up very quickly after 
being inundated with errors and warnings.

In my experience, one of the main differences is the definition of 
structures, and the structure syntax (e.g. the use of "%" instead of 
"."). Is there a way (compiler option or something) to compile old code 
with old structure definitions, using gfortran, and without replacing 
them in the source code?


Once again, thank you very much for the valuable service you provide, 
and keep up the good work!


Thank you in advance,

Daniel Heynderickx



brian at dessent dot net wrote:
> --- Comment #2 from brian at dessent dot net  2008-04-13 00:06 ---
> Subject: Re:  problem running gfortran 4.4.0 in Vista
> 
> pinskia at gcc dot gnu dot org wrote:
> 
>> IIRC the driver does not relocate correctly under Vista.
> 
> The Vista shell seems to populate argv[0] differently than previous
> versions, so the relocate machinery in the driver can't determine
> GCC_EXEX_PREFIX.  Workarounds are:
> 
> - use a shell other than CMD.EXE
> - give the full path to the binary when invoking it from CMD.EXE (even
> if its in PATH), or write a .bat/.cmd to do as such
> - add $libexec/gcc/$target/$version dir to PATH
> 
> 


-- 


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[ghazi at gcc dot gnu dot org]

--- Comment #6 from ghazi at gcc dot gnu dot org  2008-04-13 16:27 ---
So did we decide to fix this or not?

FWIW, I could fix the generic isinf transformation using:

isinf(x) -> isless(x,DBL_MAX) ? -1 : (isgreater(x,DBL_MAX))

and just always take the runtime penalty calculating for the -inf case when the
user says "if (isinf(x))" and doesn't care about the sign.  Maybe
__builtin_expect preferring zero would help here. (?)


I have an preliminary patch to do the ?: transformation, however the obtabs
isinf versions will still fail to honor sign.  This makes trouble in the
testcases if some platforms get -1 and others get 1.  So switching it would
need to be coordinated.

Thoughts?


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-03-08 10:40:32 |2008-04-13 16:27:57
   date||


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

[Bug java/35923] New: gcj: error trying to exec 'ecj1': execvp: No such file or directory

[david dot griffiths at gmail dot com]

I get the following error on a clean 4.3.0 build when trying (eg) "gcj
foo.java":

gcj: error trying to exec 'ecj1': execvp: No such file or directory

I'm a bit puzzled by bug 32712 being listed as resolved and even more so by the
references to just needing to run "./contrib/download_ecj". I tried this (on a
clean installation) and it made no difference. I also tried specifying the
location of ecj.jar with:

 ./configure --with-ecj-jar=/home/dgriff/gcc-4.3.0/ecj.jar

again, that made no difference.


-- 
   Summary: gcj: error trying to exec 'ecj1': execvp: No such file
or directory
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot griffiths at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/28239] [4.2 regression] ICE in gimple_add_tmp_var, at gimplify.c:720

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug c/35925] New: -g1 causes "Error: file number 1 already allocated"

[mrs at mythic-beasts dot com]

$ echo "void foo(void) { }" >test.c
$ gcc -g1 -S test.c
$ gcc -g1 -c test.s
test.s: Assembler messages:
test.s:79: Error: file number 1 already allocated

If "-g1" is changed to "-g", "-g0" or "-g2", or is removed, the error goes
away.

This causes problems when building glibc with CFLAGS="-g1".  glibc's configure
script invokes gcc as above in order to test whether --noexecstack is
available.  It gets an error and wrongly concludes that --noexecstack is not
available, which means libc.so doesn't get the benefit of a non-executable
stack.

Is this supposed to work, or should glibc work around it, perhaps by not
passing CFLAGS to the second invocation of gcc?


-- 
   Summary: -g1 causes "Error: file number 1 already allocated"
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at mythic-beasts dot com


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

[Bug c/35926] New: Pushing / Poping ebx without using it.

[ppelissi at caramail dot com]

The following code produces a push and pop of ebx without using it inside:

typedef struct toto_s *toto_t;
toto_t add (toto_t a, toto_t b) {
  int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
  return (toto_t)(intptr_t) tmp;
}

Here is the output of the compiler:
gcc version 4.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-S' '-fomit-frame-pointer' '-save-temps'
'-mtune=generic'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E -quiet -v immediate.c
-mtune=generic -fomit-frame-pointer -O3 -fpch-preprocess -o immediate.i
ignoring nonexistent directory
"/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.0/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-O3' '-S' '-fomit-frame-pointer' '-save-temps'
'-mtune=generic'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed immediate.i
-quiet -dumpbase immediate.c -mtune=generic -auxbase immediate -O3 -version
-fomit-frame-pointer -o immediate.s
GNU C (GCC) version 4.3.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0, GMP version 4.2.2, MPFR version 2.3.1.
warning: GMP header version 4.2.2 differs from library version 4.1.4.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128998
Compiler executable checksum: 6f004a95f08b214d06bfab9d0128e657
COMPILER_PATH=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/:/usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/:/usr/local/libexec/gcc/i686-pc-linux-gnu/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.0/:/usr/local/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.0/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O3' '-S' '-fomit-frame-pointer' '-save-temps'
'-mtune=generic'
[EMAIL PROTECTED] to-do]$ cat immediate.s 
.file   "immediate.c"
.text
.p2align 4,,15
.globl add
.type   add, @function
add:
pushl   %ebx
movl12(%esp), %eax
movl8(%esp), %ecx
popl%ebx
andl$-2, %eax
addl%ecx, %eax
ret
.size   add, .-add
.ident  "GCC: (GNU) 4.3.0"
.section.note.GNU-stack,"",@progbits

I can reproduce this problem for GCC 4.1.2 and GCC 4.2.2 too.


-- 
   Summary: Pushing / Poping ebx without using it.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppelissi at caramail dot com
 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=35926

[Bug c/35926] Pushing / Poping ebx without using it.

[ppelissi at caramail dot com]

--- Comment #1 from ppelissi at caramail dot com  2008-04-13 17:49 ---
Created an attachment (id=15473)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15473&action=view)
preprocessed sources


-- 


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

[Bug ada/17985] GNAT accepts extension aggregate where expexted type is not extension

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-04-13 18:16 ---
Subject: Bug 17985

Author: sam
Date: Sun Apr 13 18:15:20 2008
New Revision: 134244

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134244
Log:
gcc/ada/
PR ada/17985
* sem_aggr.adb (Valid_Ancestor_Type): A type is not an ancestor of
itself.

gcc/testsuite/
PR ada/17985
* gnat.dg/ancestor_type.ads, gnat.dg/ancestor_type.adb: New test.

Added:
trunk/gcc/testsuite/gnat.dg/ancestor_type.adb
trunk/gcc/testsuite/gnat.dg/ancestor_type.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/sem_aggr.adb
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/17985] GNAT accepts extension aggregate where expexted type is not extension

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2008-04-13 18:16 ---
Bug fix in GCC SVN.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #4 from hutchinsonandy at gcc dot gnu dot org  2008-04-13 19:15 
---
Please look at PR35860. I believe this is same problem noted here.
subreg-lowering triggering the regression due to worsened conflicts.

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


-- 

hutchinsonandy at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hutchinsonandy at gcc dot
   ||gnu dot org


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

[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally

[zadeck at naturalbridge dot com]

--- Comment #5 from zadeck at naturalbridge dot com  2008-04-13 19:31 
---
Subject: Re:  ra-conflict does not handle subregs
 optimally

hutchinsonandy at gcc dot gnu dot org wrote:
> --- Comment #4 from hutchinsonandy at gcc dot gnu dot org  2008-04-13 
> 19:15 ---
> Please look at PR35860. I believe this is same problem noted here.
> subreg-lowering triggering the regression due to worsened conflicts.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
>
>
>   
In a couple of days i will have a patch ready for public examination 
that will fix the 35404 issue.
It does so by doing a more precise conflict building so that multiword 
registers can be packed on top of one another if they the "pieces" do 
not ever conflict.  

This is the info that is encoded in REG_NO_CONFLICT notes, but i have 
discovered that I find pairs of these even in places where no such 
notes/blocks were ever created.

I am in the testing process now on the part that makes global understand 
the info my conflict builder is building.  

Stevenb is working on a patch that takes local-alloc out of the loop and 
that will help also.That is a more complex patch in that there are 
things in local that still have to be done.   

I have cc'ed my self and steven on this bugzilla and i will forward the 
patches to you as they become available and we can see if this solves 
your problems.

kenny


-- 


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

[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #6 from hutchinsonandy at gcc dot gnu dot org  2008-04-13 19:47 
---
That sounds great - it was one bug I was struggling with.

I can turn around a complete  test for AVR on mingw and Debian as soon as are
ready.


-- 


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

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[aaronavay62 at aaronwl dot com]

--- Comment #1 from aaronavay62 at aaronwl dot com  2008-04-13 19:48 ---
What is the status on this?  Does reverting the langhooks.c change remanifest
PR27067?


-- 

aaronavay62 at aaronwl dot com changed:

   What|Removed |Added

 CC||aaronavay62 at aaronwl dot
   ||com


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

[Bug libfortran/32972] performance of pack/unpack

[tkoenig at gcc dot gnu dot org]

--- Comment #23 from tkoenig at gcc dot gnu dot org  2008-04-13 20:16 
---
Subject: Bug 32972

Author: tkoenig
Date: Sun Apr 13 20:15:58 2008
New Revision: 134245

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134245
Log:
2008-04-13  Thomas Koenig  <[EMAIL PROTECTED]>
Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR libfortran/32972
PR libfortran/32512
configure.ac:  Add test for uintptr_t.
configure:  Regenerated.
config.h.in:  Regenerated.
* libgfortran.h: GFC_DTYPE_DERIVED_1:  New macro.
GFC_DTYPE_DERIVED_2:  New macro.
GFC_DTYPE_DERIVED_4:  New macro.
GFC_DTYPE_DERIVED_8:  New macro.
GFC_DTYPE_DERIVED_16:  New macro.
GFC_UNALIGNED_2:  New macro.
GFC_UNALIGNED_4:  New macro.
GFC_UNALIGNED_8:  New macro.
GFC_UNALIGNED_16:  New macro.
intptr_t:  Define if we don't have it.
uintptr_t:  Likewise.
* runtime/backtrace.c (show_backtrace):  Use intptr_t.
* intrinsics/signal.c (signal_sub):  Likewise.
(signal_sub_int):  Likewise.
(alarm_sub_int_i4):  Likewise.
* intrinsics/spread_generic.c (spread):  Use the integer
routines for handling derived types of sizes 1, 2, 4, 8 and 16
if the alignment of all pointers is correct.
(spread_scalar):  Likewise.
* intrinsics/pack_generic.c (pack):  Likewise.
Use GFD_DTYPE_TYPE_SIZE to avoid nested switch statements.
* intrinsics/unpack_generic.c (unpack1):  Likewise.
(unpack0):  Likewise.
* runtime/in_pack_generic.c (internal_pack):  Likewise.
* runtime/in_unpack_generic.c (internal_unpack):  Likewise.

2008-04-13  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/32972
PR libfortran/32512
* gfortran.dg/internal_pack_1.f90:  Add test for derived type.
* gfortran.dg/intrinsic_spread_1.f90:  Likewise.
* gfortran.dg/intrinsic_pack_1.f90:  Likewise.
* gfortran.dg/intrinsic_unpack_1.f90:  Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/internal_pack_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_pack_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_spread_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_unpack_1.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/intrinsics/pack_generic.c
trunk/libgfortran/intrinsics/signal.c
trunk/libgfortran/intrinsics/spread_generic.c
trunk/libgfortran/intrinsics/unpack_generic.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/backtrace.c
trunk/libgfortran/runtime/in_pack_generic.c
trunk/libgfortran/runtime/in_unpack_generic.c


-- 


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

[Bug fortran/32512] efficiency of RESHAPE and SPREAD

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2008-04-13 20:16 ---
Subject: Bug 32512

Author: tkoenig
Date: Sun Apr 13 20:15:58 2008
New Revision: 134245

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134245
Log:
2008-04-13  Thomas Koenig  <[EMAIL PROTECTED]>
Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR libfortran/32972
PR libfortran/32512
configure.ac:  Add test for uintptr_t.
configure:  Regenerated.
config.h.in:  Regenerated.
* libgfortran.h: GFC_DTYPE_DERIVED_1:  New macro.
GFC_DTYPE_DERIVED_2:  New macro.
GFC_DTYPE_DERIVED_4:  New macro.
GFC_DTYPE_DERIVED_8:  New macro.
GFC_DTYPE_DERIVED_16:  New macro.
GFC_UNALIGNED_2:  New macro.
GFC_UNALIGNED_4:  New macro.
GFC_UNALIGNED_8:  New macro.
GFC_UNALIGNED_16:  New macro.
intptr_t:  Define if we don't have it.
uintptr_t:  Likewise.
* runtime/backtrace.c (show_backtrace):  Use intptr_t.
* intrinsics/signal.c (signal_sub):  Likewise.
(signal_sub_int):  Likewise.
(alarm_sub_int_i4):  Likewise.
* intrinsics/spread_generic.c (spread):  Use the integer
routines for handling derived types of sizes 1, 2, 4, 8 and 16
if the alignment of all pointers is correct.
(spread_scalar):  Likewise.
* intrinsics/pack_generic.c (pack):  Likewise.
Use GFD_DTYPE_TYPE_SIZE to avoid nested switch statements.
* intrinsics/unpack_generic.c (unpack1):  Likewise.
(unpack0):  Likewise.
* runtime/in_pack_generic.c (internal_pack):  Likewise.
* runtime/in_unpack_generic.c (internal_unpack):  Likewise.

2008-04-13  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/32972
PR libfortran/32512
* gfortran.dg/internal_pack_1.f90:  Add test for derived type.
* gfortran.dg/intrinsic_spread_1.f90:  Likewise.
* gfortran.dg/intrinsic_pack_1.f90:  Likewise.
* gfortran.dg/intrinsic_unpack_1.f90:  Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/internal_pack_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_pack_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_spread_1.f90
trunk/gcc/testsuite/gfortran.dg/intrinsic_unpack_1.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/intrinsics/pack_generic.c
trunk/libgfortran/intrinsics/signal.c
trunk/libgfortran/intrinsics/spread_generic.c
trunk/libgfortran/intrinsics/unpack_generic.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/backtrace.c
trunk/libgfortran/runtime/in_pack_generic.c
trunk/libgfortran/runtime/in_unpack_generic.c


-- 


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

[Bug fortran/35846] ICE on nested character constructors

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-04-13 20:32 ---
Created an attachment (id=15474)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15474&action=view)
Backtrace

Confirmed.  Backtrace is attached.


-- 


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

[Bug fortran/35846] ICE on nested character constructors

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-13 20:33:00
   date||


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-04-13 20:45 ---
Interesting.  Running with valgrind produces an ICE:

$ valgrind  ~/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 foo.f90 
==3891== Memcheck, a memory error detector.
==3891== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3891== Using LibVEX rev 1804, a library for dynamic binary translation.
==3891== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3891== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
framework.
==3891== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==3891== For more details, rerun with: -v
==3891== 
 MAIN__==3891== Invalid read of size 4
==3891==at 0x80F3D8D: gfc_conv_expr_val (trans-expr.c:3611)
==3891==  Address 0x4 is not stack'd, malloc'd or (recently) free'd

foo.f90:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
==3891== 
==3891== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 1)
==3891== malloc/free: in use at exit: 249,564 bytes in 1,061 blocks.
==3891== malloc/free: 1,592 allocs, 531 frees, 289,234 bytes allocated.
==3891== For counts of detected errors, rerun with: -v
==3891== searching for pointers to 1,061 not-freed blocks.
==3891== checked 2,099,868 bytes.
==3891== 
==3891== LEAK SUMMARY:
==3891==definitely lost: 108 bytes in 2 blocks.
==3891==  possibly lost: 176 bytes in 14 blocks.
==3891==still reachable: 249,280 bytes in 1,045 blocks.
==3891== suppressed: 0 bytes in 0 blocks.
==3891== Rerun with --leak-check=full to see details of leaked memory.

Running under gdb yields

(gdb) r -fdefault-integer-8 -g f12_integrals.f 
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951
-fdefault-integer-8 -g f12_integrals.f
 df_fit_f12 tranop_f12 f12_unidom f12_listmo f12_integrals_jinv
f12_integrals_2idx f12_integrals_til f12_integrals_bar f12_integrals_srt {GC
5430k -> 2061k} f12_integrals_raw
Program received signal SIGSEGV, Segmentation fault.
0x08234a2c in fold_binary (code=MINUS_EXPR, type=0xb7b404b0, op0=0xb7baf688,
op1=0xb7bf6070) at ../../../gcc/trunk/gcc/fold-const.c:9920
9920  && !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (arg0)))


-- 


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

[Bug fortran/35718] deallocating non-allocated pointer target does not fail

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-04-13 20:58 ---
Ouch.  That one will be hard to fix without keeping
state around in the descriptor.


-- 


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

[Bug c++/5786] array types decay too quickly

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #7 from gcc-bugzilla at contacts dot eelis dot net  2008-04-13 
21:19 ---
Still fails on GCC 4.4.0 20080413 (experimental).


-- 


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

[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory

[brian at dessent dot net]

--- Comment #1 from brian at dessent dot net  2008-04-13 23:59 ---
Subject: Re:   New: gcj: error trying to exec 'ecj1': execvp: No 
 such file or directory

david dot griffiths at gmail dot com wrote:

> gcj: error trying to exec 'ecj1': execvp: No such file or directory

Run the command with -v to show what it's trying to exec, and paste the
output as well as the actual location of ecj1.


-- 


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

[Bug fortran/35882] Miscounted continuation lines when interspersed with data

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-04-14 00:44 
---
Subject: Bug 35882

Author: jvdelisle
Date: Mon Apr 14 00:43:32 2008
New Revision: 134251

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134251
Log:
2008-04-13  Jerry DeLisle  <[EMAIL PROTECTED]>
Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/35882
* options.c (gfc_init_options): Set the default maximum continuation
lines to 255 for both free and fixed form source for warnings.
(gfc_handle_option): Set -std=f95 fixed form max continuations to 19
and
the -std=f95 free form max continuations to 39 for warnings.
* scanner.c (gfc_next_char_literal): Adjust the current_line number
only
if it is less than the current locus.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c
trunk/gcc/fortran/scanner.c


-- 


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

[Bug fortran/35882] Miscounted continuation lines when interspersed with data

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-04-14 00:47 
---
Subject: Bug 35882

Author: jvdelisle
Date: Mon Apr 14 00:47:13 2008
New Revision: 134252

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134252
Log:
2008-04-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/35882
* gfortran.dg/continuation_3.f90: Update test.
* gfortran.dg/continuation_5.f: Update test.
* gfortran.dg/continuation_10.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/continuation_10.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/continuation_3.f90
trunk/gcc/testsuite/gfortran.dg/continuation_5.f


-- 


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

[Bug fortran/35882] Miscounted continuation lines when interspersed with data

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-04-14 01:14 
---
Fixed on trunk and closing.  Thanks for the report.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/35927] New: befriending a whole template in another namespace fails

[mec at google dot com]

In this program, Beta::Gamma declares ::Alpha as a friend, but the friendship
does not work.

===

[EMAIL PROTECTED]:~/exp-friend$ cat z1.cc
template 
void Alpha(T* a) { a->Delta(); }

namespace Beta {

class Gamma {
 public:
  template  friend void ::Alpha(T*);

 private:
  void Delta();
};

}

int main() {
  Beta::Gamma* a = new Beta::Gamma;
  ::Alpha(a);
}

bash: /home/mec/gcc-4.2.1/install/bing++: No such file or directory
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.1/install/bin/g++ -O2 -Wall -c
z1.cc
z1.cc: In function 'void Alpha(T*) [with T = Beta::Gamma]':
z1.cc:18:   instantiated from here
z1.cc:11: error: 'void Beta::Gamma::Delta()' is private
z1.cc:2: error: within this context

[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.2/install/bin/g++ -O2 -Wall -c
z1.cc
z1.cc: In function 'void Alpha(T*) [with T = Beta::Gamma]':
z1.cc:18:   instantiated from here
z1.cc:11: error: 'void Beta::Gamma::Delta()' is private
z1.cc:2: error: within this context

[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.3.0/install/bin/g++ -O2 -Wall -c
z1.cc
z1.cc: In function 'void Alpha(T*) [with T = Beta::Gamma]':
z1.cc:18:   instantiated from here
z1.cc:11: error: 'void Beta::Gamma::Delta()' is private
z1.cc:2: error: within this context
[EMAIL PROTECTED]:~/exp-friend$ 

===

In this program, Beta::Gamma declares the specialization ::Alpha
as a friend.  This works.

[EMAIL PROTECTED]:~/exp-friend$ cat z3.cc
template 
void Alpha(T* a) { a->Delta(); }

namespace Beta {

class Gamma {
 public:
  friend void ::Alpha(Beta::Gamma*);

 private:
  void Delta();
};

}

int main() {
  Beta::Gamma* a = new Beta::Gamma;
  ::Alpha(a);
}

[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.1/install/bin/g++ -O2 -Wall -c
z3.cc
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.2.2/install/bin/g++ -O2 -Wall -c
z3.cc
[EMAIL PROTECTED]:~/exp-friend$ /home/mec/gcc-4.3.0/install/bin/g++ -O2 -Wall -c
z3.cc
[EMAIL PROTECTED]:~/exp-friend$

===

I think z1.cc is valid, per this clause from [temp.friend]:

"A template friend declaration specifies that all specializations of that
template, whether they are implicitly instantiated (14.7.1), partially
specialized (14.5.4) or explicitly specialized (14.7.3) are friends of the
class containing the template friend declaration.

I suspect it's a bug with the namespace part of "template  friend
void ::Alpha(T*);".


-- 
   Summary: befriending a whole template in another namespace fails
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google dot com
 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=35927

[Bug c/35928] New: type qualifiers ignored on function return type

[cnstar9988 at gmail dot com]

the following code generate a warning on gcc 4.2.4

warning: type qualifiers ignored on function return type

#include 
#include 
#include 

typedef struct testabc{int class;}* THANDLE;

const THANDLE test()
{
THANDLE x;

x = (THANDLE)2;

return x;
}

int main(int argc, char **argv)
{
 const THANDLE p = test();
 return (int)p;
}


-- 
   Summary: type qualifiers ignored on function return type
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cnstar9988 at gmail dot com


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

[Bug c/35928] type qualifiers ignored on function return type

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-14 03:33 ---
The const in "const THANDLE" applies to the pointer type and not the element
the pointer is pointing to.  So the warning is correct.


-- 

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

[Bug c/35928] type qualifiers ignored on function return type

[cnstar9988 at gmail dot com]

--- Comment #2 from cnstar9988 at gmail dot com  2008-04-14 03:49 ---
but how to applies to the pointer type and the element
the pointer is pointing to.

I don't want someone modify my pointer and the pointing to?

but the following code has no warning, why?

#include 
#include 
#include 

typedef struct testabc {int Class;}THANDLE;

const THANDLE* test()
{
THANDLE *x;

x = (THANDLE*)2;

return x;
}

int main(int argc, char **argv)
{
 const THANDLE *p=  test();
return (int)p;
}


-- 


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

[Bug c/35928] type qualifiers ignored on function return type

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-04-14 04:10 ---
"const THANDLE" in the first case is equivalant to "THANDLE* const" when
THANDLE a struct.

> but how to applies to the pointer type and the element
> the pointer is pointing to.

With the typedefs, you can't.


-- 


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

[Bug c++/35929] New: Argument type of non-member operator->*

[gcc at magfr dot user dot lysator dot liu dot se]

When I try to compile a non-member operator ->* g++ tells me that

pmv.C:3: error: 'int& operator->*(s*, int s::*)' must have an argument of class
or enumerated type

but the only place where the standard mentions the argument types of ->* is in
13.6§11 and there it is stated

...there exist candidate operator functions of the form
 CV12 T & operator->*(CV1 C1 *, CV2 T C2 ::*);

and thus I think this is a bug.


-- 
   Summary: Argument type of non-member operator->*
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug c++/35929] Argument type of non-member operator->*

[gcc at magfr dot user dot lysator dot liu dot se]

--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se  
2008-04-14 05:24 ---
Created an attachment (id=15475)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15475&action=view)
Testcase for the error message

Repeat by compiling as 

g++ -c pmv.C


-- 


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

[Bug c++/35929] Argument type of non-member operator->*

[gcc at magfr dot user dot lysator dot liu dot se]

--- Comment #2 from gcc at magfr dot user dot lysator dot liu dot se  
2008-04-14 06:34 ---
I think I was wrong.


-- 

gcc at magfr dot user dot lysator dot liu dot se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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