[Bug middle-end/27080] gcc should emit .type directives for used undeclared extern variables and functions

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-08 04:06 ---
I should note people do tricks and one of them would cause an error being
emitting, maybe it should maybe not.  But even emitting used ones can go up in
the .s file size causing more compile time issues.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gcc should emit .type   |gcc should emit .type
   |directives for used extern  |directives for used
   |variables and functions |undeclared extern variables
   ||and functions


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

[Bug middle-end/27080] gcc should emit .type directives for used extern variables and functions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-08 04:05 ---
If we do it for all extern functions and variables, it would be about 1000
.types which are not useful.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|gcc should emit .type   |gcc should emit .type
   |directives for extern   |directives for used extern
   |variables and functions |variables and functions


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

[Bug middle-end/27080] New: gcc should emit .type directives for extern variables and functions

[nmiell at comcast dot net]

It doesn't right now, but in a perfect world ld could complain if one object
referred to a symbol of type object while another referred to the same symbol
of type function.

Of course, in order for ld to do this, gcc would have to actually emit .type
directives for extern variables and functions. It doesn't right now, hence this
bug.


-- 
   Summary: gcc should emit .type directives for extern variables
and functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmiell at comcast dot net


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

[Bug libstdc++/27079] Memory leak in std::string?..

[sakovacs at freemail dot hu]

--- Comment #4 from sakovacs at freemail dot hu  2006-04-08 02:58 ---
sorry, please disregard my last post, submitted too early...

Thanks for the very fast reply. I agree, that such a leakage would be very
unlikely. It must be something else, but I don't understand what, I've modified
the code:

#include 
#include 
int max = 500;
void bad() {
std::vector v;
for (int x = 0; x < max; x++) v.push_back(std::string("test"));
}
int main(int argc, char *argv[]) {
bad();
usleep(2 * 1000);
return 0;
}

I've already tested with valgrind, restested this ^ version too, just like you
pointed it out on the link, the result is:

valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high
--show-reachable=yes ./t
==8291== Memcheck, a memory error detector.
==8291== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==8291== Using LibVEX rev 1367, a library for dynamic binary translation.
==8291== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==8291== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==8291== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
--8291-- Valgrind library directory: /usr/lib64/valgrind
--8291-- Command line
--8291--./t
--8291-- Startup, with flags:
--8291---v
--8291----num-callers=20
--8291----leak-check=yes
--8291----leak-resolution=high
--8291----show-reachable=yes
--8291-- Contents of /proc/version:
--8291--   Linux version 2.6.14-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.4 
(Gentoo
3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #2 Tue Feb 28 22:00:41 JST 2006
--8291-- Reading syms from /mnt/evyrl/evyrl/Projects/evyrl/src/main/t
(0x40)
--8291-- Reading syms from /lib/ld-2.3.5.so (0x1190)
--8291-- Reading syms from /usr/lib/valgrind/stage2 (0x7000)
--8291--object doesn't have a symbol table
--8291-- Reading suppressions file: /usr/lib64/valgrind/default.supp
==8291==
--8291-- Reading syms from /usr/lib/valgrind/vg_preload_core.so (0x11A17000)
--8291--object doesn't have a symbol table
--8291-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x11B18000)
--8291--object doesn't have a symbol table
--8291-- REDIR: 0x1190EFA0 (index) redirected to 0x11B1BDA0 (index)
--8291-- REDIR: 0x1190F150 (strcmp) redirected to 0x11B1C250 (strcmp)
--8291-- REDIR: 0x1190F180 (strlen) redirected to 0x11B1BFE0 (strlen)
--8291-- Reading syms from
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6.0.3 (0x11C46000)
--8291-- Reading syms from /lib/libm-2.3.5.so (0x11E36000)
--8291--object doesn't have a symbol table
--8291-- Reading syms from
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.4.4/libgcc_s.so.1 (0x11FBC000)
--8291-- Reading syms from /lib/libc-2.3.5.so (0x120C8000)
--8291--object doesn't have a symbol table
--8291-- Reading syms from /lib/libdl-2.3.5.so (0x122ED000)
--8291--object doesn't have a symbol table
--8291-- REDIR: 0x12136640 (rindex) redirected to 0x11B1BCA0 (rindex)
--8291-- REDIR: 0x12136230 (strlen) redirected to 0x11B1BFA0 (strlen)
--8291-- REDIR: 0x121364A0 (strncmp) redirected to 0x11B1C1D0 (strncmp)
--8291-- REDIR: 0x11CF5140 (operator new(unsigned long)) redirected to
0x11B1A380 (operator new(unsigned long))
--8291-- REDIR: 0x12137B60 (memcpy) redirected to 0x11B1C2B0 (memcpy)
--8291-- REDIR: 0x11CF3F10 (operator delete(void*)) redirected to 0x11B1AF80
(operator delete(void*))
--8291-- REDIR: 0x12130630 (free) redirected to 0x11B1AC60 (free)
--8291-- REDIR: 0x12137460 (memset) redirected to 0x11B1C710 (memset)
==8291==
==8291== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 4)
--8291--
--8291-- supp:3 index-not-intercepted-early-enough-HACK-1
--8291-- supp:1 strlen-not-intercepted-early-enough-HACK-4
--8291-- supp:1 strlen-not-intercepted-early-enough-HACK-3
--8291-- supp:4 dl_relocate_object
==8291== malloc/free: in use at exit: 0 bytes in 0 blocks.
==8291== malloc/free: 121 allocs, 121 frees, 45777208 bytes allocated.
==8291==
==8291== No malloc'd blocks -- no leaks are possible.
--8291--  memcheck: sanity checks: 2156 cheap, 87 expensive
--8291--  memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--8291--  memcheck: auxmaps: 0 searches, 0 comparisons
--8291--  memcheck: secondaries: 1360 issued (87040k, 85M)
--8291--  memcheck: secondaries: 161 accessible and distinguished (10304k, 10M)
--8291-- tt/tc: 3550 tt lookups requiring 3607 probes
--8291-- tt/tc: 3550 fast-cache updates, 5 flushes
--8291-- translate: new1675 (36624 -> 748979; ratio 204:10) [0 scs]
--8291-- translate: dumped 0 (0 -> ??)
--8291-- translate: discarded  11 (212 -> ??)
--8291-- scheduler: 107846433 jumps (bb entries).
--8291-- scheduler: 2156/2004138 major/minor sched events.
--8291--sanity: 2157 cheap, 87 expensive checks.
--8291--exectx: 4999 lists, 14 contexts (avg 0 per list)
--8291--exectx: 251 searches, 373 full compares (1499 per 1000)
--8291--exectx: 0 cmp2, 36 

[Bug tree-optimization/19590] IVs with the same evolution not eliminated

[dberlin at gcc dot gnu dot org]

--- Comment #9 from dberlin at gcc dot gnu dot org  2006-04-08 02:53 ---
Actually, it's not really expensive at all.
It's certainly not N^2.
The new SCC value numberer for PRE i'm working on gets this case right (and
this is in fact, one of the advantages of SCC based value numbering).

You could also do it with an RPO iteration algorithm, which is what open64
does, but that will iterate over defs/uses in changing blocks repeatedly
instead of only iterating over the members of the SCC.

For this case, i get:
Value numbers:
n_3 = m_2
n_9 = m_8
n_21 = m_20

Which is what you wanted.


-- 


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

[Bug libstdc++/27079] Memory leak in std::string?..

[sakovacs at freemail dot hu]

--- Comment #3 from sakovacs at freemail dot hu  2006-04-08 02:53 ---
Thanks for the very fast reply. I agree, that such a leakage would be very
unlikely. It must be something else, but I don't understand what, I've modified
the code:

#include 
#include 
int max = 100;
void bad() {
std::vector v;
for (int x = 0; x < max; x++) v.push_back(std::string("test"));
}
int main(int argc, char *argv[]) {
bad();
usleep(2 * 1000);
return 0;
}

I've already tested with valgrind, restested this ^ version too, just like 


-- 


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

[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-04-08 02:32 ---
Store copy prop has the same issue, testcase:
void foo (int *p, int *q, int t)
{
  *p = t;
  *q = t;
  if (*p != 1)
link_error ();
}


-- 


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

[Bug tree-optimization/19590] IVs with the same evolution not eliminated

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-04-08 02:26 ---
Comparing the IVs themselves take no time, now figuring out which one are equal
to which set could take some time, at max O(n^2) time.  Now n is going to be
small for most cases anyways.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-02-13 04:03:32 |2006-04-08 02:26:25
   date||


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

[Bug target/16798] PowerPC - Opportunity to use recording form instruction.

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-04-08 02:20 ---
I should note that there are some PPC cores where most recording are
microcoded.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  GCC build triplet|powerpc64-linux |
   GCC host triplet|powerpc64-linux |


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

[Bug libstdc++/27079] Memory leak in std::string?..

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-08 02:16 ---
Also it might be glibc holding on to the memory for a little bit before
releasing it back to the kernel.

Anyways use a real leak finder and what is said in the FAQ and you should find
that libstdc++ does not leak.


-- 


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

[Bug libstdc++/27079] Memory leak in std::string?..

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-08 02:14 ---
Please read:
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak


-- 


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

[Bug libstdc++/27079] New: Memory leak in std::string?..

[sakovacs at freemail dot hu]

Am I doing something wrong here? Or is it really a memory leak in STL?... 

#include 
#include 
int max = 400;
void bad() {
std::vector v;
for (int x = 0; x < max; x++) {
v.push_back(new std::string("test"));
}
for (uint x = 0; x < max; x++) {
delete v.at(x);
}
}
void good() {
std::vector v;
for (int x = 0; x < max; x++) {
v.push_back(new std::string("test"));
delete v.at(x);
}
}
int main(int argc, char *argv[]) {
bad();  // this is not good...
//good(); // this works perfectly
//usleep(2 * 1000); // stop here so that we have time to check the RSS
return 0;
}

If you check the RSS before exiting (enable usleep) you see that when running
bad() the heap size of the process doesn't decrease (stays aroud ~300Mbs for
me). 

Compiled as: g++ test.cpp -o test

gcc -v:

Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.4
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include/g++-v3
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --enable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)


-- 
   Summary: Memory leak in std::string?..
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sakovacs at freemail dot hu
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/27078] [4.1/4.2 Regression] Duplicate error message for ambiguous enum

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.0.4   |4.1.1


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

[Bug c++/27078] [4.1/4.2 Regression] Duplicate error message for ambiguous enum

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-08 02:03 ---
I take the back it is a regression from 4.1.0, it fails there too but it does
not produce the duplicated error message in 4.0.3 though.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.0 4.2.0
  Known to work||4.0.2
Summary|[4.2 Regression] Duplicate  |[4.1/4.2 Regression]
   |error message for ambiguous |Duplicate error message for
   |enum|ambiguous enum
   Target Milestone|4.2.0   |4.0.4


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

[Bug c++/27078] [4.2 Regression] Duplicate error message for ambiguous enum

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-08 02:02 ---
Confirmed, a regression from 4.0.2 and 4.1.0


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2006-04-08 02:02:44
   date||
Summary|Duplicate error message for |[4.2 Regression] Duplicate
   |ambiguous enum  |error message for ambiguous
   ||enum
   Target Milestone|--- |4.2.0


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

[Bug c++/27078] New: Duplicate error message for ambiguous enum

[ian at airs dot com]

This C++ file:

enum E1 { V };
namespace { enum E2 { V }; }
int foo() { return static_cast(V); }

when compiled with current mainline produces a doubled error message:

foo.cc: In function ‘int foo()’:
foo.cc:3: error: reference to ‘V’ is ambiguous
foo.cc:1: error: candidates are: E1 V
foo.cc:2: error: ::E2 ::V
foo.cc:3: error: reference to ‘V’ is ambiguous
foo.cc:1: error: candidates are: E1 V
foo.cc:2: error: ::E2 ::V

This duplication is pointless and confusing.


-- 
   Summary: Duplicate error message for ambiguous enum
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2006-04-08 01:46 ---
This is not a missed optimization, just a compile time fix really.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|missed-optimization |


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

[Bug tree-optimization/24333] missed div optimizations

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-04-08 01:41 ---
x/x is done for fp now.


-- 


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

[Bug target/23983] the altivec builtins should be marked as pure/const

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-08 01:29 ---
I am going to look into this some more since well PPC/Cell/PS3 is my thing now.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/27068] complilation abandoned on NML Ada test server

[wshackle at yahoo dot com]

--- Comment #2 from wshackle at yahoo dot com  2006-04-08 00:19 ---
Subject: Re:  complilation abandoned on NML Ada test server

The compile that failed occured in rcslib/src/test
which which references files in rcslib/src/ada


-- Will


--- pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:

> 
> 
> --- Comment #1 from pinskia at gcc dot gnu dot
> org  2006-04-07 03:19 ---
> Please attach the files.
> 
> 
> -- 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>What|Removed
> |Added
>

>Severity|critical   
> |normal
>  Status|UNCONFIRMED
> |WAITING
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27068
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


--- Comment #3 from wshackle at yahoo dot com  2006-04-08 00:19 ---
Created an attachment (id=11224)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11224&action=view)


-- 


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2006-04-07 23:05 
---
Subject: Bug 26890

Author: jvdelisle
Date: Fri Apr  7 23:05:12 2006
New Revision: 112769

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

PR libgfortran/26890
* io/io.h: Revert change to pad size made on 2006-03-30.
Add comment explaining dependency with fortran/trans-io.c.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h


-- 


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

[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64

[wilson at gcc dot gnu dot org]

--- Comment #17 from wilson at gcc dot gnu dot org  2006-04-07 23:04 ---
Subject: Bug 26483

Author: wilson
Date: Fri Apr  7 23:04:15 2006
New Revision: 112768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112768
Log:
For PR 26483, IA-64 denorm failure due to unwanted rounding.
* testsuite/libffi.call/float4.c: New testcase.

Added:
trunk/libffi/testsuite/libffi.call/float4.c
Modified:
trunk/libffi/ChangeLog


-- 


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

[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64

[wilson at tuliptree dot org]

--- Comment #16 from wilson at tuliptree dot org  2006-04-07 23:00 ---
Subject: Re:  Wrong parsing of doubles when interpreted
on ia64

On Tue, 2006-04-04 at 13:46, andreast at gcc dot gnu dot org wrote:
> --- Comment #15 from andreast at gcc dot gnu dot org  2006-04-04 20:46 
> ---
> Would you mind adding a reference to the PR in the test case header and adjust
> the 'int i' in main to 'unsigned int i'? If you feel ok with the test case 
> then
> please commit to trunk.

I added the PR number, and fixed the comment about the delta check.

I see that the float1.c file on mainline is different than the gcc-4.0.x
float1.c file that I started with.  I adjusted my testcase to match,
changing the 'int i' to 'unsigned int i', and deleting one spurious
space char.

I retested on mainline with ia64 unpatched, ia64 patched, x86_64, and
x86_64/-m32.  It failed for the first one, and worked for the other 3,
as expected.  I will go ahead and check it in.


-- 


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[sje at cup dot hp dot com]

--- Comment #11 from sje at cup dot hp dot com  2006-04-07 22:36 ---
I think putting pad back to where it was is a good first step and I will see if
there is room on a 64 bit machine, I think we need some kind of test to make
sure that pad is always equal to or greater than the size of structure p and a
comment that changing the size of pad will affect compatibility.  I don't know
if we can do that check at GCC compile time though. 

I am now running into a related but slighty different problem on IA64 HP-UX. In
trans-io.c (gfc_build_st_parameter) we build the 'u' field as an array of char.
 Now in actual fact 'u' is the union of an array of char and the structure 'p'.
 On IA64 HP-UX (or any strict memory alignment machine) an array of char will
just be aligned on a 1-byte boundry, but the union would be aligned on a 4 or 8
byte boundry (whatever the largest field alignment requirement is).  So I am
accessing ->u.p.item_count and the alignment is wrong because the front-end
allocated the space based on char alignment not on int/struct alignment.


-- 


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2006-04-07 22:23 
---
I put some prints at the top of get_unit in unit.c to take a look.  After
putting the padding back where it was originally in io.h:

The DTP
Size of p: 132
Size of pad: 200
Size of char *: 4
Size if int: 4

This is OK on i686.  pad needs to be >= p

The original padding in io.h should be:

  char pad[16 * sizeof (char *) + 34 * sizeof (int)];

Steve Ellcey, could you check this on a 64 bit machine, HPUX.  I used the
following with a simple program that performed a WRITE.

gfc_unit *
get_unit (st_parameter_dt *dtp, int do_create)
{
  st_printf("The DTP\n");
  st_printf("Size of p: %d\n", sizeof(dtp->u.p));
  st_printf("Size of pad: %d\n", sizeof(dtp->u.pad));
  st_printf("Size of char *: %d\n", sizeof(char *));
  st_printf("Size if int: %d\n", sizeof(int));
...


-- 


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

[Bug fortran/19101] missing & in character continuation not caught

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2006-04-07 21:20 
---
Fixed now on 4.1.1 and 4.2


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/19101] missing & in character continuation not caught

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2006-04-07 21:12 
---
Subject: Bug 19101

Author: jvdelisle
Date: Fri Apr  7 21:12:41 2006
New Revision: 112764

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

PR fortran/19101
* gfortran.dg/continuation.f90: New test.
* gfortran.dg/fmt_read_bz_bn.f90: Fix use of continuation.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/continuation.f90
Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/fmt_read_bz_bn.f90


-- 


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

[Bug fortran/19101] missing & in character continuation not caught

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2006-04-07 21:07 
---
Subject: Bug 19101

Author: jvdelisle
Date: Fri Apr  7 21:07:52 2006
New Revision: 112763

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

PR fortran/19101
* gfortran.h: Add warn_ampersand.
* invoke.texi: Add documentation for new option.
* lang.opt: Add Wampersand.
* options.c (gfc_init_options): Initialize warn_ampersand.
(gfc_post_options): Set the warn if pedantic.
(set_Wall): Set warn_ampersand.
(gfc_handle_option: Add Wampersand for itself, -std=f95, and
-std=f2003.
* scanner.c (gfc_next_char_literal): Add test for missing '&' in
continued character constant and give warning if missing.

Modified:
branches/gcc-4_1-branch/gcc/fortran/ChangeLog
branches/gcc-4_1-branch/gcc/fortran/gfortran.h
branches/gcc-4_1-branch/gcc/fortran/invoke.texi
branches/gcc-4_1-branch/gcc/fortran/lang.opt
branches/gcc-4_1-branch/gcc/fortran/options.c
branches/gcc-4_1-branch/gcc/fortran/scanner.c


-- 


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

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

[rdabrowa at poczta dot onet dot pl]

--- Comment #2 from rdabrowa at poczta dot onet dot pl  2006-04-07 20:07 
---
Execution times (in seconds) for different lengths:

stringfrom
lengthbuiltin library
--
0 0.480.07
5 0.570.11
100.650.14
200.820.17
501.330.28
100   2.160.58
200   3.840.93
500   8.882.05
1000  17.28   3.92
2000  34.07   7.55
5000  84.46   18.59

and further, with loop count reduced 100 times:

stringfrom
lengthbuiltin library
--
1 1.680.37
2 3.360.75
5 8.401.86
1016.80   3.69
2033.62   7.37


-- 


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2006-04-07 19:17 
---
st_parameter_dt are declared by the front end which then passes to the library
functions.


-- 


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

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-07 19:12 ---
Your benchmark only deals with one sized strings, you should try with multiple
different sized strings like include one which is zero lengthed, one which is
2k-2M in length and try bechmarking that.  You might get a different result, it
might be GCC's builtin one is better for shorter lengths strings than what your
current benchmark does.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target


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

[Bug c/27077] New: [x86, 4.1] builtin strlen poor performance

[rdabrowa at poczta dot onet dot pl]

Code below, when compiled with -fno-builtin option works 5 times faster:
#include 
#include 

int main(int argc, char *argv[])
{
char s[20] = "";
int i, len;

memset(s, 'a', sizeof(s)-1);
for(i = 0; i < 1000; ++i)
len = strlen(s);
printf("len: %d\n", len);
return 0;
}

My machine is Pentium IV


-- 
   Summary: [x86, 4.1] builtin strlen poor performance
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rdabrowa at poczta dot onet dot pl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[sje at cup dot hp dot com]

--- Comment #8 from sje at cup dot hp dot com  2006-04-07 18:55 ---
I am not sure why it was created the way it was or why it doesn't just use
sizeof(p).  I haven't looked back into SVN/email to see if there are any
comments on why it was done the way it was done.  Do you know where structures
of type st_parameter_dt are allocated?  I looked quickly but didn't see it.


-- 


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2006-04-07 18:50 
---
Another thought.  If comment #5 about size of p is true, why not set pad to
sizeof(p)?  Why was it so oddly constructed in the first place?


-- 


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2006-04-07 18:42 
---
We posted a question about that on the list.  Not knowing the purpose of pad, I
took a guess.  Let me know what you learn.  Appreciate your testing this and
reporting.


-- 


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

[Bug bootstrap/27074] Bootstrap fails on i686-pc-linux-gnu

[amylaar at gcc dot gnu dot org]

--- Comment #2 from amylaar at gcc dot gnu dot org  2006-04-07 18:07 ---
 (In reply to comment #1)
> File this first with gdb as it is gdb's sources which are have the warning in
> it, if they say the warning is bogus, file a real bug report with the
> preprocessed source.

When you look at the code, the warning is obviously spurious.
But we know that uninitialized warnings cannot be made reliable, so it is
unclear if you can call it bogus.
With the bootstrap building gdb with -Wuninitailized -Werror, we are basically
asking for trouble.
AFAIK we have not documented any conding standards that tell how to write
code that can be compiled successfully with these options, so it seems
disingenious to put the blame on the code in gdb.


-- 


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

[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-07 17:15 ---
../../gcc-3.4.0/libiberty/getpwd.c:74: storage size of `dotstat' isn't known
../../gcc-3.4.0/libiberty/getpwd.c:74: storage size of `pwdstat' isn't known


Why are you trying to compile 3.4.0, when there is 3.4.6 to try?

Also if 3.4.6 does not work, please try 4.0.3 as 3.4.x is no longer being
updated.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target


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

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

[sje at cup dot hp dot com]

--- Comment #5 from sje at cup dot hp dot com  2006-04-07 17:02 ---
I believe this patch is causing a bunch of IO failures on ia64-hp-hpux11.23. 
Specifically, the setting of "pad" looks bad to me.  pad, in this case, is not
a padding on the end of the structure but a parallel array of chars that is in
union u and should be the same size as the structure p and using the same space
as the structure p.  I think the fix is to increase the size of pad, not
decrease it.  I will do some testing and see if I am right.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

[tromey at gcc dot gnu dot org]

--- Comment #7 from tromey at gcc dot gnu dot org  2006-04-07 16:50 ---
Yes, we can use most of these sources, just not all of them.
I have a patch here which does it.  And we already have
stubbed declarations for most of the needed VM support.

To finish we need:

1. A script which takes the jsr166 source and strips out
everything copyright Sun (last time I did this by hand,
but we want to automate for future imports).

2. A script to change com.sun.Unsafe (or whatever it was called)
to gnu.classpath.Unsafe (a trivial sed would do).

3. We have to figure out how to handle some reflection permissions
calls in the concurrency code.  Nobody has really looked at this
yet; in my tree I have them commented out just to make it all compile.

At this point we could import, but it wouldn't work.
For it to work, VMs must implement the Unsafe API.

I can send my patch to anybody who wants it.
Perhaps I ought to upload it here... ?


-- 

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

[Bug c/27076] New: During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"

[sagar dot indalkar at ge dot com]

Hi,

I am trying to install gcc compiler 3.4.0 on Red Hat Advance Server 2.1.
Current gcc version is 3.2.2-5 which is seems to bugy as I have tried to
compile and install some other packages and was getting error messages which
denoting that it is a problem with bugy gcc compiler version which had been
shipped with Red Hat Advanced Server2.1
After that I have decided to upgrade gcc compiler version from 3.2.2-5 to
3.4.0. For upgrading I am following steps given below.
Running ../gcc-3.4.0/configure --prefix=/usr/bin/gcc-3.4.0 command from
gcc-3.4.0-build directoy.
Configuration steps is getting completed without any errors.
Then from gcc-3.4.0-build directory I am running make command which is giving
following errors as given below..

gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.4.0/libiberty/../include  -W
-Wall -Wtraditional -pedantic ../../gcc-3.4.0/libiberty/getpwd.c -o getpwd.o
../../gcc-3.4.0/libiberty/getpwd.c: In function `getpwd':
../../gcc-3.4.0/libiberty/getpwd.c:74: storage size of `dotstat' isn't known
../../gcc-3.4.0/libiberty/getpwd.c:74: storage size of `pwdstat' isn't known
../../gcc-3.4.0/libiberty/getpwd.c:78: warning: implicit declaration of
function `getenv'
../../gcc-3.4.0/libiberty/getpwd.c:78: warning: assignment makes pointer from
integer without a cast
../../gcc-3.4.0/libiberty/getpwd.c:80: warning: implicit declaration of
function `stat'
../../gcc-3.4.0/libiberty/getpwd.c:86: warning: implicit declaration of
function `getcwd'
../../gcc-3.4.0/libiberty/getpwd.c:89: warning: implicit declaration of
function `free'
../../gcc-3.4.0/libiberty/getpwd.c:74: warning: unused variable `dotstat'
../../gcc-3.4.0/libiberty/getpwd.c:74: warning: unused variable `pwdstat'
make[1]: *** [getpwd.o] Error 1
make[1]: Leaving directory `/var/build/gcc-3.4.0-build/libiberty'
make: *** [all-libiberty] Error 2

Could anybody please tell me why I am getting this error and is there any way
to overcome these types of errors. Also I am not able to go forward with next
steps as I am not able to upgrade the current gcc compiler version.

Your help is much appreciated. Thanks in advance.

Also if you need any details please let me know.

Kind Regards
Sagar


-- 
   Summary: During installation of gcc-3.4.0 compiler getting an
error "make[1]: *** [getpwd.o] Error 1"
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sagar dot indalkar at ge dot com


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

[Bug target/27075] [4.1 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-04-07 16:00 ---
g, well this is why reusing the operand is not a good idea anyways this is
a regression from when the builtins came in which was 4.1.0.

Well confirmed, a simple testcase is:

int f(int *a, int b)
{
  return __sync_fetch_and_add(a, b);
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|powerpc-unknown-linux-gnuspe|powerpc-*-linux-gnuspe
   Last reconfirmed|-00-00 00:00:00 |2006-04-07 16:00:50
   date||
Summary|Compiler generate incorrect |[4.1 Regression] Compiler
   |assembler   |generate incorrect assembler
   ||for __sync_fetch-* builtins
   ||on e500 aka SPE
   Target Milestone|--- |4.1.1


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

[Bug target/27075] Compiler generate incorrect assembler

[edmar at freescale dot com]

--- Comment #6 from edmar at freescale dot com  2006-04-07 15:54 ---
The problem is how %y is defined in rs6000.c (print_operand)


-- 


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

[Bug target/27075] Compiler generate incorrect assembler

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-04-07 15:52 ---
But I don't see anything obviously wrong in sync.md, like missing a y (aka %y1
or %y0 is used correctly).


-- 


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

[Bug target/27075] Compiler generate incorrect assembler

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-04-07 15:48 ---
hmm:
lwarx 9,0(3)

 That is definitely wrong.

It should have been "lwarx 9, 0, 3".  (This is a real compiler issue).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||assemble-failure


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

[Bug target/27075] Compiler generate incorrect assembler

[edmar at freescale dot com]

--- Comment #3 from edmar at freescale dot com  2006-04-07 15:45 ---
Created an attachment (id=11222)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11222&action=view)
Aseembler file generated by the compiler

Assembler file generated by the compiler


-- 


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

[Bug target/27075] Compiler generate incorrect assembler

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-07 15:33 ---
Can you attach the atomicity.s also?


-- 


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

[Bug c/27075] Compiler generate incorrect assembler

[edmar at freescale dot com]

--- Comment #1 from edmar at freescale dot com  2006-04-07 15:32 ---
Created an attachment (id=11221)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11221&action=view)
Intermediate file of the failing code

Intermediate file that generates the wrong syntax assembler.


-- 


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

[Bug c/27075] New: Compiler generate incorrect assembler

[edmar at freescale dot com]

I get an assembler error, when trying to build gcc for the gnuspe target.
I am using binutils-2.16.1.
I don't know when this problem started because this particular target had
other failure that was fixed last week.



/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/./gcc/cc1plus -E -quiet
-nostdinc++ -v
-I/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/powerpc-unknown-linux-gnuspe/libstdc++-v3/include/powerpc-unknown-linux-gnuspe
-I/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/powerpc-unknown-linux-gnuspe/libstdc++-v3/include
-I/local/gnu_toolchain/build_area/gcc-trunk/libstdc++-v3/libsupc++ -iprefix
/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/
-isystem /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/./gcc/include
-D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux
-D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D_GNU_SOURCE -isystem
/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/powerpc-unknown-linux-gnuspe/include
-isystem
/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/powerpc-unknown-linux-gnuspe/sys-include
atomicity.cc -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-fworking-directory -O2 -fpch-preprocess -o atomicity.ii
ignoring nonexistent directory
"/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/powerpc-unknown-linux-gnuspe/include"
ignoring nonexistent directory
"/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include"
ignoring nonexistent directory
"/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include"
ignoring nonexistent directory
"/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include"
ignoring duplicate directory
"/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include"
ignoring nonexistent directory
"/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include"
#include "..." search starts here:
#include <...> search starts here:

/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/powerpc-unknown-linux-gnuspe/libstdc++-v3/include/powerpc-unknown-linux-gnuspe

/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/powerpc-unknown-linux-gnuspe/libstdc++-v3/include
 /local/gnu_toolchain/build_area/gcc-trunk/libstdc++-v3/libsupc++
 /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/./gcc/include

/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/powerpc-unknown-linux-gnuspe/sys-include

/local/gnu_toolchain/install_area/gcc-trunk-20060406-e500v1/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include
End of search list.
 /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/./gcc/cc1plus
-fpreprocessed atomicity.ii -quiet -dumpbase atomicity.cc -auxbase-strip
atomicity.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version
-fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -o atomicity.s
GNU C++ version 4.2.0 20060406 (experimental) (powerpc-unknown-linux-gnuspe)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0094760f8b7f814b4f4ae3135eee7f99
 /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/./gcc/as -mppc -mspe
-me500 -many -V -Qy -o atomicity.o atomicity.s
GNU assembler version 2.16.1 (powerpc-unknown-linux-gnuspe) using BFD version
2.16.1
atomicity.s: Assembler messages:
atomicity.s:22: Error: syntax error; found `(' but expected `,'
atomicity.s:22: Error: junk at end of line: `(3)'
atomicity.s:24: Error: syntax error; found `(' but expected `,'
atomicity.s:24: Error: junk at end of line: `(3)'
atomicity.s:42: Error: syntax error; found `(' but expected `,'
atomicity.s:42: Error: junk at end of line: `(3)'
atomicity.s:44: Error: syntax error; found `(' but expected `,'
atomicity.s:44: Error: junk at end of line: `(3)'


-- 
   Summary: Compiler generate incorrect assembler
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edmar at freescale dot com
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnuspe


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

[Bug bootstrap/27074] Bootstrap fails on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-07 15:11 ---
File this first with gdb as it is gdb's sources which are have the warning in
it, if they say the warning is bogus, file a real bug report with the
preprocessed source.


-- 

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

internal compiler error: Segmentation fault: 11

[Mr. Chernozemsky]

cc -O -pipe -funroll-loops -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\"/usr/obj/usr/src/tmp/usr\"
-I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc
-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config
-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp
-I.  -I/usr/obj/usr/src/tmp/legacy/usr/include -c
/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/typeck.c
/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/typeck.c:
In function `build_binary_op':
/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/typeck.c:3468:
internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for
instructions.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/cc/cc1plus.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/cc.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
root: uname -a
FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD
6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec
 i386
root: gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
root: 

Best regards,
 Valentin ChernoZemsky

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

[rakdver at gcc dot gnu dot org]

--- Comment #14 from rakdver at gcc dot gnu dot org  2006-04-07 13:20 
---
(In reply to comment #11)
> I updated the patch for current mainline, but it still has issues for some
> common uses of loops:
> 
> void foo(int *ie, int *je, double *x)
> {
>   int i, j;
>   for (j=0; j<*je; ++j)
> for (i=0; i<*ie; ++i)
>   x[i+j] = 0.0;
> }
> 
> After loop header copying we have
> 
>   if (*je > 0)
> for (j=0; j<*je; ++j)
>   if (*ie > 0)
> for (i=0; i<*ie; ++i)
>   x[i+j ] = 0.0;
> 
> note how in this form we see the condition *ie > 0 not invariant wrt the
> outer loop (because it does a memory load), but if we would run load-PRE
> between loop header copying and guard hoisting we would get

actually, thinking about it again, it should suffice to teach
invariant_without_guard_p about invariant memory loads, and this should just
work.


-- 


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

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz  
2006-04-07 12:57 ---
Subject: Re:  loop header should also be pulled out of the inner loop too

> I updated the patch for current mainline, but it still has issues for some
> common uses of loops:
> 
> void foo(int *ie, int *je, double *x)
> {
>   int i, j;
>   for (j=0; j<*je; ++j)
> for (i=0; i<*ie; ++i)
>   x[i+j] = 0.0;
> }
> 
> After loop header copying we have
> 
>   if (*je > 0)
> for (j=0; j<*je; ++j)
>   if (*ie > 0)
> for (i=0; i<*ie; ++i)
>   x[i+j ] = 0.0;
> 
> note how in this form we see the condition *ie > 0 not invariant wrt the
> outer loop (because it does a memory load), but if we would run load-PRE
> between loop header copying and guard hoisting we would get
> 
>   pretmp.1 = *je;
>   if (pretmp.1 > 0)
> pretmp.2 = *ie;
> for (j=0; j   if (pretmp.2 > 0)
> for (i=0; i   x[i+j] = 0.0;
> 
> which would enable us to hoist the guard out of the outer loop.

this is somewhat problematic; it would work for 2 nested loops, but not
for 3 or more (one would need to iterate guard hoisting & invariant
motion or PRE for that).  It would be possible to integrate guard hoisting
into the loop invariant motion pass, I may give it a try.


-- 


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

[Bug bootstrap/27074] New: Bootstrap fails on i686-pc-linux-gnu

[amylaar at gcc dot gnu dot org]

See http://gcc.gnu.org/ml/gcc/2006-04/msg00055.html


-- 
   Summary: Bootstrap fails on i686-pc-linux-gnu
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/27073] invalid gcse manipulation of REG_EQUIV notes

[rsandifo at gcc dot gnu dot org]

-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-04-07 12:35:50
   date||


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

[Bug rtl-optimization/27073] New: invalid gcse manipulation of REG_EQUIV notes

[rsandifo at gcc dot gnu dot org]

arm-eabi-gcc -Os -mthumb produces wrong code for the following testcase:

 void __attribute__((noinline))
 foo (int *p, int d1, int d2, int d3,
  short count, int s1, int s2, int s3, int s4, int s5)
 {
   int n = count;
   while (n--)
 {
   *p++ = s1;
   *p++ = s2;
   *p++ = s3;
   *p++ = s4;
   *p++ = s5;
 }
 }

The important things about the testcase are:

(a) There must be a subword stack parameter P1 that we do not assume
is already promoted.  This is "count" in the testcase above.

(b) There must be later stack parameters whose pseudos do not get
allocated a hard register.

Because Thumb doesn't have subword stack loads, the sequence to set up
P1's pseudo register must first load the argument pointer into a pseudo
(let's call it PA).  The gcse local-prop pass then replaces the argument
pointer with PA in the instructions related to later stack parameters.
The problem is that gcse does this in both the instruction bodies _and_
their REG_EQUIV notes, so we get things like:

 (set (reg P2) (mem (plus (reg PA) (const_int 4
 REG_EQUIV: (mem (plus (reg PA) (const_int 4)))

The change to the insn body is almost immediately undone by CSE
(that was worthwhile, wasn't it?) but the REG_EQUIV note remains.

The change to the note is bogus though.  A REG_EQUIV note is supposed
to say that all occurences of the register could be replaced with the
equivalent expression without affecting semantics.  However, when
gcse.c:try_replace_reg replaces FROM with TO in INSN, the equivalence
between FROM and TO is a local rather than a global property.

I'm not sure the replacement would be valid even if the equivalence
were global though.  Nothing ensures (or is supposed to ensure) that
PA's lifetime is extended to cover the lifetime of P2.

I'm testing a patch now.

Richard


-- 
   Summary: invalid gcse manipulation of REG_EQUIV notes
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC target triplet: arm-eabi


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

[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2006-04-07 12:23 
---
Jeff, can you send me the patch-in-progress you have for this?  Thanks.


-- 


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

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2006-04-07 12:01 
---
So what I now have is (ahh, a PROP_loops would be so nice...)

  pass_ch
  pass_split_crit_edges
  pass_pre
  [cfg_cleanup to re-merge critical edges]
  pass_hoist_guards

which works nice for this scenario, still without an extra load-PRE pass we
have
memory loads that were only PREd out of the inner loop (due to the not hoisted
guard) inside the outer loop, even if they're now redundant.

Which makes me wonder, if PRE could do loop-header-FRE here?  Danny?  Has such
been done before?  Basically you have

do {
  if (*mem > 0)
{
  i = 0;
  do {
  } while (*mem > i);
}
} while (...);

where the (*mem > 0) is (full or partially?) redundant.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2006-04-07 11:34 
---
I updated the patch for current mainline, but it still has issues for some
common uses of loops:

void foo(int *ie, int *je, double *x)
{
  int i, j;
  for (j=0; j<*je; ++j)
for (i=0; i<*ie; ++i)
  x[i+j] = 0.0;
}

After loop header copying we have

  if (*je > 0)
for (j=0; j<*je; ++j)
  if (*ie > 0)
for (i=0; i<*ie; ++i)
  x[i+j ] = 0.0;

note how in this form we see the condition *ie > 0 not invariant wrt the
outer loop (because it does a memory load), but if we would run load-PRE
between loop header copying and guard hoisting we would get

  pretmp.1 = *je;
  if (pretmp.1 > 0)
pretmp.2 = *ie;
for (j=0; j 0)
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

[roman at kennke dot org]

--- Comment #6 from roman at kennke dot org  2006-04-07 11:11 ---
whoops sorry, I missed the first couple of lines, which hopefully means that
most of the code is indeed public domain:

The software comprising JSR166 was written by Doug Lea with assistance
from members of JCP JSR-166 Expert roup and released to the public
domain, as explained at:
http://creativecommons.org/licenses/publicdomain, excepting portions
of the class java.util.concurrent.CopyOnWriteArrayList, which were
adapted from class java.util.ArrayList, written by Sun Microsystems,
Inc, which are used with kind permission, and subject to the
following:...


-- 


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

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

[roman at kennke dot org]

--- Comment #5 from roman at kennke dot org  2006-04-07 11:08 ---
This is not really public domain:

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/readme?rev=1.1&content-type=text/vnd.viewcvs-markup

This code is covered by the nearly-but-not-exactly-free nuclear-bsd license.


-- 


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

[Bug classpath/24481] SecureRandom.setSeed has no impact

[david at jpackage dot org]

--- Comment #4 from david at jpackage dot org  2006-04-07 11:06 ---
I experienced a similar problem.

I created a new SecureRandom with

SecureRandom sr = new SecureRandom();

Then, multiple calls to

sr.nextBytes()

produced the same bytes each time.


-- 


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

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

[david at jpackage dot org]

--- Comment #4 from david at jpackage dot org  2006-04-07 10:56 ---
FYI, the JSR 166 Concurrency Utilities sources
 are in the
public domain.


-- 


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

[Bug fortran/25746] Elemental assignment gives wrong result

[paul dot richard dot thomas at cea dot fr]

--- Comment #4 from paul dot richard dot thomas at cea dot fr  2006-04-07 
10:16 ---
> Patch to fix elemental subroutine dependences.
This is still a little bit ragged insofar as it produces and excess of
temporaries and that it still gets one case wrong:

x(1:2) = x(2:3) is broken.
However, the bulk of the work is done and the submission is a few days away.  I
will add the conformance checks too.

Cheers

Paul 


-- 


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

[Bug fortran/25746] Elemental assignment gives wrong result

[paul dot richard dot thomas at cea dot fr]

--- Comment #3 from paul dot richard dot thomas at cea dot fr  2006-04-07 
10:13 ---
Created an attachment (id=11220)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11220&action=view)
Patch to fix elemental subroutine dependences.


-- 


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

[Bug tree-optimization/26919] [4.1 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2006-04-07 08:13 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/26919] [4.1 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2006-04-07 08:12 
---
Subject: Bug 26919

Author: rguenth
Date: Fri Apr  7 08:12:41 2006
New Revision: 112750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112750
Log:
2006-04-07  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/26919
* ipa-inline.c (cgraph_decide_inlining_incrementally): Fix argument
to cgraph_estimate_size_after_inlining.

* gcc.dg/ipa/ipa-1.c: Use -fno-early-inlining.
* gcc.dg/ipa/ipa-2.c: Likewise.
* gcc.dg/ipa/ipa-3.c: Likewise.
* gcc.dg/ipa/ipa-5.c: Likewise.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/ipa-inline.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ipa/ipa-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ipa/ipa-2.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ipa/ipa-3.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ipa/ipa-5.c


-- 


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

[Bug tree-optimization/26135] store copyprop not effective

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2006-04-07 08:05 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/26135] store copyprop not effective

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2006-04-07 08:04 ---
Subject: Bug 26135

Author: rguenth
Date: Fri Apr  7 08:04:26 2006
New Revision: 112749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112749
Log:
2006-04-07  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/26135
* tree-ssa-copy.c (stmt_may_generate_copy): Handle memory
loads for store copy-prop.
(copy_prop_visit_stmt): Likewise.

* gcc.dg/tree-ssa/ssa-copyprop-1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-copy.c


-- 


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