[Bug c++/35125] Violating standards

[amitondemand at gmail dot com]

--- Comment #5 from amitondemand at gmail dot com  2008-02-08 07:20 ---
As i know C++ doesn't support VLA. Please update me if i m wrong.

(In reply to comment #2)
> VLA in C++ is an extension, if you use -pedantic, you will get an error.
> Also VLA uses the value at the time at definition and no other value after
> wards.


-- 


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

[Bug c++/35125] Violating standards

[amitondemand at gmail dot com]

--- Comment #4 from amitondemand at gmail dot com  2008-02-08 06:59 ---
i think this should not work. you should get an error that array size must be
constant.

(In reply to comment #1)
> This code doesn't work reliably.  Change it to
> int main()
> {
> int size;
> cout<<"Enter size of array: ";
> cin>>size;
> int arr[size];
> ...


-- 


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

[Bug testsuite/23613] obj-c++.dg/isa-field-1.mm fails with the GNU runtime

[ghazi at gcc dot gnu dot org]

--- Comment #6 from ghazi at gcc dot gnu dot org  2008-02-08 06:08 ---
This error still happens on 4.1/4.2/trunk.  I get it on x86_64 and i686:

x86_64:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html

i686:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00441.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00366.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00365.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
  Known to fail||4.1.3 4.2.4 4.3.0
   Last reconfirmed|2006-01-08 05:22:17 |2008-02-08 06:08:20
   date||


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

[Bug testsuite/23610] obj-c++.dg/bitfield-[14].mm, obj-c++.dg/layout-1.mm fails with the GNU runtime

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2008-02-08 05:59 ---
The ICE mentioned in comment#7 is a dup from PR31032.  I think this PR should
focus on the excess "padding struct" warnings from the three testcases:
bitfield-1.mm, bitfield-4.mm and layout-1.mm.

I see these three failures on mainline gcc-4.3 on x86_64:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html

but not e.g. i686, so it appears to remain lp64-specific.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
  Known to fail||4.3.0
   Last reconfirmed|2006-01-08 05:22:23 |2008-02-08 05:59:26
   date||


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

[Bug objc++/27232] encode-3.mm fails with "deprecated conversion" warning

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2008-02-08 05:34 ---
If I backport this patch to 4.1:

http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01001.html

the testcase compiles with gcc-4.1 and executes on x86_64.


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #22 from jpr at csc dot fi  2008-02-08 05:29 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP



> So if the above is really at fault then the
> leak should not manifest on Cygwin at all.

The logic there is ok i guess, as i already noted later in the thread.
As the handles also leak using posix threads under cygwin,  i guess the 
posix thread implementation does something similiar. The  problem is that 
when the mutex is done with pthread_mutex_destroy() should be called. 
gcc's gthread interface used in libfortran however does not however have 
this functionality as far as i can tell from the sources.

Anyway, Jerry idea of reusing the internal unit structure would 
effectively solve this problem, being also a good thing otherwise IMO.

Juha

> This gthr-win32 stuff should only be run if --enable-threads=win32.
> That is not the case with Cygwin which should be using pthreads
> (--enable-threads=posix).  So if the above is really at fault then the
> leak should not manifest on Cygwin at all.
>
> Brian
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug objc++/31032] [4.3 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225

[ghazi at gcc dot gnu dot org]

--- Comment #6 from ghazi at gcc dot gnu dot org  2008-02-08 05:01 ---
I get the tree checking failure on mainline for i686 and x86_64:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00441.html

bitfield-1.mm:113: internal compiler error: tree check: expected tree that
contains 'decl with RTL' structure, have 'field_decl' in
assemble_external_real, at varasm.c:2220


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
  Known to fail||4.3.0
   Last reconfirmed|2008-01-13 14:48:31 |2008-02-08 05:01:56
   date||


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #21 from jvdelisle at gcc dot gnu dot org  2008-02-08 03:14 
---
The problem manifests with:

$ gfc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc43/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --disable-bootstrap --enable-threads=posix
--enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls
--disable-libmudflap --disable-shared --disable-win32-registry
--with-system-zlib --enable-checking=release --enable-werror
--without-included-gettext --without-x --enable-libgomp
Thread model: posix
gcc version 4.3.0 20080128 (experimental) [trunk revision 131899] (GCC) 

I removed the mutex_lock code from the relevant sections of
libgfortran/io/unit.c for internal units and the handle count growth goes away.
This confirms the problem.  I am still working the solution and have two
approaches.  One is to modify the mutex_unlock to delete the semaphore created
and thus release the handle (Danny Smith idea).  The other is to keep track of
units assigned as internal and not create a new unit structure, but reuse the
old. Stay tuned.


-- 


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

[Bug objc++/34193] [4.3 regression] FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)

[mrs at apple dot com]

--- Comment #2 from mrs at apple dot com  2008-02-08 03:10 ---
It should be const char**argv.


-- 


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

[Bug ada/33420] [Ada] crash passing SomeFunctionReturningPointer.all as function argument

[jdgressett at amli-denton dot com]

--- Comment #6 from jdgressett at amli-denton dot com  2008-02-08 02:16 
---
Subject: Re:  [Ada] crash passing SomeFunctionReturningPointer.all
 as function argument

ludovic at ludovic-brenta dot org wrote:
> --- Comment #5 from ludovic at ludovic-brenta dot org  2008-02-06 13:42 
> ---
> Since the test case uses only Ada 95 features, what does the compiler say with
> -gnat95?
>
>
>   
Same thing.


-- 


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

[Bug objc++/34193] [4.3 regression] FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2008-02-08 02:11 ---
It's not target specific, I get the same error on i686 and x86_64.  Removing
target tags.

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00441.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html

The identical testcase works on 4.1 and 4.2.  So this is a regression in 4.3. 
I don't know objc to know if void** is a valid parameter type to main.  Maybe
4.3 is right to warn about it and previous versions that accepted it were
broken.

If void** is not valid, then the testcase should be fixed.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|hppa64-hp-hpux11.11 |
   GCC host triplet|hppa64-hp-hpux11.11 |
 GCC target triplet|hppa64-hp-hpux11.11 |
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 02:11:53
   date||
Summary|FAIL: obj-c++.dg/gnu-   |[4.3 regression] FAIL: obj-
   |runtime-2.mm (test for  |c++.dg/gnu-runtime-2.mm
   |excess errors)  |(test for excess errors)


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

[Bug objc++/32052] [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin

[ghazi at gcc dot gnu dot org]

--- Comment #5 from ghazi at gcc dot gnu dot org  2008-02-08 02:04 ---
It's not darwin-specific, removing target tag.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|powerpc-darwin  |


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

[Bug objc++/32052] [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2008-02-08 02:01 ---
I also see these regressions on mainline on i686 and x86_64:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00441.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
  Known to fail||4.3.0
   Last reconfirmed|2008-01-13 14:52:00 |2008-02-08 02:01:40
   date||


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

[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2008-02-08 01:52 ---
Bug is not hppa-specific, removing target tags.

I also see the failure on i686 and x86_64 on 4.1, 4.2, and trunk.

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|hppa*-*-*   |
   GCC host triplet|hppa*-*-*   |
 GCC target triplet|hppa*-*-*   |
  Known to fail||4.1.3 4.2.4 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 01:52:15
   date||


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

[Bug objc++/27247] FAIL: obj-c++.dg/cxx-ivars-2.mm execution test

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2008-02-08 01:49 ---
Bug is not hppa-specific, removing target tags.

I also see the failure on i686 and x86_64 on 4.1, 4.2, and trunk.

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|hppa*-*-*   |
   GCC host triplet|hppa*-*-*   |
 GCC target triplet|hppa*-*-*   |
  Known to fail||4.1.3 4.2.4 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 01:49:25
   date||


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

[Bug objc++/27232] encode-3.mm fails with "deprecated conversion" warning

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2008-02-08 01:40 ---
This testcase has execution failure on mainline for i686 and x86_64:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00441.html

On 4.2.x, it passes on both systems:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00366.html

on 4.1.x, it passes on i686 but fails on x86_64:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00365.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html

Between 4.1 and 4.2, there are some changes to the testcase itself that look
like support for lp64 systems.  I believe that explains the failure on 4.1 on
x86_64.  I believe if I backport that testsuite change to 4.1, the testcase
might pass.

However it fails everywhere on mainline, so that is a regression.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-08 01:40:58
   date||


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

[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2008-02-08 01:22 ---
This failure occurs on x86_64-unknown-linux-gnu on 4.1, 4.2 and trunk:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html

The tree checking failure says:

comp-types-10.mm:19: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in setup_one_parameter, at
tree-inline.c:1535


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
  Known to fail||4.1.3 4.2.4 4.3.0
   Last reconfirmed|2006-01-08 05:22:06 |2008-02-08 01:22:15
   date||


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

[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime

[ghazi at gcc dot gnu dot org]

--- Comment #10 from ghazi at gcc dot gnu dot org  2008-02-08 01:12 ---
Problem still occurs on x86_64-unknown-linux-gnu on 4.1, 4.2 and trunk:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
   Last reconfirmed|2007-07-09 07:44:16 |2008-02-08 01:12:20
   date||


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

[Bug objc++/23614] obj-c++.dg/lookup-2.mm fails with the GNU runtime

[ghazi at gcc dot gnu dot org]

--- Comment #6 from ghazi at gcc dot gnu dot org  2008-02-08 01:07 ---
This failure occurs on x86_64-unknown-linux-gnu on 4.1, 4.2 and trunk:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00468.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00466.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, mrs at apple dot com
   Last reconfirmed|2006-01-08 05:22:12 |2008-02-08 01:07:08
   date||


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

[Bug target/35135] unable to find a register to spill in class �GENERAL_REGS� with global registers

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-08 00:32 ---
I don't think we can consider this a regression, the global registers just
makes an already register starved target even more register starved.

We go from having 6 registers down to 3 in this case.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|i686-suse-linux |
 GCC target triplet||i686-suse-linux
Summary|[4.3 regression] unable to  |unable to find a register to
   |find a register to spill in |spill in class
   |class ‘GENERAL_REGS’|‘GENERAL_REGS’ with global
   ||registers


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

[Bug tree-optimization/34363] [4.2 Regression] Aliasing failure during tree fre

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-02-08 00:30 ---
*** Bug 35134 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/35134] Invalid cse on aliased global variable

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-08 00:30 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/35135] New: [4.3 regression] unable to find a register to spill in class �GENERAL_REGS�

[mueller at gcc dot gnu dot org]

gcc -v -O2 -c test.c

=== Cut ===
extension__ typedef unsigned long long int uint64_t;
typedef unsigned target_ulong;
register target_ulong T0 asm ("ebx");
register target_ulong T1 asm ("esi");
register target_ulong T2 asm ("edi");
typedef struct CPUX86State
{
  uint64_t xmm_regs[8];
}
CPUX86State;

save_raw_fp_state (CPUX86State * env)
{
  int i;
  char *addr;
  for (i = 0; i < 8; i++)
env->xmm_regs[i] = *(uint64_t *) (addr);
}
=== Cut ===

GNU C (SUSE Linux) version 4.3.0 20080131 (experimental) [trunk revision
131976] (i586-suse-linux)
compiled by GNU C version 4.3.0 20080131 (experimental) [trunk revision
131976], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 86307befc2a0b2e7a5d9beb62be4b74e
test.c: In function ‘save_raw_fp_state’:
test.c:18: error: unable to find a register to spill in class ‘GENERAL_REGS’
test.c:18: error: this is the insn:
(insn:HI 14 13 15 3 test.c:17 (set (mem/s:DI (plus:SI (mult:SI (reg/v:SI 64 [ i
])
(const_int 8 [0x8]))
(reg/v/f:SI 66 [ env ])) [2 .xmm_regs S8 A8])
(reg:DI 67)) 63 {*movdi_2} (expr_list:REG_DEAD (reg:DI 67)
(nil)))
test.c:18: confused by earlier errors, bailing out


-- 
   Summary: [4.3 regression] unable to find a register to spill in
class ‘GENERAL_REGS’
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
  GCC host triplet: i686-suse-linux


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

[Bug tree-optimization/35134] New: Invalid cse on aliased global variable

[amylaar at gcc dot gnu dot org]

The following testcase fails at -O3.  It succeeds at -O3 -fno-tree-fre
-fno-tree-dominator-opts -fno-tree-pre


extern void abort (void);

int i;

int f (int *) __attribute((noinline));
int
f (int *p)
{
  int a, b;

  a = i;
  *p = 1;
  b = i;
  return a + b;
}

int
main (void)
{
  if (f (&i) != 1)
abort ();
  return 0;
}


-- 
   Summary: Invalid cse on aliased global variable
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: arc-elf32, i686-pc-linux-gnu


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-02-07 22:52 ---
See:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9e38ff2694bfdab1/

If I understand it correctly, the right solution is do the same as NAG f95 does
and print the following:

123456
ASDFef
End of file on unit 20
Program terminated by I/O error on unit 20 (File="foo.txt",Formatted,Stream)

With the file "foo.txt" containing two lines.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-07 22:52:03
   date||


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

[Bug fortran/35130] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-02-07 22:44 ---
*** Bug 35131 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/35131] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-07 22:44 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/35130] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-07 22:44 ---
*** Bug 35133 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/35133] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-07 22:44 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/35133] New: OpenMP: Private variable passed to subroutine

[burnus at gcc dot gnu dot org]

As reported by Ignacio Fernández Galván, the following program prints with
"gfortran -fopenmp" 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.

See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html

I believe the program is valid, compare also
http://www.openmp.org/pipermail/omp/2006/000532.html

PROGRAM Outer
 IMPLICIT NONE
 REAL, DIMENSION(20) :: A
 INTEGER :: k
 A = 0.0
!$OMP PARALLEL DO PRIVATE(k)
 DO k=1,SIZE(A)
   CALL Inner(k)
 END DO
!$OMP END PARALLEL DO
 print *, A
CONTAINS
 SUBROUTINE Inner(i)
   IMPLICIT NONE
   INTEGER :: i
   A(i) = 42
 END SUBROUTINE Inner
END PROGRAM Outer


-- 
   Summary: OpenMP: Private variable passed to subroutine
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, openmp
  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=35133

[Bug libfortran/35132] New: Formatted stream I/O write should truncate

[tkoenig at gcc dot gnu dot org]

>From c.l.f, Richard Maine:

2003 9.2.3.3, "File position after data
transfer", 3rd para

  "For a formatted stream output statement, if no error condition
occurred, the terminall point of the file is set to the highest-numbered
position to which data was transferred by the statement."

Currently, we don't.  The following program shouldn't work:

program main
  implicit none
  character(len=6) :: c
  integer :: i
  open(20,file="foo.txt",form="formatted",access="stream")
  write(20,'(A)') '123456'
  write(20,'(A)') 'abcdef'
  write(20,'(A)') 'qwerty'
  rewind 20
  ! Skip over the first line
  read(20,'(A)') c
  ! Save the position
  inquire(20,pos=i)
  ! Read in the complete line...
  read(20,'(A)') c
  ! Write out the first four characters
  write(20,'(A)',pos=i,advance="no") 'ASDF'
  ! Fill up the rest of the line.  Here, we know the length.  If we
  ! don't, things will be a bit more complicated.
  write(20,'(A)') c(5:6)
  ! Copy the file to standard output
  rewind 20
  do i=1,3
read(20,'(A)') c
print '(A)',c
  end do
  close (20)
end program main

It currently prints

123456
ASDFef
qwerty

which is wrong.


-- 
   Summary: Formatted stream I/O write should truncate
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

--- Comment #13 from dfranke at gcc dot gnu dot org  2008-02-07 22:30 
---
> As valgrind --leak-check=full shows, the generated program still 
> leaks memory

Forgot to check this one :(

Interestingly, the error seems to be with forall only. 
The equivalent DO-loop does not leak:

  type :: a
integer, allocatable :: i(:)
  end type a
  type :: b
type (a), allocatable :: at(:)
  end type b
  type(a) :: x(2)
  type(b) :: y(2)
  integer i
  y(1) = b ((/x(1),x(2)/))
  y(2) = b ((/x(2),x(1)/))
 ! forall (i=1:2) y(i) = b ((/x(i)/))   ! memory leak (12 of 14)
 DO i = 1,2 ! frees 14 of 14
   y(i) = b ((/x(i)/))
 END DO
end


-- 


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

[Bug fortran/35131] New: OpenMP: Private variable passed to subroutine

[burnus at gcc dot gnu dot org]

As reported by Ignacio Fernández Galván, the following program prints with
"gfortran -fopenmp" 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.

See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html

I believe the program is valid, compare also
http://www.openmp.org/pipermail/omp/2006/000532.html

PROGRAM Outer
 IMPLICIT NONE
 REAL, DIMENSION(20) :: A
 INTEGER :: k
 A = 0.0
!$OMP PARALLEL DO PRIVATE(k)
 DO k=1,SIZE(A)
   CALL Inner(k)
 END DO
!$OMP END PARALLEL DO
 print *, A
CONTAINS
 SUBROUTINE Inner(i)
   IMPLICIT NONE
   INTEGER :: i
   A(i) = 42
 END SUBROUTINE Inner
END PROGRAM Outer


-- 
   Summary: OpenMP: Private variable passed to subroutine
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, openmp
  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=35131

[Bug fortran/35130] New: OpenMP: Private variable passed to subroutine

[burnus at gcc dot gnu dot org]

As reported by Ignacio Fernández Galván, the following program prints with
"gfortran -fopenmp" 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.

See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html

I believe the program is valid, compare also
http://www.openmp.org/pipermail/omp/2006/000532.html

PROGRAM Outer
 IMPLICIT NONE
 REAL, DIMENSION(20) :: A
 INTEGER :: k
 A = 0.0
!$OMP PARALLEL DO PRIVATE(k)
 DO k=1,SIZE(A)
   CALL Inner(k)
 END DO
!$OMP END PARALLEL DO
 print *, A
CONTAINS
 SUBROUTINE Inner(i)
   IMPLICIT NONE
   INTEGER :: i
   A(i) = 42
 END SUBROUTINE Inner
END PROGRAM Outer


-- 
   Summary: OpenMP: Private variable passed to subroutine
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, openmp
  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=35130

[Bug fortran/32795] allocatable components are nullified prematurely

[burnus at gcc dot gnu dot org]

--- Comment #12 from burnus at gcc dot gnu dot org  2008-02-07 22:17 ---
> This is regtesting but all the allocatable component tests are OK.
> Could somebody check the memory leakage for me, please?  The test of comment 2
> is now OK in that it prints the right numbers.

Thanks for the wrong-code fix; valgrind also shows no invalid accesses etc.
However, the initial bug of comment 0 is still present: As valgrind
--leak-check=full shows, the generated program still leaks memory:

==19078== 96 bytes in 1 blocks are definitely lost in loss record 1 of 2
==19078==at 0x4C2560E: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==19078==by 0x401246: MAIN__ (dfdf.f90:11)
==19078==by 0x401FDB: main (fmain.c:21)
==19078==
==19078==
==19078== 96 bytes in 1 blocks are definitely lost in loss record 2 of 2
==19078==at 0x4C2560E: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==19078==by 0x400B52: MAIN__ (dfdf.f90:10)
==19078==by 0x401FDB: main (fmain.c:21)

I think the one-liner could go into GCC 4.3.0 as it fixes a (user-visible)
wrong-code bug; still the missing _builtin_free calls should be added later.


-- 


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

[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[hjl dot tools at gmail dot com]

--- Comment #21 from hjl dot tools at gmail dot com  2008-02-07 22:15 
---
The real problem is i386 gcc expects 16 byte stack boundary while the
psABI specifies 4 byte. When you link a callee, which expects incoming
stack at 16 byte boundary, with a caller, which only guarantees 4 byte
stack boundary, you will run into problem. The stack alignment branch can
automatically align the incoming stack. But we have to generate 16byte
stack boundary when calling a function by default since callees compiled by
older gcc expects 16 byte stack boundary.  Since incoming stack is aligned
at 16byte by default, the stack alignment branch still assumes incoming
stack aligned at 16 byte by default. You can override it with -mstackrealign
or force_align_arg_pointer attribute, which will assume incoming stack is
aligned at 4 byte.


-- 


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

[Bug testsuite/35047] some vectorisation tests fail with --with-arch=core2 or on i338-apple-darwin8.11.1

[jrp at dial dot pipex dot com]

--- Comment #12 from jrp at dial dot pipex dot com  2008-02-07 22:13 ---
oh and 

FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o execute 

also fails


-- 


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

[Bug testsuite/35047] some vectorisation tests fail with --with-arch=core2 or on i338-apple-darwin8.11.1

[jrp at dial dot pipex dot com]

--- Comment #11 from jrp at dial dot pipex dot com  2008-02-07 22:10 ---
Latest gcc now reports only:

FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 0
FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect "vectorized 1
loops" 1


-- 

jrp at dial dot pipex dot com changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

--- Comment #11 from dfranke at gcc dot gnu dot org  2008-02-07 22:10 
---
> You mean that one-liner did it

I did not regtest, but yes, the testcases from this PR are fixed by the patch
attached in comment #7 :)


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2008-02-07 22:04 ---
(In reply to comment #9)
> Regtested without regression on ppc/intel-darwin9, 32 and 64 bit modes.
> 
> Thanks for the patch.
> 

Dominique and Daniel,

You mean that one-liner did it  That represents a seriously large number of
hours to do the diagnosis:)  Ah well, I'll use #2 as a testcase and submit to
the list.

Many thanks for your help.

Paul


-- 


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[rth at gcc dot gnu dot org]

--- Comment #24 from rth at gcc dot gnu dot org  2008-02-07 21:59 ---
Subject: Bug 33410

Author: rth
Date: Thu Feb  7 21:58:42 2008
New Revision: 132176

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132176
Log:
PR rtl-opt/33410
* config/alpha/alpha.c (alpha_emit_xfloating_compare): Use an
EXPR_LIST for the REG_EQUAL instead of a comparison with a 
funny mode.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/alpha/alpha.c


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[brian at dessent dot net]

--- Comment #20 from brian at dessent dot net  2008-02-07 21:17 ---
Subject: Re:  I/O leaks handles/memory on Windows XP


> 1) __gthr_win32_mutex_init_function()
>- sets counter=-1
>- creates a semaphore (the windows handle!)
> 
> 2)__gthr_win32_mutex_lock()
> - increments counter (now 0)
> 
> 3) __gthr_win32_mutex_unlock()
>- decrements counter (now -1 again)
>- would release the semaphore, if counter >= 0 but doesn't...!

This gthr-win32 stuff should only be run if --enable-threads=win32. 
That is not the case with Cygwin which should be using pthreads
(--enable-threads=posix).  So if the above is really at fault then the
leak should not manifest on Cygwin at all.

Brian


-- 


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

[Bug c/15236] pedantic switch modifies treatment of non-ISO compliant enumerations

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-02-07 20:56 ---
Cachis, I didn't find this when searching. Anyway, there is a patch that fixes
this in PR35129.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||33702
  nThis||


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

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2008-02-07 20:52 ---
Related to PR33992 ?


-- 


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-02-07 20:50 ---
Fixed in GCC 4.2.4 and GCC 4.3. I don't think it is worth to fix this in
earlier versions.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.4


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-02-07 20:49 ---
Subject: Bug 32754

Author: manu
Date: Thu Feb  7 20:48:24 2008
New Revision: 132175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132175
Log:
2008-02-07  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR other/32754
* doc/options.texi (Options): Replace references to opts.sh with
optc-gen.awk.
* opts-common.c: Likewise.
* optc-gen.awk: Likewise.
* opth-gen.awk: Replace reference to opts.sh with
opth-gen.awk.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/doc/options.texi
branches/gcc-4_2-branch/gcc/optc-gen.awk
branches/gcc-4_2-branch/gcc/opth-gen.awk
branches/gcc-4_2-branch/gcc/opts-common.c


-- 


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[ubizjak at gmail dot com]

--- Comment #18 from ubizjak at gmail dot com  2008-02-07 20:47 ---
(In reply to comment #17)
> P2 - this should not block the release (it's not that profiledbootstrap was
> never
> broken in released compilers).  It's also hard to analyze (no, I'm not on it,
> volunteers welcome).

It looks that ten_to_ptwo() returns wrong result for argumens >= 7.

Try this debug session:

< non-profiled (correct) cc1>:

(gdb) set args -E -quiet /dev/null
(gdb) break real_to_decimal
Breakpoint 3 at 0x599580: file ../../gcc-svn/trunk/gcc/real.c, line 1453.
(gdb) run
Breakpoint ...

(gdb) p *ten_to_ptwo (7)
$1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 426, sig = {159020156881263929, 14298703881791668535, 
10644899600020376799}}
---

:



(gdb) p *ten_to_ptwo (7)
$1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 423, sig = {5021769561911101971, 862341187440057448, 
11372220470965069550}}

You can see that the results are different.

Suprisingly, result when passing 6 as an argument differs only for one LSB.

(correct):
(gdb) p *ten_to_ptwo (6)
$2 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 213, sig = {5834422113351499776, 4377335499248575995, 
14012984643248170709}}

(wrong):
(gdb) p *ten_to_ptwo (6)
$2 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 213, sig = {5834422113351499776, 4377335499248575995, 
14012984643248170708}}

Luckily, ten_to_ptwo() from real.c has only ~20 lines.


-- 


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

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #14 from irar at il dot ibm dot com  2008-02-07 20:44 ---
Giving it another thought, this is not necessary an alias analysis issue, even
that it fails to tell that the pointers not alias. Since in this case the
pointers do differ, the runtime test should take the flow to the vectorized
loop. Maybe the test is too strict. I'll look into this on Sunday.


-- 


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-07 20:41 ---
Subject: Bug 32754

Author: manu
Date: Thu Feb  7 20:40:19 2008
New Revision: 132174

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132174
Log:
2008-02-07  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR other/32754
* doc/options.texi (Options): Replace references to opts.sh with
optc-gen.awk.
* opts-common.c: Likewise.
* optc-gen.awk: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/options.texi
trunk/gcc/optc-gen.awk
trunk/gcc/opts-common.c


-- 


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

[Bug c/35129] -pedantic changes code-generation for unsigned enumerators

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-07 20:34 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c/15236] pedantic switch modifies treatment of non-ISO compliant enumerations

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-02-07 20:34 ---
*** Bug 35129 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug target/32918] segmentation fault

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-07 20:19 ---
Sorry for the delay, this seems to have fallend through bugzilla's cracks.

GCC 3.3.1 is not supported anymore. Can you reproduce the bug in a recent
release like GCC 4.2.3 or preferably in GCC 4.3?

Thanks for the report anyway.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug c/35129] -pedantic changes code-generation for unsigned enumerators

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-02-07 19:57 ---
Got the blocks/depends thing wrong, sorry.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|33702   |
OtherBugsDependingO||33702
  nThis||


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

[Bug c/35129] -pedantic changes code-generation for unsigned enumerators

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-07 19:56 ---
Created an attachment (id=15117)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15117&action=view)
Patch

Bootstrapped with --enable-languages=all and regression tested on
x86_64-unknown-linux-gnu


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/35129] New: -pedantic changes code-generation for unsigned enumerators

[manu at gcc dot gnu dot org]

-pedantic converts enumerators to 'int', while without -pedantic they are
handled as-is.


-- 
   Summary: -pedantic changes code-generation for unsigned
enumerators
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
 BugsThisDependsOn: 33702


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2008-02-07 19:52 ---
Regtested without regression on ppc/intel-darwin9, 32 and 64 bit modes.

Thanks for the patch.


-- 


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

[Bug testsuite/20567] dg-options in gcc.c-torture

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2008-02-07 19:52 ---
*** Bug 35126 has been marked as a duplicate of this bug. ***


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[jsm28 at gcc dot gnu dot org]

--- Comment #6 from jsm28 at gcc dot gnu dot org  2008-02-07 19:52 ---


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


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/19159] [4.0/4.1/4.2/4.3 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[dave at genussoft dot com]

--- Comment #40 from dave at genussoft dot com  2008-02-07 19:39 ---
I am trying to use g++ 4.0.0 on AIX 5.3 and have run into this problem and also
the problem reported in bug 18257.  What recommendation do you have for using
g++ on AIX? Should I go back to an earlier version, or has this problem been
resolved in the 4.2.2 version?


-- 

dave at genussoft dot com changed:

   What|Removed |Added

 CC||dave at genussoft dot com


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

[Bug target/35128] New: illegal opcode movw for mcu avr3, GCC 4.2.3 too

[Rudolf dot Leitgeb at gmx dot at]

Since adding to the bug description of Bug #35073 was impossible and the 
reported bug also affects release versions of GCC, I submit a cloned
version of this bug report.

Platform: PowerMac G5, Mac OSX Tiger, fully updated
Target platform: AVR

Binutils version installed for AVR: 2.18

+++ This bug was initially created as a clone of Bug #35073 +++

Building/bootstrapping today's gcc-trunk (rev. 132088/2008-02-04) for
avr-rtems4.9 fails
with:
...
/users/rtems/src/toolchains/BUILD/avr-rtems4.9/./gcc/xgcc
-B/users/rtems/src/toolchains/BUILD/avr-rtems4.9/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/BUILD/avr-rtems4.9/avr-rtems4.9/newlib/ -isystem
/users/rtems/src/toolchains/BUILD/avr-rtems4.9/avr-rtems4.9/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.9/avr-rtems4.9/bin/ -B/opt/rtems-4.9/avr-rtems4.9/lib/ -isystem
/opt/rtems-4.9/avr-rtems4.9/include -isystem
/opt/rtems-4.9/avr-rtems4.9/sys-include -O2 -g -g -O2 -mmcu=avr35 -O2
-I../../../gcc-trunk/gcc/../newlib/libc/sys/rtems/include -O2 -g -g -O2  
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc
-I../../../../../gcc-trunk/libgcc -I../../../../../gcc-trunk/libgcc/.
-I../../../../../gcc-trunk/libgcc/../gcc
-I../../../../../gcc-trunk/libgcc/../include   -o _mulsi3.o -MT _mulsi3.o -MD
-MP -MF _mulsi3.dep -DL_mulsi3 -xassembler-with-cpp \
  -c ../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S
../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S: Assembler messages:
../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S:281: Error: illegal
opcode movw for mcu avr3
../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S:283: Error: illegal
opcode movw for mcu avr3
make[4]: *** [_mulsi3.o] Error 1
make[4]: Leaving directory
`/users/rtems/src/toolchains/BUILD/avr-rtems4.9/avr-rtems4.9/avr35/libgcc'


-- 
   Summary: illegal opcode movw for mcu avr3, GCC 4.2.3 too
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Rudolf dot Leitgeb at gmx dot at
 GCC build triplet: powerpc-apple-darwin8.11.0
  GCC host triplet: powerpc-apple-darwin8.11.0
GCC target triplet: avr-unknown-none


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

[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)

[ghazi at gcc dot gnu dot org]

--- Comment #32 from ghazi at gcc dot gnu dot org  2008-02-07 19:14 ---
Jason - Should the fix for PR28834 (AKA PR29436) be backported to 4.2/4.1?

I still see errors from mayalias-2.c on 4.2.  (4.1 doesn't have the testcase,
but I suspect it still has the bug.)


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[dgregor at gcc dot gnu dot org]

--- Comment #4 from dgregor at gcc dot gnu dot org  2008-02-07 19:06 ---
Fixed. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[dgregor at gcc dot gnu dot org]

--- Comment #3 from dgregor at gcc dot gnu dot org  2008-02-07 19:04 ---
Subject: Bug 35115

Author: dgregor
Date: Thu Feb  7 19:03:40 2008
New Revision: 132173

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132173
Log:
2008-02-06  Douglas Gregor  <[EMAIL PROTECTED]>

* g++.dg/ext/vector13.C: Fix for compilation under -pedantic.
2008-02-07  Andreas Tobler  <[EMAIL PROTECTED]>
Douglas Gregor  <[EMAIL PROTECTED]>

PR bootstrap/35115
* objcp-decl.c (objcp_comptypes): Call cp_comptypes, not comptypes.


Modified:
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-decl.c


-- 


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[dgregor at gcc dot gnu dot org]

--- Comment #2 from dgregor at gcc dot gnu dot org  2008-02-07 18:59 ---
This is fallout from my comptypes patch. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00195.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-06 23:01:33 |2008-02-07 18:59:57
   date||


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[dgregor at gcc dot gnu dot org]

--- Comment #5 from dgregor at gcc dot gnu dot org  2008-02-07 18:56 ---
This is definitely a canonical-types bug. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00230.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-07 15:13:39 |2008-02-07 18:56:38
   date||


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

[Bug tree-optimization/21655] g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0 fails

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2008-02-07 18:33 ---
This test is still XPASS'ing everywhere on 4.1, may I backport this?

2005-11-30  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/21655
* g++.dg/tree-ssa/pr14814.C: Remove XFAIL.

Recent results from Jan/Feb:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00469.html
ia64: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00451.html
s390x: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00421.html
s390: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00411.html
powerpc64: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00406.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00365.html
m68k: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00073.html
hppa: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01317.html
arm: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00996.html
sparc: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00836.html
mips: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00845.html
i486: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00835.html
alpha: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00833.html
hppa64: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00077.html
hppa2.0w: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00025.html

That's enough, yes? :-)


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

--- Comment #9 from janis at gcc dot gnu dot org  2008-02-07 18:21 ---
I talked to Steve Munroe about the ABI issues.  We determined that for
powerpc*-linux, vector types that cannot be passed in vector registers should
be passed as aggregates according to the relevant ABI (32-bit or 64-bit PowerPC
ELF).  I'll re-enable -mabi=no-altivec in a way that doesn't break SPE, fix the
argument/result passing mess, and then switch the default to -mabi=altivec for
-m32, as separate patches.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu dot
   ||org


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-07 18:06 ---
Sure.  Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|2008-02-07 15:53:56 |2008-02-07 18:06:30
   date||


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

[Bug testsuite/35127] Ineffective dg-options in gcc.c-torture/compile

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-07 18:05 ---
Confirmed.


-- 

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 |2008-02-07 18:05:55
   date||


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

[Bug c++/33887] [4.1/4.2 Regression] Reference to bitfield gets wrong value when optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #39 from rguenth at gcc dot gnu dot org  2008-02-07 18:03 
---
*** Bug 33205 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||xk-corpse at hotmail dot com


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

[Bug target/33205] optimization bug: unsigned bitfield expands with non-zero padding bits

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-07 18:03 ---
Ok, that's quite likely.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[rth at gcc dot gnu dot org]

--- Comment #23 from rth at gcc dot gnu dot org  2008-02-07 17:46 ---
Subject: Bug 33410

Author: rth
Date: Thu Feb  7 17:45:24 2008
New Revision: 132171

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132171
Log:
PR rtl-opt/33410
* config/alpha/alpha.c (alpha_emit_xfloating_compare): Use an
EXPR_LIST for the REG_EQUAL instead of a comparison with a
funny mode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.c


-- 


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

[Bug target/33205] optimization bug: unsigned bitfield expands with non-zero padding bits

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2008-02-07 17:32 ---
A regression hunt on powerpc-linux showed that the test starts passing with:

http://gcc.gnu.org/viewcvs?view=rev&rev=131823
r131823 | rguenth | 2008-01-25 12:06:31 + (Fri, 25 Jan 2008)

That's a fix for 33887.


-- 


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

[Bug libgcj/33085] liblt_prog_compiler_pic_GCJ='-DDLL_EXPORT' is wrong

[Ralf dot Wildenhues at gmx dot de]

--- Comment #2 from Ralf dot Wildenhues at gmx dot de  2008-02-07 17:25 
---
Argh.  Why doesn't GCC import the fix in libtool instead of hacking around
it downstream?



-- 

Ralf dot Wildenhues at gmx dot de changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

--- Comment #8 from dfranke at gcc dot gnu dot org  2008-02-07 17:24 ---
> Could somebody check the memory leakage for me, please?

  type :: a
integer, allocatable :: i(:)
  end type a
  type(a) :: x, y

  x = a ((/ 1,2,3 /))
! y = a (x%i(1:3))   ! ok
! y = a (x%i(1:))! ok
! y = a (x%i(:3))! ok
! y = a (x%i(:)) ! ok
! y = a (x%i)! ok
! y = x  ! ok
end

Test in comment #2 works on i686-pc-linux-gnu as well.
Thanks for fixing this!


-- 


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

[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers

[michael dot meissner at amd dot com]

--- Comment #6 from michael dot meissner at amd dot com  2008-02-07 17:22 
---
Subject: RE:  Adding 4 more tree codes causes a crash in
 building libstdc++ pre-compiled headers

The problem is there are two different vector shifts.  There is vector
shift by a scalar amount (each element gets shifted the same amount),
and vector shift by a vector (each element gets shifted by the
corresponding element in the vector).

Right now, GCC in tree-vect-transform.c looks at the shift optab and
sees if the second operand is a scalar mode, it believes the machine
only supports the vector shift by scalar mode, and assumes that if the
type is vector mode, that the machine supports vector/vector shifts.

The SSE2 instruction set extension on the x86 has vector/scalar shift
instructions, and the SSE5 instruction set extension adds vector/vector
shifts and rotates.  I want to be able to add support for a machine that
has both types of vector shift, but with the current framework, this was
impossible.

--
Michael Meissner
AMD, MS 83-29
90 Central Street
Boxborough, MA 01719

> -Original Message-
> From: bonzini at gnu dot org [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 07, 2008 12:11 PM
> To: Meissner, Michael
> Subject: [Bug c++/35004] Adding 4 more tree codes causes a crash in
> building libstdc++ pre-compiled headers
> 
> 
> 
> --- Comment #5 from bonzini at gnu dot org  2008-02-07 17:10
---
> Unrelated, but why couldn''t vector/vector shifts/rotates overload
> LSHIFT_EXPR
> instead? :-)
> 
> 
> --
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug libgcj/33085] liblt_prog_compiler_pic_GCJ='-DDLL_EXPORT' is wrong

[rondesot at yahoo dot com]

--- Comment #1 from rondesot at yahoo dot com  2008-02-07 17:15 ---
I would like to confirm this bug and discuss a work around that I used.

This bug seems to be the only thing that keeps gcc 4.3 with java from
completing a native build under mingw.

With the two patches below, I was able to build snapshot gcc-4.3-20080118.

The gcj.exe created with this change works a little, about what you would
expect from an early snapshot of a new revision. Simple .java files that have
already been converted into .class files can be compiled into Windows
executables. On the other hand, .java files cannot be compiled directly into
executables because the ecj1.exe program does not seem to work.

Using Sun's javac to compile a simple HelloWorld.java into a .class file then
using gcj to get an .exe. created a working executable.

I could also compile .java files directly by replacing the ecj1.exe file
created by my native build with ecj1.exe from Mohan Embar's GCC/GCJ 4.3
(gcj-eclipse-merge-branch).

More complex programs, i.e. the building an Eclipse SWT Library, do not work.

PATCHES

In gcc\java\jvspec.c, I changed the test for arguments beginning with 'D'

FROM

else if (argv[i][1] == 'D')
  saw_D = 1;

TO

else if (argv[i][1] == 'D' && strcmp (argv[i], "-DDLL_EXPORT") != 0) 
   saw_D = 1;



In gcc\java\jvgenmain.c, I changed the handling of arguments 
beginning with 'D' to treat "-DDL_EXPORT" as it would a non "-D" argument.

FROM

for (i = 1; i < argc; ++i)
  {
if (! strncmp (argv[i], "-D", 2))
  {
/* Handled later.  */
  }
else
  break;
  }


TO

for (i = 1; i < argc; ++i)
  {
if (! strncmp (argv[i], "-D", 2) || strcmp (argv[i], "-DDLL_EXPORT") == 0)
  {
/* Handled later.  */
  }
else
  break;
  }

The second patch may not be doing exactly what is needed. There are several
places within gcc\java\jvgenmain.c where the test for -DDLL_EXPORT can be done.
As this directive should be handled like a non "-D' would be, I guessed that
the test for it should be made as early in the program as possible.

I welcome any help that I can get to improve on this.


-- 

rondesot at yahoo dot com changed:

   What|Removed |Added

Summary|liblt_prog_compiler_pic_GCJ=|liblt_prog_compiler_pic_GCJ=
   |'-DDLL_EXPORT'  is wrong|'-DDLL_EXPORT'  is wrong


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

[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2008-02-07 17:10 ---
Unrelated, but why couldn''t vector/vector shifts/rotates overload LSHIFT_EXPR
instead? :-)


-- 


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

[Bug rtl-optimization/31704] x86_64 poor floating point register allocation across function call

[hubicka at gcc dot gnu dot org]

--- Comment #1 from hubicka at gcc dot gnu dot org  2008-02-07 16:36 ---
This is fixed by the call frequency patch on mainline.
.L2:
cvtsi2ss(%ebx,%eax,4), %xmm0
addl$1, %eax
cmpl$1000, %eax
mulss   %xmm2, %xmm0
addss   %xmm0, %xmm1
jne .L2

(on i386, but x86-64 behaves same way)

Honza


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/35125] Violating standards

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-02-07 16:07 ---
Also, you should get a warning when using -Wuninitialized -O (or -Wall -O).


-- 


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-02-07 15:55 ---
Can we move them into gcc.dg/torture?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[Jerry_V_DeLisle at rl dot gov]

--- Comment #19 from Jerry_V_DeLisle at rl dot gov  2008-02-07 15:54 ---
Writing to an internal unit is nothing more than a fancy (formatted)
assignment.  Each thread allocates its own unit structure.  Its not like file
I/O where threads are accessing a common shared resource.

I should mention that Danny Smith has sent me a potential patch that I will
test tonight or tomorrow.  I would not mind seeing a threaded example where
this could be tested and that confirms we need to lock internal units. :)


-- 


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-02-07 15:53 ---
My point is those dg-options aren't applied to the testcases. We should
either remove them or make sure that they are used.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Last reconfirmed|-00-00 00:00:00 |2008-02-07 15:53:56
   date||


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

[Bug testsuite/35127] New: Ineffective dg-options in gcc.c-torture/compile

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/compile/*.c | grep O
gcc.c-torture/compile/20031125-1.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/20031125-2.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/20031203-1.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/acc1.c:/* { dg-options "-O2 -ffast-math" } */
gcc.c-torture/compile/builtin_constant_p.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/pr21562.c:/* { dg-options "-O3 -fno-inline" } */
gcc.c-torture/compile/pr25483.c:/* { dg-options "-O -fmove-loop-invariants" }
*/
gcc.c-torture/compile/pr32349.c:/* { dg-options "-O2 -fmodulo-sched" } */
gcc.c-torture/compile/pr32355.c:/* { dg-options "-O3" } */
gcc.c-torture/compile/pr34448.c:/* { dg-options "-O" } */
gcc.c-torture/compile/pr34648.c:/* { dg-options "-O2 -fexceptions" } */

Since dg-options overrides different optimization levels set by
c-torture, those different optimization levels aren't tested on those
files.


-- 
   Summary: Ineffective dg-options in gcc.c-torture/compile
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-02-07 15:44 ---
(In reply to comment #0)
> [EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/execute/*.c
> gcc.c-torture/execute/pr7284-1.c:/* { dg-options "-std=c89" } */
> gcc.c-torture/execute/wchar_t-1.c:/* { dg-options "-finput-charset=utf-8" } */
> [EMAIL PROTECTED] testsuite]$
> 
> But those dg-options are ignored since gcc.c-torture/execute/execute.exp
> doesn't load gcc-dg.exp.

You can add .x driver files in the directory to achieve same
functionality.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca  2008-02-07 
15:33 ---
Subject: Re:  wo_prof_two_strs.c:56: internal compiler error: in
find_new_var_of_type, at ipa-struct-reorg.c:605

> I looked into assembly you send and see the following difference:
> for original malloc there is additional instruction 
> 
> stwm %r4,64(%r30)
> 
> before malloc call, while for first artificial malloc (field a, I suppose)
> there is similar instruction
> 
> stw %r3,-60(%r30)
> 
> but for the second artificial malloc there isn't. ("Copy" instructions are to
> carry results of the malloc).
> 
> As I am not familiar with hp assembler, can you please explain what is the
> meaning of this instruction? Probably my suspicion is wrong.

The above two instructions are part of the prologue for main.  Both
instructions are stores.  In non leaf functions, the prologue always
creates a frame.  In the 32-bit runtime, this is always a multiple of
64 bytes.  Depending on the details of the prologue, the creation
of a new frame may be combined with a register store.  The above stwm
instruction saves register r4 at the stack pointer address contained
in r30 (conventionally the stack pointer register) and then 64 is
added to r30.  The stw insn saves r3 at the stack pointer address
minus 60.  r3 and r4 are both caller saves registers, so they have
to be saved in the frame when used and restored in the epilogue.

Prologue and epilogue handling occurs in every function with a frame,
so it is extremely well tested.

Dave


-- 


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-07 15:32 ---
This is semi by designed, you can use gcc.dg/torture for this.


-- 


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

[Bug c/35122] gcc segfaults when compiling code with pointers to vector float

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-07 15:27 ---
First off this is not a bug in the FSF GCC as the FSF GCC does not support
vector array access syntax so this should have been filed with the provider
that gave you the source.  Second off this has been since fixed in IBM's SDK
(but not yet released IIRC) (I should know I fixed it).

When this goes into the FSF GCC (which might be later next month if I get some
time), it should be fixed here too.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug testsuite/35126] New: dg-options in gcc.c-torture/execute ignored

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/execute/*.c
gcc.c-torture/execute/pr7284-1.c:/* { dg-options "-std=c89" } */
gcc.c-torture/execute/wchar_t-1.c:/* { dg-options "-finput-charset=utf-8" } */
[EMAIL PROTECTED] testsuite]$

But those dg-options are ignored since gcc.c-torture/execute/execute.exp
doesn't load gcc-dg.exp.


-- 
   Summary: dg-options in gcc.c-torture/execute ignored
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/35125] Violating standards

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-07 15:22 ---
VLA in C++ is an extension, if you use -pedantic, you will get an error.

Also VLA uses the value at the time at definition and no other value after
wards.


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[fxcoudert at gcc dot gnu dot org]

--- Comment #18 from fxcoudert at gcc dot gnu dot org  2008-02-07 15:20 
---
(In reply to comment #17)

> This begs a question.  Why do we even want locking on internal units?  The
> string is local to the thread and allocated on the stack most likely.

What about the case of two threads writing to the same string (maybe to
overlapping parts of the same string)? It's not good programing, but if we
support it for files, why not for internal units?

I don't see why the string should be local to the thread, and it might not
always be allocated on the stack. "Most likely" just doesn't seem good enough
:)


-- 


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2008-02-07 15:19 ---
Indeed.  I developed my 35049 patch in an old check-out (to avoid conflicts
with Doug's patch), but after updating the tree it fails for me too.


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2008-02-07 15:19 ---
Created an attachment (id=15116)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15116&action=view)
A tentative patch for the PR

This is regtesting but all the allocatable component tests are OK.

Could somebody check the memory leakage for me, please?  The test of comment 2
is now OK in that it prints the right numbers.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-07 15:16 ---
I can also confirm that

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00212.html

does _not_ fix the problem.  We still ICE with

/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/ext/vector13.C:6: internal
compiler error: canonical types differ for identical types const int __vector__
[] and const int __vector__ []^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

FAIL: g++.dg/ext/vector13.C (internal compiler error)
FAIL: g++.dg/ext/vector13.C (test for excess errors)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[debian-gcc at lists dot debian dot org]

-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[debian-gcc at lists dot debian dot org]

--- Comment #4 from debian-gcc at lists dot debian dot org  2008-02-07 
15:15 ---
reproducible with 20080206, gcc is configured with

Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080206-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libffi --enable-objc-gc
--enable-mpfr --disable-softfloat --enable-secureplt
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --with-long-double-128 --enable-checking=release
--build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu
Thread model: posix
gcc version 4.3.0 20080206 (experimental) [trunk revision 132160] (Debian
4.3-20080206-1) 

  Matthias


-- 


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-07 15:13 ---
Confirmed.  We're back to an ICE.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-checking, ice-on-valid-
   ||code
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-07 15:13:39
   date||
Summary|g++.dg/ext/vector13.C   |[4.3 Regression]
   |doesn't work|g++.dg/ext/vector13.C
   ||doesn't work


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

[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2008-02-07 15:10 ---
Test summary comparison before and after the patch in comment #4:

ibook-dhum] gcc/i686-darwin% diff -u res-132160p3m.log res-132160p4m.log
--- res-132160p3m.log   2008-02-07 15:52:50.0 +0100
+++ res-132160p4m.log   2008-02-07 15:54:58.0 +0100
@@ -12,16 +12,14 @@
 FAIL: g++.dg/ext/vector13.C (test for excess errors)
 FAIL: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
 FAIL: g++.dg/pubtypes.C scan-assembler long+[ \\t]+0x24+[ \\t]+[#;]+[
\\t]+Length of Public Type Names Info
-FAIL: g++.dg/template/spec35.C scan-assembler .glob(a|)l[\\t ]*_Z2f2IfEvT_
-FAIL: g++.dg/template/spec35.C scan-assembler .weak[\\t ]*_Z2f2IiEvT_
 FAIL: g++.dg/special/conpr-3.C execution test
 FAIL: g++.dg/special/initpri1.C execution test
 FAIL: g++.old-deja/g++.pt/const2.C (test for excess errors)

=== g++ Summary for unix ===

-# of expected passes   17297
-# of unexpected failures   10
+# of expected passes   17299
+# of unexpected failures   8
 # of expected failures 82
 # of unsupported tests 125

@@ -34,23 +32,21 @@
 FAIL: g++.dg/inherit/override-attribs.C  (test for errors, line 14)
 FAIL: g++.dg/inherit/override-attribs.C (test for excess errors)
 FAIL: g++.dg/pubtypes.C scan-assembler long+[ \\t]+0x24+[ \\t]+[#;]+[
\\t]+Length of Public Type Names Info
-FAIL: g++.dg/template/spec35.C scan-assembler .glob(a|)l[\\t ]*_Z2f2IfEvT_
-FAIL: g++.dg/template/spec35.C scan-assembler .weak[\\t ]*_Z2f2IiEvT_
 FAIL: g++.dg/special/conpr-3.C execution test
 FAIL: g++.dg/special/initpri1.C execution test
 FAIL: g++.old-deja/g++.pt/const2.C (test for excess errors)

=== g++ Summary for unix/-m64 ===

-# of expected passes   17215
-# of unexpected failures   13
+# of expected passes   17217
+# of unexpected failures   11
 # of expected failures 82
 # of unsupported tests 151

=== g++ Summary ===

-# of expected passes   34512
-# of unexpected failures   23
+# of expected passes   34516
+# of unexpected failures   19
 # of expected failures 164
 # of unsupported tests 276
 /opt/gcc/i686-darwin/gcc/testsuite/g++/../../g++  version 4.3.0 20080206
(experimental) (GCC) 


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-02-07 15:01 
---
Once again, good detective work by jpr.  This then does make this a regression
wrt 4.1.  I do not have a 4.1 build on my windows machine to check.  Regardless
...

This begs a question.  Why do we even want locking on internal units?  The
string is local to the thread and allocated on the stack most likely.  I am not
sure that another thread can even see it.  The unit structure is created on a
per READ/WRITE basis and is freed after the operation is complete.  Anyone else
have any thoughts on this.


-- 


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

[Bug fortran/35123] ICE in fold_convert, at fold-const.c:2248

[sfilippone at uniroma2 dot it]

--- Comment #3 from sfilippone at uniroma2 dot it  2008-02-07 14:54 ---
(In reply to comment #2)
> gfortran 4.1 errors with
> 
>  In file t.f90:3
> 
> integer, allocatable :: md(:), g2l(:)
>1
> Error: Attribute at (1) is not allowed in a TYPE definition
>

The failure in 4.1 is due to the support of language extension TR 15581, which
was only added in 4.2.0. 
Salvatore


-- 


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