[Bug driver/30460] [4.0/4.1/4.2 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2007-11-16 07:10 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression]
   |asm_debug is not initialized|asm_debug is not initialized
   |in gcc.c when using a   |in gcc.c when using a
   |"default" specs file|"default" specs file


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

[Bug c++/34100] [4.3 regression] ICE with vector attribute

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-16 07:11 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/34100] [4.3 regression] ICE with vector attribute

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-16 07:06 ---
Subject: Bug 34100

Author: jakub
Date: Fri Nov 16 07:06:25 2007
New Revision: 130220

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130220
Log:
PR c++/34100
* pt.c (apply_late_template_attributes): Do nothing if decl's type is
error_mark_node.

* g++.dg/template/crash73.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/crash73.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2007-11-16 07:03 ---
Subject: Bug 30460

Author: jakub
Date: Fri Nov 16 07:02:49 2007
New Revision: 130219

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130219
Log:
PR driver/30460
* gcc.c (init_spec): Don't initialize asm_debug here...
(main): ... but here.

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


-- 


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[eres at il dot ibm dot com]

--- Comment #12 from eres at il dot ibm dot com  2007-11-16 06:48 ---
Created an attachment (id=14562)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14562&action=view)
gcda file


-- 


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

[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-11-16 06:23 
---
program test
 implicit none
 call sub(1)
 call sub()
contains
 subroutine sub(dimmy)
   integer, optional :: dimmy
   logical :: lotto(4)
   lotto = .false.
   lotto = cshift((/.true.,.true.,.true.,.true./),1,dimmy)
   print *, lotto
 end subroutine
end program test

After enabling the optional argument with -m32 -fdump-tree-original we get:

sub (dimmy)
{
  logical4 lotto[4];

  (void) __builtin_memset ((void *) &lotto, 0, 16);
  {
int4 * D.515;
static int4 C.514 = 1;
struct array1_logical4 parm.2;
static logical4 A.1[4] = {1, 1, 1, 1};
struct array1_logical4 parm.0;

parm.0.dtype = 273;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 4;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) &lotto[0];
parm.0.offset = -1;
parm.2.dtype = 273;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 4;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &A.1[0];
parm.2.offset = 0;
D.515 = dimmy != 0B ? dimmy : 0B;
_gfortran_cshift0_4 (&parm.0, &parm.2, &C.514, D.515);
  }
 and it works as expected.

With -m64 it obviously fails with the following:

sub (dimmy)
{
  logical4 lotto[4];

  (void) __builtin_memset ((void *) &lotto, 0, 16);
  {
int4 D.874;
static int4 C.873 = 1;
struct array1_logical4 parm.2;
static logical4 A.1[4] = {1, 1, 1, 1};
struct array1_logical4 parm.0;

parm.0.dtype = 273;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 4;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) &lotto[0];
parm.0.offset = -1;
parm.2.dtype = 273;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 4;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &A.1[0];
parm.2.offset = 0;
D.874 = *dimmy;
_gfortran_cshift0_4 (&parm.0, &parm.2, &C.873, &D.874);
  }


-- 


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

[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals

[kuba at et dot pl]

--- Comment #8 from kuba at et dot pl  2007-11-16 01:19 ---
i've tried to understand it but i can't. Can anyone explain me..
Why does coalesce_partitions (tree-ssa-coalesce.c) fail after unsuccessful
attempt_coalesce? what is the difference if it is abnormal edge, or not?


-- 


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

[Bug c/34116] New: GCC for CELL processor does NOT relocate properly with Optimization Turned on.,

[sparc64 at rediffmail dot com]

Please see the following thread in IBM's CELL BE Forum for more details:

http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=182669


-- 
   Summary: GCC for CELL processor does NOT relocate properly with
Optimization Turned on.,
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sparc64 at rediffmail dot com
 GCC build triplet: 4.1.1
  GCC host triplet:  ???
GCC target triplet: CELL BE Host running Linux


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

[Bug target/34001] Incorrect x86 fastcall behavior

[hjl at lucon dot org]

--- Comment #5 from hjl at lucon dot org  2007-11-16 04:52 ---
The correct patch is at

http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00885.html


-- 


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

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[schlie at comcast dot net]

--- Comment #7 from schlie at comcast dot net  2007-11-16 02:35 ---
Subject: Re:  Initializing string literal data
 improperly marked frame-relative?, should be readonly static const.

I believe so.


> From: manu at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 15 Nov 2007 16:19:49 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug middle-end/21018] Initializing string literal data improperly
> marked frame-relative?, should be readonly static const.
> 
> 
> 
> --- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 16:19 ---
> Is this still a valid bug?
> 
> 
> -- 
> 
> 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=21018
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-11-16 01:52 ---
(In reply to comment #3)
> Here's another example, which I think may represent a different case (and 
> which
> I found much more surprising than the first):

> no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops

No this is correct, try having n as UINT_MAX.  The conditional will always be
true.


-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

--- Comment #9 from schlie at comcast dot net  2007-11-16 02:35 ---
Subject: Re:  Small targets without 64 bit long long
 support are can't bootstrap GCC.

submitted, a long while ago; but honestly haven't been tracking things
lately.


> From: manu at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 15 Nov 2007 15:39:19 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug middle-end/20675] Small targets without 64 bit long long support
> are can't bootstrap GCC.
> 
> 
> 
> --- Comment #8 from manu at gcc dot gnu dot org  2007-11-15 15:39 ---
> What happened to this patch?
> 
> 
> -- 
> 
> 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=20675
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[rakdver at gcc dot gnu dot org]

--- Comment #6 from rakdver at gcc dot gnu dot org  2007-11-16 02:38 ---
(In reply to comment #2)
> Is there be any way to modify the code such that GCC would have an easier time
> seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
> __assert_fail is marked with noreturn I thought it might help), but that 
> didn't
> seem to have an effect.

As a workaround, you may change the type of i and rnd_to_2 to signed (signed
arithmetics in C is guaranteed not to overflow, and loop optimizer will use
this to prove that the loop is finite).


-- 


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

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[lloyd at randombit dot net]

--- Comment #5 from lloyd at randombit dot net  2007-11-16 02:00 ---
Argh, you are correct. The original code has

  unsigned int n = an_input / 160;

so this could never occur there, but GCC's inability to tell that this
assignment means that n cannot be UINT_MAX (in that code) is clearly much like
the original example. And then I simplified it enough that the loop actually
could be infinite...

Sorry for the noise.


-- 


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

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[lloyd at randombit dot net]

--- Comment #3 from lloyd at randombit dot net  2007-11-16 01:49 ---
Here's another example, which I think may represent a different case (and which
I found much more surprising than the first):

$ cat no_loop_opt2.c 

void g(unsigned int n)
   {
   unsigned int k;
   for(k = 0; k <= n; ++k)
  ;
   }
(motoko ~)$ g++-4.1.2 -O2 -Wunsafe-loop-optimizations -c no_loop_opt2.c 
no_loop_opt2.c: In function 'void g(unsigned int)':
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops

(same output with 4.2.0)

However if <= is changed to <, no problem.

Version info:

$ g++-4.1.2 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4
--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 --enable-secureplt --disable-libunwind-exceptions
--enable-multilib --enable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)

$ g++-4.2.0 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.0/configure --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.2.0
Thread model: posix
gcc version 4.2.0


-- 


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

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[j at uriah dot heep dot sax dot de]

--- Comment #6 from j at uriah dot heep dot sax dot de  2007-11-15 21:21 
---
I'm not sure whether this is related or not... but from the description, it
looks so.

avr-libc contains a macro that helps the users declaring a flash-ROM string,
lacking any real support in GCC for different memory sections (as proposed
by the Embedded C draft).  This works by using the GCC extension that a
block can return a value: a block is openened, and a block-scope static
variable is allocated, using the string literal passed in by the user.  Then,
that block returns the address of this variable to the caller.  By giving
the block-scope variable the "progmem" attribute, it will eventually be
allocated in ROM rather than RAM.

Now, if that macro is called with identical string literals within one
translation unit, the strings are allocated separately rather than merged
into a single location.

This behaviour is reproducable as well on the i386 target, so it looks like
not really related to the avr backend.

Here's a simple test case.  For simplicity, the original PSTR() macro is
just reproduced in the file rather than including the entire original
header(s).

#if defined(__AVR__)
#  define PROGMEM __attribute__((__progmem__))
#else
#  define PROGMEM /* nothing */
#endif

#define PSTR(x) \
(__extension__({static const char __c[] PROGMEM = (x); &__c[0];}))

extern void puts_P(const char *);

void
dosomething(void)
{
puts_P(PSTR("Hello world!"));
puts_P(PSTR("Hello world!"));
}

Compiling for the avr target yields:

.file   "foo.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global dosomething
.type   dosomething, @function
dosomething:
/* prologue: frame size=0 */
/* prologue end (size=0) */
ldi r24,lo8(__c.1471)
ldi r25,hi8(__c.1471)
rcall puts_P
ldi r24,lo8(__c.1473)
ldi r25,hi8(__c.1473)
rcall puts_P
/* epilogue: frame size=0 */
ret
/* epilogue end (size=1) */
/* function dosomething size 7 (6) */
.size   dosomething, .-dosomething
.section.progmem.data,"a",@progbits
.type   __c.1473, @object
.size   __c.1473, 13
__c.1473:
.string "Hello world!"
.type   __c.1471, @object
.size   __c.1471, 13
__c.1471:
.string "Hello world!"
/* File "foo.c": code7 = 0x0007 (   6), prologues   0, epilogues   1 */

Compiling the same file for the i386 target also shows two copies of the
string literal:

.file   "foo.c"
.section.rodata
.type   __c.0, @object
.size   __c.0, 13
__c.0:
.string "Hello world!"
.type   __c.1, @object
.size   __c.1, 13
__c.1:
.string "Hello world!"
.text
.globl dosomething
.type   dosomething, @function
dosomething:
pushl   %ebp
movl%esp, %ebp
pushl   $__c.0
callputs_P
movl$__c.1, (%esp)
callputs_P
leave
ret
.size   dosomething, .-dosomething
.ident  "GCC: (GNU) 3.4.4 [FreeBSD] 20050518"


-- 


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

[Bug target/34115] atomic builtins not supported on i686?

[scovich at gmail dot com]

--- Comment #6 from scovich at gmail dot com  2007-11-16 01:04 ---
(In reply to comment #5)
> Subject: Re:  atomic builtins not supported on i686?
> 
> On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com
> <[EMAIL PROTECTED]> wrote:
> > > Because the default arch for i686-linux-gnu is i386.
> > Which is a stupid inconsistency and arguably a bug.
> 
> ++
> 
> BTW, -march=i686 works beautifully. Close the bug? or rename it as a
> RFE to have i686-* default to -march=i686?
> 

Oh, and is there supposed to be a warning about unsupported atomic ops or not?
If not the docs should say to expect a linker error instead (and also
mention/link those macros Paolo pointed out).


-- 


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

[Bug target/34115] atomic builtins not supported on i686?

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-11-16 00:07 ---
Yeah, the wind is changing!


-- 


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

[Bug target/34115] atomic builtins not supported on i686?

[scovich at gmail dot com]

--- Comment #5 from scovich at gmail dot com  2007-11-16 01:00 ---
Subject: Re:  atomic builtins not supported on i686?

On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com
<[EMAIL PROTECTED]> wrote:
> > Because the default arch for i686-linux-gnu is i386.
> Which is a stupid inconsistency and arguably a bug.

++

BTW, -march=i686 works beautifully. Close the bug? or rename it as a
RFE to have i686-* default to -march=i686?


-- 


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

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[lloyd at randombit dot net]

--- Comment #2 from lloyd at randombit dot net  2007-11-16 00:50 ---
Is there be any way to modify the code such that GCC would have an easier time
seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
__assert_fail is marked with noreturn I thought it might help), but that didn't
seem to have an effect.

Short background that might be relevant: the code this is derived from is doing
partial loop unrolling (8 iterations in the actual code) with a block of inline
asm inserted, and then another loop following that handles any slop. Would
rewriting the loop as

   while(in >= 2)
  {
  in -= 2;
  i += 2;
  }

be likely to help? I see that it does with one particular version (4.1.2), but
I have no intuition if that is because the optimizer understands such loops
better or if it is just random luck.


-- 


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

[Bug target/34115] atomic builtins not supported on i686?

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2007-11-15 23:53 ---
Subject: Re:  atomic builtins not supported on i686?

On Thu, 15 Nov 2007, pinskia at gcc dot gnu dot org wrote:

> Because the default arch for i686-linux-gnu is i386.

Which is a stupid inconsistency and arguably a bug.  sparcv9-linux-gnu 
defaults to -mcpu=v9 (where -mcpu means -march for SPARC), likewise 
various other architectures; i686-linux-gnu should be consistent with 
those other targets and default to -march=i686.  libstdc++ will use 
i486-specific code if you configure GCC for i[456]86, even when GCC itself 
restricts itself to i386 code, making this default to i386 even less 
useful; likewise glibc will use i486/i586/i686 code when configured for 
those processors (and no longer supports i386).


-- 


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

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2007-11-15 23:31 ---
We may be able to propagate somehow that rnd_to_2 is always even.  I doubt it
is worth the trouble, to be honest...  Zdenek may have some thought on this.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 23:31:55
   date||


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

[Bug c++/34111] new overload resolution error

[mueller at gcc dot gnu dot org]

--- Comment #2 from mueller at gcc dot gnu dot org  2007-11-15 23:17 ---
reduced testcase:

class QChar
{
};
struct QString
{
  QString(QChar);
};
struct QPainter
{
  void drawText (int x, int y, const QString &);
};

  class KHEChar:public QChar
  {
  public:KHEChar (QChar C);
  };

void
drawByte (QPainter * P, char, KHEChar B)
{
  P->drawText (0, 0, B);
}


-- 

mueller at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 23:17:52
   date||


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

[Bug target/34115] atomic builtins not supported on i686?

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-15 22:19 ---
Because the default arch for i686-linux-gnu is i386.


-- 


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

possible bug in 4.2-20071107 snapshot

[Chris Clayton]

Hi

I've just built the 4.2-20071107 snapshot and got the folowing warning that I 
think you will want to know about. 

../../../libjava/classpath/gnu/java/security/util/Base64.java: In class 
'gnu.java.security.util.Base64':
../../../libjava/classpath/gnu/java/security/util/Base64.java: In method 
'gnu.java.security.util.Base64.decode(byte[],int,int)':
../../../libjava/classpath/gnu/java/security/util/Base64.java:200: warning: 
Unreachable statement.
for (i = off; i < off + len; i++)
   ^
1 warning

Thanks,

Chris
-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin

[Bug target/34115] atomic builtins not supported on i686?

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-11-15 22:30 ---
I think this is essentially invalid. Note that now we also have the various 
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros:

  http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html


-- 


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

[Bug c/34115] New: atomic builtins not supported on i686?

[scovich at gmail dot com]

Linking fails for the program below, with the error:

undefined reference to `___sync_val_compare_and_swap_4'

// gcc -Wall atomic.c
int main() {
  int *a, b, c;
  return __sync_val_compare_and_swap(a, b, c);
}

According to the atomic builtins docs (), "Not all operations are supported by
all target processors. If a particular operation cannot be implemented on the
target processor, a warning will be generated and a call an external function
will be generated. The external function will carry the same name as the
builtin, with an additional suffix `_n' where n is the size of the data type."

If CAS is not supported, how come I don't get a warning? Why would i686 *not*
support compare and swap? The cmpxchg instruction has been around since 80486,
according to the intel IA-32 processor manual. 

Also, does an unsupported builtin mean the user is responsible to write that
function, or simply that the compiler must make a function call to synthesize
its behavior?

FWIW, my x86_64 cross-compile gcc 4.2.0 handles it fine, emitting a
"lock"+"cmpxchg" pair.


-- 
   Summary: atomic builtins not supported on i686?
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
  GCC host triplet: i686-pc-cygwin


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2007-11-15 21:54 ---

Awesome. Looks good. 


-- 


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

[Bug c++/5310] Weird warnings about using (int)NULL

[patchapp at dberlin dot org]

--- Comment #8 from patchapp at dberlin dot org  2007-11-15 20:05 ---
Subject: Bug number PR c++/5310

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00865.html


-- 


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

[Bug middle-end/23848] [4.0/4.1/4.2/4.3 Regression] stack deallocation can be more efficient

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2007-11-15 19:03 ---
Subject: Bug 23848

Author: jakub
Date: Thu Nov 15 19:02:54 2007
New Revision: 130206

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130206
Log:
PR middle-end/23848
* tree-ssa-ccp.c (optimize_stack_restore): New function.
(execute_fold_all_builtins): Call optimize_stack_restore for
BUILT_IN_STACK_RESTORE.

* gcc.dg/tree-ssa/pr23848-1.c: New test.
* gcc.dg/tree-ssa/pr23848-2.c: New test.
* gcc.dg/tree-ssa/pr23848-3.c: New test.
* gcc.dg/tree-ssa/pr23848-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug target/11787] always call memcpy for block move in mips16

[rsandifo at gcc dot gnu dot org]

--- Comment #6 from rsandifo at gcc dot gnu dot org  2007-11-15 20:52 
---
Fixed on mainline, and not appropriate for backporting.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/34113] [4.3 Regression] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE in  |[4.3 Regression] ICE in
   |get_addr_dereference_operand|get_addr_dereference_operand
   |s, at tree-ssa- |s, at tree-ssa-
   |operands.c:1746 |operands.c:1746
   Target Milestone|--- |4.3.0


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

[Bug c/34114] New: Missed optimization: cannot determine loop termination

[lloyd at randombit dot net]

As far as I can see the loop in the function f() always terminates without the
loop counter overflowing, but GCC cannot tell that it does.

$ g++-4.3-20070907 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907
--enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt
Thread model: posix
gcc version 4.3.0 20070907 (experimental) (GCC) 

$ cat no_loop_opt.c 

void f(unsigned int in)
   {
   unsigned int rnd_to_2 = (in - (in % 2));
   unsigned int i;

   for(i = 0; i != rnd_to_2; i += 2)
  ;
   }

$ gcc-4.3-20070907 -O2 -Wall -Wextra -Wunsafe-loop-optimizations -c
no_loop_opt.c
no_loop_opt.c: In function ‘f’:
no_loop_opt.c:7: warning: cannot optimize loop, the loop counter may overflow


-- 
   Summary: Missed optimization: cannot determine loop termination
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c/34113] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

[dirtyepic at gentoo dot org]

--- Comment #2 from dirtyepic at gentoo dot org  2007-11-15 20:06 ---
Created an attachment (id=14561)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14561&action=view)
access-mini.i

further reduced.


-- 

dirtyepic at gentoo dot org changed:

   What|Removed |Added

  Attachment #14560|0   |1
is obsolete||


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

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

[simon_baldwin at yahoo dot com]

--- Comment #3 from simon_baldwin at yahoo dot com  2007-11-15 19:55 ---
The definition's really there in 4.2.1, absent in 4.1.1:

$ 4.2.1/g++ -S ns1.cc && c++filt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2007-11-15 18:14 ---
I'm finishing testing a complete patch.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c/34113] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

[dirtyepic at gentoo dot org]

--- Comment #1 from dirtyepic at gentoo dot org  2007-11-15 19:34 ---
Created an attachment (id=14560)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14560&action=view)
access-min.i

preprocessed source reduced by delta.

# gcc -v -O2 access-min.i
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.0_pre20071113/work/gcc-4.3.0-20071113/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-pre20071113
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-nls --with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-libunwind-exceptions --enable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.3.0-pre20071113  (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O2' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/cc1 -fpreprocessed
access-min.i -quiet -dumpbase access-min.i -mtune=generic -auxbase access-min
-O2 -version -o /tmp/cc45MInZ.s
GNU C (GCC) version 4.3.0-pre20071113  (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.0-pre20071113  (experimental), GMP
version 4.2.2, MPFR version 2.3.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128180
Compiler executable checksum: bdea9186cf5370f8e72d4207bcebdb8c
access-min.i:38: warning: data definition has no type or storage class
access-min.i:152: warning: 'struct stat64' declared inside parameter list
access-min.i:152: warning: its scope is only this definition or declaration,
which is probably not what you want
access-min.i:155: warning: 'struct stat64' declared inside parameter list
access-min.i:183: warning: '__transparent_union__' attribute ignored
access-min.i:320: warning: 'struct cmsghdr' declared inside parameter list
access-min.i:322: warning: 'struct cmsghdr' declared inside parameter list
access-min.i:325: warning: 'struct cmsghdr' declared inside parameter list
access-min.i:355: warning: 'struct rpcent' declared inside parameter list
access-min.i:357: warning: 'struct rpcent' declared inside parameter list
access-min.i:381: warning: 'struct protoent' declared inside parameter list
access-min.i:405: warning: parameter names (without types) in function
declaration
access-min.i:483: warning: parameter names (without types) in function
declaration
access-min.i:502: warning: parameter names (without types) in function
declaration
access-min.i: In function 'ResetHosts':
access-min.i:610: warning: assignment makes pointer from integer without a cast
access-min.i:611: warning: assignment makes pointer from integer without a cast
access-min.i: In function 'siTypeAdd':
access-min.i:736: warning: incompatible implicit declaration of built-in
function 'strlen'
access-min.i: In function 'siCheckAddr':
access-min.i:747: warning: incompatible implicit declaration of built-in
function 'strlen'
access-min.i: In function 'siHostnameAddrMatch':
access-min.i:760: warning: assignment makes pointer from integer without a cast
access-min.i: In function 'siLocalCredGetId':
access-min.i:798: warning: initialization makes pointer from integer without a
cast
access-min.i:804: warning: initialization makes pointer from integer without a
cast
access-min.i: In function 'AccessUsingXdmcp':
access-min.i:560: internal compiler error: in get_addr_dereference_operands, at
tree-ssa-operands.c:1746
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug middle-end/23848] [4.0/4.1/4.2 Regression] stack deallocation can be more efficient

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2007-11-15 19:37 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression]
   |stack deallocation can be   |stack deallocation can be
   |more efficient  |more efficient


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[pcarlini at suse dot de]

--- Comment #8 from pcarlini at suse dot de  2007-11-15 19:07 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug c/34113] New: ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746

[dirtyepic at gentoo dot org]

while compiling xorg-server-1.4 with GCC trunk rev 130172.

 x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE
-DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE
-I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I../include -I../include
-I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -O2 -g
-march=native -fomit-frame-pointer -pipe -MT access.lo -MD -MP -MF
.deps/access.Tpo -c access.c  -fPIC -DPIC -o .libs/access.o
access.c: In function 'siHostnameAddrMatch':
access.c:2115: warning: assignment from incompatible pointer type
access.c: In function 'InvalidHost':
access.c:1767: warning: 'addr' may be used uninitialized in this function
access.c: In function 'DefineSelf':
access.c:718: internal compiler error: in get_addr_dereference_operands, at
tree-ssa-operands.c:1746
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [access.lo] Error 1


# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.0_pre20071113/work/gcc-4.3.0-20071113/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-pre20071113
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-nls --with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-libunwind-exceptions --enable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.3.0-pre20071113  (experimental) (GCC)


-- 
   Summary: ICE in get_addr_dereference_operands, at tree-ssa-
operands.c:1746
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirtyepic at gentoo dot org
 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=34113

[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-15 19:25 ---
For stdcall and @n decoration, see also PR 31073.


-- 


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[paolo at gcc dot gnu dot org]

--- Comment #7 from paolo at gcc dot gnu dot org  2007-11-15 19:05 ---
Subject: Bug 34105

Author: paolo
Date: Thu Nov 15 19:05:17 2007
New Revision: 130207

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130207
Log:
2007-11-15  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/34105
* include/bits/stl_algobase.h: Do not include .
(lexicographical_compare(const unsigned char*, const unsigned char*,
const unsigned char*, const unsigned char*),
lexicographical_compare(const char*, const char*, const char*,
const char*)): Move to namespace (std, _GLIBCXX_STD_P).
* include/parallel/algobase.h: Do not include .
(equal): Move after mismatch.
* include/bits/stl_heap.h (is_heap, is_heap_until): Reorder.
* include/bits/char_traits.h: Include  instead
of .
* include/bits/stl_algo.h: Include first .
* include/bits/algorithmfwd.h (lexicographical_compare): Do not
declare overloads.
* include/parallel/partition.h: Include .
* testsuite/util/testsuite_abi.cc: Include .

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/algorithmfwd.h
trunk/libstdc++-v3/include/bits/char_traits.h
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h
trunk/libstdc++-v3/include/bits/stl_heap.h
trunk/libstdc++-v3/include/parallel/algobase.h
trunk/libstdc++-v3/include/parallel/partition.h
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc


-- 


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

[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-15 18:53 ---
I think this is already fixed in 4.3.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||wrong-code


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

[Bug bootstrap/34110] gcc fails to build on i686

[mueller at gcc dot gnu dot org]

--- Comment #1 from mueller at gcc dot gnu dot org  2007-11-15 18:21 ---
temp_stack.reg[i_90] is the access, compare_for_stack_reg is the function,
and i_90 has the VRP determined range [-1, 2147483646]. 

it shouldn't warn for that. I'll work on a patch. 


-- 

mueller at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 18:21:40
   date||


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

[Bug fortran/34112] New: Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

[burnus at gcc dot gnu dot org]

32bit Windows uses a different calling convention (called procedure pops the
stack, not caller) with a symbol name _@n, where n is the number of bytes
to pop off.

See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58
http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html

As the standard makes not provisions and !DEC$ (*DEC$, cDEC$) is widely used,
gfortran should accept the following:

  function CallWndRetProc(nCode, wParam, lParam)
  !DEC$ ATTRIBUTES STDCALL,DECORATE, ALIAS: 'CallWndRetProc' :: CallWndRetProc 
  end function

Documentation:
http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattcst.htm
http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattrib.htm

They seem to map to
(http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html):

STDCALL  ->  __attribute__(stdcall)
ALIAS->  __attribute__(alias("name"))
DECORATE -> ?

The problem with decorate is that its meaning depends on the platform. It may
decorate the "name" of alias with a "_" prefix and "@n" postfix or only with a
"_" prefix. Maybe one should start with STDCALL and ALIAS.

For alias one should do something as in c-pragma.c's apply_pragma_weak:

decl_attributes (&decl, build_tree_list (get_identifier ("alias"),
 build_tree_list (NULL, value)),
 0);


-- 
   Summary: Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug middle-end/26544] printf calls optimized at -O0

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 17:43 ---
This is either a bug or not. I think that if it is not mere constant folding
and it takes some effort, we should not do it. So let's decide so we can either
confirm it or close it as invalid.


-- 

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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2007-11-15 17:10 
---
Trivial testcase we get wrong with the current scheme:

int foo (int b, int c)
{
  int x;
  if (b)
return x & c;
  else
return 1;
}
extern void abort (void);
int main()
{
  if (foo(1, 0) != 0)
abort ();
  return 0;
}

because we say that x & c is UNDEFINED (and so ignore its value in the
otherwise CONSTANT PHI).


-- 


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

[Bug other/19180] How to Add New GCC option

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-11-15 17:40 ---
>From bug 26168:

"gcc/gcc.c has a comment at the top that's a guide to adding a command line
option.  It's incomplete: it should say to add the new option to c.opt and
rebuild the compiler, and then describe how the variable OPT_whatever gets
created by the awk scripts during the build process, so you can then check for
the option elsewhere in the compiler.  That mechanism doesn't appear documented
at all, and took me a while to figure out through code tracing.  Some
description in the comment would have been a big help.

Also, the comment at the top of the automatically-generated options.c file says
it's generated by "opts.sh" rather than by those awk scripts.  That's a minor
thing but updating it wouldn't hurt."


-- 

manu 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=19180

[Bug driver/26016] using -S on a .S file does not work properly

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 17:35 ---
This patch is just a guess but it seems to fix this:

Index: gcc/gcc.c
===
--- gcc/gcc.c   (revision 130174)
+++ gcc/gcc.c   (working copy)
@@ -841,9 +841,9 @@

 static const char *invoke_as =
 #ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT
-"%{!S:-o %|.s |\n as %(asm_options) %|.s %A }";
+"%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n as %(asm_options) %|.s %A }";
 #else
-"%{!S:-o %|.s |\n as %(asm_options) %m.s %A }";
+"%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n as %(asm_options) %m.s %A }";
 #endif

 /* Some compilers have limits on line lengths, and the multilib_select
@@ -1029,12 +1029,12 @@
 #ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT
"%(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\
   %{E|M|MM:%(cpp_debug_options)}\
-  %{!M:%{!MM:%{!E:%{!S:-o %|.s |\n\
+  %{!M:%{!MM:%{!E:%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n\
as %(asm_debug) %(asm_options) %|.s %A "
 #else
"%(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\
   %{E|M|MM:%(cpp_debug_options)}\
-  %{!M:%{!MM:%{!E:%{!S:-o %|.s |\n\
+  %{!M:%{!MM:%{!E:%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n\
as %(asm_debug) %(asm_options) %m.s %A "
 #endif
, 0, 1, 0},


-- 


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

[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2007-11-15 15:10 ---
Subject: Bug number PR34079

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00851.html


-- 


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

[Bug c++/34111] new oveload resolution error

[mueller at gcc dot gnu dot org]

--- Comment #1 from mueller at gcc dot gnu dot org  2007-11-15 16:55 ---
Created an attachment (id=14559)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14559&action=view)
the preprocessed source

.ii file


-- 


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

[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2007-11-15 17:42 ---
Testing a patch which addresses the simple pointer va_list targets (i386,
non-v4-abi ppc{,64}, etc.).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-07-05 09:23:01 |2007-11-15 17:42:02
   date||


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

[Bug driver/26168] improve comment about adding command line options

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 17:41 ---


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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug other/19180] How to Add New GCC option

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 17:41 ---
*** Bug 26168 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||phr-gcc at nightsong dot com


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

[Bug fortran/34108] ICE: Segmentation fault occurs by "write(*,0)" statement

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-15 16:40 
---
Confirmed on x86_64-linux, where it triggers (with valgrind):

==2841== Conditional jump or move depends on uninitialised value(s)
==2841==at 0x43550B: next_char (io.c:141)
==2841==by 0x435616: next_char_not_space (io.c:183)
==2841==by 0x4356C1: format_lex (io.c:221)
==2841==by 0x435A5D: check_format (io.c:467)
==2841==by 0x4369B5: match_io (io.c:927)
==2841==by 0x44D8A9: match_word (parse.c:64)
==2841==by 0x44E078: decode_statement (parse.c:296)
==2841==by 0x44EA84: next_statement (parse.c:505)
==2841==by 0x451EC4: gfc_parse_file (parse.c:3320)
==2841==by 0x479B64: gfc_be_parse_file (f95-lang.c:258)
==2841==by 0x6E901C: toplev_main (toplev.c:1042)
==2841==by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |
   Keywords||ice-on-invalid-code
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 16:40:54
   date||


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2007-11-15 17:17 
---
I think this has been caused by the fix for PR29738.

Author: rakdver
Date: Thu Nov  9 00:09:43 2006
New Revision: 118602

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118602
Log:
PR tree-optimization/29738
* tree-ssa-ccp.c: Remove UNKNOWN_VAL from comments.
(ccp_lattice_t): Remove UNKNOWN_VAL.
(dump_lattice_value, ccp_lattice_meet, ccp_visit_phi_node):
Do not handle UNKNOWN_VAL.
(get_default_value): Set initial value of virtual operands to
VARYING.
(get_value): Always use get_default_value on uninitialized
operands.
(set_value_varying, surely_varying_stmt_p): New functions.
(set_lattice_value): Do not pass argument to get_value.
Do not handle UNKNOWN_VAL.
(likely_value): Follow the semantics described in the comment.
(ccp_initialize): Use surely_varying_stmt_p.  Do not mark
phi nodes DONT_SIMULATE_AGAIN.
(ccp_fold): Do not pass argument to get_value.
(fold_const_aggregate_ref, visit_assignment): Ditto.  Do not
handle UNKNOWN_VAL.

* gcc.dg/tree-ssa/ssa-ccp-14.c: New test.
* gcc.dg/tree-ssa/ssa-ccp-15.c: New test.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||29738
  nThis||


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

[Bug driver/26016] using -S on a .S file does not work properly

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2007-11-15 17:16 ---
Confirmed. Probably some issue with the default specs.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 17:16:06
   date||


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

[BUG] GCC 4.1 bug - Optimization breaks variables of type double

[Le Thanh Trung]

Hi,

When I compile my program without optimization (-O2 or -O3), it works
normally. However when I compile the code with -O2 or -O3 (GCC version
4.1), my program output wrong data. In addition, I did not see this
problem when I used GCC 3.4.6.

Information regarding my GCC:
OS: Centos 5  (a clone of Redhat Enterprise 5)
GCC: 4.1.1 20070105 (Red Hat 4.1.1-52)

Command:
   gcc -g -Wall gensvmparams.c -lm -o gensvmparams
   gcc -g -Wall -O2 gensvmparams -c -lm -o gensvmparams
   
My code:
#include 
#include 
#include 

int main()
{
  double g = pow(2, -7);
  double c = 2;
  double cc = 1;
  double gg = -7;
  double cMax;
  cMax = pow(2,5);
  cMax = cMax + 0.01;
  double gMax;
  gMax = pow(2,-3);
  gMax = gMax + 0.01;

  while (c < cMax)  //gcc -O2 change the cMax to something different
than 32
  {
gg = -7;
g = pow(2, -7);
while (g < gMax)
{
  printf("5 %lf %lf\n", c, g);
  gg = gg + 0.25; 
  g = pow(2, gg);
}
cc = cc + 0.25;
c = pow(2, cc);
  }
  return 0;
}

P.S: When I add "volatile" to the declaration of cMax and gMax, my
program works correctly for all cases.

Thanks,
Regards,
Le Thanh Trung

[Bug c++/21603] C++ front-end accepts "new" with VLAs

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 17:05 ---
This is confirmed.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 17:05:28
   date||


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

[Bug c++/21361] sizeof() packed structs potential errors

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2007-11-15 16:45 ---
Closing then.

(The link you gave is broken. A more stable link is
 http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html
)


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/21474] missed optimizations when comparing address to NULL

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2007-11-15 17:03 ---
I think it is odd that if you call subr(i,0), it doesn't crash, that is &(p->a)
does not actually dereferences p. Nonetheless, I agree that the behaviour seems
inconsistent. A nice little project for someone. As they say, patches welcome!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 17:03:30
   date||


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

[Bug c++/34111] New: new oveload resolution error

[mueller at gcc dot gnu dot org]

this used to work a few days ago still:


-- 
   Summary: new oveload resolution error
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org


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

[Bug c++/21393] Internal error: Segmentation Fault (program cc1plus) on a very long cout << ... << command

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2007-11-15 16:39 ---
It also works in GCC 4.3.0. 

If you still experience this issue, please, don't hesitate to reopen the bug.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2007-11-15 16:38 
---
Oh, trivial error.  Looking again tomorrow.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-15 15:40:13 |2007-11-15 16:38:30
   date||


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

[Bug c++/21146] unable to resolve visible symbol

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-11-15 16:30 ---
So, is this a bug or not? Do we know how icc resolves the ambiguity?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Keywords||diagnostic


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

[Bug bootstrap/34110] New: gcc fails to build on i686

[us15 at os dot inf dot tu-dresden dot de]

SVN head does not build due to a warning that is treated as error.

gcc.build.lnx/./prev-gcc/xgcc
-B/gcc-b98ac6987827a195a1492167a9a158bf/gcc.build.lnx/./prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -c   -g -O2 -fomit-frame-pointer -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror-DHAVE_CONFIG_H -I. -I.
-I../../gcc-svn/gcc -I../../gcc-svn/gcc/. -I../../gcc-svn/gcc/../include
-I../../gcc-svn/gcc/../libcpp/include  -I../../gcc-svn/gcc/../libdecnumber
-I../../gcc-svn/gcc/../libdecnumber/bid -I../libdecnumber   
../../gcc-svn/gcc/regclass.c -o regclass.o
cc1: warnings being treated as errors
../../gcc-svn/gcc/reg-stack.c: In function 'swap_to_top':
cc1: error: array subscript is below array bounds
make[3]: *** [reg-stack.o] Error 1


-- 
   Summary: gcc fails to build on i686
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: us15 at os dot inf dot tu-dresden dot de
 GCC build triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2007-11-15 16:19 ---
Is this still a valid bug?


-- 

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

[Bug c/34109] New: Incorrect code for tail calls with a structure as 4th argument

[narge-gcc at derrin dot id dot au]

In the following code, the tail call in g() is compiled incorrectly on ARM with
-O2 or higher (and -fno-inline):

#include 

struct s {
int x, y, z;
};

int f(int a, int b, int c, struct s d, int e) {
printf("%d %d %d\n", d.x, d.y, d.z);
return 0;
}

int g(int a, int b, int c, int d, struct s e, int h) {
return f(a, b, c, e, h);
}

int main(void) {
f(0, 0, 0, (struct s){ 42, 69, 105 }, 7);
g(0, 0, 0, 0, (struct s){ 42, 69, 105 }, 7);
return 0;
}

With -O1 and lower, the result is correct:

42 69 105
42 69 105

With -O2 and higher, it prints:

42 69 105
69 69 7

Inspecting the output of gcc -O3 -fno-inline -S shows that gcc is shifting the
arguments on the stack downwards for the tail call. However, it starts at the
top, rather than at the bottom. So it writes over two arguments (e.z and e.x)
before loading them.

This has been broken since 4.1.1 (possibly earlier), and is still broken in
4.2.2.


-- 
   Summary: Incorrect code for tail calls with a structure as 4th
argument
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: narge-gcc at derrin dot id dot au
GCC target triplet: arm-elf


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-11-15 15:44 
---
> That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
> constraint that if one operand is UNDEFINED the result is UNDEFINED as well.

Is the problem somehow related to PR middle-end/33088?


-- 


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

[Bug fortran/33917] Rejects valid PROCEDURE declarations

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2007-11-15 15:12 ---
Subject: Bug 33917

Author: burnus
Date: Thu Nov 15 15:12:03 2007
New Revision: 130202

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

PR fortran/33917
* decl.c (match_procedure_decl): Pre-resolve interface.
* resolve.c (resolve_symbol): Reject interfaces later
declared in procedure statements.

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

PR fortran/33917
* gfortran.dg/proc_decl_11.f90: New.


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


-- 


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2007-11-15 16:08 
---
Created an attachment (id=14558)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14558&action=view)
new broken patch

Err, that was an old patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #14557|0   |1
is obsolete||


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2007-11-15 16:06 ---
Created an attachment (id=14557)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14557&action=view)
broken patch

It miscompiles gengtype.  I remember problems with changing likely_value in
similar ways back in time.  The other option is to not ignore UNDEFINED lattice
values in ccp_lattice_meet but do

any  M UNDEFINED   = VARYING

instead of

any  M UNDEFINED   = any


-- 


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2007-11-15 16:04 ---
Which doesn't work :(  Unassigning.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[eres at il dot ibm dot com]

--- Comment #10 from eres at il dot ibm dot com  2007-11-15 15:02 ---
(In reply to comment #9)
> I mean the files you generate with -fprofile-generate.
> I expect this to be fully blamable on the partitioning code, and I would like
> to work in fixing this.  But you have to attach the profile information you
> have generated, or no-one can debug this unless he/she has access to POWER.

Sure, I'll attached the gcno file.
Please let me know if you need more information to retore the ICE.

Thanks


-- 


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

[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-15 15:53 ---
I cannot reproduce this problem with any of 4.1, 4.2 or 4.3.  But the issues
raised look related the CCP problem in PR34099.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-11-15 14:57 
---
There is a good chance that if you try to build the runtime library with
malign-double that you will break it.  My recommendation is don't use
-malign-double for I/O related things.


-- 


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2007-11-15 15:51 ---
Subject: Re:  [4.3 Regression] optimizer problem

On Thu, 15 Nov 2007, ebotcazou at gcc dot gnu dot org wrote:

> --- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-11-15 15:44 
> ---
> > That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
> > constraint that if one operand is UNDEFINED the result is UNDEFINED as well.
> 
> Is the problem somehow related to PR middle-end/33088?

It looks like so, but I cannot reproduce the problem in PR33088.

Richard.


-- 


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2007-11-15 15:40 ---
That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
constraint that if one operand is UNDEFINED the result is UNDEFINED as well.

For example MIN_EXPR , or MAX_EXPR 
are of such kind as well.  No idea if we want a white-list here instead.
BIT_AND_EXPR  is also not UNDEFINED.

(all of the above not with actual constants as defined arg, but VARYING ones)

I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-15 10:21:31 |2007-11-15 15:40:13
   date||


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

[Bug fortran/33917] Rejects valid PROCEDURE declarations

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2007-11-15 15:18 ---
FIXED on the trunk (4.3.0) [is not part of any branch].


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  GCC build triplet|x86_64-unknown-linux-gnu|
 Resolution||FIXED


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2007-11-15 15:39 ---
What happened to this patch?


-- 

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

[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-11-15 15:10 ---
See also:
  http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html
and for the patch:
  http://gcc.gnu.org/ml/fortran/2007-11/msg00093.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-15 15:10:33
   date||


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

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

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2007-11-15 15:19 ---
(In reply to comment #4)
> (In reply to comment #3)
> Bother, the patch causes some regressions (interface_[3-5].f90)...
> Paul

These were easily fixed - also nested_modules_1.f90 was not standard compliant
in this regard.  It now regtests with find_symbol modified to:

  c = strcmp (name, st->n.sym->name);
  if (c == 0 && st->n.sym->module
&& strcmp (module, st->n.sym->module) == 0)
return st;

Off to generics and operators now!

Paul


-- 


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-15 15:08 ---
This looks like this old bug that evaluate_stmt() sets results to UNDEFINED. 
As
we visit

D.26933_16 = __t_14 * D.26932_15;

the result should become VARYING, but we make it UNDEFINED.  Because also
likely_value () returns UNDEFINED for it.  Because in the process of setting
__t we use undefined operands (but those get overwritten).

  D.26929_10 = IMAGPART_EXPR <__t_6(D)>;
  __t_11 = COMPLEX_EXPR ;
  D.26931_13 = REALPART_EXPR <__t_11>;
  __t_14 = COMPLEX_EXPR ;
  D.26932_15 = COMPLEX_EXPR ;
  D.26933_16 = __t_14 * D.26932_15;

so at least

  has_constant_operand = false;
  FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE | SSA_OP_VUSE)
{
  prop_value_t *val = get_value (use);

  if (val->lattice_val == UNDEFINED)
return UNDEFINED; 

  if (val->lattice_val == CONSTANT)
has_constant_operand = true;
}

doesn't look conservatively correct, because we pro-actively prefer UNDEFINED
here.


-- 


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[eres at il dot ibm dot com]

--- Comment #11 from eres at il dot ibm dot com  2007-11-15 15:05 ---
Created an attachment (id=14556)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14556&action=view)
File generated by -fprofile-generate


-- 


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

[Bug tree-optimization/34099] [4.3 Regression] optimizer problem

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-11-15 14:56 ---
Uhm, this goes wrong in CCP.  (w/o SRA the failure doesn't trigger though)

Before CCP we have:

void multiply(NumType, NumType, unsigned int, NumType&) (a, b, ac, ab)
{ 
  double s$_M_value$real;
  double s$_M_value$imag;
  double b$_M_value$real;
  double b$_M_value$imag;
  double a$_M_value$imag;
  double a$_M_value$real;
  complex double __t;
  complex double D.26933;
  complex double D.26932;
  double D.26931;
  double D.26929;
  unsigned int j;

:
  # VUSE 
  a$_M_value$real_21 = REALPART_EXPR ;
  # VUSE 
  a$_M_value$imag_22 = IMAGPART_EXPR ;
  # VUSE 
  b$_M_value$imag_23 = IMAGPART_EXPR ;
  # VUSE 
  b$_M_value$real_24 = REALPART_EXPR ;
  s$_M_value$real_25 = 0.0;
  s$_M_value$imag_26 = 0.0;
  goto ;

:
  D.26929_10 = IMAGPART_EXPR <__t_6(D)>;
  __t_11 = COMPLEX_EXPR ;
  D.26931_13 = REALPART_EXPR <__t_11>;
  __t_14 = COMPLEX_EXPR ;
  D.26932_15 = COMPLEX_EXPR ;
  D.26933_16 = __t_14 * D.26932_15;
  s$_M_value$imag_17 = IMAGPART_EXPR ;
  s$_M_value$real_18 = REALPART_EXPR ;
  j_4 = j_1 + 1;

:
  # s$_M_value$real_20 = PHI 
  # s$_M_value$imag_19 = PHI 
  # j_1 = PHI <0(2), j_4(3)>
  if (j_1 < ac_3(D))
goto ;
  else
goto ;

:
  # SMT.98_38 = VDEF 
  IMAGPART_EXPR _M_value> = s$_M_value$imag_19;
  # SMT.98_39 = VDEF 
  REALPART_EXPR _M_value> = s$_M_value$real_20;
  return;

} 

where I can see nothing wrong.  Now CCP propagates s$_M_value$real_25 and
s$_M_value$imag_26 into the PHI nodes, but somehow does not simulate BB3:

Visiting PHI node: s$_M_value$real_20 = PHI 
Argument #0 (2 -> 4 executable)
s$_M_value$real_25  Value: CONSTANT 0.0

Argument #1 (3 -> 4 executable)
s$_M_value$real_18  Value: UNDEFINED

PHI node value: CONSTANT 0.0


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at google dot com


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2007-11-15 14:49 ---
I mean the files you generate with -fprofile-generate.

I expect this to be fully blamable on the partitioning code, and I would like
to work in fixing this.  But you have to attach the profile information you
have generated, or no-one can debug this unless he/she has access to POWER.


-- 


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-11-15 13:04 ---
Created an attachment (id=14555)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14555&action=view)
Draft patch for normal mode


-- 


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[eres at il dot ibm dot com]

--- Comment #8 from eres at il dot ibm dot com  2007-11-15 14:17 ---
When disabling rest_of_handle_reorder_blocks (bbro) the ICE disappears. (it
seems that it is not caused due to the partitioning - bbpart)


-- 


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

[Bug java/21206] gcj seems not to pass the option to ld correctly

[tom_francen at midtechcorp dot com]

--- Comment #18 from tom_francen at midtechcorp dot com  2007-11-15 13:46 
---
Subject: Re:  gcj seems not to pass the option to ld correctly


thank you wilson ... i just tried suggestion #6 ... and it WORKED!!  thank you
very much!!

tjf
---
Thomas James Francen
Midwest Technologies Corporation
http://www.midtechcorp.com - website

+1.303.898.6300 - Cell / Voicemail
+1.610.887.5155 - Fax

--- [EMAIL PROTECTED] wrote:

From: "wilson at tuliptree dot org" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Bug java/21206] gcj seems not to pass the option to ld correctly
Date: 14 Nov 2007 23:46:07 -



--- Comment #17 from wilson at tuliptree dot org  2007-11-14 23:46 ---
Subject: Re:  gcj seems not to pass the option to ld
correctly

On Wed, 2007-11-14 at 23:16 +, tom_francen at midtechcorp dot com
wrote:
> i'm receiving a very similar error under solaris 2.10, binutils and core utils
> (latest versions), gnu make, etc.  gcc 4.1.2 built fine ... gcc 4.2.1 and 
> 4.2.2
> fail with the same error below ... 

You can try the workaround I gave in comment #6.

Jim


-- 


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

[Bug c++/34104] auto_ptr error catching

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-11-15 13:32 ---
intptr is not initialized: when i is destructed it calls delete on the owned
pointer, that is intptr, and anything can happen. Just initialize intptr to
zero or to a value returned by new.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-11-15 13:09 ---
By the way, while we are talking about those QoI issues, I think it's in any
case better not including something like algorithmfwd.h in algobase.h: it's
relatively big and we are doing our best to keep algobase.h, the core
algorithmic facilities optimized for internal use, as minimal as possible.


-- 


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-11-15 13:06 ---
Something like the attached (lightly tested) fixed the problem for normal mode,
the error becomes:

34105.cc: In function ‘int main()’:
34105.cc:8: error: ‘find’ is not a member of ‘std’

however, it doesn't for parallel mode. I think it's better if Benjamin looks
into those headers...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-15 11:26 ---
-malign-double changes the ABI.  You need to rebuild libgfortran with that
option.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2007-11-15 13:10 ---
I meant bits/stl_algobase.h, of course.


-- 


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

[Bug fortran/33917] Rejects valid PROCEDURE declarations

[patchapp at dberlin dot org]

--- Comment #9 from patchapp at dberlin dot org  2007-11-15 12:35 ---
Subject: Bug number PR33917

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00842.html


-- 


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[eres at il dot ibm dot com]

--- Comment #7 from eres at il dot ibm dot com  2007-11-15 12:29 ---
(In reply to comment #6)
> I can't reproduce this on x86*.
> Again, please attach the profile information and state the exact compiler
> revision you used to generate this profile information.


Sorry - I am working on r129702.
What do you mean by profile information (a dump file)?

Thanks.


-- 


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

[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2007-11-15 10:54 ---
Jens,

I cannot reproduce this bug, even with the same flags that you are using, under
Cygwin_NT and last night's build.  I will check on a Linux system tonight.

I have downrated the severity because "critical" refers to bugs that prevent
the gcc build.  I assure you that the gfortran maintainers will take the report
just as seriously.

Thanks for the report

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
   Severity|critical|normal


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

[Bug fortran/34108] New: ICE: Segmentation fault occurs by "write(*,0)" statement

[fujimura at giga dot it dot okayama-u dot ac dot jp]

I use gfortran on cygwin.

% wget
http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.3-Cygwin-i686.tar.bz2
% tar fjx gfortran-4.3-Cygwin-i686.tar.bz2 -C /


I get a segmentation fault when compiling program contains a simple write
statement.

% cat zerolabel.f95
write(*,0)

% /usr/local/gfortran/bin/gfortran.exe -v zerolabel.f95
Driving: /usr/local/gfortran/bin/gfortran -v zerolabel.f95 -lgfortranbegin
-lgfortran
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 : (reconfigured)
../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 20071005 (experimental) [trunk revision 127783] (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
 /usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.3.0/f951.exe zerolabel.f95
-quiet -dumpbase zerolabel.f95 -mtune=generic -auxbase zerolabel -version
-fintrinsic-modules-path
/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.3.0/finclude -o /tmp/ccbbRPye.s
GNU F95 (GCC) version 4.3.0 20071005 (experimental) [trunk revision 127783]
(i686-pc-cygwin)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125), GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
zerolabel.f95:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE: Segmentation fault occurs by "write(*,0)" statement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fujimura at giga dot it dot okayama-u dot ac dot jp
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[eres at il dot ibm dot com]

--- Comment #5 from eres at il dot ibm dot com  2007-11-15 12:04 ---
It seems that verify_flow_info complains about the following note,
which is generated in the partitioning phase:

(note 234 232 172 11 NOTE_INSN_SWITCH_TEXT_SECTIONS)


-- 


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2007-11-15 12:21 ---
I can't reproduce this on x86*.
Again, please attach the profile information and state the exact compiler
revision you used to generate this profile information.


-- 


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