[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-02-20 
07:58:39 UTC ---
The ICE went away starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166164

[Bug target/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #9 from Kai Tietz  2011-02-20 07:30:31 
UTC ---
ok, closed.

[Bug target/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[dongsheng.song at gmail dot com]

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

--- Comment #8 from Dongsheng Song  2011-02-20 
04:18:08 UTC ---
(In reply to comment #7)
> Yes, I assume it is a binutils issue. And my bets are going to version-script
> issue. I am not 100% sure, but it looks pretty likely, as version-scripts are
> used for doing export definitions.  I just sent a patch about it to binutils 
> ML
> and this issue seems to exists already for some time. I am curious that Dave
> didn't noticed it earlier.
> I stumbled about it by doing a binutils regression-test for 32-bit COFF
> targets.

Verified on:

gcc version 4.6.0 20110219
gcc version 4.5.3 20110219

This bug not exist now.

[Bug c/47821] BUG: warning: left shift count >= width of type

[nfavaro at uwo dot ca]

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

nfavaro at uwo dot ca changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from nfavaro at uwo dot ca 2011-02-20 03:45:47 UTC ---
In attempts to work-around the issue, this was fashioned

kk = ((long)B << 56);

It was assumed at the onset that the destination of the shift
was long kk and it should compile correctly, but did not.

Casting B long removes the warning and produces correct results.

-NF

[Bug c/47821] New: BUG: warning: left shift count >= width of type

[nfavaro at uwo dot ca]

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

   Summary: BUG: warning: left shift count >= width of type
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nfav...@uwo.ca


Created attachment 23409
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23409
Example c program for UltraSPARC producing incorrect results with left shift

While developing a 64bit program for the UltraSPARC,
I was warned shifting 56 times left was >= width of type
See attachment code.
Since you may not be able to run it,
here is the output: 

sizeof 'k'  is 4
sizeof 'kk' is 8
sizeof 'B'  is 1
B = 2c (hex)
2c00<-This is not correct!

The last line should be:
2c00<-This is correct (32 bits more)


The issue here is this:
kk is a long int (64 bits)
and compiling produces a warning:
(at line 39): warning: left shift count >= width of type

Line 39 is:

kk = (B << 56);// place B in bit position 63..56 of 64 bits

This warning is incorrect.
-AND-
The compiled code is incorrect.

-NF

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  2011-02-20 
02:19:42 UTC ---
Patch is at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00981.html

Deferred to 4.7.

[Bug bootstrap/47820] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from H.J. Lu  2011-02-20 00:43:49 
UTC ---
I think my machine with 8GB RAM plus 9GB swap ran out of
memory when linking jc1. This may be caused by revision
170321:

http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00866.html

[Bug bootstrap/47820] New: [4.6 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] LTO bootstrap failed with
bootstrap-profiled
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 170329 LTO bootstrap failed
with bootstrap-profiled:

http://gcc.gnu.org/ml/gcc-regression/2011-02/msg00301.html

xgcc: internal compiler error: Segmentation fault (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc returned 4
exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [jc1] Error 1

Revision 170320 is OK.

[Bug c++/44118] ICE: in instantiate_decl, at cp/pt.c:16657

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com
  Known to fail||

--- Comment #4 from Paolo Carlini  2011-02-20 
00:01:47 UTC ---
Zdenek, can you double check this one too? It works for me with r170330. If we
can't figure out which specific patch fixed the problem, I can still close the
PR after having added the testcase to the testsuite. Thanks.

[Bug c++/47503] [4.6 Regression] [C++0x] ICE: in adjust_temp_type, at cp/semantics.c:5876 with -fno-elide-constructors

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2011-02-19 
23:33:18 UTC ---
Should be fixed then.

[Bug lto/47788] [4.6 Regression] New LTO failures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-02-19 
22:44:18 UTC ---
Fixed.

[Bug c++/47503] [4.6 Regression] [C++0x] ICE: in adjust_temp_type, at cp/semantics.c:5876 with -fno-elide-constructors

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-02-19 
22:39:53 UTC ---
Author: jason
Date: Sat Feb 19 22:39:50 2011
New Revision: 170330

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170330
Log:
PR c++/47503
* semantics.c (cxx_eval_call_expression): Shortcut trivial copy.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/regress/no-elide1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/47819] [meta-bug] LTO debug information issues

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.19 22:07:07
 Ever Confirmed|0   |1

[Bug debug/47819] New: [meta-bug] LTO debug information issues

[rguenth at gcc dot gnu.org]

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

   Summary: [meta-bug] LTO debug information issues
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


Meta-bug, tracking trunk issues.

[Bug c++/47817] incorrectly working code generated with -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2011-02-19 
21:37:08 UTC ---
(In reply to comment #4)
> But given that reinterpret_cast does not, I would still suspect some tricky
> things happening inside gcc anyway..

No reinterpret_cast does not change the fact you are violating the aliasing
rules.

[Bug c++/15774] Conflicting function decls not diagnosed

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Kai Tietz  2011-02-19 21:26:39 
UTC ---
After discussing in more detail with Jason, I'll close this bug as fixed.

[Bug debug/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #18 from Alexandre Oliva  2011-02-19 
21:25:23 UTC ---
Fixed

[Bug tree-optimization/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Alexandre Oliva  2011-02-19 
21:19:16 UTC ---
Fixed

[Bug tree-optimization/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva  2011-02-19 
21:14:53 UTC ---
Author: aoliva
Date: Sat Feb 19 21:14:49 2011
New Revision: 170327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170327
Log:
PR tree-optimization/46620
* gcc.dg/pr46620.c: New.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr46620.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[aoliva at gcc dot gnu.org]

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

--- Comment #9 from Alexandre Oliva  2011-02-19 
21:15:09 UTC ---
Author: aoliva
Date: Sat Feb 19 21:15:01 2011
New Revision: 170328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170328
Log:
PR tree-optimization/46620
* tree-sra.c (try_instantiate_multiple_fields): Don't get stuck at
padding within accessed words.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/tree-sra.c

[Bug c++/47817] incorrectly working code generated with -O3

[andrew.aksyonoff at gmail dot com]

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

--- Comment #4 from Andrew Aksyonoff  
2011-02-19 21:10:21 UTC ---
(In reply to comment #2)
> I think you have some violation of the C/C++ aliasing rules where you access 
> an
> "unsigned int" via an "unsigned long long" which in turn causes undefined
> behavior.

You're referring to aliasing DOCINFO2ID helper, right?

gcc -Wall -Wstrict-aliasing does not result in any warnings.

Replacing DOCINFO2ID body with a more C++ish { return * reinterpret_cast(pDocinfo); } does not help either.

Replacing it with { return (uint64_t(pDocinfo[1])<<32) + uint64_t(pDocinfo[0]);
} does help, so that just might be my workaround, thanks for the pointer!

But given that reinterpret_cast does not, I would still suspect some tricky
things happening inside gcc anyway..

[Bug c/47809] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:7291

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.6.0
Summary|[4.5/4.6 Regression] ICE in |[4.5 Regression] ICE in
   |gimplify_expr, at   |gimplify_expr, at
   |gimplify.c:7291 |gimplify.c:7291
  Known to fail||4.5.2

--- Comment #4 from Jakub Jelinek  2011-02-19 
21:09:35 UTC ---
Fixed on the trunk so far.

[Bug tree-optimization/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  2011-02-19 
21:08:51 UTC ---
Author: aoliva
Date: Sat Feb 19 21:08:40 2011
New Revision: 170326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170326
Log:
PR tree-optimization/46620
* gcc.dg/pr46620.c: New.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46620.c
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug ada/47818] New: Pragma Assert is rejected with No_Implementation_Pragmas restriction.

[eugen at debian dot org]

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

   Summary: Pragma Assert is rejected with
No_Implementation_Pragmas restriction.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eu...@debian.org


Created attachment 23408
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23408
Patch for the bug

Compilation of code containing pragma Assert fails if restriction
No_Implementation_Pragmas is used, even with -gnat2005 or -gnat2012 flags:

% cat test.adb  
pragma Restrictions(No_Implementation_Pragmas);

procedure test(I : Integer) is
begin
  pragma Assert(I /= 1);
  null;
end;
% gcc -c test.adb -gnat2005 
test.adb:5:03: violation of restriction "no_implementation_pragmas" at line 1

Source file gcc/ada/sem_prag.adb contains correct check for Pragma_Assert
(Ada_2005_Pragma). But this pragma is then rewritten as pragma Check and
restrictions (GNAT_Pragma) are tested again. This test fails and causes
compilation error.

Attached patch adds check in Pragma_Check case. If rewritten pragma Assert was
found then restrictions are not checked.

[Bug tree-optimization/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  2011-02-19 
21:02:39 UTC ---
Author: aoliva
Date: Sat Feb 19 21:02:35 2011
New Revision: 170325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170325
Log:
PR tree-optimization/46620
* gcc.dg/pr46620.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr46620.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/47817] incorrectly working code generated with -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andrew Pinski  2011-02-19 
20:59:51 UTC ---
typedef unsigned intDWORD;
...

typedef unsigned long long SphDocID_t;

inline SphDocID_t DOCINFO2ID ( const DWORD * pDocinfo ) { return
*(SphDocID_t*)pDocinfo; }


..

SphDocID_t Key ( DWORD * pData ) const
{
return DOCINFO2ID(pData);
}

void CopyKey ( SphDocID_t * pMed, DWORD * pVal ) const
{
*pMed = Key(pVal);
}
...



Actually it is obvious you are violating those rules based on the code which I
Posted as what is passed into sphSort is an array of DWORD.

[Bug bootstrap/47630] [4.6 regression] ICE in queue_insn, at haifa-sched.c:1322 compiling 64-bit libjava/java/lang/natString.cc

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  2011-02-19 
20:59:27 UTC ---
Author: aoliva
Date: Sat Feb 19 20:59:23 2011
New Revision: 170324

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170324
Log:
PR debug/47620
PR debug/47630
* haifa-sched.c (fix_tick_ready): Skip tick computation
for debug insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c

[Bug debug/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux

[aoliva at gcc dot gnu.org]

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

--- Comment #17 from Alexandre Oliva  2011-02-19 
20:59:27 UTC ---
Author: aoliva
Date: Sat Feb 19 20:59:23 2011
New Revision: 170324

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170324
Log:
PR debug/47620
PR debug/47630
* haifa-sched.c (fix_tick_ready): Skip tick computation
for debug insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c

[Bug c/47809] [4.5/4.6 Regression] ICE in gimplify_expr, at gimplify.c:7291

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-02-19 
20:57:15 UTC ---
Author: jakub
Date: Sat Feb 19 20:57:12 2011
New Revision: 170323

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170323
Log:
PR c/47809
* c-common.c (c_fully_fold_internal): Handle VIEW_CONVERT_EXPR.

* gcc.target/i386/pr47809.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr47809.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47817] incorrectly working code generated with -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-02-19 
20:56:45 UTC ---
I think you have some violation of the C/C++ aliasing rules where you access an
"unsigned int" via an "unsigned long long" which in turn causes undefined
behavior.

[Bug c++/47817] incorrectly working code generated with -O3

[andrew.aksyonoff at gmail dot com]

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

--- Comment #1 from Andrew Aksyonoff  
2011-02-19 20:51:23 UTC ---
Created attachment 23407
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23407
the preprocessed .ii file built with -O3 -save-temps

[Bug c++/47817] New: incorrectly working code generated with -O3

[andrew.aksyonoff at gmail dot com]

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

   Summary: incorrectly working code generated with -O3
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andrew.aksyon...@gmail.com


Created attachment 23406
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23406
sample code that works with -O2 but fails with -O3

The attached sample behaves differently when built with -O2 and -O3
respectively. It's essentially a sorting routine implementation. The expected
behavior is to sort the data in ascending order and there is a check that
verifies that. It works as expected with gcc -O2 (also with a few other
compilers):

shodan@dev1:~/gccbug$ g++ -O2 tests.cpp
shodan@dev1:~/gccbug$ ./a.out
DEBUG: sorting 57 entries, stride 3

However, with -O3 the sanity check fails. (Two rows are ending up in the wrong
order.)

shodan@dev1:~/gccbug$ g++ -O3 tests.cpp
shodan@dev1:~/gccbug$ ./a.out
DEBUG: sorting 57 entries, stride 3
DEBUG: !!! sorting2 failed

The issue is present in two versions of gcc, 4.4.3 as packaged in Ubuntu 10.04
LTS, and 4.4.4 as packaged in RedHat 6.0, both running on x86_64 platform.
Here's gcc -v output for both

Ubuntu 10.04 x64 gcc -v

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

RedHat 6.0 x64 gcc -v

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)

Not sure if the following helps, but anyway. This trimmed down sample starts to
work if I remove unused (!) CSphString from SortDocinfos() function. That was
*not* the case on a larger codebase this example was extracted from. Original
SortDocinfos() function only consisted of two lines, one declaring
DocinfoSort_fn functor and the other one invoking sphSort(), but that was
failing nevertheless.

Last but not least, any insight and/or workarounds I could implement in my code
to prevent this bug from happening on affected gcc versions would be really
appreciated. Our application depends on sorting a lot...

Thanks.

[Bug debug/47647] BLOCKs are empty

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2011-02-19 
19:51:06 UTC ---
Fixed.

[Bug debug/47647] BLOCKs are empty

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-02-19 
19:50:40 UTC ---
Author: rguenth
Date: Sat Feb 19 19:50:36 2011
New Revision: 170321

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170321
Log:
2011-02-18  Richard Guenther  

PR lto/47647
* lto-streamer-in.c (lto_input_ts_decl_minimal_tree_pointers):
Remove lazy BLOCK_VARS streaming.
(lto_input_ts_block_tree_pointers): Likewise.
* lto-streamer-out.c (lto_output_ts_block_tree_pointers): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c

[Bug tree-optimization/46723] [4.5 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at ubuntu dot com

--- Comment #13 from Matthias Klose  2011-02-19 
18:43:00 UTC ---
the patch fixes the ICE on the 4.5 branch, no regressions on a i686-linux-gnu
biarch build and test.

[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu.org

--- Comment #23 from Ralf Wildenhues  2011-02-19 
17:49:19 UTC ---
(In reply to comment #21)
> The error for 46 is this:
> 
> *skip*
[...]
> Stop in /usr/ports/lang/gcc46.
> *** Error code 1

Unfortunately, you skipped too much: the text you quoted does not contain an
error message.  Please go back and post the very first error message that shows
up in the output log.  Thanks.

[Bug c/47809] [4.5/4.6 Regression] ICE in gimplify_expr, at gimplify.c:7291

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Jakub Jelinek  2011-02-19 
17:31:43 UTC ---
Created attachment 23405
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23405
gcc46-pr47809.patch

Untested fix.

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  2011-02-19 
17:30:27 UTC ---
> Yes, so HP-UX 11 seems to do the right thing by default. So the problem is
> HP-UX 10, which only provides the 3-arg form and not the standard one, right?

I believe HP changed to the POSIX interfaces in HP-UX 10.30.  Prior to that,
only the 3-arg form is provided and not the standard one.

The library build if I hack ctime.c and getlog.c, so these are the only
build issues.

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  2011-02-19 
17:23:08 UTC ---
Also, we have another problem:

libtool: compile:  /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/
-
B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.6/hppa1.1-h
p-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include
-isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H
-I. -
I../../../../gcc/libgfortran -iquote../../../../gcc/libgfortran/io
-I../../../..
/gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config
-I../../../../gcc/libgfortran/../libquadmath -I../../.././gcc -D_GNU_SOURCE
-std=gnu99 -Wall
 -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite
-strings -fcx-fortran-rules -g -O2 -threads -MT getlog.lo -MD -MP -MF
.deps/getl
og.Tpo -c ../../../../gcc/libgfortran/intrinsics/getlog.c  -fPIC -DPIC -o
.libs/
getlog.o
../../../../gcc/libgfortran/intrinsics/getlog.c: In function
'_gfortran_getlog':
../../../../gcc/libgfortran/intrinsics/getlog.c:89:3: error: too many arguments
to function 'getpwuid_r'
/usr/include/pwd.h:37:17: note: declared here

The HP-UX 10.20 version of 'getpwuid_r' doesn't have last argument of POSIX
version.

_REENTRANT needs to be defined to obtain header declarations for reentrant
functions.

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[jb at gcc dot gnu.org]

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

--- Comment #3 from Janne Blomqvist  2011-02-19 16:57:18 
UTC ---
(In reply to comment #2)
> > Is there no way to get a posix compliant ctime?  Alternatively, we'll need
> > autoconf magic to detect the extra arg.  I know at one time it was 
> > relatively
> > common, so autoconf magic might be around somewhere.  Assuming it is you 
> > just
> > have to do something like
> > 
> > 
> > #if defined (oddballctime)
> >   *date = ctime_r (&now, cbuf, CSZ);
> > #else
> >   *date = ctime_r (&now, cbuf);
> > #endif
> 
> Using ctime_r is a bit of a can of worms.  The GNU autoconf manual recommends
> not using ctime_r unless the inputs are known to be within certain limits.

Well, since the usage here is for the Fortran intrinsics CTIME and FDATE which
are defined as interfaces to ctime(), unless you're volunteering to fix all the
Fortran code out there using these intrinsics, there's not much we can do.

gfortran at least makes sure to call ctime_r() with a buffer of >= 26 bytes
which is what POSIX requires. If some platform overflows this buffer, a bug
report to the platform libc maintainers seems to be the correct approach.

> It seems HP-UX and Solaris have both forms.

For Solaris we had some similar problems with _r() functions, yes. This was
solved by 

AC_USE_SYSTEM_EXTENSIONS

(from ../config/extensions.m4) which sets _POSIX_PTHREAD_SEMANTICS on Solaris,
which makes it expose the POSIX standard interfaces rather than some
pre-standard version.

>  In the HP-UX 11 case,
> which form is used at compilation time depends on _PTHREADS_DRAFT4:
> 
> #  ifndef _PTHREADS_DRAFT4
>  extern char *ctime_r(const __time_t *, char *);
> #  else /* _PTHREADS_DRAFT4 */
>  extern int ctime_r(const __time_t *, char *, int);
> #  endif /* _PTHREADS_DRAFT4 */

Yes, so HP-UX 11 seems to do the right thing by default. So the problem is
HP-UX 10, which only provides the 3-arg form and not the standard one, right?

> Potential autoconf test:
> 
> # ctime_r --
> #
> # There are two versions of ctime_r, one of which takes a buffer length as a
> # third argument, and one which only takes two arguments.  (There is also a
> # difference in return values, but we handle that in the code itself.)
> AC_CHECK_FUNCS(ctime_r)
> if test "$ac_cv_func_ctime_r" = "yes"; then
> AC_CACHE_CHECK([for 2 or 3 argument version of ctime_r], db_cv_ctime_r_3arg, [
> AC_TRY_LINK([
> #include ], [
> ctime_r(NULL, NULL, 100);
> ],  [db_cv_ctime_r_3arg="3-argument"], [db_cv_ctime_r_3arg="2-argument"])])
> fi
> if test "$db_cv_ctime_r_3arg" = "3-argument"; then
> AC_DEFINE(HAVE_CTIME_R_3ARG)
> AH_TEMPLATE(HAVE_CTIME_R_3ARG,
> [Define to 1 if ctime_r takes a buffer length as a third argument.])
> fi

Thanks, that looks like a doable approach. Unless somebody else gets there
first, I'll try to find some time to do this next week.

[Bug fortran/45592] [F03] Valid structure constructor rejected for extended types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from janus at gcc dot gnu.org 2011-02-19 16:40:09 UTC ---
(In reply to comment #2)
> This pr seems to have been fixed at revision 170312, probably by revision
> 170291 (it looks like a duplicate of pr47789).

Yes:

http://gcc.gnu.org/viewcvs?view=revision&revision=170291

Definitely a duplicate. Closing as fixed.

[Bug fortran/45592] [F03] Valid structure constructor rejected for extended types

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-02-19 
16:30:56 UTC ---
This pr seems to have been fixed at revision 170312, probably by revision
170291 (it looks like a duplicate of pr47789).

[Bug fortran/47778] reading two arrays of structures from namelist fails

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.19 15:52:35
 AssignedTo|unassigned at gcc dot   |jvdelisle at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Jerry DeLisle  2011-02-19 
15:52:35 UTC ---
A reduced test case:

program test_nml
type field_descr
  integer number
end type
type fsetup
  type (field_descr), dimension(3) :: vel
  type (field_descr), dimension(3) :: scal
end type
type (fsetup) field_setup
namelist /nl_setup/ field_setup
field_setup%vel%number = 0
field_setup%scal%number = 0
open(10, status="scratch")
write(10,'(a)') "&nl_setup"
write(10,'(a)') " field_setup%scal(1)%number=  2,"
write(10,'(a)') " field_setup%scal(2)%number=  6,"
write(10,'(a)') "/"
rewind(10)
read(10,nml=nl_setup)
write(*,nml=nl_setup)
end program test_nml

[Bug bootstrap/47806] Failure to build cross-combiner to powerpc-ibm-aix6.0

[steven at gcc dot gnu.org]

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

--- Comment #5 from Steven Bosscher  2011-02-19 
15:48:45 UTC ---
sysroot, right. obviously I don't have AIX so that basically means I can't
build a cross-compiler to it, IIUC. Close as IBTK (aka INVALID)?

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #19 from Jerry DeLisle  2011-02-19 
15:42:47 UTC ---
Closing once again. Thanks for reports.

[Bug c/47816] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[lennox at cs dot columbia.edu]

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

--- Comment #2 from Jonathan Lennox  2011-02-19 
15:38:04 UTC ---
Created attachment 23404
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23404
Preprocessed source for test case

[Bug c/47809] [4.5/4.6 Regression] ICE in gimplify_expr, at gimplify.c:7291

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.19 15:36:33
   Target Milestone|--- |4.5.3
Summary|ICE in gimplify_expr, at|[4.5/4.6 Regression] ICE in
   |gimplify.c:7291 [4.6]   |gimplify_expr, at
   ||gimplify.c:7291
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak  2011-02-19 15:36:33 
UTC ---
Confirmed on x86_64-pc-linux-gnu, 4.5/4.6 regression.

[Bug c/47816] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.19 15:26:48
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-02-19 
15:26:48 UTC ---
Can you attach preprocessed source?

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle  2011-02-19 
15:21:10 UTC ---
Author: jvdelisle
Date: Sat Feb 19 15:21:05 2011
New Revision: 170319

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170319
Log:
2011-02-19  Jerry DeLisle  

PR libgfortran/47567
* gfortran.dg/fmt_f0_1.f90: Update test.
Fix previous log entry.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_f0_1.f90

[Bug c/47816] New: GCC pedwarns about use of static inline functions from system headers in extern inline functions

[lennox at cs dot columbia.edu]

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

   Summary: GCC pedwarns about use of static inline functions from
system headers in extern inline functions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: len...@cs.columbia.edu
  Host: x86_64-apple-darwin10.6.0
Target: x86_64-apple-darwin10.6.0
 Build: x86_64-apple-darwin10.6.0


On Mac OS X 10.6, Apple has modified their system header files to use 'static
inline' functions much more extensively (I believe they're now using fortify by
default?)

However, GCC (since version 4.3) prints an unsuppressible pedwarn about any use
of a static inline function in a non-static inline function.

This essentially means that basic libc functions are unusable from non-static
inline functions.

Thus, on Mac OS X 10.6.6 with a current GCC tree from subversion:

$ cat inline-test.c
#include 

extern inline __attribute__((__gnu_inline__))
void* memcpy_wrap_1(void* dst, const void* src, size_t n)
{
return memcpy(dst, src, n);
}

inline
void* memcpy_wrap_2(void* dst, const void* src, size_t n)
{
return memcpy(dst, src, n);
}


void foo(char *buf1, char *buf2, char *buf3, char *buf4, size_t length)
{
memcpy_wrap_1(buf1, buf2, length);

memcpy_wrap_2(buf3, buf4, length);
}


$ ~/GCC/svn/bin/gcc-4.6 -c --std=gnu99
--sysroot=/Developer/SDKs/MacOSX10.6.sdk/ inline-test.c
inline-test.c:12:9: warning: ‘__inline_memcpy_chk’ is static but used in inline
function ‘memcpy_wrap_2’ which is not static [enabled by default]
inline-test.c:6:9: warning: ‘__inline_memcpy_chk’ is static but used in inline
function ‘memcpy_wrap_1’ which is not static [enabled by default]



Jonathan-Lennoxs-MacBook-Pro:scratch jonathan$ ~/GCC/svn/bin/gcc-4.6 -v -c
--std=gnu99 --sysroot=/Developer/SDKs/MacOSX10.6.sdk/ inline-test.c
Using built-in specs.
COLLECT_GCC=/Users/jonathan/GCC/svn/bin/gcc-4.6
COLLECT_LTO_WRAPPER=/Users/jonathan/GCC/svn/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../trunk/configure --prefix=/Users/jonathan/GCC/svn
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-checking=release
--program-suffix=-4.6
Thread model: posix
gcc version 4.6.0 20110218 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-c' '-std=gnu99'
'-mtune=core2'
 /Users/jonathan/GCC/svn/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/cc1 -quiet
-v -isysroot /Developer/SDKs/MacOSX10.6.sdk/ -D__DYNAMIC__ inline-test.c -fPIC
-quiet -dumpbase inline-test.c -mmacosx-version-min=10.6.6 -mtune=core2
-auxbase inline-test -std=gnu99 -version -o
/var/folders/DK/DKO9pSWtFASzzyjD7MKJlTI/-Tmp-//ccg3ldYs.s
GNU C (GCC) version 4.6.0 20110218 (experimental) (x86_64-apple-darwin10.6.0)
compiled by GNU C version 4.6.0 20110218 (experimental), GMP version 4.3.2,
MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/Developer/SDKs/MacOSX10.6.sdk//usr/local/include"
ignoring nonexistent directory
"/Users/jonathan/GCC/svn/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/../../../../x86_64-apple-darwin10.6.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/jonathan/GCC/svn/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/include
 /Users/jonathan/GCC/svn/include
 /Users/jonathan/GCC/svn/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/include-fixed
 /Developer/SDKs/MacOSX10.6.sdk//usr/include
 /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks
 /Developer/SDKs/MacOSX10.6.sdk//Library/Frameworks
End of search list.
GNU C (GCC) version 4.6.0 20110218 (experimental) (x86_64-apple-darwin10.6.0)
compiled by GNU C version 4.6.0 20110218 (experimental), GMP version 4.3.2,
MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1e40ed1f0984385bdcb3920828281613
inline-test.c:12:9: warning: ‘__inline_memcpy_chk’ is static but used in inline
function ‘memcpy_wrap_2’ which is not static [enabled by default]
inline-test.c:6:9: warning: ‘__inline_memcpy_chk’ is static but used in inline
function ‘memcpy_wrap_1’ which is not static [enabled by default]
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-c' '-std=gnu99'
'-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o inline-test.o
/var/folders/DK/DKO9pSWtFASzzyjD7MKJlTI/-Tmp-//ccg3ldYs.s
COMPILER_PATH=/Users/jonathan/GCC/svn/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/jonathan/GCC/svn/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/jonathan/GCC/svn/libexec/gcc/x86_64-apple-darwin10.6.0/:/Users/jonathan/GCC/svn/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/jonathan/GCC/sv

[Bug web/47718] bugzilla: commit mails mentioning binutils PR wrongly linked to GCC bug

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #7 from Ralf Wildenhues  2011-02-19 
15:12:38 UTC ---
(In reply to comment #6)
> So if I understand correctly, this case is rare enough to not care?

Hmm, I guess so.  Bummer.  Anyway, thanks Andreas for proving me wrong in
thinking that this used to work.  Closing as wontfix.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  2011-02-19 
15:10:58 UTC ---
Author: jvdelisle
Date: Sat Feb 19 15:10:55 2011
New Revision: 170318

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170318
Log:
2011-02-19  Jerry DeLisle  

PR libgfortran/47567
* io/write_float.def (output_float): Adjust width for F0.d to
allow space for negative signs on zero.

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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[paul.richard.thomas at gmail dot com]

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

--- Comment #32 from paul.richard.thomas at gmail dot com  2011-02-19 15:07:03 UTC ---
Dear Tobias,


>
> Aha, you have taken the simple route of modifying trans-decl.c and not the
> whole module reading apparatus :-)

Of course - otherwise, we stand no chance of getting rid of the
regression.  It's only a small addition to the existing section of
code, so I thought that it had the advantage of being very clean too.

The revamp of module.c can wait until we have nothing to do :-)

>
> I think the patch is OK, though I would do some reordering, e.g. "sym->module"
> is not needed as the whole block is enclosed in such a check.
>
> I also would move the block down into
>        if (gsym && gsym->ns && gsym->type == GSYM_MODULE)
> which could be changed into
>        if (!gsym || (gsym && gsym->ns && gsym->type == GSYM_MODULE))
>
> And
> -        gfc_find_symbol (sym->name, gsym->ns, 0, &s);
> +         if (gsym)
> +          gfc_find_symbol (sym->name, gsym->ns, 0, &s);
>
> And then placing the "if (gsym == NULL)" in the
> +       else if (s == NULL)
> block.

All done.

> (In reply to comment #30)
>> The bus error reported in comment #21 has disappeared from my scope between
>> revisions 167584 and 167726;-(
>
> Ditto here, but looking at the dump, I see that the underlying issue is still
> present - and it is fixed by the patch.
>
>  * * *
>
> I will do some more tests.

Let me know when you have done them.  What about a testcase?  I guess
that since it was a testsuite failure we do not need one?
>
> Related to those whole-file DECL issues: I wonder why there are still
> differences between -flto and -fno-lto on Polyhedron (result is correct but
> runtimes are different) and for Jack (-O3 miscompilation of xplor-nih's 
> slink.f
> and tenso.f, unless -fno-whole-file is used; -fno-inline-functions does not
> help).

Is there a PR for Jack's problem.

Thanks for looking at the patch

Paul

[Bug fortran/47348] wrong string length with array constructor

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  2011-02-19 15:03:30 
UTC ---
Author: pault
Date: Sat Feb 19 15:03:27 2011
New Revision: 170317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170317
Log:
2011-02-19  Paul Thomas  

PR fortran/47348
* trans-array.c (get_array_ctor_all_strlen): Move up in file.
(get_array_ctor_var_strlen): Add block dummy and add call to
get_array_ctor_all_strlen instead of giving up on substrings.
Call gcc_unreachable for default case.
(get_array_ctor_strlen): Add extra argument to in call to
get_array_ctor_var_strlen.

2011-02-19  Paul Thomas  

PR fortran/47348
* gfortran.dg/array_constructor_36.f90 : New test.
* gfortran.dg/bounds_check_10.f90 : Change dg-output message to
allow for comparison between different elements of the array
constructor at different levels of optimization.


Added:
trunk/gcc/testsuite/gfortran.dg/array_constructor_36.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bounds_check_10.f90

[Bug middle-end/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  2011-02-19 
14:53:24 UTC ---
Author: hjl
Date: Sat Feb 19 14:53:20 2011
New Revision: 170316

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170316
Log:
Properly handle target not in Pmode when expanding strlen.

gcc/

2011-02-19  H.J. Lu  

PR middle-end/47364
* builtins.c (expand_builtin_strlen): Properly handle target
not in Pmode.

gcc/testsuite/

2011-02-19  H.J. Lu  

PR middle-end/47364
* gcc.dg/torture/pr47364-1.c: New.

Added:
branches/x32/gcc/testsuite/gcc.dg/torture/pr47364-1.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/builtins.c
branches/x32/gcc/config/i386/i386.c
branches/x32/gcc/testsuite/ChangeLog.x32

[Bug objc/47813] Some ObjC tests failing on ia6-suse-linux-gnu

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.19 14:33:59
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-02-19 14:33:59 
UTC ---
I got access to a ia64 linux gnu machine.  The regression is present in 
revision 170260.  Here is the detail log

Executing on host: /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc
-B/home/nicola/GCC/build-trunk-full-serial/gcc/
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m  -fgnu-runtime
-Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc 
-B/home/nicola/GCC/build-trunk-full-serial/ia64-unkn
own-linux-gnu/./libobjc/.libs  
-L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs
  -lobjc -lm   -o ./bitfield-3.exe(timeout = 300)
spawn /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc
-B/home/nicola/GCC/build-trunk-full-serial/gcc/
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m -fgnu-runtime
-Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc
-B/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/.
/libobjc/.libs
-L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs
-lobjc -lm -o ./bitfield-3.exe
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:20:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:27:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:32:16: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:33:16: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:49:1: warning:
padding struct to align 'defs' [-Wpadded]
output is:
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:20:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:27:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:32:16: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:33:16: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:49:1: warning:
padding struct to align 'defs' [-Wpadded]

PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 20)
PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 27)
PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 32)
PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 33)
FAIL: objc.dg/bitfield-3.m -fgnu-runtime (test for excess errors)
Excess errors:
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:49:1: warning:
padding struct to align 'defs' [-Wpadded]

---

Executing on host: /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc
-B/home/nicola/GCC/build-trunk-full-serial/gcc/
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m  -fgnu-runtime
-Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc 
-B/home/nicola/GCC/build-trunk-full-serial/ia64-unkn
own-linux-gnu/./libobjc/.libs  
-L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs
  -lobjc -lm   -o ./bitfield-5.exe(timeout = 300)
spawn /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc
-B/home/nicola/GCC/build-trunk-full-serial/gcc/
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m -fgnu-runtime
-Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc
-B/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/.
/libobjc/.libs
-L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs
-lobjc -lm -o ./bitfield-5.exe
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:24:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:33:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:40:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:52:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:57:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:70:1: warning:
padding struct size to alignment boundary [-Wpadded]
/home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:74:16: warning:
padding struct size to alignment boundary [-Wpadded]
/ho

[Bug target/47812] [x32] __builtin_strlen is miscompiled at -O2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from H.J. Lu  2011-02-19 14:22:45 
UTC ---
(In reply to comment #2)
> In ix86_expand_strlen:
> 
> if (GET_MODE (out) != Pmode)
>out = convert_to_mode (Pmode, out, 1);
> 
> 
> Here out is REG:SI 59 -- the result register for strlen. After conversion, new
> reg:DI 64 is created. There are two problems here:
> 
> 1) the result is now 64, but the caller 'expand_builtin_strlen' still uses reg
> 59
> 2) the conversion itself generates an uninitialized use.
> 

Thanks for the analysis.  This is a dup of PR47364. I have a patch.

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

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2011-02-19 14:22:45 
UTC ---
*** Bug 47812 has been marked as a duplicate of this bug. ***

[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2011-02-19 13:57:09 UTC ---
(In reply to comment #2)
> One can get rid of this error message e.g. by ... (warning: not regtested)

Side note: This patch does not cause any regressions in the test suite.
However, it makes no sense to apply it without any run-time support for this
feature (which will be less trivial to implement). Also one should probably
wait for the final result of the interpretation request, which means this will
probably not make it into 4.6.

[Bug tree-optimization/47815] Tail call regression with GCC snapshot

[adam at consulting dot net.nz]

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

--- Comment #3 from Adam Warner  2011-02-19 
13:55:43 UTC ---
OK I finally understand. Tail call optimisation also disappears when the
noreturn attribute is added to the leaf functions when compiled with gcc-4.5.

>From my perspective this is a bug. A call to a function that does not return is
a clear candidate for turning a call into a jump. At high levels of
optimisation this should always trump any extra ease of debugging.

Additionally it is important that adding debugging statements changes the main
code as little as possible. Otherwise it may become very difficult to determine
what is wrong using debugging statements if the debugging statements are the
cause of differently generated code.

If there is a printf in tail_call0() instead of an assert that evaluates to
false then make_tail_calls() generates a jump to tail_call0(). If I add an
assert statement to see what is going on then there is a chance different code
is generated for make_tail_calls() depending on whether GCC can statically
determine if tail_call0() does not return.

You are likely to create a situation were adding debugging statements causes a
bug to change or even disappear. This can be the most infuriating kind of bug.
So I don't accept that this will always help with debugging. There's no point
having an accurate backtrace of the wrong code.

Thirdly I can eliminate many stack alignment instructions with tail calls. A
call instruction pushes the return address on the stack causing a 16-byte
aligned stack to become misaligned. The parent function compensates by
including a stack alignment instruction. A jump does not cause 16-byte stack
misalignment.

You are generating inferior code. With newer versions of gcc make_tail_calls()
includes a stack alignment instruction (push %rcx at -Os). This will be the
case even if a non-returning function is only called once. Here is an example:

$ cat no_tail_call_optimisation.c 
#include 

__attribute__((noinline)) void is_complete_helper() {
  assert("complete"=="");
}

__attribute__((noinline)) void is_complete(unsigned int i) {
  if(i==0) is_complete_helper();
}

int main() {
  for (unsigned int i=30; ;--i) {
is_complete(i);
  }
}

$ gcc-4.5 -std=gnu99 -Os no_tail_call_optimisation.c && time ./a.out
a.out: no_tail_call_optimisation.c:4: is_complete_helper: Assertion
`"complete"==""' failed.
Aborted

real0m8.014s
user0m8.009s
sys0m0.000s

$ gcc-4.6 --version
gcc-4.6 (Debian 4.6-20110216-1) 4.6.0 20110216 (experimental) [trunk revision
170225]

$ gcc-4.6 -std=gnu99 -Os no_tail_call_optimisation.c && time ./a.out
a.out: no_tail_call_optimisation.c:4: is_complete_helper: Assertion
`"complete"==""' failed.
Aborted

real0m10.015s
user0m10.009s
sys0m0.000s

So why does the version compiled with gcc-4.6 take two seconds longer to run?
Compare the code generated for is_complete():

gcc-4.5:
00400511 :
  400511:   85 ff   test   %edi,%edi
  400513:   75 07   jne40051c 
  400515:   31 c0   xor%eax,%eax
  400517:   e9 d8 ff ff ff  jmpq   4004f4 
  40051c:   c3  retq  

gcc-4.6:
0040051e :
  40051e:   85 ff   test   %edi,%edi
  400520:   51  push   %rcx
  400521:   75 07   jne40052a 
  400523:   31 c0   xor%eax,%eax
  400525:   e8 da ff ff ff  callq  400504 
  40052a:   5a  pop%rdx
  40052b:   c3  retq   

6,000,000,000 additional push/pop instructions are executed with gcc-4.6. These
stack alignment instructions are generated because a known tail call
optimisation has been ignored for spurious reasons.

Tail call optimisation should be the default at high levels of optimisation
regardless of whether a function returns. This bug only manifests more often in
gcc-4.6 because of superior code inference.

Regards,
Adam

[Bug tree-optimization/47815] Tail call regression with GCC snapshot

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-02-19 
13:45:50 UTC ---
Hm, or rather it also is because

  FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR->preds)
{
  /* Only traverse the normal exits, i.e. those that end with return
 statement.  */
  stmt = last_stmt (e->src);

  if (stmt
  && gimple_code (stmt) == GIMPLE_RETURN)
find_tail_calls (e->src, &tailcalls);
}

which of course does not find callsites that do not return.

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu.org]

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

--- Comment #31 from Tobias Burnus  2011-02-19 
13:08:26 UTC ---
(In reply to comment #29)
> A candidate fix for the PR

Aha, you have taken the simple route of modifying trans-decl.c and not the
whole module reading apparatus :-)

I think the patch is OK, though I would do some reordering, e.g. "sym->module"
is not needed as the whole block is enclosed in such a check.

I also would move the block down into
if (gsym && gsym->ns && gsym->type == GSYM_MODULE)
which could be changed into
if (!gsym || (gsym && gsym->ns && gsym->type == GSYM_MODULE))

And
-gfc_find_symbol (sym->name, gsym->ns, 0, &s);
+ if (gsym)
+  gfc_find_symbol (sym->name, gsym->ns, 0, &s);

And then placing the "if (gsym == NULL)" in the
+   else if (s == NULL)
block.



(In reply to comment #30)
> The bus error reported in comment #21 has disappeared from my scope between
> revisions 167584 and 167726;-(

Ditto here, but looking at the dump, I see that the underlying issue is still
present - and it is fixed by the patch.

 * * *

I will do some more tests.

Related to those whole-file DECL issues: I wonder why there are still
differences between -flto and -fno-lto on Polyhedron (result is correct but
runtimes are different) and for Jack (-O3 miscompilation of xplor-nih's slink.f
and tenso.f, unless -fno-whole-file is used; -fno-inline-functions does not
help).

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[dominiq at lps dot ens.fr]

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

--- Comment #30 from Dominique d'Humieres  
2011-02-19 12:43:04 UTC ---
The bus error reported in comment #21 has disappeared from my scope between
revisions 167584 and 167726;-(

I'll test the patch in comment #29 ASAP.

[Bug c++/47300] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3564 when using incomplete type as constexpr

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Zdenek Sojka  2011-02-19 12:26:37 
UTC ---
Indeed, I tested r170243 - crash, r170310 - OK. Seems it was fixed by the fix
for PR47208 - it had the same ICE message, just different testcase.

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

[Bug c++/47208] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 with missing #include

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  2011-02-19 12:26:37 
UTC ---
*** Bug 47300 has been marked as a duplicate of this bug. ***

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |pault at gcc dot gnu.org
   |gnu.org |

--- Comment #29 from Paul Thomas  2011-02-19 12:08:49 
UTC ---
Created attachment 23403
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23403
A candidate fix for the PR

I believe that this does the job by generating the missing gsymbol and
populating its namespace with symbols to which backend_decls are attached.

As far as I can see, the same declaration is used consistently for c
(D.1737_69). 

Could somebody please check that I have hold of the right end of the stick?

Thanks

Paul

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #12 from Tobias Burnus  2011-02-19 
11:28:30 UTC ---
Fixed on the trunk (4.6) and on the 4.4 and 4.5 branches.

Thanks for the report!

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  2011-02-19 
11:27:55 UTC ---
Author: burnus
Date: Sat Feb 19 11:27:52 2011
New Revision: 170312

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170312
Log:
2011-02-19  Tobias Burnus

PR fortran/47775
* trans-expr.c (arrayfunc_assign_needs_temporary): Use
esym to check whether the specific procedure returns an
allocatable or pointer.

2011-02-19  Tobias Burnus

PR fortran/47775
* gfortran.dg/func_result_6.f90: New.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/func_result_6.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/trans-expr.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug target/47800] [4.6 Regression] i?86 peephole related ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-02-19 
11:26:01 UTC ---
Fixed.

[Bug tree-optimization/47815] Tail call regression with GCC snapshot

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.19 11:25:54
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-02-19 
11:25:54 UTC ---
Confirmed.  In 4.6 we have noreturn discovery which figures out that
tail_call0 and tail_call1 do not return.  Then this causes us to not
apply tailcall optimization _by design_ to provide accurate backtraces
for noreturn functions which are usually especially used for debugging.

You can simulate the same effect with GCC 4.5 by adding noreturn
in addition to the noinline attribute.

I think we are not going to fix this because it is a feature and not a bug.

[Bug target/47800] [4.6 Regression] i?86 peephole related ICE

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-02-19 
11:23:06 UTC ---
Author: jakub
Date: Sat Feb 19 11:23:02 2011
New Revision: 170311

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170311
Log:
PR target/47800
* config/i386/i386.md (peephole2 for shift and plus): Use
operands[1] original mode in the first insn.

* gcc.target/i386/pr47800.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr47800.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org 2011-02-19 10:41:13 UTC ---
(In reply to comment #0)
> Overriding a TBP seems to OK, if the TBP is hidden through accessibility
> (PRIVATE).

Huh, tricky thing.



> The first example given in the file is rejected with:
> 
>   PROCEDURE,NOPASS :: p => p2 ! (2).
>1
> Error: 'p' at (1) must have the same number of formal arguments as the
> overridden procedure


One can get rid of this error message e.g. by ... (warning: not regtested)


Index: class.c
===
--- class.c (revision 170290)
+++ class.c (working copy)
@@ -639,21 +639,24 @@
   res = gfc_find_symtree (root, name);
   if (res && res->n.tb && !res->n.tb->error)
 {
-  /* We found one.  */
-  if (t)
-   *t = SUCCESS;
-
   if (!noaccess && derived->attr.use_assoc
  && res->n.tb->access == ACCESS_PRIVATE)
{
  if (where)
-   gfc_error ("'%s' of '%s' is PRIVATE at %L",
-  name, derived->name, where);
+   {
+ gfc_error ("'%s' of '%s' is PRIVATE at %L",
+name, derived->name, where);
+ return res;
+   }
+   }
+  else
+   {
+ /* We found one.  */
  if (t)
-   *t = FAILURE;
+   *t = SUCCESS;
+
+ return res;
}
-
-  return res;
 }

   /* Otherwise, recurse on parent type if derived is an extension.  */
Index: resolve.c
===
--- resolve.c   (revision 170290)
+++ resolve.c   (working copy)
@@ -11194,8 +11194,8 @@
   if (super_type)
 {
   gfc_symtree* overridden;
-  overridden = gfc_find_typebound_proc (super_type, NULL,
-   stree->name, true, NULL);
+  overridden = gfc_find_typebound_proc (super_type, NULL, stree->name,
+   false, NULL);

   if (overridden && overridden->n.tb)
stree->n.tb->overridden = overridden->n.tb;



However, one then gets different results than indicated in (3)-(5), i.e.
gfortran always calls 'p2'. It seems our current run-time mechanisms are not
able to cope with this case.

The only way I can see out of this is to resolve the call in 'do_p' not to the
polymorphic version 'x->_vptr->p', but to a static call to the subroutine 'p'
(since 'p' is effectively not overridable, at least not outside the module).

But then it gets really tricky if we put 't2' in the same module. Then 'p'
*will* be overridden, and we have to get back to the dynamic vtable call again
to get it right.

Then be so nasty to add another type 't3' in a different module, which defines
a new TBP 'p' which does *not* override t1%p. And, bang!, we're in trouble
again.

So, I'm clueless. Does it help to put the type-name into the binding name? Say,
have the call in 'do_p' resolve to 'x->_vptr->t1_p' (to honor the fact that the
base type for the call is t1).

[Bug tree-optimization/47815] New: Tail call regression with GCC snapshot

[adam at consulting dot net.nz]

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

   Summary: Tail call regression with GCC snapshot
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@consulting.net.nz


$ gcc-snapshot.sh --version
gcc (Debian 20110126-0ubuntu1) 4.6.0 20110126 (experimental) [trunk revision
169285]

If the code below is compiled with Debian sid gcc-snapshot no tail calls are
generated:

#include 

__attribute__((noinline)) void tail_call0() {
  assert("tail_call0"=="");
}

__attribute__((noinline)) void tail_call1() {
  assert("tail_call1"=="");
}

void make_tail_calls(int flag) {
  if (flag) tail_call0(); else tail_call1();
}

int main() {
  return 0;
}

$ gcc-snapshot.sh -Os tail_call_regression.c && objdump -d -m i386:x86-64 a.out
|less

00400508 :
  400508:   31 c0   xor%eax,%eax
  40050a:   85 ff   test   %edi,%edi
  40050c:   51  push   %rcx
  40050d:   74 05   je 400514 
  40050f:   e8 c0 ff ff ff  callq  4004d4 
  400514:   e8 d5 ff ff ff  callq  4004ee 

Expected output:

$ gcc-4.5 -Os tail_call_regression.c && objdump -d -m i386:x86-64 a.out |less

0040052e :
  40052e:   85 ff   test   %edi,%edi
  400530:   74 07   je 400539 
  400532:   31 c0   xor%eax,%eax
  400534:   e9 bb ff ff ff  jmpq   4004f4 
  400539:   31 c0   xor%eax,%eax
  40053b:   e9 d1 ff ff ff  jmpq   400511 

[Bug target/47814] New: [4.6 Regression] Bootstrap fails on mingw32 by undefined reference to 'lexer_line'

[daniel.f.starke at freenet dot de]

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

   Summary: [4.6 Regression] Bootstrap fails on mingw32 by
undefined reference to 'lexer_line'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de


Trying to build gcc 4.6 r170290 configured with
configure --enable-languages="c,c++" --disable-nls --disable-shared
--enable-static --enable-libgcj --enable-libgomp --enable-lto --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--program-suffix=-4.6 --build=mingw32 --enable-abi=32 --enable-checking=release

fails on mingw32 with
gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,--stack,12582912 -o build/gengtype.exe \
build/gengtype.o build/errors.o build/gengtype-lex.o
build/gengtype-parse.o build/gengtype-state.o build/version.o
../build-mingw32/libiberty/libiberty.a
build/gengtype.o: In function `create_optional_field_':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:843:
undefined reference to `lexer_line'
build/gengtype.o: In function `adjust_field_rtx_def':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:978:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1032:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1042:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1105:
undefined reference to `lexer_line'
build/gengtype.o:D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1144:
more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `token':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:49:
undefined reference to `yylex'
build/gengtype-parse.o: In function `parse_error':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:138:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:138:
undefined reference to `lexer_line'
build/gengtype-parse.o: In function `struct_field_seq':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:688:
undefined reference to `lexer_line'
build/gengtype-parse.o: In function `type':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:722:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:754:
undefined reference to `lexer_line'
build/gengtype-parse.o:D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:754:
more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `parse_file':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:947:
undefined reference to `yybegin'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:982:
undefined reference to `lexer_toplevel_done'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:987:
undefined reference to `yyend'
collect2: ld returned 1 exit status
make[3]: *** [build/gengtype.exe] Error 1
make[3]: Leaving directory `/new-gcc/bin/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/new-gcc/bin'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/new-gcc/bin'
make: *** [bootstrap] Error 2

after running
make bootstrap

Used environment for building:
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runtime-libs --prefix=/mingw
--with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)

binutils-2.21-2-mingw32
bison-2.4.2-1-msys-1.0.13
flex-2.5.35-2-msys-1.0.13
libiconv-1.13.1-1-mingw32
libintl-0.17-1-mingw32-dll-8
libregex-1.20090805-2-msys-1.0.13
mingwrt-3.18-mingw32
pthreads-w32-2.8.0-mingw32
w32api-3.15-1-mingw32

gcc 4.5.2 builds just fine in this environment.

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  2011-02-19 
08:57:13 UTC ---
Author: burnus
Date: Sat Feb 19 08:57:10 2011
New Revision: 170309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170309
Log:
2011-02-19  Tobias Burnus

PR fortran/47775
* trans-expr.c (arrayfunc_assign_needs_temporary): Use
esym to check whether the specific procedure returns an
allocatable or pointer.

2011-02-19  Tobias Burnus

PR fortran/47775
* gfortran.dg/func_result_6.f90: New.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/func_result_6.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog