[Bug target/48723] ICE on function returning structure with -fstack-check on corei7-avx

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2011-05-03 
07:20:06 UTC ---
Author: ebotcazou
Date: Tue May  3 07:20:01 2011
New Revision: 173288

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173288
Log:
PR target/48723
* config/i386/i386.c (ix86_expand_prologue): Do not probe the stack
for -fstack-check if the size to allocate is negative.

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

[Bug target/48723] ICE on function returning structure with -fstack-check on corei7-avx

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Botcazou  2011-05-03 
07:23:42 UTC ---
.

[Bug target/48723] ICE on function returning structure with -fstack-check on corei7-avx

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2011-05-03 
07:20:35 UTC ---
Author: ebotcazou
Date: Tue May  3 07:20:30 2011
New Revision: 173289

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173289
Log:
PR target/48723
* config/i386/i386.c (ix86_expand_prologue): Do not probe the stack
for -fstack-check if the size to allocate is negative.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/i386.c

[Bug c/48850] New: Bogus overflow in constant expression warning

[rguenth at gcc dot gnu.org]

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

   Summary: Bogus overflow in constant expression warning
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic, rejects-valid
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


typedef __SIZE_TYPE__ size_t;

extern char a[((size_t)-1 >> 1) + 1]; /* { dg-error "too large" } */
extern char b[((size_t)-1 >> 1)];
extern int c[(((size_t)-1 >> 1) + 1) / sizeof(int)]; /* { dg-error "too large"
} */
extern int d[((size_t)-1 >> 1) / sizeof(int)];

is rejected with -pendantic-errors:

t.c:3:13: error: size of array 'a' is too large
t.c:4:1: error: overflow in constant expression [-Woverflow]
t.c:5:12: error: size of array 'c' is too large
t.c:6:1: error: overflow in constant expression [-Woverflow]

the overflows reported are bogus.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-05-03 
09:03:22 UTC ---
Good point.  I think the requirement for constant complexity should have been
removed by LWG 675.  Pending clarification from the committee I think I would
implement it with the usual swap with temporary, giving linear complexity.
  valarray(std::move(v)).swap(*this);

[Bug tree-optimization/48846] Many -O2 -flto testsuite failures with -m32 -mavx

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2011-05-03 
09:05:58 UTC ---
We have a field-decl with off_align == 255, thus DECL_OFFSET_ALIGN is
technically undefined (computed as 1u << 255).  Things go downhill from there
in at gimplify.c:2051 where we call

  /* Divide the offset by its alignment.  */
  offset = size_binop_loc (loc, EXACT_DIV_EXPR, offset, factor);

with offset and factor == 0 because inn int_const_binop we do

case ROUND_DIV_EXPR:
  if (double_int_zero_p (op2))
return NULL_TREE;

and nothing checks for that result.

The bug is in the LTO streamer which packs DECL_OFFSET_ALIGN as a 8 bit
value, assumig it is decl_common.off_align which it is not.

Not sure why this is exposed by the build_int_cst patch.

Well, I have a patch anyway.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  2011-05-03 
09:27:24 UTC ---
Agreed, thanks for the feedback, let's implement it like this, for now.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2011-05-03 
09:55:45 UTC ---
It would be possible to make it constant complexity, by delaying
destruction+deallocation of the old elements of *this until its destructor runs
(at which point "an implementation may return all allocated memory") but that
would require keeping a collection of previous arrays to be freed on
destruction.
That collection would not be part of the object's value so wouldn't need to be
copied or moved, but I don't think we want to take that approach.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2011-05-03 
10:11:48 UTC ---
I think I see what you mean, but actually, I'm not sure that this kind of
sophistication would be consistent with the rationale of LWG 675: if I
understand it correctly, we really want the move-assigned-to object to behave
similarly to the copy-assigned-to object, thus destruct and release
immediately, no? We want the moral equivalent of this->clear() &
this->swap(__other).

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2011-05-03 
10:25:12 UTC ---
I'm wondering if, waiting for some possible feedback from the Committee, we
shouldn't instead simply swap the data members and disregard LWG 675 for now.
Arguably, for std::valarray, where performance is everything, the constant
complexity and total nothrow guarantee that two POD swaps achieve has the
preference to any other nice feature...

[Bug tree-optimization/48846] Many -O2 -flto testsuite failures with -m32 -mavx

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-03 
10:21:48 UTC ---
Author: rguenth
Date: Tue May  3 10:21:44 2011
New Revision: 173299

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173299
Log:
2011-05-03  Richard Guenther  

PR lto/48846
* lto-streamer-in.c (unpack_ts_decl_common_value_fields):
Stream decl_common.off_align instead of the derived DECL_OFFSET_ALIGN.
* lto-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/lto-streamer-in.c
branches/gcc-4_6-branch/gcc/lto-streamer-out.c

[Bug tree-optimization/48846] Many -O2 -flto testsuite failures with -m32 -mavx

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-05-03 
10:18:32 UTC ---
Author: rguenth
Date: Tue May  3 10:18:29 2011
New Revision: 173298

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173298
Log:
2011-05-03  Richard Guenther  

PR lto/48846
* lto-streamer-in.c (unpack_ts_decl_common_value_fields):
Stream decl_common.off_align instead of the derived DECL_OFFSET_ALIGN.
* lto-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c

[Bug c/48850] Bogus overflow in constant expression warning

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2011-05-03 10:45:43 UTC ---
Remarks:

* This is clearly a bug; the diagnostics given are simply wrong.

* It's not a conformance bug, as C99 permits a limit on object size as 
small as 64KiB (in a hosted environment) (and the apparent limit here - 
see  - is 1EiB).

* If it's hard to support such large objects for some reason, a call to 
sorry () is the appropriate way to diagnose the lack of support instead of 
incorrect overflow diagnostics.  There would still be a bug, since GNU 
programs should avoid arbitrary limits (meaning anything smaller than that 
imposed by the target instruction set, C semantics, ABI etc.), but a less 
serious one (GCC is full of inappropriate arbitrary limits, such as 2GB 
for a string constant, but the only ones people seem to encounter in 
practice are those from stack overflow).

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2011-05-03 
10:44:41 UTC ---
I'm also thinking that in terms of complexity, in this entire discussion we are
just shuffling work around in time. In LWG 675 it is established that clearing
first increases the complexity from constant to linear because the destructors
are called immediately, but sooner or later those destructors would have run
anyway, eh! On the other hand, calling the destructors immediately has the
advantage that we know all the resources owned by *this are released *now*. I'm
not sure we have an exact equivalent of that for valarray, outside resize(0) or
just some user-invisible implementation details. I'm coming to the conclusion
that, barring a clarification from the Committee, the straightforward thing to
do is just swapping the data members, the destructors of the temporarie will
run when they want, the move-assignment itself is certainly fast and nothrow,
as the FDIS wants.

[Bug target/48808] ICE in spill_failure, at reload1.c:2113

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.03 10:54:06
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #1 from Ian Bolton  2011-05-03 10:54:06 
UTC ---
Confirmed on r173122 of trunk, using the command-line args provided by the
reporter.

I have managed to traced it back to happening somewhere between r172185 (works)
and r172316 (ICEs) of trunk.  Looking through the Changelogs for "reload", the
most likely candidates are:

r172297 | cltang | 2011-04-12 05:42:55 +0100 (Tue, 12 Apr 2011) | 10 lines

2011-04-11  Chung-Lin Tang  
Richard Earnshaw  

PR target/48250
* config/arm/arm.c (arm_legitimize_reload_address): Update cases
to use sign-magnitude offsets. Reject unsupported unaligned
cases. Add detailed description in comments.
* config/arm/arm.md (reload_outdf): Disable for ARM mode; change
condition from TARGET_32BIT to TARGET_ARM.

r172231 | aesok | 2011-04-09 20:10:45 +0100 (Sat, 09 Apr 2011) | 8 lines

* expr.c (expand_expr_real_1): Use add_to_hard_reg_set function
instead of loop.
* sel-sched.c (mark_unavailable_hard_regs): Likewise.
* function.c (record_hard_reg_sets): Likewise.
* ira.c (compute_regs_asm_clobbered): Likewise.
* sched-deps.c (sched_analyze_1): Likewise.
* reload1.c (mark_reload_reg_in_use, choose_reload_regs): Likewise.

r172197 | danglin | 2011-04-08 17:21:39 +0100 (Fri, 08 Apr 2011) | 12 lines

PR target/48366
* config/pa/pa.c (hppa_register_move_cost): Increase to 18 cost of
move from floating point to shift amount register .
(emit_move_sequence): Remove secondary reload support for floating
point to shift amount amount register copies.
(pa_secondary_reload): Return GENERAL_REGS for floating point/shift
amount register copies.
* config/pa/pa32-regs.h (HARD_REGNO_MODE_OK): For shift amount
register, return false if mode isn't a scalar integer mode.
* config/pa/pa64-regs.h (HARD_REGNO_MODE_OK): Likewise.

I don't have more time to devote to investigating this today, but hopefully
someone else will be able to work out which change it was.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  2011-05-03 
11:18:28 UTC ---
(In reply to comment #12)
> I think I see what you mean, but actually, I'm not sure that this kind of
> sophistication would be consistent with the rationale of LWG 675: if I

It definitely wouldn't - but do the general container requirements apply to
valarray? if not, 675 is irrelevant
(I think it is relevant and 675 should have removed the constant complexity
requirement for valarray's move assignment op)

> understand it correctly, we really want the move-assigned-to object to behave
> similarly to the copy-assigned-to object, thus destruct and release
> immediately, no? We want the moral equivalent of this->clear() &
> this->swap(__other).

I agree that makes sense.

My suggestion about delaying deallocation only makes sense if we want to
implement the letter of the FDIS and have constant complexity for valarray move
assignment (in contrast with other containers) - but let's get clarification on
whether 675 should have been applied to valarray too

[Bug driver/48832] -O2 does not imply -fomit-frame-pointer, contrary to --help=optimizers -v -Q

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-05-03 
11:15:30 UTC ---
On the 4.5 branch this is expected.  On trunk I get as well

> ./xgcc -B. -S t.c -m32 -O2
> cat t.s
.file   "t.c"
.text
.p2align 4,,15
.globl  f
.type   f, @function
f:
.LFB0:
movl$1, %eax
ret

how did you configure?  What is the output of the gcc command when appending
-v?

[Bug gcov-profile/48845] [4.7 regression] All g++.dg/tree-prof and gcc.dg/{matrix, tree-prof} executions tests fail on Solaris 8/9

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug middle-end/48849] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 CC||matz at gcc dot gnu.org

--- Comment #4 from Richard Guenther  2011-05-03 
11:17:07 UTC ---
I think it is more likely caused by Michas type merging changes (ISTR he
was running into a similar issue at some point).

[Bug rtl-optimization/48696] Horrible bitfield code generation on x86

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Guenther  2011-05-03 
11:20:34 UTC ---
Looking into bitfield lowering again.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

Summary|Invalid UP rounding with F  |Invalid UP/DOWN rounding
   |editing |with F editing

--- Comment #17 from Jerry DeLisle  2011-05-03 
11:45:06 UTC ---
The first part of this for DOWN side is easy:

Index: write_float.def
===
--- write_float.def(revision 173234)
+++ write_float.def(working copy)
@@ -242,7 +242,13 @@ output_float (st_parameter_dt *dtp, const fnode *f
 if (!sign_bit)
   goto skip;
 rchar = '0';
-break;
+/* Scan for trailing zeros to see if we really need to round it.  */
+for(i = nbefore + nafter; i < ndigits; i++)
+  {
+if (digits[i] != '0')
+  goto do_rnd;
+  }
+goto skip;
   case ROUND_NEAREST:
 /* Round compatible unless there is a tie. A tie is a 5 with
all trailing zero's.  */

The last two cases with + or - .09 is more subtle.  We are incorrectly forcing
it to zero and not rounding at all.  I am still working at that part.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

--- Comment #16 from Paolo Carlini  2011-05-03 
11:50:22 UTC ---
I sent a message to the reflector. Let's suspend this for now.

[Bug tree-optimization/48625] [trans-mem] Segfault in libitm when compiling with -O2

[patrick.marlier at gmail dot com]

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

--- Comment #3 from Patrick Marlier  
2011-05-03 12:06:13 UTC ---
The problem is that _ITM_beginTransaction shouldn't have caller save
optimization because if the transaction aborts, registers will get random
values. It should be ok for others ITM functions.
I fixed it by adding RETURN_TWICE attribute to BUILT_IN_TM_START as a
workaround but I know it shouldn't be fixed like this. I had a look into gcc
sources but I didn't find the right way to fix it.

By the way, if a user wants to use explicit calls to _ITM_ functions to create
its TM program, _ITM_beginTransaction should have a specific attribute to avoid
caller save optimization. In the same way, the tail call optimization must be
forbidden on _ITM_commitTransaction. How should it be managed?

Patrick Marlier.

[Bug lto/48851] New: lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[michael.a.richmond at nasa dot gov]

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

   Summary: lto-plugin.c:224:7: error: missing sentinel in
function call [-Werror=format]
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.a.richm...@nasa.gov
  Host: i386-unknown-openbsd4.9
Target: i386-unknown-openbsd4.9
 Build: i386-unknown-openbsd4.9


When I compile gcc under OpenBSD 4.9 I get the following messages:

/home/mrichmon/gcc-4.7-20110416/lto-plugin/lto-plugin.c: In function
'parse_table_entry':
/home/mrichmon/gcc-4.7-20110416/lto-plugin/lto-plugin.c:224:7: error: missing
sentinel in function call [-Werror=format]
/home/mrichmon/gcc-4.7-20110416/lto-plugin/lto-plugin.c: In function
'exec_lto_wrapper':
/home/mrichmon/gcc-4.7-20110416/lto-plugin/lto-plugin.c:525:3: error: missing
sentinel in function call [-Werror=format]
cc1: all warnings being treated as errors

A rough-and-ready workaround is to compile lto-plugin.c without -Werror

[Bug libfortran/48852] New: Invalid spaces in list-directed output of complex constants

[thenlich at users dot sourceforge.net]

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

   Summary: Invalid spaces in list-directed output of complex
constants
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


There are invalid spaces in complex constants in list-directed output:

print *, (1.0, 0.0) ! " (  1.,  0.)" expected "
(1.,0.)"

Fortran 2003/2008:
"Real constants are produced with the effect of either an F edit descriptor or
an E edit descriptor, depending on the magnitude x of the value and a range
10^d1 <= x < 10^d2, where d1 and d2 are processor-dependent integers. If the
magnitude x  is within this range or is zero, the constant is produced using
0PFw.d; otherwise, 1PEw.d Ee is used.

Complex constants are enclosed in parentheses with a separator between the real
and imaginary parts, each produced as defined above for real constants. The
separator is a comma if the decimal edit mode is POINT; it is a semicolon if
the decimal edit mode is COMMA. The end of a record may occur between the
separator and the imaginary part only if the entire constant is as long as, or
longer than, an entire record. The only embedded blanks permitted within a
complex constant are between the separator and the end of a record and one
blank at the beginning of the next record."

Part of the problem is caused by GFortran using Gw.dEe editing instead of the
Fw.d editing required by the standard (i.e. appending the n blanks at the end).
This is a waste of space for real constants and an outright bug for complex
constant.

[Bug target/48792] ICE in failed_reload, at reload1.c:6000

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.03 12:54:27
 CC||ibolton at gcc dot gnu.org
  Known to work||4.7.0
   See Also||http://gcc.gnu.org/bugzilla
   ||/show_bug.cgi?id=48808
 Ever Confirmed|0   |1

--- Comment #1 from Ian Bolton  2011-05-03 12:54:27 
UTC ---
Confirmed.

r170870 works.
r172057 is broken.

I think this is related to PR48808, but that one works for r172057, so I think
that there is more likely some root cause that gets exposed in these two PRs.

[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized

[ami_stuff at o2 dot pl]

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

ami_stuff  changed:

   What|Removed |Added

  Known to fail||

--- Comment #15 from ami_stuff  2011-05-03 12:34:47 UTC 
---
Almost 1,5 year passed and still no one cares to fix a long-standing, critical
bug which generates a broken code for m68k target (ffmpeg, sox, ...).

[Bug target/48774] [4.6/4.7 Regression] gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-05-03 
13:01:17 UTC ---
Author: jakub
Date: Tue May  3 13:01:12 2011
New Revision: 173301

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173301
Log:
PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
only succeed if req_mode is the same as set_mode.

* gcc.dg/pr48774.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr48774.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/48774] [4.6/4.7 Regression] gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek  2011-05-03 
13:07:20 UTC ---
Fixed.

[Bug target/48774] [4.6/4.7 Regression] gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-05-03 
13:06:14 UTC ---
Author: jakub
Date: Tue May  3 13:06:06 2011
New Revision: 173302

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173302
Log:
PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
only succeed if req_mode is the same as set_mode.

* gcc.dg/pr48774.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48774.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/i386.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug debug/48853] New: [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] Wrong DWARF codegen when Pmode !=
ptr_mode
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ja...@gcc.gnu.org


Revision 173210:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg01406.html

breaks DWARF codegen when Pmode != ptr_mode.  For x32,
I got

FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+bar
FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+foo
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (internal compiler
error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (internal compiler
error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (internal compiler
error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (internal compiler
error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2 -flto  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O2  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/alloca-1.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O1  (internal compiler error)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto -flto-partition=none 
(test for excess errors)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto  (internal compiler
error)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto  (internal compiler
error)
FAIL: gcc.dg/torture/stackalign/nested-2.c  -O2 -flto  (test for e

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.03 13:47:40
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-05-03 
13:47:40 UTC ---
Both calls do have a NULL sentinel argument.  You didnt' specify whether you
see the error with using the host compiler or the just compiled compiler
(I don't see any warning with a GCC 4.3 host compiler).

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-05-03 
13:53:46 UTC ---
x32 is not a supported target.  Do you have something that is reproduceable on
supported targets?  ia64-hpux is the only one I think...

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #2 from H.J. Lu  2011-05-03 13:57:23 
UTC ---
(In reply to comment #1)
> x32 is not a supported target.  Do you have something that is reproduceable on
> supported targets?  ia64-hpux is the only one I think...

Steve, have you seen any DWARF regressions on ia64-hpux?

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[michael.a.richmond at nasa dot gov]

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

--- Comment #2 from Michael Richmond  
2011-05-03 14:01:53 UTC ---
I believe it is a compiled compiler. Here are the two instructions that
immediately precede the error messages:

/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=compile
/home/mrichmon/gcc-4.7-20110416/g95/./prev-gcc/xgcc
-B/home/mrichmon/gcc-4.7-20110416/g95/./prev-gcc/
-B/home/mrichmon/irun/i386-unknown-openbsd4.9/bin/
-B/home/mrichmon/irun/i386-unknown-openbsd4.9/bin/
-B/home/mrichmon/irun/i386-unknown-openbsd4.9/lib/ -isystem
/home/mrichmon/irun/i386-unknown-openbsd4.9/include -isystem
/home/mrichmon/irun/i386-unknown-openbsd4.9/sys-include-DHAVE_CONFIG_H -I.
-I/home/mrichmon/gcc-4.7-20110416/lto-plugin 
-I/home/mrichmon/gcc-4.7-20110416/lto-plugin/../include -DHAVE_CONFIG_H  -Wall
-Werror -g -O2 -gtoggle -c -o lto-plugin.lo
/home/mrichmon/gcc-4.7-20110416/lto-plugin/lto-plugin.c
libtool: compile:  /home/mrichmon/gcc-4.7-20110416/g95/./prev-gcc/xgcc
-B/home/mrichmon/gcc-4.7-20110416/g95/./prev-gcc/
-B/home/mrichmon/irun/i386-unknown-openbsd4.9/bin/
-B/home/mrichmon/irun/i386-unknown-openbsd4.9/bin/
-B/home/mrichmon/irun/i386-unknown-openbsd4.9/lib/ -isystem
/home/mrichmon/irun/i386-unknown-openbsd4.9/include -isystem
/home/mrichmon/irun/i386-unknown-openbsd4.9/sys-include -DHAVE_CONFIG_H -I.
-I/home/mrichmon/gcc-4.7-20110416/lto-plugin
-I/home/mrichmon/gcc-4.7-20110416/lto-plugin/../include -DHAVE_CONFIG_H -Wall
-Werror -g -O2 -gtoggle -c
/home/mrichmon/gcc-4.7-20110416/lto-plugin/lto-plugin.c  -fPIC -DPIC -o
.libs/lto-plugin.o

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

--- Comment #17 from Paolo Carlini  2011-05-03 
14:13:37 UTC ---
I'm under the impression that later today we can resolve this: Howard and
Daniel agree on the reflector that we want something similar to the clear() +
swap semantics we have in the containers, essentially. And noexcept can stay.

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]

[paolo at gcc dot gnu.org]

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

--- Comment #18 from paolo at gcc dot gnu.org  
2011-05-03 14:20:49 UTC ---
Author: paolo
Date: Tue May  3 14:20:45 2011
New Revision: 173309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173309
Log:
2011-05-03  Paolo Carlini  

PR libstdc++/48750
* include/parallel/multiway_merge.h: Run _ValueType destructors.
* include/parallel/multiway_mergesort.h: Likewise.
* include/parallel/quicksort.h: Likewise.
* include/parallel/random_shuffle.h: Likewise.
* include/parallel/partial_sum.h: Likewise.
* include/parallel/losertree.h: Run destructors; minor tweaks.
* include/parallel/par_loop.h: Run destructors, fix memory
allocations and deallocations.
* testsuite/26_numerics/accumulate/48750.cc: New.

* testsuite/ext/profile/mutex_extensions_neg.cc: Do not run in
parallel-mode to avoid spurious multiple errors.


Added:
trunk/libstdc++-v3/testsuite/26_numerics/accumulate/48750.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/parallel/losertree.h
trunk/libstdc++-v3/include/parallel/multiway_merge.h
trunk/libstdc++-v3/include/parallel/multiway_mergesort.h
trunk/libstdc++-v3/include/parallel/par_loop.h
trunk/libstdc++-v3/include/parallel/partial_sum.h
trunk/libstdc++-v3/include/parallel/quicksort.h
trunk/libstdc++-v3/include/parallel/random_shuffle.h
trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu.org

--- Comment #3 from Nathan Froyd  2011-05-03 
14:19:37 UTC ---
Can you attach preprocessed source to the issue (use the -save-temps option)? 
I wonder if OpenBSD's headers are defining NULL in some odd way.  It's also
possible that recent refactorings to __attribute__((sentinel)) broke
something...

[Bug c++/48854] New: signal mask is not restored when exiting signal handler via exception

[cubbi at cubbi dot org]

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

   Summary: signal mask is not restored when exiting signal
handler via exception
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cu...@cubbi.org


When using -fnon-call-exception to convert a SIGSEGV or SIGFPE to a C++
exception, the straightforward implementation fails to handle the same signal
more than once because it remains masked after the signal handler and the
exception handler have been executed.

While this is reasonable behavior, perhaps it should be briefly mentioned in
the documentation on -fnon-call-exceptions?

Example (compile with -fnon-call-exceptions)

#include 
#include 
#include 
void handler(int signo)
{
std::cerr << "Signal handler called with " << signo << '\n';

// uncomment the following lines to fix the bug
// sigset_t x;
// sigemptyset (&x);
// sigaddset(&x, SIGSEGV);
// sigprocmask(SIG_UNBLOCK, &x, NULL);

throw std::runtime_error("sigsegv");
}

int main()
{
signal(SIGSEGV, handler);
int* invalid_p = NULL;

// first attempt: always works
try{
*invalid_p = 7;
} catch(const std::exception& e)
{
std::cerr << "main() caught " << e.what() << '\n';
}

// second attempt: fails unless uncommented sigprocmask above
try{
*invalid_p = 7;
} catch(const std::exception& e)
{
std::cerr << "main() caught " << e.what() << '\n';
}
}

reproduced using
gcc 3.4.6 (linux x86_64)
gcc 4.4.1 (linux i386)
gcc 4.5.2 (linux x86_64)
gcc 4.6.0 20110325 (linux x86_64)

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-05-03 15:02:26 
UTC ---
Yes, I am seeing some new failures on IA64 HP-UX.  I do not get the stackalign
failures but I do get:

FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C scan-assembler
DW_OP_addr[^
\n\r]*[\n\r]*[^\n\r]*staticvar1
FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C scan-assembler
DW_OP_addr[^
\n\r]*[\n\r]*[^\n\r]*staticvar2
FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+bar
FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+foo

These showed up between 173204 and 173229 so they are probably due to the same
change.

[Bug c++/48854] signal mask is not restored when exiting signal handler via exception

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-05-03 
15:16:00 UTC ---
That's standard behavior of signal and not something GCC has influence on.

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.03 15:27:49
 Ever Confirmed|0   |1

--- Comment #4 from H.J. Lu  2011-05-03 15:27:49 
UTC ---
(In reply to comment #3)
> Yes, I am seeing some new failures on IA64 HP-UX.  I do not get the stackalign
> failures but I do get:

I don't think ia664 hp-ux run stackalign tests.

> FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C scan-assembler
> DW_OP_addr[^
> \n\r]*[\n\r]*[^\n\r]*staticvar1
> FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C scan-assembler
> DW_OP_addr[^
> \n\r]*[\n\r]*[^\n\r]*staticvar2
> FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
> DW_OP_addr[\\n\\r]+[^\\n\\r]+bar
> FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
> DW_OP_addr[\\n\\r]+[^\\n\\r]+foo
> 
> These showed up between 173204 and 173229 so they are probably due to the same
> change.

FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+bar
FAIL: gcc.dg/debug/dwarf2/var2.c scan-assembler
DW_OP_addr[\\n\\r]+[^\\n\\r]+foo

are the common failures for Pmode != ptr_mode targets.

[Bug c/48796] gcc: Internal error: Killed (program cc1) while compiling PHP

[wgj at cast dot uark.edu]

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

--- Comment #2 from William Johnston  2011-05-03 
15:37:55 UTC ---
(In reply to comment #1)
> You appearantly ran out of memory and the kernel decided to kill cc1.  This
> is likely not a GCC bug.  How much memory do you have?

Oh, that's possible I guess. I have 256MB and no swap. I can't say how much was
remaining when I was compiling the program. 

> 
> Please attach apprentice.i.

I thought I had attached the apprentice.i file... I just tried it again and
it's too large. 

You can pick it up here: ftp://cast-ftp1.cast.uark.edu/wgj/apprentice.i

[Bug c++/28501] ICE with __real__ and implicit type conversion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|mark at codesourcery dot|jason at gcc dot gnu.org,
   |com, mmitchel at gcc dot|paolo.carlini at oracle dot
   |gnu.org |com
  Known to fail||

--- Comment #7 from Paolo Carlini  2011-05-03 
15:48:01 UTC ---
Hi Jason. A small issue which I fixed a few days ago reminded me this one,
pretty old, on which I worked a bit two years ago, then left alone...

At the time I figured out the below patchlet, which still avoids the ICE,
passes the testsuite, and apparently provides a sensible semantics (eg, if the
operator returns 1, i is initialized to 1; if the testcase is tweaked to use
__imag__, i is initialized to 0).

What do you think? Or shall we just reject the snippet?

Index: call.c
===
--- call.c  (revision 173309)
+++ call.c  (working copy)
@@ -2586,6 +2586,12 @@ add_builtin_candidate (struct z_candidate **candid
 types are TYPE2.  */
   break;

+case REALPART_EXPR:
+case IMAGPART_EXPR:
+  if (ARITHMETIC_TYPE_P (type1))
+   break;
+  return;
+ 
 default:
   gcc_unreachable ();
 }

[Bug c/48796] gcc: Internal error: Killed (program cc1) while compiling PHP

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-05-03 
15:46:42 UTC ---
That's not a lot of memory.

You could use gzip to compress the file before attaching it.

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]

[bugs at sehe dot nl]

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

--- Comment #19 from Seth Heeren  2011-05-03 15:47:28 UTC 
---
Cheers!

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-03 
16:02:21 UTC ---
NULL seems to be just 0, ok for C++ maybe but broken for C.  Thus this seems
to be a OpenBSD header issue.

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-05-03 
16:04:42 UTC ---
Created attachment 24170
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24170
gcc47-pr48853.patch

This patch should fix var2.c on ia64-hpux - the patch will for memory addresses
only (i.e. when mem_mode is not VOIDmode) allow SYMBOL_REFs/LABEL_REFs/CONST of
larger mode than DWARF2_ADDR_SIZE, assuming it is Pmode and ptr_mode has
DWARF2_ADDR_SIZE.  It is a total mess though, because whether it is sign
extended or zero extended or something else isn't actually represented in the
debug info, the debug info consumer needs to know.

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  2011-05-03 
16:09:14 UTC ---
GCC provided stddef.h defines NULL properly, apparently OpenBSD thinks it knows
better and provides its buggy definition.
Anyway, if we want to work around it, we could use (void *) NULL or (void *) 0
instead of NULL to terminate concat arguments.

[Bug bootstrap/48855] New: [4.7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] LTO profiledbootstrap failure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 173309 configured with

../src-trunk/configure \
 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-cloog-backend=isl
--with-ppl-include=/opt/gnu/include --with-ppl-lib=/opt/gnu/lib64
--with-cloog-include=/opt/gnu/include --with-cloog-lib=/opt/gnu/lib64
--with-build-config=bootstrap-lto --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

gave me:

http://gcc.gnu.org/ml/gcc-regression/2011-05/msg00063.html

../../src-trunk/gcc/ira-color.c: In function 'improve_allocation':
../../src-trunk/gcc/ira-color.c:4512:1: error: corrupted profile info: profile
data is not flow-consistent
../../src-trunk/gcc/ira-color.c:4512:1: error: corrupted profile info: number
of executions for edge 44-45 thought to be -3942
../../src-trunk/gcc/ira-color.c:4512:1: error: corrupted profile info: number
of executions for edge 44-46 thought to be 1580350
../../src-trunk/gcc/ira-color.c:4512:1: error: corrupted profile info: number
of iterations for basic block 45 thought to be -3942
../../src-trunk/gcc/ira-color.c:4512:1: error: corrupted profile info: number
of executions for edge 95-96 thought to be -114
../../src-trunk/gcc/ira-color.c:4512:1: error: corrupted profile info: number
of executions for edge 95-1 thought to be 114
make[6]: *** [ira-color.o] Error 1

Revision 173299 is OK.

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

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

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

--- Comment #7 from Andreas Schwab  2011-05-03 16:20:35 
UTC ---
0 is a valid null pointer constant in C.  If you want to use NULL as a sentinel
you must always cast it.

[Bug c/48742] [4.5 Regression] Internal error in gimplify_expr

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-05-03 
16:34:37 UTC ---
Author: jakub
Date: Tue May  3 16:34:32 2011
New Revision: 173326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173326
Log:
Backport from mainline
2011-04-27  Jakub Jelinek  

PR c/48742
* c-typeck.c (build_binary_op): Don't wrap arguments if
int_operands is true.

* gcc.c-torture/compile/pr48742.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr48742.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/c-typeck.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/48856] New: Crash when compiling certain source code with C++0x

[thiago at kde dot org]

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

   Summary: Crash when compiling certain source code with C++0x
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thi...@kde.org


GCC crashes when compiling the attached source file in C++0x mode.

Steps to Reproduce:
1. Compile the attached preprocessed source file (Copyright Nokia, LGPL 2.1)
with C++0x support. That is, run:
   g++ -std=c++0x qxmlschema.ii

This results in the following message:

In file included from
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/parser/qmaintainingreader_p.h:226:0,
 from
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/schema/qxsdschemaparsercontext_p.h:55,
 from
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/schema/qxsdschemaparser_p.h:67,
 from
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/api/qxmlschema_p.h:62,
 from
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/api/qxmlschema.cpp:43:
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/parser/qmaintainingreader.cpp:
In member function 'QXmlStreamReader::TokenType
QPatternist::MaintainingReader::readNext()':
/home/tmacieir/src/troll/qt-main/src/xmlpatterns/parser/qmaintainingreader.cpp:86:57:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


I have looked at Mandriva patches to GCC 4.6 and they do not seem to be related
at all (nothing related to the C++ engine at all), so I believe this is a GCC
issue.

The compiler also crashes if I preprocess the sources without -std=c++0x but
compile with it. The crash happens with the exact same messages.

This crash was not present on GCC 4.5.3.

[Bug c++/48856] Crash when compiling certain source code with C++0x

[thiago at kde dot org]

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

--- Comment #1 from Thiago Macieira  2011-05-03 16:31:38 
UTC ---
Created attachment 24171
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24171
Preprocessed sources showing the error (gzipped)

[Bug target/48857] New: V2DI arguments are not passed like other vectors

[meissner at gcc dot gnu.org]

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

   Summary: V2DI arguments are not passed like other vectors
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: meiss...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 24172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24172
Patch to fix the problem

When the VSX extensions were added to the powerpc, V2DI mode was added in an
afterthought.  The machine does not have native V2DI operations, but it is
needed to correctly handle vector conversion of DImode to DFmode.  Because
there were no native V2DI operations, it was not part of VSX_MODE and similar
macros.  This caused V2DImode arguments to be passed and returned differently
than the other vector types (for -mabi=altivec, which is on implicitly for
64-bit).  We should change the compiler so V2DI mode is passed an returned the
same as the other vectors.

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-05-03 
16:36:02 UTC ---
Author: jakub
Date: Tue May  3 16:35:56 2011
New Revision: 173327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173327
Log:
Backport from mainline
2011-04-28  Jakub Jelinek  

PR middle-end/48597
* final.c (final_scan_insn): Call dwarf2out_frame_debug even for
inline asm.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/final.c

[Bug testsuite/48809] [4.4/4.5 Regression] switch statement optimization error

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-05-03 
16:37:19 UTC ---
Author: jakub
Date: Tue May  3 16:37:12 2011
New Revision: 173328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173328
Log:
Backport from mainline
2011-04-30  Jakub Jelinek  

PR tree-optimization/48809
* tree-switch-conversion.c (build_arrays): Compute tidx in unsigned
type.
(gen_inbound_check): Don't compute index_expr - range_min in utype
again, instead reuse SSA_NAME initialized in build_arrays.
Remove two useless gsi_for_stmt calls.

* gcc.c-torture/execute/pr48809.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr48809.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-switch-conversion.c

[Bug tree-optimization/48846] Many -O2 -flto testsuite failures with -m32 -mavx

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-05/msg00154.htm
   ||l
 Resolution||FIXED
   Target Milestone|4.7.0   |4.6.1

--- Comment #6 from Uros Bizjak  2011-05-03 16:44:20 
UTC ---
Works OK, fixed.

[Bug target/48774] [4.6/4.7 Regression] gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-05-03 
16:38:34 UTC ---
Author: jakub
Date: Tue May  3 16:38:25 2011
New Revision: 173329

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173329
Log:
PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
only succeed if req_mode is the same as set_mode.

* gcc.dg/pr48774.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr48774.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/48856] Crash when compiling certain source code with C++0x

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-05-03 
16:54:08 UTC ---
It would also be helpful to reduce the testcase:
http://gcc.gnu.org/bugs/minimize.html

[Bug driver/48832] -O2 does not imply -fomit-frame-pointer, contrary to --help=optimizers -v -Q

[marcus at jet dot franken.de]

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

marcus at jet dot franken.de changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #4 from marcus at jet dot franken.de 2011-05-03 16:46:31 UTC ---
configured by /mp3/gcc.trunk/configure, generated by GNU Autoconf 2.64,
  with options \" '--prefix=/mp3/buildgcc/BIN' '--enable-lto'
'--enable-checking' '--enable-frame-pointer' '--enable-languages=c,lto'\"


oops. not sure where this came from, but I suspect from an earlier debugging
attempt.

so please disregard, my faul.t

[Bug c/48685] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:7034

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-05-03 
16:33:15 UTC ---
Author: jakub
Date: Tue May  3 16:33:09 2011
New Revision: 173324

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173324
Log:
Backport from mainline
2011-04-23  Jakub Jelinek  

PR c/48685
* fold-const.c (fold_convert_loc): Add NOP_EXPR when casting
to VOID_TYPE even around MODIFY_EXPR.

* gcc.dg/pr48685.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr48685.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/fold-const.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/48856] Crash when compiling certain source code with C++0x

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|critical|normal

--- Comment #2 from Jonathan Wakely  2011-05-03 
16:51:49 UTC ---
Severity should not be critical for any C++0x bug, it's an experimental feature
and noone is forced to use.

This doesn't crash for me with 4.6.0 on x86_64-linux, please provide the
information requested at http://gcc.gnu.org/bugs/

[Bug c/48685] [4.5 Regression] ICE in gimplify_expr, at gimplify.c:7034

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek  2011-05-03 
17:17:08 UTC ---
Fixed.

[Bug testsuite/48809] [4.4 Regression] switch statement optimization error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.4/4.5 Regression] switch |[4.4 Regression] switch
   |statement optimization  |statement optimization
   |error   |error

--- Comment #10 from Jakub Jelinek  2011-05-03 
17:17:57 UTC ---
Fixed for 4.5.4+ too.

[Bug c++/48856] Crash when compiling certain source code with C++0x

[thiago at kde dot org]

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

--- Comment #4 from Thiago Macieira  2011-05-03 17:20:13 
UTC ---
Sorry, I forgot the information.

Version: 4.6.0
System: Linux 2.6.38, 32-bit
Command-line: g++ -std=c++0x qxmlschema.ii
GCC was configured with:
./configure --build=i586-mandriva-linux-gnu --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --x-includes=/usr/include --x-libraries=/usr/lib
--disable-libjava-multilib --with-java-home=/usr/lib/jvm/java-rpmbuild
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-java-awt=qt,gtk
--enable-gtk-cairo --with-cloog --with-ppl --enable-cloog-backend=ppl
--disable-libssp --disable-libunwind-exceptions --disable-werror
--enable-__cxa_atexit --enable-bootstrap --enable-checking=release
--enable-gnu-unique-object
--enable-languages=c,ada,c++,fortran,go,java,lto,objc,obj-c++
--enable-linker-build-id --enable-plugin --enable-shared --enable-threads=posix
--with-system-zlib --with-bugurl=https://qa.mandriva.com/ --with-tune=generic
--with-arch=i686 --host=i586-mandriva-linux-gnu
--target=i586-mandriva-linux-gnu

[Bug c/48742] [4.5 Regression] Internal error in gimplify_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jakub Jelinek  2011-05-03 
17:18:36 UTC ---
Fixed.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #91 from Jan Hubicka  2011-05-03 
17:34:56 UTC ---
Hi,
with the patch I just posted for removal of hash tables for cgraph/varpool node
set, the situation with hashing is better. We got from 900s WPA stage to 500s
WPA stage.

Streaming still dominate:
 ipa lto decl in   : 331.26 (56%) usr   5.51 (34%) sys 337.11 (56%) wall 
722314 kB (46%) ggc
 ipa lto decl out  : 118.21 (20%) usr   4.37 (27%) sys 122.57 (20%) wall   
   0 kB ( 0%) ggc
 ipa lto decl merge:  23.61 ( 4%) usr   0.20 ( 1%) sys  23.83 ( 4%) wall   
 962 kB ( 0%) ggc
 inline heuristics :  57.12 (10%) usr   0.14 ( 1%) sys  57.27 ( 9%) wall 
227500 kB (14%) ggc
 TOTAL : 587.0216.36   604.01   
1585790 kB

(I have plans for fixing inliner once more prominent problems are solved)
Streaming in oprofile:
150985   20.6876  lto1 htab_find_slot_with_hash
71532 9.8012  lto1 gimple_types_compatible_p
55971 7.6690  libc-2.11.1.so   _int_malloc
55104 7.5502  lto1 iterative_hash_hashval_t
33160 4.5435  lto1 type_pair_eq
31554 4.3235  libc-2.11.1.so   memset
25670 3.5172  lto1 gtc_visit
23972 3.2846  lto1 gimple_type_hash_1
21562 2.9544  lto1 lto_input_tree
15230 2.0868  lto1 gt_ggc_mx_lang_tree_node
14807 2.0288  lto1 inflate_fast

callgrind profile (of javascript instead of libxul) shows that tree_map_base
hash is the most busy one:

  453,603,428  *  
libiberty/../../libiberty/hashtab.c:htab_find_slot_with_hash'2 
   33,167,620  >   gcc/../../gcc/tree.c:tree_map_base_eq (6633524x) 
  134,245,948  >   libiberty/../../libiberty/hashtab.c:htab_expand (18x) 
 25,459,797  >   gcc/../../gcc/gimple.c:type_pair_eq (2793149x)

and the users of hashing:
   63,519,720  < /libiberty/hashtab.c:htab_find_slot'2 (676308x)
3,975,492,482  < /libiberty/hashtab.c:htab_find_slot (2179693x)
  255,072,048  *  /libiberty/hashtab.c:htab_find_slot_with_hash

   14,530,222  < /gcc/gimple.c:iterative_hash_gimple_type'2 (52634x)
  526,622,873  < /gcc/gimple.c:lookup_type_pair.isra.103.constprop.111
(1621144x)
   17,415,611  < /gcc/gimple.c:iterative_hash_gimple_type (100893x)
   11,734,620  < /gcc/gimple.c:visit'2 (98730x)
  432,531,796  < /gcc/gimple.c:gimple_type_hash_1 (3851023x)
   35,405,473  < /gcc/gimple.c:visit (319520x)
  108,790,992  *  /libiberty/hashtab.c:htab_find_slot'2


Oprofile of the whole build shows also problem in decl_assembler_name_equal
(because of our stupit alias hacks) and can_inline_edge_p.  I will look into
those two.
2607397.1750  lto1 lto1
htab_find_slot_with_hash
1510804.1574  lto1 lto1
decl_assembler_name_equal
1309693.6040  libc-2.11.1.so   libc-2.11.1.so   _int_malloc
1007232.7717  lto1 lto1
gimple_types_compatible_p
97370 2.6794  lto1 lto1
iterative_hash_hashval_t
75051 2.0653  libc-2.11.1.so   libc-2.11.1.so   memset
56508 1.5550  lto1 lto1
bitmap_set_bit
53211 1.4643  lto1 lto1
can_inline_edge_p
51613 1.4203  oprofiledoprofiled   
/usr/bin/oprofiled
49992 1.3757  lto1 lto1
pointer_map_insert
48381 1.3313  lto1 lto1
lto_input_tree
44467 1.2236  lto1 lto1
type_pair_eq
35096 0.9658  libc-2.11.1.so   libc-2.11.1.so   _int_free
35069 0.9650  lto1 lto1 gtc_visit

(this is including ltrans stage)
Honza

[Bug c++/48856] Crash when compiling certain source code with C++0x

[thiago at kde dot org]

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

--- Comment #5 from Thiago Macieira  2011-05-03 17:21:09 
UTC ---
To be exact on the version: gcc version 4.6.0 20110422 (prerelease) (GCC)

[Bug c++/48856] Crash when compiling certain source code with C++0x

[thiago at kde dot org]

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

--- Comment #6 from Thiago Macieira  2011-05-03 17:42:02 
UTC ---
(In reply to comment #3)
> It would also be helpful to reduce the testcase:
> http://gcc.gnu.org/bugs/minimize.html

Thanks for the suggestion. I can't promise I will have the time to do this
any-time soon. 

I'm hoping that the reason for a straight-out crash can be found easily :)

Hopefully this could help:
==11293== Invalid read of size 2
==11293==at 0x816090E: convert_for_initialization (typeck.c:7410)
==11293==by 0x81324B9: digest_init_r (typeck2.c:861)
==11293==by 0x813306B: store_init_value (typeck2.c:674)
==11293==by 0x81095C8: check_initializer (decl.c:5413)
==11293==by 0x811029D: cp_finish_decl (decl.c:5881)
==11293==by 0x814F79D: cp_parser_init_declarator (parser.c:14769)
==11293==by 0x8156B6A: cp_parser_simple_declaration (parser.c:9709)
==11293==by 0x8156D65: cp_parser_block_declaration (parser.c:9595)
==11293==by 0x81577BE: cp_parser_declaration_statement (parser.c:9247)
==11293==by 0x814BE19: cp_parser_statement (parser.c:8172)
==11293==by 0x814C545: cp_parser_statement_seq_opt (parser.c:8431)
==11293==by 0x814C5B8: cp_parser_compound_statement (parser.c:8385)
==11293==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Line where this fails:
7410  if ((TREE_CODE (TREE_TYPE (rhs)) == ARRAY_TYPE
7411   && TREE_CODE (type) != ARRAY_TYPE
7412   && (TREE_CODE (type) != REFERENCE_TYPE
7413   || TREE_CODE (TREE_TYPE (type)) != ARRAY_TYPE))
7414  || (TREE_CODE (TREE_TYPE (rhs)) == FUNCTION_TYPE
7415  && (TREE_CODE (type) != REFERENCE_TYPE
7416  || TREE_CODE (TREE_TYPE (type)) != FUNCTION_TYPE))
7417  || TREE_CODE (TREE_TYPE (rhs)) == METHOD_TYPE)

[Bug c++/28501] ICE with __real__ and implicit type conversion

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2011-05-03 
17:32:43 UTC ---
That patch looks fine to me.

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.1
   Severity|major   |normal

--- Comment #21 from Paolo Carlini  2011-05-03 
17:55:39 UTC ---
Fixed for 4.6.1.

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]

[paolo at gcc dot gnu.org]

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

--- Comment #20 from paolo at gcc dot gnu.org  
2011-05-03 17:54:41 UTC ---
Author: paolo
Date: Tue May  3 17:54:35 2011
New Revision: 173335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173335
Log:
2011-05-03  Paolo Carlini  

PR libstdc++/48750
* include/parallel/multiway_merge.h: Run _ValueType destructors.
* include/parallel/multiway_mergesort.h: Likewise.
* include/parallel/quicksort.h: Likewise.
* include/parallel/random_shuffle.h: Likewise.
* include/parallel/partial_sum.h: Likewise.
* include/parallel/losertree.h: Run destructors; minor tweaks.
* include/parallel/par_loop.h: Run destructors, fix memory
allocations and deallocations.
* testsuite/26_numerics/accumulate/48750.cc: New.

* testsuite/ext/profile/mutex_extensions_neg.cc: Do not run in
parallel-mode to avoid spurious multiple errors.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/accumulate/48750.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/losertree.h
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/multiway_merge.h
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/multiway_mergesort.h
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/par_loop.h
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/partial_sum.h
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/quicksort.h
branches/gcc-4_6-branch/libstdc++-v3/include/parallel/random_shuffle.h
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc

[Bug c++/28501] ICE with __real__ and implicit type conversion

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  
2011-05-03 18:30:41 UTC ---
Author: paolo
Date: Tue May  3 18:30:37 2011
New Revision: 173337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173337
Log:
/cp
2011-05-03  Paolo Carlini  

PR c++/28501
* call.c (add_builtin_candidate): Handle REALPART_EXPR and
IMAGPART_EXPR.

/testsuite
2011-05-03  Paolo Carlini  

PR c++/28501
* g++.dg/ext/complex9.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/complex9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/28501] ICE with __real__ and implicit type conversion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|paolo.carlini at oracle dot |
   |com |
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.0

--- Comment #10 from Paolo Carlini  2011-05-03 
18:33:32 UTC ---
Thanks. Committed.

[Bug target/48808] ICE in spill_failure, at reload1.c:2113

[rmansfield at qnx dot com]

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

--- Comment #2 from Ryan Mansfield  2011-05-03 
19:20:35 UTC ---
The change that introduced the ICE is rev 172201.

http://gcc.gnu.org/viewcvs?view=revision&revision=172201

[Bug c++/48838] [4.6/4.7 Regression] valid template code does not compile

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

[Bug c++/48536] C++0x Automatic Enumerator Incrementation is not compliant with Clause 7.2/5

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  2011-05-03 
20:00:08 UTC ---
I'm not sure #1 is equivalent to #2, but I think they should both be
well-formed.
Jason, can you confirm?

[Bug c++/48856] Crash when compiling certain source code with C++0x

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.03 20:09:46
 Ever Confirmed|0   |1

--- Comment #7 from Jonathan Wakely  2011-05-03 
20:09:46 UTC ---
(In reply to comment #5)
> To be exact on the version: gcc version 4.6.0 20110422 (prerelease) (GCC)

4.6.0 was released on 20110325 so I don't know what that version is, and I
can't reproduce this on i686-pc-linux-gnu with a vanilla 4.6.0, or on x86_64
(using -m32 -std=c++0x) with Red Hat's 4.6.0-6.fc15 or a current 4.7 build.

Please try to reproduce with a FSF version or report this to Mandriva.

[Bug c++/48838] [4.6/4.7 Regression] valid template code does not compile

[dodji at seketeli dot org]

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

--- Comment #4 from dodji at seketeli dot org  
2011-05-03 20:15:50 UTC ---
A candidate patch was posted to
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00219.html

[Bug bootstrap/48855] [4.7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME
   Target Milestone|--- |4.7.0

--- Comment #1 from H.J. Lu  2011-05-03 20:25:26 
UTC ---
Revision 173296 bootstrapped OK.

[Bug c++/48536] C++0x Automatic Enumerator Incrementation is not compliant with Clause 7.2/5

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.03 20:34:19
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2011-05-03 
20:34:19 UTC ---
Agreed.

"Otherwise the type of the initializing value is the same as the type of the
initializing value of the preceding enumerator unless the incremented value is
not representable in that type, in which case the type is an unspecified
integral type sufficient to contain the incremented value. If no such type
exists, the program is ill-formed."

Instead of complaining about overflow, we should adjust the type of EI_2.

But I'm pretty sure #1 and #2 are not equivalent because the initializer for
FI_2 wraps to 0.

[Bug c++/48211] [4.7 Regression] [C++0x] Segment Fault When Compiling

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.03 21:00:51
  Known to work||4.5.2, 4.6.0
Summary|[C++0x] Segment Fault When  |[4.7 Regression] [C++0x]
   |Compiling   |Segment Fault When
   ||Compiling
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #4 from Jonathan Wakely  2011-05-03 
21:00:51 UTC ---
I can confirm this with the 4.7-20110430 snapshot, but only on i686 not x86_64

The code in comment 2 gets a segfault here:

Program received signal SIGSEGV, Segmentation fault.
0x08336684 in ggc_set_mark (p=0xb6f7a878) at
../../gcc-4.7-20110430/gcc/ggc-page.c:1333
1333  if (entry->in_use_p[word] & mask)
(gdb) p entry
$1 = (page_entry *) 0x9014f48
(gdb) p word
$2 = 8699297
(gdb) p entry->in_use_p
$3 = {4293918719}

Valgrind shows lots of errors in cpp.  The code is not valid, I don't know if
the ICE also happens with a fixed version.

The code in comment 1 does not ICE

[Bug c++/47723] internal compiler: Segmentation fault - gcc 4.5.2 Arch Linux

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2011-02-14 08:16:16 |2011.05.03 21:14:02
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #12 from Jason Merrill  2011-05-03 
21:14:02 UTC ---
(In reply to comment #10)
> Jason, does DR 318 mean G++ should accept this, because the constructor is not
> an acceptable lookup result?
> struct S { };
> S* p = new S::S();

I suppose it does.

[Bug c++/47723] internal compiler: Segmentation fault - gcc 4.5.2 Arch Linux

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  2011-05-03 
21:18:14 UTC ---
Actually, I think it's unclear.  318 had to do with elaborated type specifiers,
for which we explicitly say that the lookup is done "ignoring any non-type
names that have been declared."

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

--- Comment #41 from Tobias Burnus  2011-05-03 
21:35:48 UTC ---
Author: burnus
Date: Tue May  3 21:35:44 2011
New Revision: 173341

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173341
Log:
2011-05-03  Tobias Burnus  

PR fortran/18918
* gfortran.dg/coarray/caf.dg: New.
* gfortran.dg/coarray/image_index_1.f90: New, copied
from ../coarray_16.f90.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/
trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp
trunk/gcc/testsuite/gfortran.dg/coarray/image_index_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

--- Comment #42 from Tobias Burnus  2011-05-03 
21:44:30 UTC ---
Author: burnus
Date: Tue May  3 21:44:27 2011
New Revision: 173342

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173342
Log:
2011-05-03  Tobias Burnus  

PR fortran/18918
* trans-intrinsic.c (trans_this_image): Implement version with
coarray argument.

2011-05-03  Tobias Burnus  

PR fortran/18918
* gfortran.dg/coarray/this_image_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/this_image_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[longb at cray dot com]

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

--- Comment #1 from Bill Long  2011-05-03 21:51:29 UTC 
---
As an aside, the code in the Description is a "work-around" to avoid using the
TR 29113 feature that allows Optional arguments.  This would be the preferred
code in the future:

> cat cknew1.f90
module graph_partitions
  use,intrinsic :: iso_c_binding

  interface 
 subroutine Cfun (num, array) bind(c, name="Cfun")
   import :: c_int
   integer(c_int),value :: num
   integer(c_int),optional:: array(*)
 end subroutine Cfun
  end interface

end module graph_partitions

program test
  use graph_partitions
  integer(c_int) :: a(100)

  call Cfun (1, a)
  call Cfun (2)
end program test


The Intel and PGI compilers already support this (no compile errors, correct
output).  The Cray compiler also does if the NEW_FORTRAN environment variable
is set (which just disables the error about having an OPTIONAL dummy in a
BIND(C) interface).  

It is a separate issue from this BUG, but it might be a nice enhancement to
enable the TR feature of allowing OPTIONAL arguments in BIND(C) interfaces. It
appears that some other vendors have already jumped on that bandwagon.

[Bug fortran/48858] New: Incorrect error for same binding label on two generic interface specifics

[longb at cray dot com]

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

   Summary: Incorrect error for same binding label on two generic
interface specifics
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com


For this example code:

> cat ck1.c
#include 
void Cfun ( int n, int *array){

  if ( array == NULL )
printf ( "call %d passes NULL as arg 2 \n", n);
  else
printf ( "call %d passes array address as arg 2 \n", n);
}

[The C part compiles fine.]

> cat ck.f90
module graph_partitions
  use,intrinsic :: iso_c_binding

  interface Cfun
 subroutine cfunc1 (num, array) bind(c, name="Cfun")
   import :: c_int
   integer(c_int),value :: num
   integer(c_int)   :: array(*)
 end subroutine cfunc1

 subroutine cfunf2 (num, array) bind(c, name="Cfun")
   import :: c_int, c_ptr
   integer(c_int),value :: num
   type(c_ptr),value:: array
 end subroutine cfunf2
  end interface
end module graph_partitions

program test
  use graph_partitions
  integer(c_int) :: a(100)

  call Cfun (1, a)
  call Cfun (2, C_NULL_PTR)
end program test


I get

> gcc -c ck1.c
> gfortran ck.f90 ck1.o
ck.f90:11.22:

 subroutine cfunf2 (num, array) bind(c, name="Cfun")
  1
ck.f90:5.22:

 subroutine cfunc1 (num, array) bind(c, name="Cfun")
  2
Error: Binding label 'Cfun' in interface body at (1) collides with the global
entity 'Cfun' at (2)
ck.f90:20.22:



Same behavior for 4.5.2 and 4.6.0.

The same code compiles and executes fine with the Cray, Intel, and PGI
compilers.  The expected output is:

> ./a.out
call 1 passes array address as arg 2 
call 2 passes NULL as arg 2 
>

This code should compile.  There is only one "entity" with the binding lablel
"Cfun".  In the words in the standard, only one "entity of the program" with
this binding label.  The names cfunc2 and cfunc1 are both local identifiers.
(Sections 16.2 and 16.3).

This construction is specifically allowed in the standard to allow users to
call a C function with multiple interfaces, similar to what is illustrated
here.

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

--- Comment #43 from Tobias Burnus  2011-05-03 
21:56:47 UTC ---
Author: burnus
Date: Tue May  3 21:56:45 2011
New Revision: 173343

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173343
Log:
2011-05-03  Tobias Burnus  

PR fortran/18918
* gfortran.dg/coarray/this_image_1.f90: Remove dg-options.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray/this_image_1.f90

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #18 from Paolo Carlini  2011-05-03 
22:13:29 UTC ---
On it.

[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode

[sje at cup dot hp.com]

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

--- Comment #6 from Steve Ellcey  2011-05-03 22:15:38 
UTC ---
The patch works for me on ia64-hp-hpux11.23.  It fixed the four new failures I
had and caused no regressions.

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo at gcc dot gnu.org]

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

--- Comment #19 from paolo at gcc dot gnu.org  
2011-05-03 22:25:28 UTC ---
Author: paolo
Date: Tue May  3 22:25:24 2011
New Revision: 173344

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173344
Log:
2011-05-03  Paolo Carlini  

PR libstdc++/48848
* include/std/valarray (valarray<>::valarray(valarray&&),
valarray<>::operator=(valarray&&), valarray<>::swap): Add.
* doc/xml/manual/status_cxx200x.xml: Update.
* testsuite/26_numerics/valarray/moveable.cc: New.
* testsuite/26_numerics/valarray/swap.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/moveable.cc
trunk/libstdc++-v3/testsuite/26_numerics/valarray/swap.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/status_cxx200x.xml
trunk/libstdc++-v3/include/std/valarray

[Bug libstdc++/48848] [C++0x] std::valarray functions missing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #20 from Paolo Carlini  2011-05-03 
22:35:13 UTC ---
Done.

[Bug c++/39055] [4.3/4.4/4.5/4.6/4.7 regression] ICE with questionable default parameter of a member function

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2011-05-03 
22:52:57 UTC ---
Jason, sorry for bothering, did we eventually get feedback from the committee
about this issue?

[Bug c++/38634] ICE with wrong number of template parameters

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  2011-05-03 
22:50:12 UTC ---
This doesn't ICE anymore in mainline and 4_6-branch, and I would be tempted to
close it, but I notice that the error message is now quite different, it talks
about incompleteness and line 1 also appears:

38634.C:6:31: error: invalid use of incomplete type ‘struct A’
38634.C:1:22: error: declaration of ‘struct A’

Is it good enough?

[Bug c++/38634] ICE with wrong number of template parameters

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-05-03 
23:39:02 UTC ---
(In reply to comment #2)

No, that's a regression in diagnostic quality.

[Bug c++/48859] New: Regression: incorrect "uninitialized const member" error on new without new-initializer

[jyasskin at gcc dot gnu.org]

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

   Summary: Regression: incorrect "uninitialized const member"
error on new without new-initializer
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


$ cat test.cc
struct HasConstructor {
  HasConstructor() {}
};

class ConstMember {
  const HasConstructor empty_;
};

void foo() {
  new ConstMember;
}
$ g++-mp-4.5 -c test.cc
$ g++-mp-4.6 -c test.cc
test.cc: In function 'void foo()':
test.cc:10:7: error: uninitialized const member in 'class ConstMember' using
'new' without new-initializer
test.cc:6:24: note: 'ConstMember::empty_' should be initialized
$ 


[expr.new]p15 says, "If the new-initializer is omitted: If T is a (possibly
cv-qualified) non-POD class type (or array thereof), the object is
default-initialized (8.5) If T is a const-qualified type, the underlying class
type shall have a user-declared default constructor."

T is ConstMember and is not const-qualified, so the object is
default-initialized.

[dcl.init]p5 says, "To default-initialize an object of type T means: if T is a
non-POD class type (clause 9), the default constructor for T is called (and the
initialization is ill-formed if T has no accessible default constructor);"

[class.ctor]p7 says, "The implicitly-defined default constructor performs the
set of initializations of the class that would be performed by a user-written
default constructor for that class with an empty mem- initializer-list (12.6.2)
and an empty function body. If that user-written default constructor would be
ill- formed, the program is ill-formed."

The empty user-written default constructor for ConstMember is well-formed, and
I don't see any other wording saying that const members prevent the creation of
a default constructor. Further, a local variable with no initializer
successfully compiles. So I believe gcc-4.6 is wrong here and gcc-4.5 was
right.

I don't see anything in the C++0x draft that would change the right behavior
here.

The workaround, of course, is to define the empty default constructor in
ConstMember. (In C++0x mode, "=default" does not work around the problem.)

[Bug c++/48859] Regression: incorrect "uninitialized const member" error on new without new-initializer

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-05-04 
00:03:08 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811

[Bug target/48792] ICE in failed_reload, at reload1.c:6000

[rmansfield at qnx dot com]

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

--- Comment #2 from Ryan Mansfield  2011-05-04 
00:22:54 UTC ---
The change that introduced this ICE is rev171520.

http://gcc.gnu.org/viewcvs?view=revision&revision=171520