[Bug regression/34221] New: -save-temps is broken on mainline

[ismail at pardus dot org dot tr]

Look at  : 

[~/test]> ls
mul.c

[~/test]> cat mul.c
long long mul (long long a, long long b) {
  return a * b;
}

[~/test]> gcc -c -save-temps mul.c
[~/test]> ls
mul.c  mul.o

No assembly or preprocessed file produced.

If I use -o :

[~/test]> gcc -o mul -save-temps  mul.c
/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status

[~/test]> ls
mul.c  mul.i  mul.o  mul.s

works as expected.


-- 
   Summary: -save-temps is broken on mainline
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ismail at pardus dot org dot tr


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

[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-11-25 08:41 
---
By Olivier.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 08:41:30
   date||


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

[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hainque at adacore dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test

[hainque at adacore dot com]

--- Comment #3 from hainque at adacore dot com  2007-11-25 08:43 ---
Subject: Re:  [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution
test

> ebotcazou at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  AssignedTo|unassigned at gcc dot gnu   |hainque at adacore dot com

 Thanks. I tried to do that yesterday and was refused the privilege.


-- 


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

[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-11-25 08:51 
---
>  Thanks. I tried to do that yesterday and was refused the privilege.

I guess you need to ask Daniel what's going on exactly here.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug c++/34222] New: ice for legal code with -O3

[dcb314 at hotmail dot com]

Hello there,

I just tried to compile the Suse Linux package celestia-1.4.1-16
with the GNU C++ compiler version 4.3 snapshot 20071123

The compiler said

3dsread.cpp: In function 'Mat4f readMeshMatrix(std::ifstream&, int)':
3dsread.cpp:275: error: missing definition
for SSA_NAME: SMT.659_346 in statement:
SMT.659_363 = PHI 
PHI argument
SMT.659_346
for PHI node
SMT.659_363 = PHI 
3dsread.cpp:275: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source code attached. Flag -O3 required.


-- 
   Summary: ice for legal code with -O3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c++/34222] ice for legal code with -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2007-11-25 09:27 ---
Created an attachment (id=14633)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14633&action=view)
C++ source code


-- 


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

[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2007-11-25 09:59 ---
Subject: Bug 33499

Author: pault
Date: Sun Nov 25 09:59:42 2007
New Revision: 130403

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130403
Log:
2007-11-25  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33499
* decl.c (get_proc_name): If ENTRY statement occurs before type
specification, set the symbol untyped and ensure that it is in
the procedure namespace.

2007-11-25  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33499
* gfortran.dg/entry_16.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34223] New: missed optimization - complete unrolling pass before the vectorizer

[eres at il dot ibm dot com]

Consider the following test compiled with r130351 on ppc64-linux:

#define M 10
#define N 3

void
foo (int n, int *ub, int *uc)
{
  int i, j, tmp1;

  for (i = 0; i < n; i++)
{
  tmp1 = 0;
  for (j = 0; j < M; j++)
{
  tmp1 += uc[i] * ((int)(j << N) / M);
}
  ub[i] = tmp1;
}
}

Here is a snippet from the vectorizer dump:

c.c:12: note: not vectorized: relevant stmt not supported: D.1652_13 = j_29 <<
3
c.c:12: note: bad operation or unsupported loop bound.

[Adding a complete unrolling + ccp passes before the vectorizer can help to
vectorize the outer loop]


-- 
   Summary: missed optimization - complete unrolling pass before the
vectorizer
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com


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

[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2007-11-25 10:40 ---
(In reply to comment #11)
> I think the failures in test3 are ok. Example program:

Yes, you are right.  You and Dominique are correct about test2.  The odd thing
is that there is a test for this in the testsuite already.  I'll fix it
tonight.

Many thanks to both of you.

Paul


-- 


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

[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)

[eres at il dot ibm dot com]

--- Comment #2 from eres at il dot ibm dot com  2007-11-25 11:21 ---
I have been testing Zdenek's initial lim patch on SPEC2006 and tramp3d but saw
no effect on the preformance.  We had an example which is similar to the
testcase shown in (http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00067.txt)
which boosted the performance x1.5 due to the store motion (it also opened
opportunity for the vectorizer).  On the other hand; this patch may increased
register pressure.


-- 


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

[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2007-11-25 11:54 ---
Subject: Re:  [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution
test

On 25 Nov 2007 08:51:45 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> I guess you need to ask Daniel what's going on exactly here.

Have you tried your @gcc.gnu.org account?

Thanks,
Andrew Pinski


-- 


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

[Bug c++/34220] Internal compiler error

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-25 12:43 ---
Works for me with r130405.
(Please try to reduce the number of optimization options yourself
if you can reproduce the bug -- a lot of them are completely redundant and
already enabled by -O3)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-25 12:50 ---
Related to PR18754 - but vectorizer folks say early complete unrolling defeats
the vectorizer.  So possibly a compromise is to do early complete unrolling
only
for nested loops.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
  BugsThisDependsOn||18754
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 12:50:00
   date||
Summary|missed optimization -   |missed optimization -
   |complete unrolling pass |complete unrolling pass
   |before the vectorizer   |before the vectorizer


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

[Bug c++/34222] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-25 13:00 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/34222] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-11-25 13:19 ---
Created an attachment (id=14634)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14634&action=view)
reduced testcase


-- 


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

[Bug c++/34222] [4.3 Regression] verify_ssa failed, missing definition

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-25 13:20 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 13:20:57
   date||
Summary|ice for legal code with -O3 |[4.3 Regression] verify_ssa
   ||failed, missing definition
   Target Milestone|--- |4.3.0


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

[Bug other/34224] New: Problem compiling gcc 4.2.2

[pierre42d at 9online dot fr]

[...]
make[2]: Entering directory `/tmp/gcc-4.2.2'
make[3]: Entering directory `/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/libiberty'
if [ x"" != x ]; then \
  /tmp/gcc-4.2.2/host-i686-pc-linux-gnu/prev-gcc/xgcc
-B/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -c -DHAVE_CONFIG_H -O2 -g
-fomit-frame-pointer -I. -I../.././libiberty/../include  -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -Wc++-compat  ../.././libiberty/pex-unix.c
-o pic/pex-unix.o; \
else true; fi
/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/prev-gcc/xgcc
-B/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -c -DHAVE_CONFIG_H -O2 -g
-fomit-frame-pointer -I. -I../.././libiberty/../include  -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -Wc++-compat ../.././libiberty/pex-unix.c
-o pex-unix.o
In file included from /usr/include/signal.h:358,
 from ../.././libiberty/pex-unix.c:28:
/usr/include/bits/sigthread.h:36: error: storage class specified for parameter
'type name'
../.././libiberty/pex-unix.c: In function 'pex_wait':
../.././libiberty/pex-unix.c:100: warning: implicit declaration of function
'waitpid'
../.././libiberty/pex-unix.c:103: warning: implicit declaration of function
'wait4'
make[3]: *** [pex-unix.o] Error 1
make[3]: Leaving directory `/tmp/gcc-4.2.2/host-i686-pc-linux-gnu/libiberty'
make[2]: *** [all-stage2-libiberty] Error 2
make[2]: Leaving directory `/tmp/gcc-4.2.2'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/gcc-4.2.2'
make: *** [all] Error 2


-- 
   Summary: Problem compiling gcc 4.2.2
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pierre42d at 9online dot fr


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

[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2007-11-25 13:36 ---
Why is this a shift not supported:
not vectorized: relevant stmt not supported: D.1652_13 = j_29 << 3

Is j_29*8 supported (i.e. if you hack this expression to turn it into a
MULT_EXPR), does the vectorizer work then??


-- 


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

[Bug target/34225] New: [4.3 Regression] ICE (segfault)

[rguenth at gcc dot gnu dot org]

./cc1 -fpreprocessed main.7.min.i -quiet -O2 -fstack-protector
-fno-strict-aliasing
main.7.min.i: In function 'main':
main.7.min.i:42: warning: incompatible implicit declaration of built-in
function 'strlen'
main.7.min.i:58: warning: incompatible implicit declaration of built-in
function 'sscanf'
main.7.min.i:74: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3 Regression] ICE (segfault)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug target/34225] [4.3 Regression] ICE (segfault)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-25 13:41 ---
Created an attachment (id=14635)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14635&action=view)
reduced testcase


-- 


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

[Bug target/34225] [4.3 Regression] ICE (segfault)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-25 13:57 ---
A cross to ppc64 shows

Program received signal SIGSEGV, Segmentation fault.
0x00b7ff6a in adjacent_mem_locations (insn1=0x2b2889d519b0, 
insn2=0x2b2889ce50f0)
at /space/rguenther/src/svn/trunk/gcc/config/rs6000/rs6000.c:18191
18191 return ((REGNO (reg0) == REGNO (reg1))
(gdb) print reg0
$1 = (rtx) 0x2b28893626e0
(gdb) print reg1
$2 = (rtx) 0x2b28893626e0
(gdb) call debug_rtx (reg0)
(reg/f:DI 1 1)

huh?

(gdb) bt
#0  0x00b7ff6a in adjacent_mem_locations (insn1=0x2b2889d519b0, 
insn2=0x2b2889ce50f0)
at /space/rguenther/src/svn/trunk/gcc/config/rs6000/rs6000.c:18191
#1  0x00b80d2a in rs6000_sched_reorder2 (dump=0x2b2889cd6840, 
sched_verbose=0, ready=0x137e998, pn_ready=0x7fff217a7000, clock_var=26)
at /space/rguenther/src/svn/trunk/gcc/config/rs6000/rs6000.c:18735
#2  0x00d2e240 in schedule_block (target_bb=0x7fff217a7190, 
rgn_n_insns1=62) at /space/rguenther/src/svn/trunk/gcc/haifa-sched.c:2487
#3  0x008461f6 in schedule_region (rgn=0)
at /space/rguenther/src/svn/trunk/gcc/sched-rgn.c:2815
#4  0x00846598 in schedule_insns ()
at /space/rguenther/src/svn/trunk/gcc/sched-rgn.c:2935
#5  0x00846fab in rest_of_handle_sched2 ()


-- 


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

[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer

[eres at il dot ibm dot com]

--- Comment #3 from eres at il dot ibm dot com  2007-11-25 14:13 ---
(In reply to comment #2)
> Why is this a shift not supported:
> not vectorized: relevant stmt not supported: D.1652_13 = j_29 << 3
> Is j_29*8 supported (i.e. if you hack this expression to turn it into a
> MULT_EXPR), does the vectorizer work then??

Still the division is not supported... (on altivec).  the thing is that
complete unrolling and ccp can help in such cases.

c.c:12: note: not vectorized: relevant stmt not supported: D.1653_14 =
D.1652_13 / 10


-- 


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

[Bug ada/28305] GNAT bug when inlining instance of a generic subprogram

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-07-11 11:03:48 |2007-11-25 14:19:24
   date||


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

[Bug ada/28733] GNAT crash while compiling Ada-2005 code

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-05-02 14:54:13 |2007-11-25 14:20:43
   date||


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

[Bug target/34226] New: [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[rask at gcc dot gnu dot org]

$ echo 'int main (int argc, char *argv[]) { return 0; }' >/tmp/test.c
$ ./xgcc -B./ /tmp/test.c -S -o /dev/null
/tmp/test.c:1: internal compiler error: in default_secondary_reload, at
targhooks.c:612
Please submit a full bug report,
...
This happens with revision 130402. Revision 129967 worked. Configure flags:
--target frv-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim
--disable-gdb --disable-nls


-- 
   Summary: [4.3 Regression][frv] ICE in default_secondary_reload,
at targhooks.c:612
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: frv-unknown-elf


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

[Bug ada/30740] Improper semantics in gnat's compilation of certain expressions involving modular arithmetic

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 14:26:23
   date||


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

[Bug ada/34149] GNAT crash - deeply inrerited function

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|sam at rfc1149 dot net  |
 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 14:31:44
   date||


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

[Bug ada/20615] IP address 255.255.255.255 cannot be set with GNAT.Sockets

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2007-11-25 14:15 ---
Bug is fixed in current sources


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/33152] Initialization/declaration problems in block data

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2007-11-25 15:58 
---
Subject: Bug 33152

Author: jvdelisle
Date: Sun Nov 25 15:57:55 2007
New Revision: 130409

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130409
Log:
2007-11-25  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33152
* gfortran.texi: Document default forms assumed for various file
extensions.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi


-- 


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

[Bug fortran/33152] Initialization/declaration problems in block data

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-11-25 17:22 
---
oops, I had the wrong PR number in the ChangeLog. Should have been for PR34175.


-- 


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

[Bug fortran/34175] Document when fixed form and when free form source code is assumed

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-11-25 17:25 
---
Subject: Bug 34175

Author: jvdelisle
Date: Sun Nov 25 17:25:22 2007
New Revision: 130411

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130411
Log:
2007-11-25  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/34175
* gfortran.texi: Document default forms assumed for various file
extensions.

Modified:
trunk/gcc/fortran/ChangeLog


-- 


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

[Bug target/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-25 17:27 ---
Looks like a possible bug in the .md:

  gcc_assert (insn_data[(int) icode].n_operands == 3);

but more information would be appreciated here.


-- 


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

[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.0


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

[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-11-25 18:50 ---
18191 return ((REGNO (reg0) == REGNO (reg1))
18192 && (val_diff == INTVAL (MEM_SIZE (a))
18193 || val_diff == -INTVAL (MEM_SIZE (b;
18194   }
18195
(gdb) p a
$1 = (rtx) 0x426fca60
(gdb) p b
$2 = (rtx) 0x426fb370
(gdb) p debug_rtx(a)
(mem/c:BLK (reg/f:DI 1 1) [0 A8])
$3 = void
(gdb) p debug_rtx(b)
(mem/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 120 [0x78])) [0 argv+0 S8 A8])


Confirmed.  a does not have a mem attributes.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 18:50:20
   date||


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

[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-11-25 18:51 ---
(insn:TI 448 79 76 2 t.c:18 (set (mem/c:BLK (reg/f:DI 1 1) [0 A8])
(unspec:BLK [
(mem/c:BLK (reg/f:DI 1 1) [0 A8])
] 5)) 542 {stack_tie} (nil))


-- 


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

[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-11-25 18:52 ---
#1  0x00828329 in rs6000_emit_stack_tie () at
../../gcc/config/rs6000/rs6000.c:14974
14974 emit_insn (gen_stack_tie (mem));
(gdb) l
14969   rs6000_emit_stack_tie (void)
14970   {
14971 rtx mem = gen_frame_mem (BLKmode,
14972  gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
14973
14974 emit_insn (gen_stack_tie (mem));


that is where the stack_tie is generated.


-- 


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

[Bug middle-end/34222] [4.3 Regression] verify_ssa failed, missing definition

[tbm at cyrius dot com]

--- Comment #5 from tbm at cyrius dot com  2007-11-25 19:01 ---
I wonder if this is related to PR33869 (which now works).


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


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

[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2007-11-25 19:05 ---
Fixed on trunk

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

[Bug target/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug fortran/34227] New: initialized symbol in common: Better error message

[burnus at gcc dot gnu dot org]

character(len=3) :: emname(nmin)=(/'bar','baz'/)
 common/nmstr/emname
end

currently gfortran prints:

   Error: Previously initialized symbol 'emname' in COMMON block 'nmstr' at (1)

If find the error message of NAG f95 better, which mentions that BLOCK DATA can
be used:

   Error: EMNAME has been initialised - can only be COMMON in BLOCK DATA


-- 
   Summary: initialized symbol in common: Better error message
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/34228] New: -std=f* should diagnose used but later typed variables

[burnus at gcc dot gnu dot org]

The following is frequently used and accepted by many compilers; thus it should
continue to work in -std=gnu, but - if feasible - one should reject it with
-std=f95/f2003.

  subroutine y
  data emname/'bar'/
  character(len=3) :: emname
  end subroutine y

Accepted by most compilers including the picky NAG f95. Rejected by g95:
  Symbol 'emname' at (1) being given type CHARACTER(1) already has implicit
type REAL(4)

"5.2.5 DATA statement
[...] A variable that appears in a DATA statement and has not been typed
previously may appear in a subsequent type declaration only if that declaration
confirms the implicit typing. An array name, array section, or array element
that appears in a DATA statement shall have had its array properties
established by a previous specification statement."

The part about DIMENSION is taken into account.

 * * *

  subroutine y(A,n)
implicit none
real :: A(n)
integer :: n
  end subroutine y

This is invalid as "n" is first used and then typed. NAG f95 rejects it with:
  Error: Implicit type for N
  Error: Symbol N has already been implicitly typed
as other compilers accept this, it frequently occurs and should be allowed for
-std=gnu.

See:
F2003, 7.1.6 (Specification expression), pg 126
F95, 7.1.6.2 (Specification expression), pg 96

"A variable in a specification expression shall have its type and type
parameters, if any, specified by a previous declaration in the scoping
unit, by the implicit typing rules in effect for the scoping unit, or by
host association. If a variable in a specification expression is typed
by the implicit typing rules, its appearance in any subsequent type
declaration statement shall confirm the implicit type and type
parameters".


-- 
   Summary: -std=f* should diagnose used but later typed variables
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191

[dje at gcc dot gnu dot org]

--- Comment #6 from dje at gcc dot gnu dot org  2007-11-25 20:26 ---
It is not clear that the scheduling code should be considering stack_tie for
this particular conflict.  But the stack_tie MEM probably should have some
basic attributes using set_mem_attrs_from_reg.


-- 


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

[Bug c++/34229] New: error on correct code

[rwgk at yahoo dot com]

Platform:
  Fedora release 7 (Moonshine)
  Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64
x86_64 x86_64 GNU/Linux

% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure
--prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130411_x86_64_fc7
--enable-languages=c,c++,fortran --with-mpfr=/usr
Thread model: posix
gcc version 4.3.0 20071125 (experimental) (GCC)

I'll attach a small reproducer.

% g++ -c -fpermissive -I/usr/include/python2.5 used_but_not_defined.cpp
/usr/include/boost/type_traits/detail/cv_traits_impl.hpp:37: error: static data
member
'boost::detail::cv_traits_imp::bind_return>*>::is_const'
used, but not defined

Some data points:

svn revision 130341 didn't have this problem.
svn revision 130396 is broken already.
svn revision 130411 is still broken.

Ralf


-- 
   Summary: error on correct code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/34229] error on correct code

[rwgk at yahoo dot com]

--- Comment #1 from rwgk at yahoo dot com  2007-11-25 20:30 ---
Created an attachment (id=14636)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14636&action=view)
reproducer


-- 


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

[Bug c++/34094] [4.2 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-11-25 20:46 ---
Here is a testcase which shows this is not a complete fix, it does not fix the
case where the static const was initialized inside the class.

namespace {
 struct c
{
  static const bool t = 0;
};
}

const bool &f()
{
  return c::t;
}

int main(void)
{
  return 0;
}


-- 


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

[Bug c++/34229] error on correct code

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-11-25 20:46 ---
I don't think this is valid code.  There is no definition for the is_const part
for the template where bind_return is in the anonymous namespace.  The code was
diagnose before that date but it was not rejected because GCC did not diagnose
the issue before.  We are diagnosing the invalid code now (which does not have
to be diagnose according to the C++ standard).

Please read PR 34094 also.

Basically it comes down to (which is not rejected but should be but that is a
different bug):
template   struct c
{
  static const bool t = 1;
};

namespace {
  struct b{};
}

int main(void)
{
  return c::t;
}


-- 


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

[Bug c++/34229] error on correct code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-11-25 20:47 ---
Also please attach the preprocessed source.


-- 


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

[Bug preprocessor/33907] Empty macro definitions not considered equal

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2007-11-25 21:11 ---
Given that this is a constraint, my first inclination is to close the bug
report.

Richard, what motivated this PR?


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2007-11-25 21:18 ---
Confirming; still happens with svn trunk.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 21:18:23
   date||


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

[Bug fortran/34227] initialized symbol in COMMON: Missing checks

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-25 21:20 ---
That error message disappears with the patch to PR 33152.

>From "5.5.2.4 Differences between named common and blank common":

"A data object in a named common block may be initially defined by means of a
DATA statement or type declaration statement in a block data program unit
(11.3), but objects in blank common shall not be initially defined."

The initialization of common blocks outside block-data program units is
supported by several compilers and thus one can consider allowing it for
-std=gnu.

program main
 implicit none
 integer, parameter:: nmin = 2
 character(len=3) :: emname(nmin)=(/'bar','baz'/)
 common/nmstr/emname
end program main

As NAG f95 kindly writes:
  EMNAME has been initialised - can only be COMMON in BLOCK DATA

ifort -stand f95 diagnoses:
  In Fortran 95, this DATA statement object cannot appear in either a blank
COMMON block or a named COMMON block.
but I like the mentioning of DATA BLOCK more.

Same, but with DATA:

program main
 implicit none
 integer, parameter:: nmin = 2
 character(len=3) :: emname(nmin)
 data emname/ 'bar','baz' /
 common/nmstr/emname
end program main


And for blank commons:

program main
 implicit none
 integer, parameter:: nmin = 2
 character(len=3) :: emname(nmin) = [ 'Aaa','aaa']
 common//emname
end program main

gfortran (w/o patch):
  Previously initialized symbol 'emname' in blank COMMON block at (1)

Similarly to above, gfortran misses the initialization with DATA. (With the
patch, neither diagnosed):
program main
 implicit none
 integer, parameter:: nmin = 2
 character(len=3) :: emname(nmin)
 data emname/ 'bar','baz' /
 common//emname
end program main

Note: For blank commons, one should not point to BLOCK DATA as they are not
allowed there. gfortran (patched and unpatched) correctly diagnoses (default
options):

  Warning: BLOCK DATA unit cannot contain blank COMMON


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
   Keywords||accepts-invalid
Summary|initialized symbol in   |initialized symbol in
   |common: Better error message|COMMON: Missing checks


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

[Bug other/34211] Wrong preprocessor called in build-i686-cygwin/libiberty/configure

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2007-11-25 21:20 ---
Not a preprocessor bug; refiling to 'other'.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|preprocessor|other


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

[Bug preprocessor/33907] Empty macro definitions not considered equal

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2007-11-25 21:34 ---
Subject: Re:  Empty macro definitions not considered
 equal

On Sun, 25 Nov 2007, tromey at gcc dot gnu dot org wrote:

> --- Comment #5 from tromey at gcc dot gnu dot org  2007-11-25 21:11 
> ---
> Given that this is a constraint, my first inclination is to close the bug
> report.
> 
> Richard, what motivated this PR?

Complaints that we now diagnose those as error for C++ (where
-pedantic-errors is default and that now infects the preprocessor
behavior, which is what changed compared to 4.2).

But yes, there's probably nothing else than to close this bug.

Richard.


-- 


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

[Bug c++/17519] [4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct

[mdorey at bluearc dot com]

--- Comment #19 from mdorey at bluearc dot com  2007-11-25 21:41 ---
(We finally got round to throwing the switch on our next release from gcc-3.3
to gcc-4.2.  It works great - the compiled code gets us significantly higher
benchmark numbers and we're appreciating improved error reporting from the
compiler.  This PR had been the killer obstacle, so many, if belated, thanks to
Jason for sorting this out.)


-- 

mdorey at bluearc dot com changed:

   What|Removed |Added

 CC||mdorey at bluearc dot com


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

[Bug fortran/34230] New: Expressions of parameters evaluated with too high precision

[burnus at gcc dot gnu dot org]

Found by FX. See
http://gcc.gnu.org/ml/fortran/2007-11/msg00208.html

 $ cat a.f90
   real, parameter :: y = exp(log(huge(y))+20)
   real, parameter :: x = log(y)
   print *, x, y
   end
 $ gfortran a.f90 -fno-range-check && ./a.out
108.72284   +Infinity

The problem is the following: gfortran does not do:
  y = INF
  x = log(y) = log(INF) = INF
but it does:
  y = exp(log(huge())+20) = INF
  x = log(exp(log(huge())+20)) = log(huge())+20 = 108.7

Calculating with higher precision to obtain "y" is ok (though one gets
different results compared with the run-time evaluation, but I expect that the
differences are only minor. Having the correct precision from the beginning
would be also ok.)

However, I regard it as bug if for expressions using y not y but a variant with
higher precision.


-- 
   Summary: Expressions of parameters evaluated with too high
precision
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/34079] Bind(C): Character argument/return value problems

[burnus at gcc dot gnu dot org]

--- Comment #12 from burnus at gcc dot gnu dot org  2007-11-25 22:03 ---
Subject: Bug 34079

Author: burnus
Date: Sun Nov 25 22:02:53 2007
New Revision: 130414

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130414
Log:
2007-11-25  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34079
* trans-types.c (gfc_return_by_reference,
gfc_get_function_type): Do not return result of
character-returning bind(C) functions as argument.
* trans-expr.c (gfc_conv_function_call): Ditto.

2007-11-25  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34079
* gfortran.dg/bind_c_usage_10_c.c: Fix comment.
* gfortran.dg/bind_c_usage_16.f03: New.
* gfortran.dg/bind_c_usage_16_c.c: New.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_16.f03
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_10_c.c


-- 


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

[Bug fortran/33152] Initialization/declaration problems in block data

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-11-25 22:12 
---
Subject: Bug 33152

Author: jvdelisle
Date: Sun Nov 25 22:12:19 2007
New Revision: 130415

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130415
Log:
2007-11-25  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33152
* decl.c (add_init_expr_to_sym): Remove error message.
* resolve.c (check_data_variable): Add new check for a data variable
that has an array spec, but no ref and issue an error.
* match.c (gfc_match_common): Remove error message.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c


-- 


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

[Bug fortran/33152] Initialization/declaration problems in block data

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2007-11-25 22:15 
---
Subject: Bug 33152

Author: jvdelisle
Date: Sun Nov 25 22:14:57 2007
New Revision: 130416

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130416
Log:
2007-11-25  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33152
*gfortran.dg\blockdata_4.f90: New test.

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


-- 


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

[Bug fortran/34079] Bind(C): Character argument/return value problems

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2007-11-25 22:15 ---
Subject: Bug 34079

Author: burnus
Date: Sun Nov 25 22:15:47 2007
New Revision: 130417

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130417
Log:
Forgot trans-expr.c in previous commit:

2007-11-25  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34079
* trans-types.c (gfc_return_by_reference,
gfc_get_function_type): Do not return result of
character-returning bind(C) functions as argument.
* trans-expr.c (gfc_conv_function_call): Ditto.

Modified:
trunk/gcc/fortran/trans-expr.c


-- 


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

[Bug fortran/34079] Bind(C): Character argument/return value problems

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2007-11-25 22:18 ---
FIXED on the trunk (4.3.0) [there is no bind(C) support in 4.2.x].


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug preprocessor/33907] Empty macro definitions not considered equal

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2007-11-25 22:23 ---
(In reply to comment #6)
> 
> But yes, there's probably nothing else than to close this bug.
> 

Well you could make the error depend on the pedantic flag. This is a recurrent
confusion: C++ does not enable pedantic-errors by default. It makes pedwarns as
errors. -pedantic-errors is pedantic flag + pedwarns as errors. 

If you can provide me with a better text for the comment (something about the
part of the standard that requires us to give a diagnostic), I can update the
patch, bootstrap it and regression test it.

Index: libcpp/macro.c
===
--- libcpp/macro.c  (revision 130380)
+++ libcpp/macro.c  (working copy)
@@ -1284,6 +1284,12 @@
   || macro1->variadic != macro2->variadic)
 return true;

+
+  /* If the macro expansion has no tokens there is no need to compare
+ parameters spellings unless -pedantic was given.  */
+  if (!CPP_PEDANTIC (pfile) && macro1->count == 0 && macro2->count == 0)
+  return false;
+
   /* Check parameter spellings.  */
   for (i = 0; i < macro1->paramc; i++)
 if (macro1->params[i] != macro2->params[i])
Index: gcc/testsuite/g++.dg/cpp/redefine-empty-macro-pedantic.C
===
--- gcc/testsuite/g++.dg/cpp/redefine-empty-macro-pedantic.C(revision 0)
+++ gcc/testsuite/g++.dg/cpp/redefine-empty-macro-pedantic.C(revision 0)
@@ -0,0 +1,4 @@
+// { dg-do preprocess }
+// { dg-options "-pedantic" }
+#define A(a) // { dg-error "this is the location of the previous definition" }
+#define A(b) // { dg-error ".A. redefined" }
Index: gcc/testsuite/g++.dg/cpp/redefine-empty-macro.C
===
--- gcc/testsuite/g++.dg/cpp/redefine-empty-macro.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp/redefine-empty-macro.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do preprocess }
+// { dg-options "" }
+#define A(a)
+#define A(b)


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-25 22:23:50
   date||


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

[Bug preprocessor/33907] Empty macro definitions not considered equal

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2007-11-25 22:29 ---
Subject: Re:  Empty macro definitions not considered
 equal

On Sun, 25 Nov 2007, manu at gcc dot gnu dot org wrote:

> --- Comment #7 from manu at gcc dot gnu dot org  2007-11-25 22:23 ---
> (In reply to comment #6)
> > 
> > But yes, there's probably nothing else than to close this bug.
> > 
> 
> Well you could make the error depend on the pedantic flag. This is a recurrent
> confusion: C++ does not enable pedantic-errors by default. It makes pedwarns 
> as
> errors. -pedantic-errors is pedantic flag + pedwarns as errors. 

But C++ has -pedantic as default as well ;)

> If you can provide me with a better text for the comment (something about the
> part of the standard that requires us to give a diagnostic), I can update the
> patch, bootstrap it and regression test it.

Tom can probably do this.  But I belive the patch will not work,
as CPP_PEDANTIC is set to true by the C++ frontend now.

Richard.


-- 


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

[Bug fortran/34231] New: wrong selection of a routine belonging to an interface

[francois dot jacq at irsn dot fr]

The following test program calls the wrong routine :

[EMAIL PROTECTED] test]$ gfortran test3.f90
[EMAIL PROTECTED] test]$ a.out
 odfamilycnames

With ifort (or g95, lf95, SUN f90) the result is :

[EMAIL PROTECTED] test]$ ifort test3.f90
[EMAIL PROTECTED] test]$ a.out
 odfamilycname

File test3.f90 :

MODULE test

   TYPE odbase ; INTEGER :: value ; END TYPE

   INTERFACE odfname
  MODULE PROCEDURE odfamilycname,odfamilycnames
   END INTERFACE

   CONTAINS

   SUBROUTINE odfamilycnames(base,nfam,cnames)
  TYPE(odbase),INTENT(in)  :: base
  INTEGER ,INTENT(out) :: nfam
  CHARACTER(*),INTENT(out) :: cnames(*)
  nfam=0
  cnames(1:nfam)=' '
  write(*,*) 'odfamilycnames'
   END SUBROUTINE

   SUBROUTINE odfamilycname(base,pos,cname)
  TYPE(odbase),INTENT(in)  :: base
  INTEGER ,INTENT(in)  :: pos
  CHARACTER(*),INTENT(out) :: cname
  cname=' '
  write(*,*) 'odfamilycname'
   END SUBROUTINE

END MODULE

PROGRAM main
  USE test
  TYPE(odbase) :: base
  INTEGER :: i=1
  CHARACTER(8) :: cname
  CALL odfname(base,i,cname)
END PROGRAM


-- 
   Summary: wrong selection of a routine belonging to an interface
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: francois dot jacq at irsn dot fr
 GCC build triplet: [trunk revision 130366]
  GCC host triplet: GNU Fortran (GCC) 4.3.0
GCC target triplet: 20071123 (experimental)


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

[Bug preprocessor/33907] Empty macro definitions not considered equal

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2007-11-25 22:56 ---
(In reply to comment #8)
> 
> But C++ has -pedantic as default as well ;)
> 

How you reached to that conclusion?

> 
> Tom can probably do this.  But I belive the patch will not work,
> as CPP_PEDANTIC is set to true by the C++ frontend now.
> 

Again, how you reached to that conclusion and what you mean by now?


-- 


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

[Bug preprocessor/33907] Empty macro definitions not considered equal

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2007-11-25 22:59 ---
(In reply to comment #8)
> 
> Tom can probably do this.  But I belive the patch will not work,
> as CPP_PEDANTIC is set to true by the C++ frontend now.

BTW, the patch works for the revision I diffed against. The testcases included
in the patch pass.


-- 


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

[Bug boehm-gc/34232] New: bootstrap fails when libgcj enabled due to undefined reference in libgcjgc (boehm-gc)

[silver-dad at comcast dot net]

libgcj build in bootstrap fails on i686-pc-cygwin due to undefined reference
error in boehm-gc library.

libtool: link: /home/LarryR/Build/gcc-4.3.0/gcc/gcj
-B/home/LarryR/Build/gcc-4.3.0/i686-pc-cygwin/libjava/
-B/home/LarryR/Build/gcc-4.3.0/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-march=prescott -pipe -o .libs/jv-convert.exe --main=gnu.gcj.convert.Convert
-shared-libgcc  -L/home/LarryR/Build/gcc-4.3.0/i686-pc-cygwin/libjava/.libs
-L/home/LarryR/Build/gcc-4.3.0/i686-pc-cygwin/libjava ./.libs/libgcj.a -ldl -lz
-L/gcc-4.3.0/lib/gcc/i686-pc-cygwin/4.3.0
./.libs/libgcj.a(lt105-misc.o):misc.c:(.text+0xc10): undefined reference to
`_GC_get_thread_stack_base'
collect2: ld returned 1 exit status

This is caused by the following in "boehm-gc":

in "pthread-support.c" line 60 ...

# if defined(GC_PTHREADS) && !defined(GC_SOLARIS_THREADS) \
 && !defined(GC_WIN32_THREADS)

the functions in "pthread-support.c" are not compiled if GC_WIN32_THREADS is
defined, in particular "GC_get_thread_stack_base()" is not compiled.

in "misc.c" line 677 ...

# if defined(GC_PTHREADS) && ! defined(GC_SOLARIS_THREADS)
/* Use thread_stack_base if available, as GC could be initialized from
   a thread that is not the "main" thread.  */
GC_stackbottom = GC_get_thread_stack_base();
# endif

thus a call to GC_get_thread_stack_base() is generated even though
GC_WIN32_THREADS is defined so that GC_get_thread_stack_base() does not exist,
which breaks the build.

The following patch fixes the problem

--- boehm-gc/misc.c (revision 130402)
+++ boehm-gc/misc.c (working copy)
@@ -674,7 +674,7 @@
 #   if !defined(THREADS) || defined(GC_PTHREADS) || defined(GC_WIN32_THREADS)
\
|| defined(GC_SOLARIS_THREADS)
   if (GC_stackbottom == 0) {
-# if defined(GC_PTHREADS) && ! defined(GC_SOLARIS_THREADS)
+# if defined(GC_PTHREADS) && ! defined(GC_SOLARIS_THREADS) && !
defined(GC_WIN32_THREADS)
/* Use thread_stack_base if available, as GC could be initialized from
   a thread that is not the "main" thread.  */
GC_stackbottom = GC_get_thread_stack_base();


-- 
   Summary: bootstrap fails when libgcj enabled due to undefined
reference in libgcjgc (boehm-gc)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: silver-dad at comcast dot net
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug regression/34221] -save-temps is broken on mainline

[ismail at pardus dot org dot tr]

--- Comment #1 from ismail at pardus dot org dot tr  2007-11-25 23:21 
---
Looks like a ccache bug instead.


-- 

ismail at pardus dot org dot tr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/33152] Initialization/declaration problems in block data

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2007-11-25 23:51 
---
Fixed on trunk.  


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2007-11-26 00:12 ---
There is no bug here.  You have explicitly disabled
range checking.  This means that you no longer have
a limitation on range in constant folding.  It may
be help to look at -fdump-parse-tree.  YOu don't
have an Inf until you actually do the transfer.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

--- Comment #25 from rakdver at gcc dot gnu dot org  2007-11-26 00:48 
---
Created an attachment (id=14637)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view)
Patch to make ivopts take autoincrement addressing modes into account

Ivopts take autoincrement addressing modes into account with this patch (in a
fairly simplistic form, sufficient to improve the code for the testcases in
this PR).  However, I do not have access to any architecture where I could test
it (I somewhat suspect it might cause performance regressions -- using
autoincrement addressing modes is not necessarily always profitable).


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[mmitchel at gcc dot gnu dot org]

--- Comment #26 from mmitchel at gcc dot gnu dot org  2007-11-26 00:53 
---
Zdenek, do you have the ability to get code-size measurements on ARM?  (You
don't need to actually run the code to find out if this improves code density.)
 If you don't, I'll ask someone at CodeSourcery to measure that.

Thanks,

-- Mark


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #27 from rakdver at kam dot mff dot cuni dot cz  2007-11-26 
01:12 ---
Subject: Re:  [4.3 Regression] Code size regression caused by fix to PR 31360

> Zdenek, do you have the ability to get code-size measurements on ARM?  (You
> don't need to actually run the code to find out if this improves code 
> density.)
>  If you don't, I'll ask someone at CodeSourcery to measure that.

I can check the code size; however, I am somewhat concerned about
possible performance regressions on other architectures,
in particular, ia64, where the dependences created by introducing
autoincrements might conflict with scheduling.  I would appreciate
if someone could run some benchmark on ia64 with the patch.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[pinskia at gcc dot gnu dot org]

--- Comment #28 from pinskia at gcc dot gnu dot org  2007-11-26 01:24 
---
A couple of comments about the patch.
+ #define CP_AUTOINC_OFFSET(CP) ((int) (size_t) (CP)->value)

I don't like this idea at all.

The patch should support pre increment also (this shows up on PPC) and pre/post
decrement.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #29 from rakdver at kam dot mff dot cuni dot cz  2007-11-26 
01:42 ---
Subject: Re:  [4.3 Regression] Code size regression caused by fix to PR 31360

> --- Comment #28 from pinskia at gcc dot gnu dot org  2007-11-26 01:24 
> ---
> A couple of comments about the patch.
> + #define CP_AUTOINC_OFFSET(CP) ((int) (size_t) (CP)->value)
> 
> I don't like this idea at all.

I may change cost_pair to union, if this bothers you too much.

> The patch should support pre increment also (this shows up on PPC) and 
> pre/post
> decrement.

post-decrement is already supported.  Pre-(inc/dec)rements are more
complicated, as supporting them would require us to create induction
variables incremented at the start of the loop body (instead of at the
end, as we do now).


-- 


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

[Bug c++/34229] error on correct code

[rwgk at yahoo dot com]

--- Comment #4 from rwgk at yahoo dot com  2007-11-26 01:52 ---
Created an attachment (id=14638)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14638&action=view)
reproducer preprocessed gzip'ed


-- 


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

[Bug c++/34229] error on correct code

[rwgk at yahoo dot com]

--- Comment #5 from rwgk at yahoo dot com  2007-11-26 02:11 ---
cc'ing David Abrahams since the original code is his.


-- 

rwgk at yahoo dot com changed:

   What|Removed |Added

 CC||dave at boost-consulting dot
   ||com


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

[Bug c++/34229] error on correct code

[rwgk at yahoo dot com]

--- Comment #6 from rwgk at yahoo dot com  2007-11-26 02:17 ---
The patch below makes the Boost.Python compilation work again with
gcc svn trunk revision 130411. This solves my problem. :-)

The g++ change could be tough for people who have to keep using older
boost versions for one reason or another. I think it would be best
to accept the old code if -fpermissive is given, at least on the
gcc 4.3 line.

Index: function.cpp
===
--- function.cpp(revision 41350)
+++ function.cpp(working copy)
@@ -565,7 +565,11 @@
 }


-namespace
+namespace detail
+/* Cannot be anonymous namespace:
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34229
+ */
 {
   struct bind_return
   {
@@ -610,7 +614,8 @@
 function_call(PyObject *func, PyObject *args, PyObject *kw)
 {
 PyObject* result = 0;
-handle_exception(bind_return(result, static_cast(func),
args, kw));
+handle_exception(
+  detail::bind_return(result, static_cast(func), args,
kw));
 return result;
 }


-- 


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

[Bug c++/34233] New: ICE: get_callee_fndecl, at tree.c:6592

[rwgk at yahoo dot com]

Platform:
  Fedora release 7 (Moonshine)
  Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64
x86_64 x86_64 GNU/Linux

% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure
--prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130411_x86_64_fc7
--enable-languages=c,c++,fortran --with-mpfr=/usr
Thread model: posix
gcc version 4.3.0 20071125 (experimental) (GCC)

% g++ -c -fno-strict-aliasing -Wall -O2 -ffast-math -ftrapping-math
ice_get_callee_fndecl.cpp
ice_get_callee_fndecl.cpp:1: warning: -fassociative-math disabled; other
options take precedence
ice_get_callee_fndecl.cpp: In constructor
'cctbx::maptbx::find_gaussian_parameters::find_gaussian_parameters(const
scitbx::af::const_ref&, const scitbx::af::const_ref&, const
double&, const double&, double)':
ice_get_callee_fndecl.cpp:78: internal compiler error: in get_callee_fndecl, at
tree.c:6592
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I'll attach the reproducer.
There are many ways to make the ICE go away. For example, I couldn't find
an easy way to eliminate the dependence on std::string. Both -ffast-math
and -ftrapping-math are essential.

Ralf


-- 
   Summary: ICE: get_callee_fndecl, at tree.c:6592
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/34233] ICE: get_callee_fndecl, at tree.c:6592

[rwgk at yahoo dot com]

--- Comment #1 from rwgk at yahoo dot com  2007-11-26 03:33 ---
Created an attachment (id=14639)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14639&action=view)
reproducer


-- 


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

[Bug c++/34233] ICE: get_callee_fndecl, at tree.c:6592

[rwgk at yahoo dot com]

--- Comment #2 from rwgk at yahoo dot com  2007-11-26 03:34 ---
Created an attachment (id=14640)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14640&action=view)
reproducer preprocessed gzip'ed


-- 


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-11-26 04:50 
---
I have been studying this more in some debug sessions.  We actually
successfully match the iterator multiple times.  However, by the time we get
through several attempted matchings, I think we get left with the last one
which is NULL.  There is an attempt to match multiple iterators, I presume for
each dimension of the array and these are kept in a linked list.  I suspect the
handling of this list is what is messed up.

I will have to keep digging at this a bit before I can say anything with any
certainty,  :)


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-05 20:01:45 |2007-11-26 04:50:29
   date||


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

--- Comment #30 from rakdver at gcc dot gnu dot org  2007-11-26 05:08 
---
The patch improves size of adler32 (and several other files in zlib) by about
2%.  However, overall on the whole csibe it is neutral (the sum of the sizes of
all the files increases by 0.02%) -- the changes in size of the files range
from 7.5% improvement to 7% regression.  I did not investigate the cause of the
regressions yet.


-- 


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

[Bug c/27898] Compile failure with --combine and anonymous structures

[aoliva at gcc dot gnu dot org]

--- Comment #4 from aoliva at gcc dot gnu dot org  2007-11-26 06:26 ---
Subject: Bug 27898

Author: aoliva
Date: Mon Nov 26 06:26:18 2007
New Revision: 130425

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130425
Log:
PR c/27898
* c-typeck.c (tagged_types_tu_compatible_p): Enable exact
matches between anonymous union fields.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c


-- 


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-11-26 06:28 
---
OK, tracing this farther, the correct iterator makes it to translation at
gfc_conv_array_initializer.  Here we simply have not implemented code to handle
it and we have this:

  if (c->iterator)
{
  /* Problems occur when we get something like
 integer :: a(lots) = (/(i, i=1,lots)/)  */
  /* TODO: Unexpanded array initializers.  */
  internal_error
("Possible frontend bug: array constructor not expanded");
}
So I keep at it.


-- 


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2007-11-26 06:52 
---
Food for thought:

I wonder if this is best solved by creating a general purpose iterator function
that we call at run time whenever needed.  A function for each Basic Type. 
Seems this would be fine for initializing arrays.


-- 


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