[Bug fortran/43841] Missing temporary for ELEMENTAL function call

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2010-04-24 07:44 ---
(In reply to comment #7)
> I posted a fix this morning.
...which gives,

  {
struct polar_t D.1625;

D.1625 = b[0];
{
  integer(kind=8) S.18;

  S.18 = 1;
  while (1)
{
  if (S.18 > 3) goto L.15;
  b[S.18 + -1] = div_pp (&b[S.18 + -1], &D.1625);
  S.18 = S.18 + 1;
}
  L.15:;
}
  }


-- 


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

[Bug c/43876] New: [avr] Improper updating of struct members when written out of order from struct definition

[justin at mattair dot net]

avr-gcc may improperly update members of a struct if:

1) The access to the members is in a different order than the struct was
defined and
2) The volatile modifier is used on the struct variable (instance) and
3) The target device is set to atxmega128a1 (possibly all xmega chips) and
4) Optimizations are enabled (I tested -Os)

The following code replicates the problem:

#include 

typedef struct {
uint16_tyear;
uint8_t month;
uint8_t mday;
uint8_t hour;
uint8_t min;
uint8_t sec;
} RTC_time_t;

volatile RTC_time_t t;

void rtc_init (void)
{
t.sec = 0;
t.min = 0;
t.hour = 0;
t.mday = 1;
t.month = 1;
t.year = 2010;
//t.month = 1;
//t.mday = 1;
//t.hour = 0;
//t.min = 0;
//t.sec = 0;
}

void main(void)
{
rtc_init();

while (1);
}

The makefile used was the WinAVR Makefile Template written by Eric B.
Weddington, Jörg Wunsch, et al. with MCU = atxmega128a1. The problem does not
exist when using, for example, MCU = atmega32u2, or if the volatile modifier is
removed.

The problem can be seen in the disassembly of rtc_init(). The disassembly
without the problem:

  t.year = 2010;
7a1c:   8a ed  ldi   r24, 0xDA   ; 218
7a1e:   97 e0  ldi   r25, 0x07   ; 7
7a20:   80 93 1b 2bsts   0x2B1B, r24
7a24:   90 93 1c 2bsts   0x2B1C, r25
  t.month = 1;
7a28:   81 e0  ldi   r24, 0x01   ; 1
7a2a:   80 93 1d 2bsts   0x2B1D, r24
  t.mday = 1;
7a2e:   80 93 1e 2bsts   0x2B1E, r24
  t.hour = 0;
7a32:   10 92 1f 2bsts   0x2B1F, r1
  t.min = 0;
7a36:   10 92 20 2bsts   0x2B20, r1
  t.sec = 0;
7a3a:   10 92 21 2bsts   0x2B21, r1 

which is pretty straightforward.

The disassembly of the nonworking version:

t.sec = 0;
7a1c:   10 92 21 2bsts   0x2B21, r1
  t.min = 0;
7a20:   e0 e2  ldi   r30, 0x20   ; 32
7a22:   fb e2  ldi   r31, 0x2B   ; 43
7a24:   10 82  st   Z, r1
  t.hour = 0;
7a26:   12 92  st   -Z, r1
  t.mday = 1;
7a28:   81 e0  ldi   r24, 0x01   ; 1
7a2a:   82 93  st   -Z, r24
  t.month = 1;
7a2c:   82 93  st   -Z, r24
  t.year = 2010;
7a2e:   8a ed  ldi   r24, 0xDA   ; 218
7a30:   97 e0  ldi   r25, 0x07   ; 7
7a32:   31 97  sbiw   r30, 0x01   ; 1
7a34:   81 93  st   Z+, r24
7a36:   90 83  st   Z, r25
7a38:   32 97  sbiw   r30, 0x02   ; 2 

As you can see, the high byte of t.year is being updated with the low byte of
2010. Then t.month is overwritten with the high byte of 2010. The compiler
should have subtracted 2 from Z (the first sbiw instruction), but it only
subtracts 1. It does manage to subtract 2 in the last instruction, which seems
rather pointless.

I have tested this using both avr-gcc 4.3.3 (built on Linux using the
"build-avr-gcc-4.3.3-binutils-2.20-libc-1.6.8-insight6.8-dude-5.10-insight-patch"
script available on avrfreaks.net), avr-gcc 4.3.4, as well as WinAVR20100110 on
Windows. The problem exists in all of these cases.


Using built-in specs.
Target: avr
Configured with: ../../source/gcc-4.3.4/configure -v --target=avr --disable-nls
--prefix=/usr/local/avr --with-gnu-ld --with-gnu-as --enable-languages=c,c++
--disable-libssp --with-dwarf2
Thread model: single
gcc version 4.3.4 (GCC)

Command Line: avr-gcc -c -mmcu=atxmega128a1 -I. -gdwarf-2 -DF_CPU=3200UL 
-Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wundef -Wall -Wstrict-prototypes -Wa,-adhlns=test.lst 
-std=gnu99 -MD -MP -MF .dep/test.o.d test.c -o test.o


-- 
   Summary: [avr] Improper updating of struct members when written
out of order from struct definition
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: justin at mattair dot net
GCC target triplet: avr-*-*


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

[Bug fortran/43843] Wrong-code due to missing temporary with user-defined operatator

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2010-04-24 09:28 ---
Subject: Bug 43843

Author: pault
Date: Sat Apr 24 09:28:32 2010
New Revision: 158683

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158683
Log:
2010-04-24  Paul Thomas  

PR fortran/43841
PR fortran/43843
* trans-expr.c (gfc_conv_expr): Supply an address expression for
GFC_SS_REFERENCE.
(gfc_conv_expr_reference): Call gfc_conv_expr and return for
GFC_SS_REFERENCE.
* trans-array.c (gfc_add_loop_ss_code): Store the value rather
than the address of a GFC_SS_REFERENCE.
* trans.h : Change comment on GFC_SS_REFERENCE. 

2010-04-24  Paul Thomas  

PR fortran/43841
PR fortran/43843
* gfortran.dg/elemental_scalar_args_1.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/elemental_scalar_args_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43841] Missing temporary for ELEMENTAL function call

[pault at gcc dot gnu dot org]

--- Comment #9 from pault at gcc dot gnu dot org  2010-04-24 09:28 ---
Subject: Bug 43841

Author: pault
Date: Sat Apr 24 09:28:32 2010
New Revision: 158683

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158683
Log:
2010-04-24  Paul Thomas  

PR fortran/43841
PR fortran/43843
* trans-expr.c (gfc_conv_expr): Supply an address expression for
GFC_SS_REFERENCE.
(gfc_conv_expr_reference): Call gfc_conv_expr and return for
GFC_SS_REFERENCE.
* trans-array.c (gfc_add_loop_ss_code): Store the value rather
than the address of a GFC_SS_REFERENCE.
* trans.h : Change comment on GFC_SS_REFERENCE. 

2010-04-24  Paul Thomas  

PR fortran/43841
PR fortran/43843
* gfortran.dg/elemental_scalar_args_1.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/elemental_scalar_args_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/43877] New: container declaration disables standard outoput

[nico at josuttis dot de]

With g++ 4.5.0 built on cygwin pc (x86, 32bit) the following
program has no output. Without the declaration of the vector
anything works fine as expected.
Does anybody know what could cause this strange behavior?

#include 
#include 

int main()
{
std::cout << "hello" << std::endl;
std::vector v;
}


-- 
   Summary: container declaration disables standard outoput
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nico at josuttis dot de


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

[Bug bootstrap/43878] New: Building a cross gcc fails due to a bug in the build process

[fgn123 at freenet dot de]

I am building gcc 4.4.3 with the following ./configure command line:

../gcc-4.4.3/configure --prefix=/some_path/build_tools
--program-prefix=build-tool- --build=i686-pc-linux-gnu
--host=i686-buildtools-linux-gnu
--with-gmp-include=/some_path/build_tools/include
--with-gmp-lib=/some_path/build_tools/lib
--with-mpfr-include=/some_path/build_tools/include
--with-mpfr-lib=/some_path/build_tools/lib
--with-ld=/some_path/build_tools/bin/build-tool-ld
--with-as=/some_path/build_tools/bin/build-tool-as --disable-nls
--disable-shared --disable-multilib --disable-decimal-float --disable-threads
--disable-libmudflap --disable-libssp --disable-libgomp --disable-bootstrap
--enable-languages=c

During the build process, libdecnumber is compiled - which works fine,
as the libdecnumber/configure script sets "enable_decimal_float" to "bid",
regardless of the "disable-decimal-float" option that was given on the toplevel
configure command line. 
The following code was extracted from libdecnumber/configure.ac:

# x86's use BID format instead of DPD
# In theory --enable-decimal-float=no should not compile anything
# For the sake of simplicity, just use the default format in this directory
if test x$enable_decimal_float = xyes -o x$enable_decimal_float = xno; then
  case $target in
i?86*-*-linux* | x86_64*-*-linux*)
  enable_decimal_float=bid
  ;;
*)
  enable_decimal_float=dpd
  ;;
  esac
fi

Later in the build process, gcc configures libgcc: 

>> Checking multilib configuration for libgcc...
>> mkdir -p -- i686-buildtools-linux-gnu/libgcc
>> Configuring in i686-buildtools-linux-gnu/libgcc

libgcc/configure, in contrary to libdecnumber/configure, leaves 
"enable_decimal_float" set to "no". 
The following code is extracted from libgcc/configure.ac:

# x86's use BID format instead of DPD
if test x$enable_decimal_float = xyes; then
  case $host in
i?86*-*-linux* | x86_64*-*-linux*)
  enable_decimal_float=bid
  ;;
*)
  enable_decimal_float=dpd
  ;;
  esac
fi

The resulting libgcc/Makefile then tries to build libdecnumber and fails,
as the relevant libdecnumber/bid/* files are not included.

This is an extract from libgcc/Makefile in:

ifeq ($(decimal_float),yes)
ifeq ($(enable_decimal_float),bid)
DECNUMINC = -I$(srcdir)/config/libbid -DENABLE_DECIMAL_BID_FORMAT
else
DECNUMINC = -I$(srcdir)/../libdecnumber/$(enable_decimal_float) \
-I$(srcdir)/../libdecnumber
endif
else
DECNUMINC =
endif

"decimal_float" is "yes" on my system, "enable_decimal_float" is "no".
So with "DECNUMINC" being

>> -I$(srcdir)/../libdecnumber/$(enable_decimal_float) \
>>  -I$(srcdir)/../libdecnumber

the build:

cc  -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include 
-fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I../../../gcc-4.4.3/libgcc -I../../../gcc-4.4.3/libgcc/.
-I../../../gcc-4.4.3/libgcc/../gcc -I../../../gcc-4.4.3/libgcc/../include
-I../../../gcc-4.4.3/libgcc/../libdecnumber/no
-I../../../gcc-4.4.3/libgcc/../libdecnumber -DHAVE_CC_TLS -DUSE_TLS -o
decLibrary.o -MT decLibrary.o -MD -MP -MF decLibrary.dep -c
../../../gcc-4.4.3/libgcc/../libdecnumber/decLibrary.c

of course fails with errors of this kind:

../../../gcc-4.4.3/libgcc/../libdecnumber/decLibrary.c:27:24: error:
decimal128.h: No such file or directory


Yes, I can circumvent this by simply setting --decimal-float=bid or not setting
--decimal-float at all, but I guess some fine tuning regarding the building of
libdecnumber is required as well. 

Thanks a lot,

Frank


-- 
   Summary: Building a cross gcc fails due to a bug in the build
process
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fgn123 at freenet dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-buildtools-linux-gnu
GCC target triplet: i686-buildtools-linux-gnu


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

[Bug libstdc++/43877] container declaration disables standard output

[nico at josuttis dot de]

--- Comment #1 from nico at josuttis dot de  2010-04-24 10:16 ---
compiler built with:
 ../src/gcc-4*/configure
--prefix=/cygdrive/p/gcc4
--program-suffix=4
--with-gxx-include-dir=/cygdrive/p/gcc4-include
example compiled with:
 g++4 -std=c++0x move.cpp -o move


-- 

nico at josuttis dot de changed:

   What|Removed |Added

Summary|container declaration   |container declaration
   |disables standard outoput   |disables standard output


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

[Bug target/42879] Replace "tst r3, 1" with "lsl r3, r3, 31" in thumb2

[carrot at google dot com]

--- Comment #3 from carrot at google dot com  2010-04-24 11:53 ---
lsls  r2,r3, #1   can be assembled to 16 bit.

lsl   r2,r3, #1  is 32 bit because only 32 bit encoding can ignore condition
code.


-- 


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

[Bug libfortran/43844] open(unit, status="scratch") fails to create tempporary file

[ktietz at gcc dot gnu dot org]

--- Comment #10 from ktietz at gcc dot gnu dot org  2010-04-24 12:02 ---
So I investigated this issue about mktemp in more detail and found finally the
first-scope and second-scope bug here.

Old logic was opening files and as long as mktemp failed on a second call,
things were working (the re-initialization of the template was missing, so one
of the following calls will failed). As side-effect there were many file
handles generated, which weren't closed.

Tested patch is

Index: unix.c
===
--- unix.c  (revision 158676)
+++ unix.c  (working copy)
@@ -889,25 +889,26 @@

   template = get_mem (strlen (tempdir) + 20);

+#ifdef HAVE_MKSTEMP
   sprintf (template, "%s/gfortrantmpXX", tempdir);

-#ifdef HAVE_MKSTEMP
-
   fd = mkstemp (template);

 #else /* HAVE_MKSTEMP */
-
-  if (mktemp (template))
-do
+  fd = -1;
+  do
+{
+  sprintf (template, "%s/gfortrantmpXX", tempdir);
+  if (!mktemp (template))
+   break;
 #if defined(HAVE_CRLF) && defined(O_BINARY)
   fd = open (template, O_RDWR | O_CREAT | O_EXCL | O_BINARY,
 S_IREAD | S_IWRITE);
 #else
   fd = open (template, O_RDWR | O_CREAT | O_EXCL, S_IREAD | S_IWRITE);
 #endif
-while (!(fd == -1 && errno == EEXIST) && mktemp (template));
-  else
-fd = -1;
+}
+  while (fd == -1 && errno == EEXIST);

 #endif /* HAVE_MKSTEMP */

Ok for applying it to trunk, 4.5, and 4.4?

Kai


-- 


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

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-04-24 12:04 
---
Subject: Bug 43832

Author: jvdelisle
Date: Sat Apr 24 12:04:09 2010
New Revision: 158684

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158684
Log:
2010-04-24  Jerry DeLisle  

PR fortran/43832
* io.c (gfc_match_open): Remove branch to syntax error. Add call to
gfc_error with new error message.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c


-- 


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

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-04-24 12:07 
---
Subject: Bug 43832

Author: jvdelisle
Date: Sat Apr 24 12:07:07 2010
New Revision: 158685

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158685
Log:
2010-04-24  Jerry DeLisle  

PR fortran/43832
* gfortran.dg/open_nounit.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/open_nounit.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-04-24 12:09 
---
Fixed on trunk. Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/43844] open(unit, status="scratch") fails to create tempporary file

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2010-04-24 12:17 
---
Yes, OK to commit to trunk. Thanks!


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-24 12:17:26
   date||


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[jv244 at cam dot ac dot uk]

--- Comment #12 from jv244 at cam dot ac dot uk  2010-04-24 12:25 ---
This was also ported back to 4.5.1, causing a regression there. This is against
the policy of 'open for regression and documentation fixes'. It was also never
approved for the branch only trunk.

2010-04-16  Steven G. Kargl  

PR fortran/30073
* trans-array.c (gfc_trans_array_bound_check): Eliminate a redundant
block of code.  Set name to the variable associated with the
descriptor.

Just for completeness, this testcase again emphasizes that this is an ICE on
valid code.

MODULE fft_tools
  IMPLICIT NONE
  INTEGER, PARAMETER :: sp=4, dp=8
  INTEGER, PARAMETER :: lp = dp
CONTAINS
  SUBROUTINE sparse_alltoall ( rs, rq, rcount, rreq, group )
COMPLEX(KIND=lp), DIMENSION(:, :), &
  POINTER:: rs
COMPLEX(KIND=lp), DIMENSION(:, :), &
  POINTER:: rq
INTEGER, DIMENSION(:) :: rcount,rreq
INTEGER :: group, pos
IF ( rcount(pos) /= 0 ) THEN
   rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos)
END IF
  END SUBROUTINE sparse_alltoall
END MODULE fft_tools


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||rguenther at suse dot de
   Keywords|ice-on-invalid-code |ice-on-valid-code
  Known to fail|4.6.0   |4.5.1 4.6.0
Summary|[4.6 Regression] tree check:|[4.5/4.6 Regression] tree
   |expected tree that contains |check: expected tree that
   |�decl minimal�  |contains �decl minimal�
   |structure, have |structure, have
   |�indirect_ref� in   |�indirect_ref� in
   |gfc_trans_array_bound_check |gfc_trans_array_bound_check
   Target Milestone|4.6.0   |4.5.1


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

[Bug libfortran/43844] open(unit, status="scratch") fails to create tempporary file

[ktietz at gcc dot gnu dot org]

--- Comment #12 from ktietz at gcc dot gnu dot org  2010-04-24 12:25 ---
(In reply to comment #11)
> Yes, OK to commit to trunk. Thanks!
> 

Ok, applied to trunk at revision 158686.

Kai


-- 


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

[Bug fortran/43227] [4.5 Regression] ICE: segmentation fault in mio_expr

[pault at gcc dot gnu dot org]

--- Comment #28 from pault at gcc dot gnu dot org  2010-04-24 12:29 ---
Subject: Bug 43227

Author: pault
Date: Sat Apr 24 12:29:23 2010
New Revision: 158687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158687
Log:
2010-04-24  Paul Thomas  

PR fortran/43227
* resolve.c (resolve_fl_derived): If a component character
length has not been resolved, do so now.
(resolve_symbol): The same as above for a symbol character
length.
* trans-decl.c (gfc_create_module_variable): A 'length' decl is
not needed for a character valued, procedure pointer.

PR fortran/43266
* resolve.c (ensure_not_abstract_walker): If 'overriding' is
not found, return FAILURE rather than ICEing.

2010-04-24  Paul Thomas  

PR fortran/43227
* gfortran.dg/proc_decl_23.f90: New test.

PR fortran/43266
* gfortran.dg/abstract_type_6.f03: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/abstract_type_6.f03
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/proc_decl_23.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/resolve.c
branches/gcc-4_5-branch/gcc/fortran/trans-decl.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2010-04-24 12:29 ---
Subject: Bug 43266

Author: pault
Date: Sat Apr 24 12:29:23 2010
New Revision: 158687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158687
Log:
2010-04-24  Paul Thomas  

PR fortran/43227
* resolve.c (resolve_fl_derived): If a component character
length has not been resolved, do so now.
(resolve_symbol): The same as above for a symbol character
length.
* trans-decl.c (gfc_create_module_variable): A 'length' decl is
not needed for a character valued, procedure pointer.

PR fortran/43266
* resolve.c (ensure_not_abstract_walker): If 'overriding' is
not found, return FAILURE rather than ICEing.

2010-04-24  Paul Thomas  

PR fortran/43227
* gfortran.dg/proc_decl_23.f90: New test.

PR fortran/43266
* gfortran.dg/abstract_type_6.f03: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/abstract_type_6.f03
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/proc_decl_23.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/resolve.c
branches/gcc-4_5-branch/gcc/fortran/trans-decl.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43227] [4.5 Regression] ICE: segmentation fault in mio_expr

[pault at gcc dot gnu dot org]

--- Comment #29 from pault at gcc dot gnu dot org  2010-04-24 12:30 ---
Fixed on trunk and 4.5.

Thanks, as ever, Dominique!

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/18401] Bootstrap failure on all ARM targets due to incorrect GCSE

[rearnsha at gcc dot gnu dot org]

--- Comment #9 from rearnsha at gcc dot gnu dot org  2010-04-24 12:43 
---
Not seen this again in a long time, so closing as works for me.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/43868] [4.5/4.6 Regression] ICE with -g

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-04-24 13:47 ---
It is caused by revision 153978:

http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00196.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug target/19598] [arm] non-optimal handling of invalid immediate constant in XOR

[rearnsha at gcc dot gnu dot org]

--- Comment #2 from rearnsha at gcc dot gnu dot org  2010-04-24 14:24 
---
Fixed with:

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01723.html


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/43879] New: [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/20000822-1.c execution

[zsojka at seznam dot cz]

Tested revisions:
r158683 - fail
r158486 - OK

Compiler output:
$ binary-158683-lto-fortran/bin/gcc -O2 -fipa-pta
gcc/testsuite/gcc.c-torture/execute/2822-1.c && ./a.out
gcc/testsuite/gcc.c-torture/execute/2822-1.c: In function 'main':
gcc/testsuite/gcc.c-torture/execute/2822-1.c:25:5: warning: incompatible
implicit declaration of built-in function 'abort' [enabled by default]
Aborted

Is -fipa-pta still no-op?


-- 
   Summary: [4.6 Regression] -fipa-pta causes FAIL: gcc.c-
torture/execute/2822-1.c execution
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/43879] [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/20000822-1.c execution

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-24 16:17 ---
It also causes:

$ binary-158683-lto-fortran/bin/gcc -O3 -fipa-pta
gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c && ./a.out
gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c: In function 'main':
gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c:44:5: warning: incompatible
implicit declaration of built-in function 'abort' [enabled by default]
gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c:47:3: warning: incompatible
implicit declaration of built-in function 'exit' [enabled by default]
Aborted

r158486 was fine


-- 


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2010-04-24 16:56 ---
(In reply to comment #12)
> 
> Just for completeness, this testcase again emphasizes that this is an ICE on
> valid code.
> 
> MODULE fft_tools
>   IMPLICIT NONE
>   INTEGER, PARAMETER :: sp=4, dp=8
>   INTEGER, PARAMETER :: lp = dp
> CONTAINS
>   SUBROUTINE sparse_alltoall ( rs, rq, rcount, rreq, group )
> COMPLEX(KIND=lp), DIMENSION(:, :), &
>   POINTER:: rs
> COMPLEX(KIND=lp), DIMENSION(:, :), &
>   POINTER:: rq
> INTEGER, DIMENSION(:) :: rcount,rreq
> INTEGER :: group, pos
> IF ( rcount(pos) /= 0 ) THEN
>rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos)
> END IF
>   END SUBROUTINE sparse_alltoall
> END MODULE fft_tools

For even more completeness, the code in comment #12 is still
invalid.  Don't worry I'll fix it before I eventually commit
the patch as noted in comment #11.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|rguenther at suse dot de|


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

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2010-04-24 17:01 ---
Subject: Bug 43832

Author: hp
Date: Sat Apr 24 17:00:52 2010
New Revision: 158688

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158688
Log:
PR fortran/43832
* gfortran.dg/fgetc_3.f90: Delete bogus test.

Removed:
trunk/gcc/testsuite/gfortran.dg/fgetc_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[jv244 at cam dot ac dot uk]

--- Comment #14 from jv244 at cam dot ac dot uk  2010-04-24 17:58 ---
(In reply to comment #13)

> For even more completeness, the code in comment #12 is still
> invalid.

do you mind to clarify ?


-- 


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[kargl at gcc dot gnu dot org]

--- Comment #15 from kargl at gcc dot gnu dot org  2010-04-24 18:03 ---
(In reply to comment #14)
> (In reply to comment #13)
> 
> > For even more completeness, the code in comment #12 is still
> > invalid.
> 
> do you mind to clarify ?
> 

pos is undefined.

Here's the testcase I will be committing.module fft_tools
  implicit none
  integer, parameter :: lp = 8
contains
  subroutine sparse_alltoall (rs, rq, rcount)
complex(kind=lp), dimension(:, :), pointer :: rs, rq
integer, dimension(:) :: rcount
integer :: pos
pos = 1
if (rcount(pos) /= 0) then
   rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos)
end if
  end subroutine sparse_alltoall
end module fft_tools


-- 


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[jv244 at cam dot ac dot uk]

--- Comment #16 from jv244 at cam dot ac dot uk  2010-04-24 18:12 ---
(In reply to comment #15)
> 
> pos is undefined.
> 

Ah, we're at that level.


-- 


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[kargl at gcc dot gnu dot org]

--- Comment #17 from kargl at gcc dot gnu dot org  2010-04-24 18:38 ---
Patch is here:

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01518.html


-- 


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

[Bug tree-optimization/43879] [4.6 Regression] -fipa-pta causes various miscompilations

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-04-24 18:49 ---
Bootstrap fails too with -fipa-pta, (at least) cfgrtl.o is miscompiled.


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

Summary|[4.6 Regression] -fipa-pta  |[4.6 Regression] -fipa-pta
   |causes FAIL: gcc.c- |causes various
   |torture/execute/2822-1.c|miscompilations
   |execution   |


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

[Bug tree-optimization/41442] missed optimization for boolean expression

[bernds at gcc dot gnu dot org]

--- Comment #4 from bernds at gcc dot gnu dot org  2010-04-24 18:54 ---
Subject: Bug 41442

Author: bernds
Date: Sat Apr 24 18:53:47 2010
New Revision: 158689

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158689
Log:
gcc/
PR tree-optimization/41442
* fold-const.c (merge_truthop_with_opposite_arm): New function.
(fold_binary_loc): Call it.

gcc/testsuite/
PR tree-optimization/41442
* gcc.target/i386/pr41442.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr41442.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-04-24 18:55 ---
Well, -fipa-pta is no longer a no-op and I wouldn't call the existing (known)
bugs a regression.  I have some pending patches to fix issues.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-24 18:55:15
   date||
Summary|[4.6 Regression] -fipa-pta  |-fipa-pta causes various
   |causes various  |miscompilations
   |miscompilations |


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

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-04-24 20:04 ---
(In reply to comment #2)
> Bootstrap fails too with -fipa-pta, (at least) cfgrtl.o is miscompiled.

Yep, I know.  If you can isolate the miscompile that would be great
(I am concentrating on completing IPA PTA as time permits).


-- 


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

[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-24 20:23 ---
With -fipa-cp -flto -fuse-linker-plugin -Wl,--allow-multiple-definition,
but gold does not know --allow-multiple-definition and thus I get

> gcc-4.5 1.c 2.c -fipa-cp -flto -fuse-linker-plugin
/usr/bin/gold: error: /tmp/ccLqKKQ3.o: multiple definition of f
/usr/bin/gold: error: /tmp/ccgya79G.o: previous definition here
lto1: internal compiler error: bytecode stream: trying to read 0 bytes after
the end of the input buffer

which simply means that we do not properly detect gold exiting with an error.

With GNU ld and w/o -fuse-linker-plugin I see

$ ./xgcc -B. 2.c 1.c -fipa-cp -flto -Wl,--allow-multiple-definition
/tmp/ccedC6yL.o: In function `f':
2.c:(.text+0x7): undefined reference to `g'
2.c:(.text+0xf): undefined reference to `h'
collect2: ld returned 1 exit status

which means it "works" and we choose the wrong f() to succeed linking
and thus we never end up invoking lto1 (which is what should happen
in the gold case as well).

Yes, we _do_ invoke the linker before invoking lto1!


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-24 20:23:01
   date||


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[kargl at gcc dot gnu dot org]

--- Comment #18 from kargl at gcc dot gnu dot org  2010-04-24 20:32 ---
Subject: Bug 43793

Author: kargl
Date: Sat Apr 24 20:32:04 2010
New Revision: 158692

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158692
Log:
2010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
* trans-array.c (gfc_trans_array_bound_check): Use TREE_CODE instead
of mucking with a tree directly.

2010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
gfortran.dg/pr43793.f90: New test.

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


-- 


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

[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2010-04-24 20:32 ---
Subject: Bug 30073

Author: kargl
Date: Sat Apr 24 20:32:04 2010
New Revision: 158692

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158692
Log:
2010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
* trans-array.c (gfc_trans_array_bound_check): Use TREE_CODE instead
of mucking with a tree directly.

2010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
gfortran.dg/pr43793.f90: New test.

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


-- 


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

[Bug c++/43880] New: internal compiler error: in make_decl_rtl

[jengelh at medozas dot de]

pngtex.cpp: In constructor ‘test::test()’:
pngtex.cpp:12:14: internal compiler error: in make_decl_rtl, at varasm.c:1317
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.5/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.5
--enable-linux-futex --without-system-libunwind --enable-gold
--with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.5.0 20100420 [gcc-4_5-branch revision 158562] (SUSE Linux)


-- 
   Summary: internal compiler error: in make_decl_rtl
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengelh at medozas dot de
 GCC build triplet: i586-suse-linux-gnu
  GCC host triplet: i586-suse-linux-gnu
GCC target triplet: i586-suse-linux-gnu


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

[Bug c++/43880] internal compiler error: in make_decl_rtl

[jengelh at medozas dot de]

--- Comment #1 from jengelh at medozas dot de  2010-04-24 20:40 ---
Created an attachment (id=20478)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20478&action=view)
testcase


-- 


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

[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-24 21:44 ---
Confirmed.  Somehow another DECL_VALUE_EXPR issue

test::test() (struct test * const this)
{
  union ._0 D.2124;
  char pngpal[1] [value-expr: D.2119.pngpal];
  char * D.2127;

  # BLOCK 2
  # PRED: ENTRY (fallthru)
  D.2127_1 = &D.2119.pngpal[0];
  xread (D.2127_1);
  return;

there is no D.2119 anymore - it gets replaced with D.2124 duing gimplification.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.5.0
  Known to work||4.4.3
   Last reconfirmed|-00-00 00:00:00 |2010-04-24 21:44:56
   date||
Summary|[4.5] internal compiler |[4.5/4.6 Regression]
   |error: in make_decl_rtl |internal compiler error: in
   ||make_decl_rtl
   Target Milestone|--- |4.5.1


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[kargl at gcc dot gnu dot org]

--- Comment #19 from kargl at gcc dot gnu dot org  2010-04-24 21:47 ---
Subject: Bug 43793

Author: kargl
Date: Sat Apr 24 21:46:45 2010
New Revision: 158693

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158693
Log:
010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
* trans-array.c (gfc_trans_array_bound_check): Use TREE_CODE instead
of mucking with a tree directly.

2010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
gfortran.dg/pr43793.f90: New test.

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


-- 


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

[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2010-04-24 21:47 ---
Subject: Bug 30073

Author: kargl
Date: Sat Apr 24 21:46:45 2010
New Revision: 158693

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158693
Log:
010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
* trans-array.c (gfc_trans_array_bound_check): Use TREE_CODE instead
of mucking with a tree directly.

2010-04-24  Steven G. Kargl  

PR fortran/30073
PR fortran/43793
gfortran.dg/pr43793.f90: New test.

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


-- 


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

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

[kargl at gcc dot gnu dot org]

--- Comment #20 from kargl at gcc dot gnu dot org  2010-04-24 21:48 ---
Fix.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/43881] New: warning attached to a function is emitted even though the function is not being called

[bruno at clisp dot org]

The gcc documentation, section "Declaring Attributes of Functions", states
about the __attribute__ ((__warning__ ("..."))) of a function:
"If this attribute is used on a function declaration and a call to
such a function is not eliminated through dead code elimination or
other optimizations, a warning which will include MESSAGE will be
diagnosed."

Here is a case where the warning is diagnosed although the program contains
no direct call to the function:
=== main.cc ===
extern "C" int close(int);
static int (*safe_close) (int fd) = close;
extern __typeof__ (close) close __attribute__ ((__warning__ ("The symbol close
refers to the system function. Use safe_close instead.")));
int fd;
int main()
{
  safe_close(fd);
}
===
$ g++ -S -O main.cc
main.cc: In function 'int main()':
main.cc:7:17: warning: call to 'close' declared with attribute warning: The
symbol close refers to the system function. Use safe_close instead.

The warning is not justified, because its only use is as initializer
of the variable 'safe_close', and at that moment, the warning is not yet
attached to it.

Notes:
  - The warning occurs only with optimization, not with -O0.
  - The warning occurs only if the variable 'safe_close' is 'static', not
when it is changed to a global variable.
  - The behaviour of GCC 4.3.4 and GCC 4.4.3 is the same as the one of GCC
4.5.0.


-- 
   Summary: warning attached to a function is emitted even though
the function is not being called
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
 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=43881

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

[bruno at clisp dot org]

--- Comment #1 from bruno at clisp dot org  2010-04-24 22:49 ---
Created an attachment (id=20479)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20479&action=view)
test case


-- 


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

Re: [Bug c++/43881] New: warning attached to a function is emitted even though the function is not being called

[Andrew Pinski]

It is called directly because safe_close's value is replaced in the  
indirect call. Since safe_close is static and not changed in the code  
at all, it is marked as read only and the initialized value can be  
used directly.


Sent from my iPhone

On Apr 24, 2010, at 3:49 PM, "bruno at clisp dot org" > wrote:


The gcc documentation, section "Declaring Attributes of Functions",  
states

about the __attribute__ ((__warning__ ("..."))) of a function:
"If this attribute is used on a function declaration and a call to
such a function is not eliminated through dead code elimination or
other optimizations, a warning which will include MESSAGE will be
diagnosed."

Here is a case where the warning is diagnosed although the program  
contains

no direct call to the function:
=== main.cc ===
extern "C" int close(int);
static int (*safe_close) (int fd) = close;
extern __typeof__ (close) close __attribute__ ((__warning__ ("The  
symbol close

refers to the system function. Use safe_close instead.")));
int fd;
int main()
{
 safe_close(fd);
}
===
$ g++ -S -O main.cc
main.cc: In function 'int main()':
main.cc:7:17: warning: call to 'close' declared with attribute  
warning: The

symbol close refers to the system function. Use safe_close instead.

The warning is not justified, because its only use is as initializer
of the variable 'safe_close', and at that moment, the warning is not  
yet

attached to it.

Notes:
 - The warning occurs only with optimization, not with -O0.
 - The warning occurs only if the variable 'safe_close' is 'static',  
not

   when it is changed to a global variable.
 - The behaviour of GCC 4.3.4 and GCC 4.4.3 is the same as the one  
of GCC

4.5.0.


--
  Summary: warning attached to a function is emitted even  
though

   the function is not being called
  Product: gcc
  Version: 4.5.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: bruno at clisp dot org
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=43881

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2010-04-24 23:12 ---
Subject: Re:   New: warning attached to a function is emitted even though the
function is not being called

It is called directly because safe_close's value is replaced in the  
indirect call. Since safe_close is static and not changed in the code  
at all, it is marked as read only and the initialized value can be  
used directly.

Sent from my iPhone

On Apr 24, 2010, at 3:49 PM, "bruno at clisp dot org"  wrote:

> The gcc documentation, section "Declaring Attributes of Functions",  
> states
> about the __attribute__ ((__warning__ ("..."))) of a function:
> "If this attribute is used on a function declaration and a call to
> such a function is not eliminated through dead code elimination or
> other optimizations, a warning which will include MESSAGE will be
> diagnosed."
>
> Here is a case where the warning is diagnosed although the program  
> contains
> no direct call to the function:
> === main.cc ===
> extern "C" int close(int);
> static int (*safe_close) (int fd) = close;
> extern __typeof__ (close) close __attribute__ ((__warning__ ("The  
> symbol close
> refers to the system function. Use safe_close instead.")));
> int fd;
> int main()
> {
>  safe_close(fd);
> }
> ===
> $ g++ -S -O main.cc
> main.cc: In function 'int main()':
> main.cc:7:17: warning: call to 'close' declared with attribute  
> warning: The
> symbol close refers to the system function. Use safe_close instead.
>
> The warning is not justified, because its only use is as initializer
> of the variable 'safe_close', and at that moment, the warning is not  
> yet
> attached to it.
>
> Notes:
>  - The warning occurs only with optimization, not with -O0.
>  - The warning occurs only if the variable 'safe_close' is 'static',  
> not
>when it is changed to a global variable.
>  - The behaviour of GCC 4.3.4 and GCC 4.4.3 is the same as the one  
> of GCC
> 4.5.0.
>
>
> -- 
>   Summary: warning attached to a function is emitted even  
> though
>the function is not being called
>   Product: gcc
>   Version: 4.5.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: bruno at clisp dot org
> 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=43881
>


-- 


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

[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-04-24 23:23 ---
It is caused by revision 149750:

http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00631.html


-- 


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

[Bug libstdc++/43877] container declaration disables standard output

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-04-24 23:28 
---
Totally crazy. Dave can you reproduce this?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||dave dot korn dot cygwin at
   ||gmail dot com


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

[Bug libstdc++/43877] container declaration disables standard output

[davek at gcc dot gnu dot org]

--- Comment #3 from davek at gcc dot gnu dot org  2010-04-24 23:33 ---
(In reply to comment #2)
> Totally crazy. Dave can you reproduce this?
> 

  I have a theory.  Will report back in ten minutes or so...


-- 


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

[Bug libstdc++/43877] container declaration disables standard output

[davek at gcc dot gnu dot org]

--- Comment #4 from davek at gcc dot gnu dot org  2010-04-24 23:44 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Totally crazy. Dave can you reproduce this?
> > 
> 
>   I have a theory.  Will report back in ten minutes or so...

Uh, well, nope, that didn't work.  I was wondering if the code might have been
using some new export from the DLL that didn't exist back in 4.3.4 days, and
that would cause problems if the distro's dll was in $PATH ahead of the newly
built one, but then I tried it and it worked fine.

However, this problem is symptomatic of a missing DLL, or a DLL which doesn't
have an expected export.  Nicolai, please run "cygcheck ./move.exe" and paste
the results into the PR, and please zip up and attach the generated exe file
and I'll try and figure out what went wrong.


-- 


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

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

[bruno at clisp dot org]

--- Comment #3 from bruno at clisp dot org  2010-04-24 23:54 ---
When the line
  static int (*safe_close) (int fd) = close;
is changed to
  static int (*safe_close) (int fd) = ((void)0, close);
the warning also disappears, but then the generate code is suboptimal:
the variable safe_close is not eliminated from the 'data' section.
Therefore I cannot use this as a workaround.


-- 


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

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

[bruno at clisp dot org]

--- Comment #4 from bruno at clisp dot org  2010-04-24 23:58 ---
(In reply to comment #2)
> It is called directly because safe_close's value is replaced in the  
> indirect call. Since safe_close is static and not changed in the code  
> at all, it is marked as read only and the initialized value can be  
> used directly.

This is an explanation why gcc behaves like this, but not a justification.

1) GCC should try to make warnings independent of optimization settings.
2) GCC warns about a line of code that calls 'safe_close', which it should not
   warn about. Only calls of 'close' should be warned about, and there are
   no such calls in the source program.


-- 


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

[Bug c++/43882] New: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[yuri at tsoft dot com]

I have a c++ project with a lots of STL.
It compiles fine with gcc 4.3.1 and 4.4.3, but with the new 4.5.0 I get those
two missing symbols in linking:

std::_List_node_base::_M_hook(std::_List_node_base*)
std::_List_node_base::_M_unhook()

libstdc++.so from 4.5.0 has those relevant symbols, and the ones not found are
there:
000584c4 T std::_List_node_base::_M_hook(std::_List_node_base*)
000585bc T std::__norm::_List_node_base::_M_hook(std::__norm::_List_node_base*)
000ab3c8 T
std::__cxx1998::_List_node_base::_M_hook(std::__cxx1998::_List_node_base*)
000584e0 T std::_List_node_base::_M_unhook()
000585d8 T std::__norm::_List_node_base::_M_unhook()
000ab3e4 T std::__cxx1998::_List_node_base::_M_unhook()


-- 
   Summary: 4.5.0 produces missing symbols
(std::_List_node_base::_M_hook ...)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-04-25 00:28 
---
Thus the symbols are there, and exported (ie, capital T), everything seems fine
to me.


-- 


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

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[yuri at tsoft dot com]

--- Comment #2 from yuri at tsoft dot com  2010-04-25 00:35 ---
But linker produces messages like this:
x.C:229: undefined reference to
`std::_List_node_base::_M_hook(std::_List_node_base*)'

New with the switch to 4.5.0


-- 


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

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-04-25 00:37 
---
Thus, either the linker is buggy, or the installation.


-- 


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

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-04-25 00:40 
---
Note, those symbols are new in 4.5.0, thus you should check that your new 4.5.0
*.so is actually searched by linker, ie, check the installation, again, because
if the linker tries to link vs the 4.4.x *.so the symbols will not be found.


-- 


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

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[yuri at tsoft dot com]

--- Comment #5 from yuri at tsoft dot com  2010-04-25 01:17 ---
Sorry, my bad.

It really was picking up the default libstdc++.so from the OS installation. I
used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out
that -L/path/to/4.5.0/libstdc++.so is also required in addition to this,
otherwise the default libstdc++.so is looked up by linker.

Maybe this is a bug in linker, don't know.

But those new symbols revealed the problem.


-- 


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

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-04-25 04:49 
---
Ok, thanks, let's close this then.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/43883] New: missed optimization of constant __int128_t modulus

[svfuerst at gmail dot com]

The following function gets optimized at -O3 to:

long long tmod2(long long x)
{
return x % 2;
}


mov%rdi,%rdx   
shr$0x3f,%rdx  
lea(%rdi,%rdx,1),%rax  
and$0x1,%eax   
sub%rdx,%rax   
retq

This is very good code.  Unfortunately, the 128 bit version doesn't get
optimized nearly so well.

__int128_t tmod2(__int128_t x)
{
return x % 2;
}

mov%rsi,%rdx
mov%rdi,%r8
xor%ecx,%ecx
shr$0x3f,%rdx
push   %rbx
add%rdx,%r8
xor%edi,%edi
mov%r8,%rsi
mov%rdi,%r9
and$0x1,%esi
mov%rsi,%r8
sub%rdx,%r8
sbb%rcx,%r9
mov%r8,%rax
mov%r9,%rdx
pop%rbx
retq

It looks like this simple variation of the 64bit algorithm will work for the
128 bit version:

mov%rsi,%rdx<--- Just changed rdi into rsi
shr$0x3f,%rdx   <--- nicely already calculates high bytes in rdx
lea(%rdi,%rdx,1),%rax
and$0x1,%eax
sub%rdx,%rax
retq


-- 
   Summary: missed optimization of constant __int128_t modulus
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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