[Bug target/52495] rs6000.c fails to (cross-) build: "implicit declaration of function ‘ASM_WEAKEN_DECL’"

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2012-08-17 01:13:29 
UTC ---
I also run into this.  The bug is in rs6000.h:

#ifdef HAVE_GAS_WEAK
#define RS6000_WEAK 1
#else
#define RS6000_WEAK 0
#endif

#if RS6000_WEAK
/* Used in lieu of ASM_WEAKEN_LABEL.  */
#define ASM_WEAKEN_DECL(FILE, DECL, NAME, VAL)  \
  do\
{   \
  fputs ("\t.weak\t", (FILE));  \
  RS6000_OUTPUT_BASENAME ((FILE), (NAME));  \
  if ((DECL) && TREE_CODE (DECL) == FUNCTION_DECL   \
  && DEFAULT_ABI == ABI_AIX && DOT_SYMBOLS) \
{   \
  if (TARGET_XCOFF) 

..


ASM_WEAKEN_DECL is used unconditionally.

[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Hans-Peter Nilsson  2012-08-17 
00:19:57 UTC ---
fixed for 4.8

[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  2012-08-17 
00:18:42 UTC ---
Author: hp
Date: Fri Aug 17 00:18:35 2012
New Revision: 190463

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190463
Log:
PR middle-end/54261
* optabs.c (expand_atomic_fetch_op): Save and restore code when
retrying after failed attempt.

Modified:
trunk/gcc/optabs.c

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  2012-08-17 
00:03:17 UTC ---
(In reply to comment #13)
> I disagree: 
> I know enough to use strcat and strcpy.

That's provably false.

> 1: Why those functions work false and are dependent on variables(! I name it
> correct even if it is one dimenision array of chararters) declare order I 
> don't
> know.
> 
> 2: on this site there are enough people with very vary C and C++ language
> skills, so this sites helps on learning also. I know too much people who
> learner more from wrong experiences rather than from clear imagination.

No, this is not the place to learn how to fix your code, we have better things
to do. Please find a different site.

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||steven at gcc dot gnu.org

--- Comment #2 from Uros Bizjak  2012-08-16 23:25:30 
UTC ---
Adding come CCs that might be interested in this issue.

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

--- Comment #1 from Uros Bizjak  2012-08-16 23:23:39 
UTC ---
Created attachment 28040
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28040
Preprocessed source of the object file that triggers comparison failure

~/gcc-build/stage1-gcc/xgcc -B ~/gcc-build/stage1-gcc -O2 -fno-exceptions
-fno-rtti -fno-common -fcompare-debug cprop.ii
xgcc: error: cprop.ii: -fcompare-debug failure (length)

[Bug rtl-optimization/54294] New: [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

 Bug #: 54294
   Summary: [4.8 Regression]: [alpha] Bootstrap comparison failure
due to fwprop handling of debug insns
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Target: alphaev68-unknown-linux-gnu


Alpha bootstrap is currently broken due to stage2/3 comparison failure.

The problem is in handling of debug instructions in fwprop1 pass.

Please compare following non-debug compilation, where we start from
_.ii.156r.cse1 pass:

(note 3642 3637 3643 423 [bb 423] NOTE_INSN_BASIC_BLOCK)
(insn 3643 3642 3644 423 (set (reg:DI 1212 [ ei ])
(sign_extend:DI (subreg:SI (reg:DI 1212 [ ei ]) 0))) 2 {*extendsidi2_1}
 (nil))
(insn 3644 3643 3728 423 (set (reg:DI 1263 [ ivtmp.371 ])
(sign_extend:DI (subreg:SI (reg:DI 1212 [ ei ]) 0))) 2 {*extendsidi2_1}
 (nil))

And in _.ii.157.fwprop1, operands got propagated to:

(note 3642 3637 3643 423 [bb 423] NOTE_INSN_BASIC_BLOCK)
(insn 3643 3642 3644 423 (set (reg:DI 1212 [ ei ])
(sign_extend:DI (reg:SI 2385))) 2 {*extendsidi2_1}
 (nil))
(insn 3644 3643 3728 423 (set (reg:DI 1263 [ ivtmp.371 ])
(sign_extend:DI (reg:SI 2385))) 2 {*extendsidi2_1}
 (nil))


The difference in debug compilation can be shown starting again from
_.ii.156r.cse1 pass:

(note 4153 4148 4154 423 [bb 423] NOTE_INSN_BASIC_BLOCK)
(insn 4154 4153 4155 423 (set (reg:DI 1212 [ ei ])
(sign_extend:DI (subreg:SI (reg:DI 1212 [ ei ]) 0))) 2 {*extendsidi2_1}
 (nil))
(debug_insn 4155 4154 4157 423 (var_location:SI ei (subreg:SI (reg:DI 1212 [ ei
]) 0)) -1
 (nil))
(debug_insn 4157 4155 4158 423 (var_location:BLK D#9 (clobber (const_int 0
[0]))) ../../gcc-svn/trunk/gcc/cprop.c:1519 -1
 (nil))
(debug_insn 4158 4157 4159 423 (var_location:DI p (debug_implicit_ptr:DI e))
../../gcc-svn/trunk/gcc/cprop.c:1519 -1
 (nil))
(debug_insn 4159 4158 4160 423 (var_location:SI ei (subreg:SI (reg:DI 1212 [ ei
]) 0)) -1
 (nil))
(debug_insn 4160 4159 4162 423 (var_location:DI ei$8 (debug_expr:DI D#34)) -1
 (nil))
(debug_insn 4162 4160 4163 423 (var_location:BLK D#7 (clobber (const_int 0
[0]))) ../../gcc-svn/trunk/gcc/basic-block.h:636 -1
 (nil))
(debug_insn 4163 4162 4164 423 (var_location:DI i$container (debug_expr:DI
D#34)) -1
 (nil))
(debug_insn 4164 4163 4165 423 (var_location:DI vec_ (clobber (const_int 0
[0]))) ../../gcc-svn/trunk/gcc/basic-block.h:586 -1
 (nil))
(insn 4165 4164 4249 423 (set (reg:DI 1263 [ ivtmp.371 ])
(sign_extend:DI (subreg:SI (reg:DI 1212 [ ei ]) 0))) 2 {*extendsidi2_1}
 (nil))

where _.ii.157.fwprop1 pass propagates only operands before the clobber,
resulting in:

(note 4153 4148 4154 423 [bb 423] NOTE_INSN_BASIC_BLOCK)
(insn 4154 4153 4155 423 (set (reg:DI 1212 [ ei ])
(sign_extend:DI (reg:SI 2385))) 2 {*extendsidi2_1}
 (nil))
(debug_insn 4155 4154 4157 423 (var_location:SI ei (reg:SI 2385)) -1
 (nil))
(debug_insn 4157 4155 4158 423 (var_location:BLK D#9 (clobber (const_int 0
[0]))) ../../gcc-svn/trunk/gcc/cprop.c:1519 -1
 (nil))
(debug_insn 4158 4157 4159 423 (var_location:DI p (debug_implicit_ptr:DI e))
../../gcc-svn/trunk/gcc/cprop.c:1519 -1
 (nil))
(debug_insn 4159 4158 4160 423 (var_location:SI ei (subreg:SI (reg:DI 1212 [ ei
]) 0)) -1
 (nil))
(debug_insn 4160 4159 4162 423 (var_location:DI ei$8 (debug_expr:DI D#34)) -1
 (nil))
(debug_insn 4162 4160 4163 423 (var_location:BLK D#7 (clobber (const_int 0
[0]))) ../../gcc-svn/trunk/gcc/basic-block.h:636 -1
 (nil))
(debug_insn 4163 4162 4164 423 (var_location:DI i$container (debug_expr:DI
D#34)) -1
 (nil))
(debug_insn 4164 4163 4165 423 (var_location:DI vec_ (clobber (const_int 0
[0]))) ../../gcc-svn/trunk/gcc/basic-block.h:586 -1
 (nil))
(insn 4165 4164 4249 423 (set (reg:DI 1263 [ ivtmp.371 ])
(sign_extend:DI (subreg:SI (reg:DI 1212 [ ei ]) 0))) 2 {*extendsidi2_1}
 (nil))

This introduces real difference in (insn 4165) of the debug compilation vs
(insn 3644) of the non-debug compilation. Things go down from there, the final
difference is (non-debug):

(insn:TI 3643 2534 3644 (set (reg:DI 2 $2 [orig:1212 ei ] [1212])
(sign_extend:DI (plus:SI (reg:SI 4 $4 [orig:1263 ivtmp.371 ] [1263])
(const_int 1 [0x1] 4 {*addsi_se}
 (expr_list:REG_DEAD (reg:SI 4 $4 [orig:1263 ivtmp.371 ] [1263])
(nil)))
(insn:TI 3644 3643 6425 (set (reg:DI 4 $4 [orig:1263 ivtmp.371 ] [1263])
(reg:DI 2 $2 [orig:1212 ei ] [1212])) 236 {*movdi}
 (nil))

versus debug compilation:

(note 8075 2865 8076 (var_location i (debug_implicit_ptr:DI ei))
NOTE_INSN_VAR_LOCATION)
(note 8076 8075 4154 (var_location i$container (reg/v/f:DI

[Bug target/54236] [SH] Improve addc and subc insn utilization

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  2012-08-16 23:19:51 
UTC ---
Author: olegendo
Date: Thu Aug 16 23:19:45 2012
New Revision: 190459

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190459
Log:
PR target/54236
* config/sh/sh.md (addc): Add commutative modifier.
(*addc, *minus_plus_one, *subc, *negc): New insns and splits.

PR target/54236
* gcc.target/sh/pr54236-1.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr54236-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[olegendo at gcc dot gnu.org]

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

--- Comment #32 from Oleg Endo  2012-08-16 
23:16:57 UTC ---
Author: olegendo
Date: Thu Aug 16 23:16:53 2012
New Revision: 190458

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190458
Log:
PR target/39423
* config/sh/sh.md (*movsi_index_disp, *movhi_index_disp): Handle
potential T_REG clobber.  Convert zero extending split to
insn_and_split.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug target/52495] rs6000.c fails to (cross-) build: "implicit declaration of function ‘ASM_WEAKEN_DECL’"

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-16
 CC||meissner at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Michael Meissner  2012-08-16 
23:14:17 UTC ---
If the configure scripts think the cross assembler does not support .weak
symbols, the compiler will fail because it does not define ASM_WEAKEN_DECL. 
Note, when I tried this on August 16th, 2012, the current head of binutils
seems broken (the archiver segfaults), but the 2_21 branch builds it fine on my
Linux system with a target of powerpc64-linux and additional targets of
powerpc-linux.  Obviously the compiler should do something more appropriate if
the assembler does not support .weak symbols.

[Bug target/54089] [SH] Refactor shift patterns

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  2012-08-16 
23:13:18 UTC ---
Author: olegendo
Date: Thu Aug 16 23:13:11 2012
New Revision: 190457

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190457
Log:
PR target/54089
* config/sh/sh.md (ashlsi3_d): Do not split if it would result
in a T_REG clobber.  Correct comment.
(ashlsi3_n): Correct comment.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[ppluzhnikov at google dot com]

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

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||aaw at gcc dot gnu.org

--- Comment #2 from Paul Pluzhnikov  2012-08-16 
23:06:58 UTC ---
(In reply to comment #1)
> I think this is a dup of bug 54197 or at least related to it.

Definitely not a dup. I somewhat doubt it's related.

Ollie, you have a GCC build with your patch for PR54197. Could you please check
what (if any) effect it has on this test case?

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

  Attachment #28020|0   |1
is obsolete||

--- Comment #53 from Steven Bosscher  2012-08-16 
23:04:04 UTC ---
Created attachment 28039
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28039
More dedicated obstacks

This, together with Richi's leak plugs from earlier today, brings peak memory
down to 5GB. That's 5GB now, down from 9GB this morning. Not bad for a day's
work.

[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-08-16 
23:02:07 UTC ---
I think this is a dup of bug 54197 or at least related to it.

[Bug target/53487] [4.8 Regression] Unrecognizable insn for conditional move

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Michael Meissner  2012-08-16 
22:59:35 UTC ---
Fixed on June 5, 2012.

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #14 from Andrew Pinski  2012-08-16 
22:59:51 UTC ---
Can you stop reopening this bug?  The problem again is that you are writing
past the array bounds and anytime that happens it is undefined behavior. 
Please fix the array bounds issue and you will see it works now.

[Bug target/52775] Change default for using FCFID instruction

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Michael Meissner  2012-08-16 
22:58:02 UTC ---
Fixed in April, 2012.

[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)

[lirex.software at gmail dot com]

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

--- Comment #7 from Denis Kolesnik  2012-08-16 
22:38:19 UTC ---
*** Bug 54213 has been marked as a duplicate of this bug. ***

[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)

[lirex.software at gmail dot com]

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

Denis Kolesnik  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |DUPLICATE

--- Comment #6 from Denis Kolesnik  2012-08-16 
22:38:19 UTC ---


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

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[lirex.software at gmail dot com]

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

Denis Kolesnik  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #13 from Denis Kolesnik  
2012-08-16 22:35:01 UTC ---
I disagree: 
I know enough to use strcat and strcpy.

1: Why those functions work false and are dependent on variables(! I name it
correct even if it is one dimenision array of chararters) declare order I don't
know.

2: on this site there are enough people with very vary C and C++ language
skills, so this sites helps on learning also. I know too much people who
learner more from wrong experiences rather than from clear imagination.

[Bug c++/54293] New: When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[ppluzhnikov at google dot com]

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

 Bug #: 54293
   Summary: When a reference is bound to subobject of a temporary,
lifetime of the temporary is not extended
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


Google reference: b/6996555

"ISO/IEC 14882:2011(E) 12.2.5 [class.temporary]

The temporary to which the reference is bound or the temporary that is the
complete object of a subobject to which the reference is bound persists for the
lifetime of the reference except: [etc]"

With gcc-4.6, the lifetime extension is not happening at all:

FAIL int
FAIL Obj

With gcc-4.7 and 4.8 (rev 190453), lifetime is extended for Obj subobject, but
not for 'int' (or 'char', or other primitive types):

FAIL int

The test:

#include 
#include 

std::set subobjs;

template 
struct ValueHolder {
  explicit ValueHolder() {
subobjs.insert(&v);
  }
  ~ValueHolder() {
subobjs.erase(&v);
  }
  T v;
};

struct Obj { };

bool IsValid(const void* p) {
  return subobjs.find(p) != subobjs.end();
}

int main() {
  const int& ref_int = ValueHolder().v;
  if (!IsValid(&ref_int)) {
std::cout << "FAIL int" << std::endl;
  }

  const Obj& ref_obj = ValueHolder().v;
  if (!IsValid(&ref_obj)) {
std::cout << "FAIL Obj" << std::endl;
  }
}

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[sch...@linux-m68k.org]

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

--- Comment #12 from Andreas Schwab  2012-08-16 22:26:11 
UTC ---
*** Bug 54291 has been marked as a duplicate of this bug. ***

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #7 from Andreas Schwab  2012-08-16 22:26:11 
UTC ---
If you want to learn C this is not the right place.

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

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

--- Comment #10 from Hans-Peter Nilsson  2012-08-16 
22:23:32 UTC ---
(In reply to comment #9)
> Actually, that's the way __atomic_is_lock_free()  has always been implemented
> (even in 4.7).  

There's miscommunication here.  The point of this PR is, the code for
is_lock_free must be per-type, agreed?  It used __atomic_is_lock_free() with a
non-null pointer, hence it was per-object, a bug, agreed?  (Mr. Crowl asserts
on IRC what can be understood from the referenced URL; that the function
started as per-object but semantics later changed to be per-type.)

The committed changes were to make it use __atomic_always_lock_free() so
per-type.
IIUC you mean it should instead use __atomic_is_lock_free() with the object
pointer changed to NULL.  That might be: whether that is preferred to r190216 I
can't say, in particular with a pending rewrite.

[Bug c++/53540] C++11: using fails to be equivalent to typedef

[dodji at seketeli dot org]

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

--- Comment #5 from dodji at seketeli dot org  
2012-08-16 22:18:36 UTC ---
A candidate patch was sent to 
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg0.html.

[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson  2012-08-16 
22:05:37 UTC ---
Author: hp
Date: Thu Aug 16 22:05:32 2012
New Revision: 190455

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190455
Log:
PR middle-end/54261
* gcc.dg/torture/pr54261-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr54261-1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson  2012-08-16 
22:03:39 UTC ---
Author: hp
Date: Thu Aug 16 22:03:33 2012
New Revision: 190454

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190454
Log:
PR middle-end/54261
* optabs.c (expand_atomic_fetch_op): Save and restore code when
retrying after failed attempt.

Modified:
trunk/gcc/ChangeLog

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
Summary|Errors due to conflicting   |[4.8 Regression] Errors due
   |strsignal headers   |to conflicting strsignal
   ||headers

--- Comment #2 from Andrew Pinski  2012-08-16 
21:58:49 UTC ---
This is due to including gmp.h inside system.h so the tests for those functions
are failing.

There is a mention of this on the list too.  IIRC Diego is fixing it.

[Bug bootstrap/54292] Errors due to conflicting strsignal headers

[tobi at gcc dot gnu.org]

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

--- Comment #1 from Tobias Schlüter  2012-08-16 
21:49:53 UTC ---
Created attachment 28038
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28038
configure log

[Bug bootstrap/54292] New: Errors due to conflicting strsignal headers

[tobi at gcc dot gnu.org]

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

 Bug #: 54292
   Summary: Errors due to conflicting strsignal headers
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@gcc.gnu.org
Target: Darwin


This resembles PR31776.  My build from current HEAD fails with
g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build
-I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I/Users/tobi/src/gcc/build/./gmp -I/Users/tobi/src/gcc/gmp
-I/Users/tobi/src/gcc/build/./mpfr -I/Users/tobi/src/gcc/mpfr
-I/Users/tobi/src/gcc/mpc/src  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber\
-o build/genconstants.o ../../gcc/genconstants.c
In file included from /usr/include/sys/wait.h:117,
 from /usr/include/stdlib.h:65,
 from ../../gcc/system.h:228,
 from ../../gcc/genconstants.c:29:
/usr/include/sys/resource.h:89: error: declaration does not declare anything
In file included from ../../gcc/genconstants.c:29:
../../gcc/system.h:499: error: declaration of C function 'const char*
strsignal(int)' conflicts with
/usr/include/string.h:144: error: previous declaration 'char* strsignal(int)'
here
make[3]: *** [build/genconstants.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

I'm using an in-tree gmp, mpfr etc setup with contrib/download_prerequisites. 
I mention this because in gcc/config.log (attached) I see that the strsignal
configure tests apparently got confused by the location of gmp.h.

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

--- Comment #6 from Denis Kolesnik  2012-08-16 
21:18:32 UTC ---
I know it could be because if accounts values are changed they
are sorted in reverse order(last changed), but my SQL request requests
in strict order and my program even not changes the value of SQL_from_account
in this function int apply_button_add(etc...).

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

Denis Kolesnik  changed:

   What|Removed |Added

  Attachment #28034|0   |1
is obsolete||

--- Comment #5 from Denis Kolesnik  2012-08-16 
21:15:14 UTC ---
Created attachment 28037
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28037
additional files to the source asked

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

--- Comment #4 from Denis Kolesnik  2012-08-16 
21:11:38 UTC ---
Created attachment 28036
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28036
assembler source file

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

--- Comment #3 from Denis Kolesnik  2012-08-16 
21:09:24 UTC ---
Created attachment 28035
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28035
object file to the source

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

--- Comment #2 from Denis Kolesnik  2012-08-16 
21:06:51 UTC ---
to THE source

[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

--- Comment #1 from Denis Kolesnik  2012-08-16 
21:04:28 UTC ---
Created attachment 28034
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28034
additional files to source asked

[Bug c++/54291] New: why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?

[lirex.software at gmail dot com]

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

 Bug #: 54291
   Summary: why the value of the variable CHAR SQL_from_account[3]
of  is changed if it should not be changed?
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lirex.softw...@gmail.com


Created attachment 28033
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28033
a c++ source file

2 SQL requests update fields of accounts table and one adds a payment into
bills table.

The requests are for PostgreSQL server using their native library.

As I add a transaction from 1001 to 1000 for the first time all is ok,
but for the second time the value of the variable(! according to the C language
syntax it is a variable even if it is a CHAR characters 1 dimenisional array)
SQL_from_account changes it value from 1001 to 1000(but it should not).

So if I press add(caption in cyrillic, but function names, etc are in english)

Why is this?

[Bug target/54272] [SH] Add support for addv / subv instructions

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-16
 Ever Confirmed|0   |1

--- Comment #5 from Oleg Endo  2012-08-16 20:34:53 
UTC ---
Regarding saturating arithmetic, I took the function FIXED_SSADD from
libgcc/fixed-bit.c and substituted FIXED_C_TYPE with int.

int test_01 (int a, int b)
{
  int c;
  int x, y, z;
  x = a;
  y = b;
  z = x + y;
  if x ^ y) >> 31) & 1) == 0)
{
  if (((z ^ x) >> 31) & 1)
{
  z = 1;
  z = z << 31;
  if (x >= 0)
z--;
}
}
  c = z;
  return c;
}

compiled with -O2 -m4 -ml:
div0s   r4,r5
mov r4,r0
bt/s.L4
add r5,r0
div0s   r0,r4
bt/s.L6
cmp/pz  r4
.L4:
rts
nop
.align 1
.L6:
mov.l   .L7,r0
movtr1
rts
sub r1,r0
.L8:
.align 2
.L7:
.long   -2147483648

In this case combine can successfully match the div0s sign comparison patterns
that I added in PR 52933.  However, after matching those, it does not try to
combine the patterns any further (probably because of the conditional
branches). I guess this would be a job for an optimization at the GIMPLE level.

[Bug fortran/54285] [F03] Calling a PPC with proc-ptr result

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2012-08-16 20:33:22 UTC ---
The following patch fixes the error message in comment 0:


Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(revision 190419)
+++ gcc/fortran/primary.c(working copy)
@@ -2004,8 +2004,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl

   primary->ts = component->ts;

-  if (component->attr.proc_pointer && ppc_arg
-  && !gfc_matching_procptr_assignment)
+  if (component->attr.proc_pointer && ppc_arg)
 {
   /* Procedure pointer component call: Look for argument list.  */
   m = gfc_match_actual_arglist (sub_flag,
@@ -2014,7 +2013,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
 return MATCH_ERROR;

   if (m == MATCH_NO && !gfc_matching_ptr_assignment
-  && !matching_actual_arglist)
+  && !gfc_matching_procptr_assignment && !matching_actual_arglist)
 {
   gfc_error ("Procedure pointer component '%s' requires an "
  "argument list at %C", component->name);



However, with this one gets:

pp => x%p()
  1
Error: Interface mismatch in procedure pointer assignment at (1): 'p' has the
wrong number of arguments

... which is obviously not true. Apparently the formal args of pp are compared
to the formal args of x%p itself, and not to those of the result of x%p.

[Bug libstdc++/54289] setjmp isn't included into std namespace

[dmitriy-hshg at mail dot ru]

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

--- Comment #9 from Dmitry  2012-08-16 19:55:57 
UTC ---
C standard:

The header  defines the macro setjmp, and declares one function and
one type, for bypassing the normal function call and return discipline.

OK. I agree with you. But one moment. If my system is BSD I will write
std::setjmp() that isn't good. May be better:


__BEGIN_NAMESPACE_STD
typedef struct __jmp_buf_tag jmp_buf[1];
__END_NAMESPACE_STD
extern int setjmp (jmp_buf __env) __THROW;

I think setjmp should be outside of std.

[Bug libstdc++/54289] setjmp isn't included into std namespace

[daniel.kruegler at googlemail dot com]

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

--- Comment #8 from Daniel Krügler  
2012-08-16 19:54:10 UTC ---
(In reply to comment #6)
> I think standard of C std libs declares setjmp as a function. So, it should be
> function.

I'm not looking at any code, but C says:

"The header  defines the macro setjmp, [..]"

And in C++ (quoting from C++11) [headers]:

"Names which are defined as macros in C shall be defined as macros in the C++
standard library, even if C grants license for implementation as functions. [
Note: The names defined as macros in C include the following: assert, offsetof,
setjmp, va_arg, va_end, and va_start. —end note ]"

For this discussion it is completely irrelevant whether the macro expands to a
function or something else.

[Bug libstdc++/54289] setjmp isn't included into std namespace

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2012-08-16 
19:51:54 UTC ---
Nothing changes, because the C++ standard says that macros which can be
implemented as functions in C must be actual macros in C++ (and setjmp is
*explicitly* mentioned)

[Bug target/54290] gcc 4.4/4.5/4.6 produces wrong code on sparc with -O2

[eriksnga at gmail dot com]

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

--- Comment #1 from Erik Volk  2012-08-16 19:51:23 
UTC ---
Created attachment 28032
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28032
preprocessed test case

[Bug libstdc++/54289] setjmp isn't included into std namespace

[dmitriy-hshg at mail dot ru]

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

--- Comment #6 from Dmitry  2012-08-16 19:49:27 
UTC ---
I think standard of C std libs declares setjmp as a function. So, it should be
function.

Some code:

__BEGIN_NAMESPACE_STD
typedef struct __jmp_buf_tag jmp_buf[1];

extern int setjmp (jmp_buf __env) __THROW;

__END_NAMESPACE_STD

#ifndef__FAVOR_BSD
extern int _setjmp (struct __jmp_buf_tag __env[1]) __THROW;
# define setjmp(env)_setjmp (env)
#else
# define setjmp(env)setjmp (env)
#endif 

Do you see that if __FAVOR_BSD is defined then std::setjmp will work? Different
behaviours aren't good.

[Bug target/54290] New: gcc 4.4/4.5/4.6 produces wrong code on sparc with -O2

[eriksnga at gmail dot com]

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

 Bug #: 54290
   Summary: gcc 4.4/4.5/4.6 produces wrong code on sparc with -O2
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eriks...@gmail.com


Created attachment 28031
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28031
Output from gcc -v

Test system: SunOS 5.10 sun4u sparc SUNW,SPARC-Enterprise Solaris

GCC Config:  output from gcc -v is attached for version 4.6.3


# Test case:

# cat ./testcase.c
#define CHECK 1234567890
double vd[2] = {1., 0.};
intvi[2] = {CHECK, 0};
double *pd = vd;
int*pi = vi;
void init (int *n, int *dummy) __attribute__ ((noinline));
void init (int *n, int *dummy)
{
  if(0 == n) dummy[0] = 0;
}
int main ()
{
  int dummy[1532];
  int i = -1, n = 1, s = 0;
  init (&n, dummy);
  while (i < n) {
if (i == 0) {
  if (pd[i] > 0) {
if (pi[i] > 0) {
  s += pi[i];
#ifdef VERIFY
  return (pi[i] == CHECK? 2 : 3);
#endif
}
  }
  pd[i] = pi[i];
}
++i;
  }
  return (s == CHECK? 0 : 1);
}
# 
# gcc-4.6.3 -O2 ./testcase.c
# ./a.out; echo $?
1
# 

O1 returns expected result (exit code 0).

Problem is reproducible with gcc/g++, 32/64bit ABI with same test case 
or slight variations thereof.

Problem is not reproducible on x86_64/Linux.


# Results from other GCC versions:

GCC version 4.3.2: returns 0, ie. correct result
GCC version 4.4.3: returns 1, ie. wrong   result
GCC version 4.5.2: returns 1, ie. wrong   result
GCC version 4.6.1: returns 1, ie. wrong   result
GCC version 4.6.3: returns 1, ie. wrong   result
GCC version 4.7.1: returns 0, ie. correct result

On x86_64/Linux, all versions return 0.


# Details:

The code produced by gcc-4.6.3 misses a load (resp. contains erroneous 
instructions) resulting in the use of the address of a temp in place of 
the value stored at that address.

[..]
fbule,pt %fcc0, .LL10
 ld [%o7], %f8  ! %f8 <- pi[i]
sethi   %hi(-6144), %i5 ! compute address for temp
or  %i5, 4, %i5
add %i5, %fp, %i5
st  %f8, [%i5]  ! copy from %f8 ...
ld  [%i5], %i5  ! ... to %i5 via temp
add %g4, %i5, %o5   ! %o5 <- s+pi[i]
sethi   %hi(-6144), %i5 ! recompute address of temp ...
or  %i5, 4, %i5 ! ... which is unnecessary; but when doing so
add %i5, %fp, %i5   ! ... value needs to be reloaded as well:
!   !
!   ld  [%i5], %i5  ! missing instruction
!   !
cmp %i5, 0  ! supposedly (pi[i] <=> 0), except %i5 contains
!   ! address of temp instead of its value
movg%icc, %o5, %g4  ! pi[i] > 0 : s <- s+pi[i]
.LL10:
fitod   %f8, %f8
[..]

As an apparent pre-requisite, the offset for the temp needs to be too 
large to fit into an immediate constant. Any array size greater equal to 
1022(m32) resp. 1532(m64) for "dummy" in the test case seems to fit the bill.

[Bug libstdc++/54289] setjmp isn't included into std namespace

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler  
2012-08-16 19:46:16 UTC ---
(In reply to comment #4)
> Sorry, but I think standard declares that all function should be in std.

No. 17.6.1.2 [headers] only says so for non-macros:

"In the C++ standard library, however, the declarations (except for names which
are defined as macros in C) are within namespace scope (3.3.6) of the namespace
std."

[Bug libstdc++/54289] setjmp isn't included into std namespace

[dmitriy-hshg at mail dot ru]

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

--- Comment #4 from Dmitry  2012-08-16 19:43:15 
UTC ---
Sorry, but I think standard declares that all function should be in std.

[Bug libstdc++/54289] setjmp isn't included into std namespace

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #3 from Daniel Krügler  
2012-08-16 19:41:00 UTC ---
(In reply to comment #1)
> Open the header with your favorite editor and you will see why (spoiler: 
> setjmp
> is defined as a macro in C)

You are right, but I initially thought that this would be a function in C++11.
But after checking, I'm satisfied, it is macro here as well.

[Bug libstdc++/54289] setjmp isn't included into std namespace

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2012-08-16 19:38:16 UTC ---
The problem seems still to exist in gcc 4.8.0 20120729 (experimental).

Just to be sure that this is not due to a badly formed error description I
tested to compile the folowing code (C++03 or C++11 mode)

#include 

std::jmp_buf b;

int main()
{
  std::setjmp(b); // Error
}

"In function 'int main()':|
7|error: '_setjmp' is not a member of 'std'|
7|note: suggested alternative:|
c:\program files\develop\gcc\x86_64-w64-mingw32\include\setjmp.h|164|note:  
'_setjmp'|"

[Bug libstdc++/54289] setjmp isn't included into std namespace

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Paolo Carlini  2012-08-16 
19:33:11 UTC ---
Open the header with your favorite editor and you will see why (spoiler: setjmp
is defined as a macro in C)

[Bug c++/53540] C++11: using fails to be equivalent to typedef

[dodji at seketeli dot org]

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

--- Comment #4 from dodji at seketeli dot org  
2012-08-16 19:11:01 UTC ---
> I think it's valid, CC'ing Dodji for confirmation.

I agree this is a bug.  I am looking into it.

[Bug c++/53540] C++11: using fails to be equivalent to typedef

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Dodji Seketeli  2012-08-16 
19:09:39 UTC ---
Sorry, I am getting to this just now.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[aaw at gcc dot gnu.org]

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

--- Comment #4 from Ollie Wild  2012-08-16 18:46:42 UTC 
---
Fix submitted to the google/gcc-4_7 branch.

Still waiting on maintainer approval for the trunk and gcc-4_7-branches.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[aaw at gcc dot gnu.org]

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

--- Comment #3 from Ollie Wild  2012-08-16 18:44:01 UTC 
---
Author: aaw
Date: Thu Aug 16 18:43:52 2012
New Revision: 190450

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190450
Log:
Fix some cases where lifetimes of temporaries bound to expressions are not
properly extended (Google ref b/6946758).

2012-08-16  Ollie Wild  

PR c++/54197
* gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees.
* gcc/testsuite/g++.dg/init/lifetime3.C: New test.

Added:
branches/google/gcc-4_7/gcc/testsuite/g++.dg/init/lifetime3.C
Modified:
branches/google/gcc-4_7/gcc/cp/ChangeLog.google-4_7
branches/google/gcc-4_7/gcc/cp/call.c
branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

--- Comment #9 from Diego Novillo  2012-08-16 
18:42:48 UTC ---
New proposed patch.  Needs testing with a 4.1 compiler.  I couldn't build my
own (fails to build).

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01090.html

[Bug libstdc++/54289] New: setjmp isn't included into std namespace

[dmitriy-hshg at mail dot ru]

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

 Bug #: 54289
   Summary: setjmp isn't included into std namespace
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dmitriy-h...@mail.ru


Hello!

longjmp, jmp_buf are included into std namespace, but setjmp isn't! It is
possible:

#include 

...
std::jmp_buf ...
std::longjmp() ...

...

// but
std::setjmp() // => error: «_setjmp» isn't an element/item of «std»

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

--- Comment #8 from Diego Novillo  2012-08-16 
18:24:30 UTC ---
Author: dnovillo
Date: Thu Aug 16 18:24:22 2012
New Revision: 190449

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190449
Log:
2012-08-16   Diego Novillo  

Revert

PR bootstrap/54281
* double-int.h: Move including of gmp.h ...
* system.h: ... here.
* realmpfr.h: Do not include gmp.h.
* tree-ssa-loop-niter.c: Do not include gmp.h.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/double-int.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/realmpfr.h
trunk/gcc/system.h
trunk/gcc/tree-ssa-loop-niter.c

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

Diego Novillo  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-08-16
 Resolution|FIXED   |
 Ever Confirmed|0   |1

--- Comment #7 from Diego Novillo  2012-08-16 
18:03:47 UTC ---
Mi fix broke Ada and in-tree cloog/isl.  I will revert and fix it without the
system.h modification.

[Bug c++/54288] Wrong sign compiled at run-time

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andreas Schwab  2012-08-16 16:46:04 
UTC ---
The usual arithmetic conversions convert _i to unsigned int in the condition
inside CQ::question.

[Bug c++/54288] New: Wrong sign compiled at run-time

[l.lapointe at srtechlabs dot com]

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

 Bug #: 54288
   Summary: Wrong sign compiled at run-time
Classification: Unclassified
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l.lapoi...@srtechlabs.com


Simple code will be found below.
Optimization of the code lose the sign of a negative integer.


#include 
#include 
#include 
#include 
#include 
#include 


struct struct_sz
{
   static const unsigned int scu_sz = 40;
};


class CQ
{
public:
void  doIt();
  CQ();
private:
   int _i;
   bool question();
};
//
const unsigned int struct_sz::scu_sz;

CQ::CQ()
{
   _i = -1;
}

void CQ::doIt()
{
   double dZ;
   double dO = 0.0;
   if (question())
   {
  dO = 1.0;
   }
   else
   {
  //Execution is going here

  dO = 0.0;
   }
   dZ = 1.0/dO;
   cout << dZ << endl;
}

bool CQ::question()
{
   if (_i < struct_sz::scu_sz - 2)
   {
  return true;
   }
   return false;
}


int main(int argc, char* argv[])
{
   CQ cq;
   cq.doIt();
  return 0;
}

[Bug c/54282] GCC generates incorrect code for the PDP-11 target when -Os or -O2 is specified

[jguillaumes at gmail dot com]

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

Jordi Guillaumes Pons  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jordi Guillaumes Pons  
2012-08-16 16:20:46 UTC ---
The problem seems to be in binutils (gas) instead of gcc. I'm opening a bug in
the binutils tracker.

[Bug middle-end/54287] New: -finstrument-functions-exclude-function-list ignores class/namespace scope

[mg1102 at web dot de]

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

 Bug #: 54287
   Summary: -finstrument-functions-exclude-function-list ignores
class/namespace scope
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mg1...@web.de


In it's current implementation, the symbol matching of
-finstrument-functions-exclude-function-list performs a strstr() on the
function name only, ignoring the class/namespace scope. That is, with sym=func,
both foo::func() and bar::func() with foo and bar being either classes or
namespaces will be matched and excluded from instrumentation.

To allow for a more fine-grained specification, the function name used for
matching should include the class/namespace scope. This can easily be achived
using the patch given below (against the 4.7.1 release). A matching based on
regular expressions would be even more convenient, but the proposed change
would already help a lot.


diff -Nrup gcc-4.7.1.orig/gcc/gimplify.c gcc-4.7.1/gcc/gimplify.c
--- gcc-4.7.1.orig/gcc/gimplify.c2012-05-10 17:00:11.0 +0200
+++ gcc-4.7.1/gcc/gimplify.c2012-08-16 18:12:45.793020996 +0200
@@ -8079,7 +8079,7 @@ flag_instrument_functions_exclude_p (tre
   int i;
   char *s;

-  name = lang_hooks.decl_printable_name (fndecl, 0);
+  name = lang_hooks.decl_printable_name (fndecl, 1);
   FOR_EACH_VEC_ELT (char_p, vec, i, s)
 if (strstr (name, s) != NULL)
   return true;

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-08-16 
15:29:24 UTC ---
Maybe related that we don't build a "host" libstdc++-v3 but only a target one:

target_modules = { module= libstdc++-v3;
   bootstrap=true;
   lib_path=src/.libs;
   raw_cxx=true; };

and funnily we bootstrap it.  We should bootstrap a host libstdc++-v3 and
build a target libstdc++-v3 (if C++ is enabled).  The host libstdc++-v3
would not need libstdc++ PCHs or multilibs of course.

[Bug fortran/54286] New: [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result

[janus at gcc dot gnu.org]

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

 Bug #: 54286
   Summary: [4.8 Regression] Accepts invalid proc-pointer
assignments involving proc-ptr function result
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


The following test is probably invalid, but not rejected by recent trunk
versions:


type :: t
  procedure(a), pointer, nopass :: p
end type

type(t) :: x
procedure(iabs), pointer :: pp

x%p => a ! ok
x%p => a(1)  ! invalid, but not rejected by 4.8

pp => a(2)   ! ok
pp => a  ! invalid, but not rejected by 4.8

contains

  function a (c) result (b)
integer, intent(in) :: c
procedure(iabs), pointer :: b
b => iabs
  end function

end



gfortran 4.7 rejects it with:

x%p => a(1)
   1
Error: Interface mismatch in procedure pointer assignment at (1): Type/rank
mismatch in return value of 'b'

pp => a
  1
Error: Interface mismatch in procedure pointer assignment at (1): Type/rank
mismatch in return value of 'a'


However, I wonder why one of the errors refers to 'a' and the other to 'b'.
Also I'm not sure whether 'type/rank mismatch' is the correct diagnostic. I
would rather say there is a mismatch in the procedure pointer attribute of the
result (which is not checked for yet), cf. also PR 35831.

[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-08-16 
14:58:53 UTC ---
I'll see what I can do.

[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-08-16 
14:45:03 UTC ---
I see. Jonathan, I guess a reduced testcase not including anything would be
very useful anyway (even if the ICE is very old)

[Bug fortran/54285] New: [F03] Calling a PPC with proc-ptr result

[janus at gcc dot gnu.org]

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

 Bug #: 54285
   Summary: [F03] Calling a PPC with proc-ptr result
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


The following (supposedly valid) test case ...


type :: t
  procedure(a), pointer, nopass :: p
end type

type(t) :: x
procedure(iabs), pointer :: pp

x%p => a

pp => x%p()  ! "Invalid character in name at (1)"

print *,pp(-3)

contains

  function a() result (b)
procedure(iabs), pointer :: b
b => iabs
  end function

end


triggers the error:

pp => x%p()
 1
Error: Invalid character in name at (1)

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[rguenth at gcc dot gnu.org]

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

--- Comment #52 from Richard Guenther  2012-08-16 
14:27:59 UTC ---
Author: rguenth
Date: Thu Aug 16 14:27:51 2012
New Revision: 190445

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190445
Log:
2012-08-16  Richard Guenther  

PR middle-end/54146
* tree-ssa-loop-niter.c (find_loop_niter_by_eval): Free the
exit vector.
* ipa-pure-const.c (analyze_function): Use FOR_EACH_LOOP_BREAK.
* cfgloop.h (FOR_EACH_LOOP_BREAK): Fix.
* tree-ssa-structalias.c (handle_lhs_call): Properly free rhsc.
* tree-into-ssa.c (get_ssa_name_ann): Allocate info only when
needed.
* tree-ssa-loop-im.c (analyze_memory_references): Adjust.
(tree_ssa_lim_finalize): Free all mem_refs.
* tree-ssa-sccvn.c (extract_and_process_scc_for_name): Free
scc when bailing out.
* modulo-sched.c (sms_schedule): Use FOR_EACH_LOOP_BREAK.
* ira-build.c (loop_with_complex_edge_p): Free loop exit vector.
* graphite-sese-to-poly.c (scop_ivs_can_be_represented): Use
FOR_EACH_LOOP_BREAK.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.h
trunk/gcc/graphite-sese-to-poly.c
trunk/gcc/ipa-pure-const.c
trunk/gcc/ira-build.c
trunk/gcc/modulo-sched.c
trunk/gcc/tree-into-ssa.c
trunk/gcc/tree-ssa-loop-im.c
trunk/gcc/tree-ssa-loop-niter.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-structalias.c

[Bug target/54284] New: -mabi=ieeelongdouble problems

[segher at gcc dot gnu.org]

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

 Bug #: 54284
   Summary: -mabi=ieeelongdouble problems
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: seg...@gcc.gnu.org
CC: berg...@vnet.ibm.com, dje@gmail.com,
meiss...@gcc.gnu.org
Target: powerpc-*


As I noted in http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01017.html ,
there are quite a few problems with -mabi=ieeelongdouble.

On 64-bit Linux it crashes the compiler:

Program received signal SIGSEGV, Segmentation fault.
0x10578da4 in simplify_subreg (outermode=TImode, op=0xfffb69b1160, 
innermode=TFmode, byte=0) at /home/segher/src/gcc/gcc/simplify-rtx.c:5429

The other issues are more minor, but the option obviously suffers from
a lack of testing.

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[rguenther at suse dot de]

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

--- Comment #51 from rguenther at suse dot de  
2012-08-16 14:06:06 UTC ---
On Thu, 16 Aug 2012, stevenb.gcc at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
> 
> --- Comment #50 from stevenb.gcc at gmail dot com  com> 2012-08-16 13:55:40 UTC ---
> On Thu, Aug 16, 2012 at 2:10 PM, rguenth at gcc dot gnu.org
>  wrote:
> > bitmap stats are confusing because they show leaks for bitmaps we free
> > by releasing their obstack.  DF and PTA bitmaps are largest.
> 
> The bitmap obstack stats are not very reliable anyway, I think. I've
> been using my own stats for this (with a size_t version of
> obstack_memory_used:
> 
> +static size_t
> +obstack_memory_used2 (struct obstack *h)
> +{
> +  struct _obstack_chunk* lp;
> +  size_t nbytes = 0;
> +
> +  for (lp = h->chunk; lp != 0; lp = lp->prev)
> +{
> +  nbytes += (size_t) (lp->limit - (char *) lp);
> +}
> +  return nbytes;
> +}
> +
> 
> so that also the "freed" bitmap elements are counted). With that, you
> can show that the reg_obstack and bitmap_default_obstack grow up to
> several GB that isn't released between passes. An added problem is

Hum, I thought we release those obstacks after each pass ...

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[stevenb.gcc at gmail dot com]

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

--- Comment #50 from stevenb.gcc at gmail dot com  2012-08-16 13:55:40 UTC ---
On Thu, Aug 16, 2012 at 2:10 PM, rguenth at gcc dot gnu.org
 wrote:
> bitmap stats are confusing because they show leaks for bitmaps we free
> by releasing their obstack.  DF and PTA bitmaps are largest.

The bitmap obstack stats are not very reliable anyway, I think. I've
been using my own stats for this (with a size_t version of
obstack_memory_used:

+static size_t
+obstack_memory_used2 (struct obstack *h)
+{
+  struct _obstack_chunk* lp;
+  size_t nbytes = 0;
+
+  for (lp = h->chunk; lp != 0; lp = lp->prev)
+{
+  nbytes += (size_t) (lp->limit - (char *) lp);
+}
+  return nbytes;
+}
+

so that also the "freed" bitmap elements are counted). With that, you
can show that the reg_obstack and bitmap_default_obstack grow up to
several GB that isn't released between passes. An added problem is
that IRA puts its bitmap on its own obstack (as it should, really) but
that means the >3GB of free elements on the reg_obstack and
bitmap_default_obstack remain unused. So on the machine I use for
testing (cfarm gcc17), the memory footprint is reduced by >2GB (~25%)
with this hack:

Index: ira.c
===
--- ira.c   (revision 190442)
+++ ira.c   (working copy)
@@ -4132,6 +4132,12 @@
   int max_regno_before_ira, ira_max_point_before_emit;
   int rebuild_p;

+  /* There shouldn't be anything on these obstacks.  */
+  bitmap_obstack_release (NULL);
+  bitmap_obstack_initialize (NULL);
+  bitmap_obstack_release (®_obstack);
+  bitmap_obstack_initialize (®_obstack);
+
   if (flag_caller_saves)
 init_caller_save ();


There is in general a lot of BITMAP_ALLOC(NULL) abuse in the compiler.
I have patches to address the cases in tree-ssa-live.c and dse.c, and
I intend to look at the tree-ssa-ter and cfgexpand cases this weekend.

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2012-08-16 13:53:37 UTC 
---
Created attachment 28030
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28030
hacky patch

[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2012-08-16 13:46:24 
UTC ---
It was triggered by revision 176549:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00816.html

But ICE is always there.

[Bug bootstrap/54283] New: [4.8 regression] build tools don't run after cxx-conversion merge

[ro at gcc dot gnu.org]

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

 Bug #: 54283
   Summary: [4.8 regression] build tools don't run after
cxx-conversion merge
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: cr...@gcc.gnu.org, dnovi...@gcc.gnu.org
  Host: *-*-solaris2.*
Target: *-*-solaris2.*
 Build: *-*-solaris2.*


Since the merge of the cxx-conversion branch, Solaris bootstrap fails for me.
In stage 1, the build tools fail to run, e.g.

build/genmddeps /vol/gcc/src/hg/trunk/local/gcc/config/i386/i386.md >
tmp-mddeps
ld.so.1: genmddeps: fatal: libstdc++.so.6: open failed: No such file or
directory
make[3]: *** [s-mddeps] Killed
make[3]: *** Waiting for unfinished jobs

I'm using a self-built gcc 4.4.2 as bootstrap compiler, installed into
/vol/gcc-4.4.  In order to assure that the libstdc++.so.6 included there is
found,
I've so far been configuring with

--with-host-libstdcxx=\'-L/vol/gcc-4.4/lib -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
-lm\' --with-boot-ldflags=\'-static-libstdc++' -static-libgcc
-L/vol/gcc-4.4/lib\'

This is not enough after the conversion since the build tools don't use either
$BOOT_LDFLAGS or $HOST_LIBS.

The attached patch allowed the bootstrap to finish, but is obviously wrong
as-is
since it doesn't correctly distinguish between build and host tools.  Having
never run a canadian cross myself, I'm not sure what the right approach is.

The first part (using $CC as linker instead of $CXX_FOR_BUILD) is necessary to
avoid linking with g++ which links with -lstdc++ on its own.

  Rainer

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

Diego Novillo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Diego Novillo  2012-08-16 
13:30:22 UTC ---
Fixed at rev 190444.

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

--- Comment #5 from Diego Novillo  2012-08-16 
13:28:27 UTC ---
Author: dnovillo
Date: Thu Aug 16 13:28:13 2012
New Revision: 190444

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190444
Log:
2012-08-16  Diego Novillo  

PR bootstrap/54281
* double-int.h: Move including of gmp.h ...
* system.h: ... here.
* realmpfr.h: Do not include gmp.h.
* tree-ssa-loop-niter.c: Do not include gmp.h.

fortran/ChangeLog
* gfortran.h: Do not include gmp.h.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/double-int.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/realmpfr.h
trunk/gcc/system.h
trunk/gcc/tree-ssa-loop-niter.c

[Bug target/54272] [SH] Add support for addv / subv instructions

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima  2012-08-16 
13:00:37 UTC ---
(In reply to comment #3)
> How about small variation:

Sounds reasonable to me.

[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables

[ttignor at us dot ibm.com]

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

--- Comment #12 from Tom Tignor  2012-08-16 12:59:39 
UTC ---
Hi Jakub,
Can you tell me what gcc version has the fix? Read through 48306 and saw 
"Fixed in 4.5+" but I have a colleague here who is able to reproduce on 
4.5.1.

Tom:-)




From:   "jakub at gcc dot gnu.org" 
To: Thomas Tignor/Marlborough/IBM@IBMUS
Date:   08/16/2012 02:59 AM
Subject:[Bug other/38966] libiberty make_relative_prefix_1 
mistakes directories for executables



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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #11 from Jakub Jelinek  2012-08-16 
06:58:19 UTC ---
Dup of PR48306.

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

[Bug c/54282] New: GCC generates incorrect code for the PDP-11 target when -Os or -O2 is specified

[jguillaumes at gmail dot com]

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

 Bug #: 54282
   Summary: GCC generates incorrect code for the PDP-11 target
when -Os or -O2 is specified
Classification: Unclassified
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jguillau...@gmail.com


Created attachment 28029
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28029
Compiler generated file

When doing an indirect function call (using a function pointer table), GCC
generates incorrectly the JSR instruction. Assuming than R0 contains the
address of the pointer to the function to call, the correct instruction would
be:

JSR PC,@(R0)

The compiler generates instead:

JSR PC,(R0)

That causes the machine to jump to the pointer address instead of jumping to
the function address.

Oddly enough, the assembly (*.s) file generated it I specify the -S option is
right:


mov _trap_table.1213+02(r0), -(sp)
add $_trap_table.1213, r0
jsr pc, @(r0)

But the compiled code in the *.o file, shown using the objdump utility is
wrong:


 66:   1066mov r1, -(sp)
  68:   1c26 0082   mov 202(r0), -(sp)
  6c:   65c0 0080   add $200, r0
  70:   09c8jsr pc, (r0)

Compiler output:

Usant especificacions internes.
COLLECT_GCC=pdp11-aout-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/pdp11-aout/4.6.4/lto-wrapper
Target: pdp11-aout
Configurat amb: ../gcc/configure --enable-languages=c --target=pdp11-aout
--with-newlib
Model de fils: single
gcc version 4.6.4 20120725 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-S' '-Os' '-Wall' '-Wextra'
 /usr/local/libexec/gcc/pdp11-aout/4.6.4/cc1 -E -quiet -v indirect_call_table.c
-Wall -Wextra -Os -fpch-preprocess -o indirect_call_table.i
ignorant el directori inexistent
"/usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/sys-include"
la recerca de #include  "..." s'inicia aquí:
la recerca de #include <...> s'inicia aquí:
 /usr/local/lib/gcc/pdp11-aout/4.6.4/include
 /usr/local/lib/gcc/pdp11-aout/4.6.4/include-fixed
 /usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/include
Fi de la llista de recerca.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-S' '-Os' '-Wall' '-Wextra'
 /usr/local/libexec/gcc/pdp11-aout/4.6.4/cc1 -fpreprocessed
indirect_call_table.i -quiet -dumpbase indirect_call_table.c -auxbase
indirect_call_table -Os -Wall -Wextra -version -o indirect_call_table.s
GNU C (GCC) version 4.6.4 20120725 (prerelease) (pdp11-aout)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.4 20120725 (prerelease) (pdp11-aout)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4e94c29ebf077b5bb93c64c5b111b8f7
indirect_call_table.c: In function ‘muxx_systrap_handler’:
indirect_call_table.c:30:7: avís: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
indirect_call_table.c: In function ‘muxx_svc_conputc’:
indirect_call_table.c:48:1: avís: no hi ha una declaració de retorn en una
funció que retorna "non-void" [-Wreturn-type]
indirect_call_table.c:44:33: avís: unused parameter ‘np’ [-Wunused-parameter]
indirect_call_table.c: In function ‘muxx_svc_muxxhlt’:
indirect_call_table.c:52:1: avís: no hi ha una declaració de retorn en una
funció que retorna "non-void" [-Wreturn-type]
indirect_call_table.c:50:33: avís: unused parameter ‘np’ [-Wunused-parameter]
indirect_call_table.c:50:45: avís: unused parameter ‘args’ [-Wunused-parameter]
indirect_call_table.c: In function ‘muxx_unimpl’:
indirect_call_table.c:55:28: avís: unused parameter ‘np’ [-Wunused-parameter]
indirect_call_table.c:55:40: avís: unused parameter ‘args’ [-Wunused-parameter]
indirect_call_table.c: In function ‘muxx_systrap_handler’:
indirect_call_table.c:42:1: avís: el control arriba a el final d'una funció que
no és void [-Wreturn-type]
COMPILER_PATH=/usr/local/libexec/gcc/pdp11-aout/4.6.4/:/usr/local/libexec/gcc/pdp11-aout/4.6.4/:/usr/local/libexec/gcc/pdp11-aout/:/usr/local/lib/gcc/pdp11-aout/4.6.4/:/usr/local/lib/gcc/pdp11-aout/:/usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/bin/
LIBRARY_PATH=/usr/local/lib/gcc/pdp11-aout/4.6.4/:/usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-S' '-Os' '-Wall' '-Wextra'

[Bug target/54272] [SH] Add support for addv / subv instructions

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  2012-08-16 12:43:09 
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> For linux environment, libc's abort function is a rather complex
> function and trapa handler should do equivalent things to keep
> complete binary compatibility.  I guess that it isn't worth to do
> so.  You can introduce simple trapa sequence as an ABI changing -m
> option on linux, though trap numbers < 32 are allocated for the
> syscalls and all other numbers are given for debug purposes and
> generate SIGTRAP with modified pc which points to trapa instruction
> itself.  If the user program uses its own SIGTRAP handlers, this
> might be problematic.  Perhaps the "sleep" instruction will be
> a candidate because current libc uses it for ABORT_INSTRUCTION,
> though it would be bad for bare metal cases.
> BTW, there is a known SH4 core bug for trapa instruction and we
> are using 5 or r0,r0 instructions just after trapa.  See libitm/
> config/sh/futex_bits.h for example.

Thanks a lot for the hints!

Just for the record, the SH7750 / SH7751 trapa bug is described here
http://documentation.renesas.com/doc/products/mpumcu/tu/tnsh7456ae.pdf

Taking this into account, the trapa insn suddenly seems very unattractive for
this
purpose ;)
How about small variation:

mov.l  .Loverflow_trap, r1
addv   r4,r5
bf   0f
jsr  @r1
0:
nop


'overflow_trap' then would be a library function in libgcc lib1funcs.S,  like
e.g. the dynamic shift functions for SH2.  The default implementation of
overflow_trap could simply invoke abort to
stay in line with the other trapping operations in libgcc.
For bare metal cases, users can provide their own libgcc implementation and do
whatever they
want.

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||memory-hog

--- Comment #49 from Richard Guenther  2012-08-16 
12:10:56 UTC ---
We still use very much memory (full testcase doesn't fit in 4GB ram).  With

...
  check();
  //check();
  //check >();
  //check >();
  //check();
  //check();
  //check();
  //check();

I see (--enable-gather-detailed-mem-stats):

Kind   Nodes  Bytes
---
decls1116380  181227400
types 535841   90021288
blocks222522   17801760
stmts  457492068872
refs  854577   43178392
exprs2147881   95117920
constants 1401324176820
identifiers737106486480
vecs 2654190  131466648
binfos 481624873432
ssa names 339369   27149520
constructors   26426 634224
random kinds 1885177   73894984
lang_decl kinds   352117   13918872
lang_type kinds482187329136
omp clauses0  0
---
Total10490451  699345748

a lot of memory in TREE_VECs for some reason.

GIMPLE statements
Kind   Stmts  Bytes
---
assignments   316019   30602376
phi nodes  54994   15777472
conditionals   260902504640
everything else   237509   23110772
---
Total 634612   71995260

gimple is lean, so is RTL ;)

Alloc-pool Kind Elt size  Pools  Allocated (elts)Peak
(elts)Leak (elts)
--
live ranges40513   19250760(481269)   10800800(   
270020)  0( 0)
df_scan ref base   56   1026  331010008(   5910893)   14059808(   
251068)  0( 0)
df_scan ref artificial 64   1026   20113600(314275)4239872(
66248)  0( 0)
df_scan ref regular64   1026   66557568(   1039962)4543872(
70998)  0( 0)

are by far the biggest alloc-pool users.

bitmap stats are confusing because they show leaks for bitmaps we free
by releasing their obstack.  DF and PTA bitmaps are largest.

We leak some VECs ...

c-family/c-pragma.c:619 (push_visibility)24: 0.0% 24   
   1: 0.0%
cp/pt.c:471 (maybe_begin_member_template_process 24: 0.0% 24   
   1: 0.0%
function.c:4513 (push_struct_function)   40: 0.0% 40   
   1: 0.0%
vec.c:307 (vec_stack_p_reserve_exact_1)  40: 0.0% 40   
   1: 0.0%
tree-ssa-loop-ivopts.c:3070 (multiplier_allowed_328: 0.0%608   
   3: 0.0%
tree-ssa-loop-ivopts.c:3153 (get_address_cost)  328: 0.0%608   
   3: 0.0%
tree-ssa-sccvn.c:745 (copy_reference_ops_from_re392: 0.0% 806232   
  102098: 4.6%
cfgloop.h:583 (fel_init)480: 0.0%860   
 106: 0.0%
c-family/c-pragma.c:1246 (c_register_pragma_1)  584: 0.0%696   
   4: 0.0%
function.c:156 (push_function_context)  976: 0.0%   1200   
   8: 0.0%
ira.c:3699 (find_moveable_pseudos) 1240: 0.0% 221128   
 513: 0.0%
passes.c:2188 (execute_one_pass)   4360: 0.1% 655320   
   16466: 0.7%
tree-ssa-structalias.c:3870 (handle_lhs_call)  9576: 0.2%  18360   
 133: 0.0%
ipa-ref.c:55 (ipa_record_reference)   60184: 1.1% 327640   
5813: 0.3%
cfgloop.c:1143 (get_loop_exit_edges)  73184: 1.3% 157888   
   62221: 2.8%
tree-into-ssa.c:940 (mark_phi_for_rewrite)   153360: 2.7% 164096   
  17: 0.0%
cfgloop.c:1134 (get_loop_exit_edges) 166592: 3.0% 238712   
   11639: 0.5%
ipa-reference.c:184 (set_reference_optimization_ 180248: 3.2% 248064   
  47: 0.0%
tree-into-ssa.c:321 (get_ssa_name_ann)   627448:11.2% 716496   
  14: 0.0%
tree-ssa-sccvn.c:3657 (extract_and_process_scc_f1246864:22.3%1291960   
  105903: 4.7%
tree-ssa-loop-im.c:1562 (record_mem_ref_loc)1292560:23.1%1392576   
   55465: 2.5%
tree-ssa-loop-im.c:1551 (record_mem_ref_loc)1771800:31.7%3141360   
   52717: 2.4%

I'll look at the loop and sccvn parts.

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

--- Comment #4 from Diego Novillo  2012-08-16 
12:04:59 UTC ---
Tentative fix: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01046.html

Don't have an old enough compiler to test it myself.  Need help with testing.

[Bug target/54272] [SH] Add support for addv / subv instructions

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  2012-08-16 
11:23:42 UTC ---
(In reply to comment #1)

For linux environment, libc's abort function is a rather complex
function and trapa handler should do equivalent things to keep
complete binary compatibility.  I guess that it isn't worth to do
so.  You can introduce simple trapa sequence as an ABI changing -m
option on linux, though trap numbers < 32 are allocated for the
syscalls and all other numbers are given for debug purposes and
generate SIGTRAP with modified pc which points to trapa instruction
itself.  If the user program uses its own SIGTRAP handlers, this
might be problematic.  Perhaps the "sleep" instruction will be
a candidate because current libc uses it for ABORT_INSTRUCTION,
though it would be bad for bare metal cases.
BTW, there is a known SH4 core bug for trapa instruction and we
are using 5 or r0,r0 instructions just after trapa.  See libitm/
config/sh/futex_bits.h for example.

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-08-16 
11:22:06 UTC ---
Fails with a 4.1 host libstdc++, succeeds with a 4.6 host libstdc++.

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-08-16 
11:18:42 UTC ---
Another fix is to include all system headers (and thus gmp.h) from system.h
which always comes before includes of intl.h.

[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2
Summary|[4.7 Regression] Bad|[4.7/4.8 Regression] Bad
   |alignment code generated|alignment code generated
   |for Neon loads  |for Neon loads

[Bug libstdc++/54228] [4.6 Regression] 22_locale/num_put/put/char/9780-2.cc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.4

[Bug middle-end/54224] [4.8 Regression] Bogus -Wunused-function warning with static function

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug tree-optimization/54153] [4.8 Regression] Bytemark IDEA 6% slower

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug c++/54144] [4.6 Regression] With -std=c++0x certain incorrect arguments to map.insert cause gcc crash

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.4

[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2

[Bug other/53923] [4.8 Regression] ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2

[Bug debug/53671] [4.8 Regression] Many guality test failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

--- Comment #10 from Alexandre Oliva  2012-07-06 
11:37:19 UTC ---
Author: aoliva
Date: Fri Jul  6 11:37:14 2012
New Revision: 189325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189325
Log:
PR rtl-optimization/53827
PR debug/53671
PR debug/49888
* alias.c (memrefs_conflict_p): Adjust offset and size by the
same amount for alignment ANDs.

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

[Bug middle-end/53062] [4.8 Regression] 445.gobmk in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug bootstrap/53343] [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' breaks bootstrap

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug other/54279] [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0