[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51057 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 07:59:04 UTC --- Please confirm that this now passes on PowerPC - and, if so, please close. Thanks for the patch Dominique and thanks to all for the patience.
[Bug target/51835] New: ARM EABI violation when passing arguments to helper floating functions like __aeabi_d2iz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835
Bug #: 51835
Summary: ARM EABI violation when passing arguments to helper
floating functions like __aeabi_d2iz
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com
For following program
int func(float f)
{
double d = (double)f;
return (int)d;
}
compile it with following command:
$ arm-none-eabi-gcc -O2 -mthumb -mcpu=cortex-m4 -mfloat-abi=hard
-mfpu=fpv4-sp-d16 -S test.c -o test.S
the generated assembly code is:
---
fun:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, lr}
fmrsr0, s0
bl__aeabi_f2d
fmdrrd0, r0, r1
bl__aeabi_d2iz
pop{r3, pc}
.sizefun, .-fun
The argument of __aeabi_d2iz is passed in fp register, While ARM RTABI document
says that such functions should use the soft-float ABI, even when
-mfloat-abi=hard is specified.
The problem at least exists on trunk and 4.6 branch.
I am working a patch and will send it for review later.
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821
--- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2012-01-12 08:04:13
UTC ---
I think that DF is OK, the problem is in recog.c/peep2_find_free_register, with
this loop:
while (from != to)
{
HARD_REG_SET this_live;
from = peep2_buf_position (from + 1);
gcc_assert (peep2_insn_data[from].insn != NULL_RTX);
REG_SET_TO_HARD_REG_SET (this_live, peep2_insn_data[from].live_before);
IOR_HARD_REG_SET (live, this_live);
}
Here we need to analyse the insn patterns for ALL sets and clobbers, not only
track live registers through the insn stream.
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 08:04:57 UTC --- Created attachment 26305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26305 Incomplete chmod parser The attached chmod.c implements an incomplete chmod argument parser. TODO: - Check for the missing items and what should be supported - Implement it in libgfortran and document the supported syntax.
[Bug c/51834] -Wsequence-point fails when convoluted expressions with multiple side effects are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51834 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 08:51:03 UTC --- There is no undefined behavior in these testcases.
[Bug c++/51833] ICE in tsubst_copy, at cp/pt.c:11333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51833 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-12 Ever Confirmed|0 |1 Known to fail||4.5.3, 4.6.2 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 08:52:43 UTC --- Confirmed. Not sure if the testcase is valid or not.
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 08:54:23 UTC --- Can you attach preprocessed sources to reproduce this?
[Bug libitm/51830] FAIL: libitm.c/mem(cpy|set)-1.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target|*86*-*-*|i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-12 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 08:58:07 UTC --- Confirmed.
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-01-12 09:06:57 UTC ---
(In reply to comment #1)
Can you attach preprocessed sources to reproduce this?
I've reduced it to this snipped:
% cat foo.cpp
#include vector
struct foo
{
void bar ()
{
s.push_back (0);
}
std::vector int s;
};
% g++ foo.cpp foo.cpp -flto -std=gnu++0x
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/ccZEKdVj.o: multiple definition of
'_ZNSt16allocator_traitsISaIiEE18__construct_helperIiJiEE5valueE'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/cc1lLTi3.o: previous definition here
../sysdeps/x86_64/elf/start.S:109: error: undefined reference to 'main'
collect2: error: ld returned 1 exit statu
[Bug libfortran/50105] [4.6/4.7 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 09:07:02 UTC --- (In reply to comment #13) (In reply to comment #12) Did any interpretation requests go in on this and did we get an answer back? Thanks to Van and Dan, it's now on the server for the #197 meeting as 12-102; cf. http://j3-fortran.org/doc/meeting/197/12-102.txt / check for updates (12-102, 12-102r1 etc.) also at http://j3-fortran.org/doc/year/12/
[Bug c/51834] -Wsequence-point fails when convoluted expressions with multiple side effects are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51834 --- Comment #2 from Prasoon prasoonsaurav.nit at gmail dot com 2012-01-12 09:07:52 UTC --- @Richard Guenther Considering the expression i += (i,i++,i) +i; (i,i++,i) involves change in the value of i, however comma introduces a sequence point so very roughly considering it equivalent to func(_some_side_effect_on_i) we have i += func(_some_side_effect_on_i) + i; Do you still think the behavior is well defined? Another C++ example would be ++a = 10; where 'a'is of type int. This invokes UB but there is no warning from the compiler side even after we use this flag. Raising a similar bug for C++ because the differ may be different in C and C++. Thanks Prasoon
[Bug c++/51836] New: -Wsequence-point fails when convoluted expressions with multiple side effects are used (C++03)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51836
Bug #: 51836
Summary: -Wsequence-point fails when convoluted expressions
with multiple side effects are used (C++03)
Classification: Unclassified
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: prasoonsaurav@gmail.com
Consider the following example
int main()
{
int i=10;
i += (i , i++, i) + i; // also invokes UB
}
prasoon@Prasoon:~/test_code$ cat ub.cpp
int main()
{
int i=10;
i += (i , i++, i) + i; // also invokes UB
}
prasoon@Prasoon:~/test_code$ g++ -Wsequence-point ub.cpp
prasoon@Prasoon:~/test_code$
I don't get any warning like 'operation on 'i' may be undefined.
Another similar example
int main()
{
char *str;
char array[100]= Hello;
if((str = array)[0] == 'H'){
//do something
}
}
As per my understanding (str = array)[0] also invokes UB but no warning is
given by g++ even after using that option.
Another example is
int main()
{
int a = 10;
++a = 100; // UB
}
[Bug target/51831] internal compiler error: in simplify_subreg, at simplify-rtx.c:5375
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51831
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-12
Component|c |target
Known to work||4.7.0
Ever Confirmed|0 |1
Known to fail||4.6.2
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
09:11:55 UTC ---
Confirmed. Reduced testcase:
typedef signed short int16_t;
typedef unsigned short uint16_t;
typedef char v8qi __attribute__ ((vector_size (8)));
typedef uint16_t v4hu __attribute__ ((vector_size (8)));
typedef int16_t v4hi __attribute__ ((vector_size (8)));
v4hu v4hu_ (uint16_t const i);
void rgb_to_YCrCb (v8qi * const y, v8qi * const u, v8qi * const v,
v8qi const r, v8qi const g, v8qi const b, uint16_t *c)
{
v8qi const zero8 = { 0,0,0,0,0,0,0,0 };
v4hu r0 = (v4hu) __builtin_ia32_punpckhbw (zero8, r);
v4hu r1 = (v4hu) __builtin_ia32_punpcklbw (zero8, r);
v4hu g0 = (v4hu) __builtin_ia32_punpckhbw (zero8, g);
v4hu g1 = (v4hu) __builtin_ia32_punpcklbw (zero8, g);
v4hu b0 = (v4hu) __builtin_ia32_punpckhbw (zero8, b);
v4hu b1 = (v4hu) __builtin_ia32_punpcklbw (zero8, b);
v4hu y0 = (v4hu_(c[0]) * r0 + v4hu_(c[1]) * g0 + v4hu_(c[2]) * b0) 8;
v4hu y1 = (v4hu_(c[0]) * r1 + v4hu_(c[1]) * g1 + v4hu_(c[2]) * b1) 8;
*y = (v8qi)__builtin_ia32_packsswb ((v4hi)y0, (v4hi)y1);
}
fails at -O2. 4.5 does not support the shifts for vectors, fixed for 4.7.
[Bug c++/51826] [4.6 Regression] internal compiler error: in convert_nontype_argument, at cp/pt.c:5408
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51826 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.5.3, 4.7.0 Keywords||ice-on-invalid-code Last reconfirmed||2012-01-12 Ever Confirmed|0 |1 Summary|internal compiler error: in |[4.6 Regression] internal |convert_nontype_argument, |compiler error: in |at cp/pt.c:5408 |convert_nontype_argument, ||at cp/pt.c:5408 Target Milestone|--- |4.6.3 Known to fail||4.6.2 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 09:17:30 UTC --- Confirmed. g++ -S t.C t.C: In function 'int main(int, char**)': t.C:8:26: error: cast from 'const char*' to 'int' loses precision [-fpermissive] t.C:8:31: error: '(int)((long int)123)' is not a constant expression t.C:8:31: note: in template argument for type 'int' g++ -S t.C -m32 t.C: In function 'int main(int, char**)': t.C:8:31: internal compiler error: in convert_nontype_argument, at cp/pt.c:5408 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. On trunk: g++ -S t.C -m32 -B /abuild/rguenther/trunk-g/gcc t.C: In function 'int main(int, char**)': t.C:8:31: error: conversion from pointer type 'const char (*)[4]' to arithmetic type 'int' in a constant-expression t.C:8:31: note: in template argument for type 'int' so it's invalid source, fixed on trunk. 4.5 says g++ -S t.C -m32 t.C: In function 'int main(int, char**)': t.C:8:31: error: '(int)123' is not a valid template argument for type 'int' because it is a non-constant expression
[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 09:17:52 UTC --- Thus, confirmed.
[Bug c/51834] -Wsequence-point fails when convoluted expressions with multiple side effects are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51834 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-01-12 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2012-01-12 09:20:10 UTC --- (i++, i) + i is undefined. The sequence point only orders i++ and i inside the parens, but not the operands of +. The third example is not undefined.
[Bug c++/51827] Error: 'FOO' conflicts with a previous declaration, with PCH/LTO/C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51827 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 09:23:03 UTC --- I can't reproduce this.
[Bug c++/51833] ICE in tsubst_copy, at cp/pt.c:11333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51833 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-12 09:34:49 UTC --- It's not valid, you can't pass a function type by value
[Bug libfortran/51803] gfortran getcwd at startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51803 --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2012-01-12 09:58:39 UTC --- Author: jb Date: Thu Jan 12 09:58:34 2012 New Revision: 183122 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183122 Log: PR 51803 Avoid malloc if getcwd fails or is not available. 2012-01-12 Janne Blomqvist j...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR libfortran/51803 * runtime/main.c (store_exe_path): Avoid malloc if getcwd fails or is not available. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/main.c
[Bug fortran/51520] [4.6 Regression] ICE in gfortran 4.6.2, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51520 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 10:07:47 UTC --- Further reduced test case. Seems to be related to c_ptr/c_null_ptr. Maybe some parts of Rev. 181425 iso_c_binding related changes in symbol.c are sufficient? module sidl_array_array_F03 use iso_c_binding type sidl__array type(c_ptr) :: a = c_null_ptr end type sidl__array end module sidl_array_array_F03 module vect_Utils_F03 use sidl_array_array_F03 contains subroutine is_null_s(ext) class(sidl__array), intent(in) :: ext end subroutine is_null_s end module vect_Utils_F03 subroutine evalResA(res) use vect_Utils_F03 type (sidl__array) :: res call is_null_s(res) end subroutine evalResA
[Bug c/8081] ICE with variably sized types returned from nested functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
--- Comment #24 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
10:23:05 UTC ---
Created attachment 26306
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26306
A patch for using by-reference passing
(In reply to comment #23)
as alternative to rejecting this case we can lower returning variable-size
types during un-nesting to explicit passing of a return slot and using
memcpy, making the nested function return nothing.
It's of course not that easy as we gimplify before un-nesting. The frontend
would be responsible to arrange things that way, similar to how we pass
a return slot in the C++ frontend (DECL_BY_REFERENCE on the DECL_RESULT
variable). Like for the attached patch. Passes
extern void abort (void);
int
main (int argc, char **argv)
{
int size = 10;
typedef struct
{
char val[size];
}
block;
block a, b;
block __attribute__((noinline))
retframe_block ()
{
return *(block *) b;
}
b.val[0] = -1;
b.val[1] = -2;
a=retframe_block ();
if (a.val[0] != -1
|| a.val[1] != -2)
abort ();
return 0;
}
I'm not sure if one can construct a testcase where using return-slot
optimization causes wrong-code generation. Alternatively checking
DECL_BY_REFERENCE on the callees DECL_RESULT instead of applying it to
all VLA types could work (though not for indirect calls).
[Bug target/47852] crash with g++ -lpthread on irix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47852 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-01/msg00607.htm ||l Target Milestone|--- |4.7.0 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2012-01-12 10:23:01 UTC --- Patch submitted.
[Bug tree-optimization/51799] [4.7 Regression] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||irar at il dot ibm.com
AssignedTo|unassigned at gcc dot |irar at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Ira Rosen irar at il dot ibm.com 2012-01-12 10:48:11 UTC
---
This is actually the same problem as in pr 51301, and the fix of 51301 looks
incomplete: we want an over-promoted sequence to end with type demotion
operation, so we need to check that properly:
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 182840)
+++ tree-vect-patterns.c(working copy)
@@ -1186,13 +1186,15 @@
{
use_lhs = gimple_assign_lhs (use_stmt);
use_type = TREE_TYPE (use_lhs);
- /* Support only type promotion or signedess change. Check that USE_TYPE
-is not bigger than the original type. */
+ /* Support only type demotion or signedess change. */
if (!INTEGRAL_TYPE_P (use_type)
- || TYPE_PRECISION (new_type) TYPE_PRECISION (use_type)
- || TYPE_PRECISION (type) TYPE_PRECISION (use_type))
+ || TYPE_PRECISION (type) = TYPE_PRECISION (use_type))
return NULL;
+ /* Check that NEW_TYPE is not bigger than the conversion result. */
+ if (TYPE_PRECISION (new_type) TYPE_PRECISION (use_type))
+ return NULL;
+
if (TYPE_UNSIGNED (new_type) != TYPE_UNSIGNED (use_type)
|| TYPE_PRECISION (new_type) != TYPE_PRECISION (use_type))
{
I am going to test this patch.
[Bug c++/51827] Error: 'FOO' conflicts with a previous declaration, with PCH/LTO/C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51827 --- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2012-01-12 10:53:44 UTC --- I already mentioned PCH and .H extension, but just to be 100% clear, the error happens only when compiling the testcase as a c++ header. Reproduced on i686-pc-linux-gnu and i686-pc-mingw32.
[Bug libgcj/23856] Modification Time Incorrectly Set From Extension Entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23856 Andrew John Hughes gnu_andrew at member dot fsf.org changed: What|Removed |Added CC||gnu_andrew at member dot ||fsf.org --- Comment #3 from Andrew John Hughes gnu_andrew at member dot fsf.org 2012-01-12 10:59:20 UTC --- I have a feeling there have been changes in this area since this report (and the reporter does state that he was using an old version then). However, there doesn't seem to be an easy way of ensuring this without a zip file with the known issue to test against. Is one available?
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821
--- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-12
11:18:37 UTC ---
I think that DF is OK, the problem is in recog.c/peep2_find_free_register,
with
this loop:
while (from != to)
{
HARD_REG_SET this_live;
from = peep2_buf_position (from + 1);
gcc_assert (peep2_insn_data[from].insn != NULL_RTX);
REG_SET_TO_HARD_REG_SET (this_live, peep2_insn_data[from].live_before);
IOR_HARD_REG_SET (live, this_live);
}
Here we need to analyse the insn patterns for ALL sets and clobbers, not only
track live registers through the insn stream.
I'm not sure I understand. If the peephole matches, then the insn pattern is
present in the insn stream with instantiated registers, so it's sufficient to
scan the insn stream. AFAICS the code doesn't see that edx is live after the
instruction because DF reports that only eax is; of course it's eax in DImode
so edx is implicitly live, but it's nevertheless live.
[Bug libgcj/23856] Modification Time Incorrectly Set From Extension Entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23856 --- Comment #4 from Ranjit Mathew rmathew at gcc dot gnu.org 2012-01-12 11:19:08 UTC --- (In reply to comment #3) I have a feeling there have been changes in this area since this report (and the reporter does state that he was using an old version then). However, there doesn't seem to be an easy way of ensuring this without a zip file with the known issue to test against. Is one available? See the attachments in: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23854
[Bug middle-end/22141] [4.4/4.5/4.6/4.7 Regression] Missing optimization when storing structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 --- Comment #23 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 11:20:35 UTC --- As we have MEM_REF available we can in theory do the combining on the tree-level as well (or during gimplification). In fact, as we have the byteswap detection pass which does not yet handle byte-swapping memory (thus, a memory destination) it looks like a perfect place to handle this while also fixing that deficiency (gather sources for a contiguous piecewise stored memory region of suitable register size/alignment).
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821
--- Comment #13 from Uros Bizjak ubizjak at gmail dot com 2012-01-12 11:34:40
UTC ---
(In reply to comment #12)
Here we need to analyse the insn patterns for ALL sets and clobbers, not
only
track live registers through the insn stream.
I'm not sure I understand. If the peephole matches, then the insn pattern is
present in the insn stream with instantiated registers, so it's sufficient to
scan the insn stream. AFAICS the code doesn't see that edx is live after the
instruction because DF reports that only eax is; of course it's eax in DImode
so edx is implicitly live, but it's nevertheless live.
Please look into peep2_insn_data[from].live_before array and
peep2_insn_data[from+1].live_before. You will see that the difference is only
in ax register. This array is set with df_simulate_one_insn_forwards, and this
particular function indeed clears set hard registers when REG_UNUSED note is
found (this is OK for live analysis).
The referred loop processes
(insn 7 19 16 2 (parallel [
(set (reg:DI 0 ax [65])
(ashift:DI (const_int -1 [0x])
(reg:QI 2 cx [orig:63 shift_size ] [63])))
(clobber (reg:CC 17 flags))
]) pr51821.c:8 489 {*ashldi3_doubleword}
(expr_list:REG_DEAD (reg:QI 2 cx [orig:63 shift_size ] [63])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 1 dx)
(expr_list:REG_EQUAL (ashift:DI (const_int -1
[0x])
(subreg:QI (reg/v:SI 2 cx [orig:63 shift_size ] [63])
0))
(nil))
and since the difference between live registers before/after the insn is only
ax register, the loop claims others (including dx reg) as available. The
calculation, which register is _NOT_CLOBBERED_ by the pattern from live
information is thus not enough, we have to look into the pattern and mark all
hard registers that are set or clobbered as _NOT_AVAILABLE_ in the register
set.
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821 --- Comment #14 from Uros Bizjak ubizjak at gmail dot com 2012-01-12 11:42:00 UTC --- (In reply to comment #12) I'm not sure I understand. If the peephole matches, then the insn pattern is present in the insn stream with instantiated registers, so it's sufficient to scan the insn stream. AFAICS the code doesn't see that edx is live after the instruction because DF reports that only eax is; of course it's eax in DImode so edx is implicitly live, but it's nevertheless live. A comment to implicitly live: my second example (Comment #9) marks ax register as available, but IT IS SET in the pattern! This supports the theory outlined in the Comment #13, but df_simulate_one_insn_forwards now marks unused register ax as available. Again, live analysis is not the correct tool to determine which registers are clobbered by the insn.
[Bug target/27855] [4.4/4.5/4.7 regression] reassociation causes the RA to be confused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.6.2
Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.7 regression]
|regression] reassociation |reassociation causes the RA
|causes the RA to be |to be confused
|confused|
--- Comment #37 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
12:00:26 UTC ---
Hmm, on the 4.6 branch this seems fixed, trunk it is no longer tree-reassoc
that makes us slow, but instead with tree-reassoc things are faster ...
4.5 -O3 -ffast-math 1583.48
4.5 -O3 -ffast-math -fno-tree-reassoc 2307.55
4.6 -O3 -ffast-math 2287.99
4.6 -O3 -ffast-math -fno-tree-reassoc 2268.77
4.7 -O3 -ffast-math 1529.65
4.7 -O3 -ffast-math -fno-tree-reassoc 1144.00
4.7 -O3 -ffast-math -fno-tree-reassoc -fno-tree-vectorize 1992.50
Huh.
On the 4.6 branch we somehow avoided scheduling everything down by
tree reassoc, but on the 4.7 branch we are back to doing so.
It would be interesting to bisect what fixed it for 4.6 and what broke
it again for 4.7, even without reassociation.
With -fschedule-insns -fsched-pressure we get back to 2212.98 for 4.7.
With -fno-tree-reassoc we now vectorize the loop(!):
bb 4:
# pC0_1 = PHI pC0_361(3), C_25(D)(2)
# pA0_2 = PHI pA0_34(3), A_12(D)(2)
# pB0_4 = PHI pB0_369(3), B_14(D)(2)
rC0_0_29 = *pC0_1;
rC1_0_30 = MEM[(double *)pC0_1 + 8B];
rC2_0_31 = MEM[(double *)pC0_1 + 16B];
rC3_0_32 = MEM[(double *)pC0_1 + 24B];
rC4_0_33 = MEM[(double *)pC0_1 + 32B];
vect_var_.1256_2404 = {rC4_0_33, 0.0};
vect_var_.1298_2510 = {rC3_0_32, 0.0};
vect_var_.1340_2616 = {rC2_0_31, 0.0};
vect_var_.1382_2722 = {rC1_0_30, 0.0};
vect_var_.1424_2828 = {rC0_0_29, 0.0};
ivtmp.1443_2312 = (long unsigned int) pB0_4;
ivtmp.1451_379 = (long unsigned int) pA0_2;
D.4447_128 = ivtmp.1443_2312 + 480;
bb 5:
# vect_var_.1256_2375 = PHI vect_var_.1256_2385(5), vect_var_.1256_2404(4)
# vect_var_.1256_2376 = PHI vect_var_.1256_2386(5), {0.0, 0.0}(4)
# vect_var_.1256_2377 = PHI vect_var_.1256_2387(5), {0.0, 0.0}(4)
# vect_var_.1256_2378 = PHI vect_var_.1256_2388(5), {0.0, 0.0}(4)
# vect_var_.1256_2379 = PHI vect_var_.1256_2389(5), {0.0, 0.0}(4)
# vect_var_.1256_2380 = PHI vect_var_.1256_2390(5), {0.0, 0.0}(4)
# vect_var_.1256_2381 = PHI vect_var_.1256_2391(5), {0.0, 0.0}(4)
# vect_var_.1256_2382 = PHI vect_var_.1256_2392(5), {0.0, 0.0}(4)
# vect_var_.1256_2383 = PHI vect_var_.1256_2393(5), {0.0, 0.0}(4)
# vect_var_.1256_2384 = PHI vect_var_.1256_2394(5), {0.0, 0.0}(4)
# vect_var_.1298_2481 = PHI vect_var_.1298_2491(5), vect_var_.1298_2510(4)
# vect_var_.1298_2482 = PHI vect_var_.1298_2492(5), {0.0, 0.0}(4)
# vect_var_.1298_2483 = PHI vect_var_.1298_2493(5), {0.0, 0.0}(4)
# vect_var_.1298_2484 = PHI vect_var_.1298_2494(5), {0.0, 0.0}(4)
# vect_var_.1298_2485 = PHI vect_var_.1298_2495(5), {0.0, 0.0}(4)
# vect_var_.1298_2486 = PHI vect_var_.1298_2496(5), {0.0, 0.0}(4)
# vect_var_.1298_2487 = PHI vect_var_.1298_2497(5), {0.0, 0.0}(4)
# vect_var_.1298_2488 = PHI vect_var_.1298_2498(5), {0.0, 0.0}(4)
# vect_var_.1298_2489 = PHI vect_var_.1298_2499(5), {0.0, 0.0}(4)
# vect_var_.1298_2490 = PHI vect_var_.1298_2500(5), {0.0, 0.0}(4)
# vect_var_.1340_2587 = PHI vect_var_.1340_2597(5), vect_var_.1340_2616(4)
# vect_var_.1340_2588 = PHI vect_var_.1340_2598(5), {0.0, 0.0}(4)
...
D.4346_400 = (void *) ivtmp.1451_2315;
vect_var_.1399_2748 = MEM[base: D.4346_400, offset: 0B];
vect_var_.1400_2750 = MEM[base: D.4346_400, offset: 16B];
vect_var_.1401_2752 = MEM[base: D.4346_400, offset: 32B];
vect_var_.1402_2754 = MEM[base: D.4346_400, offset: 48B];
vect_var_.1403_2756 = MEM[base: D.4346_400, offset: 64B];
...
vect_var_.1423_2789 = vect_var_.1399_2748 * vect_var_.1413_2770;
vect_var_.1423_2790 = vect_var_.1400_2750 * vect_var_.1414_2772;
vect_var_.1423_2791 = vect_var_.1401_2752 * vect_var_.1415_2774;
...
ivtmp.1443_2318 = ivtmp.1443_2316 + 160;
ivtmp.1451_2317 = ivtmp.1451_2315 + 160;
if (ivtmp.1443_2318 != D.4447_128)
goto bb 5;
else
goto bb 6;
bb 6:
# vect_var_.1256_2405 = PHI vect_var_.1256_2385(5)
# vect_var_.1256_2406 = PHI vect_var_.1256_2386(5)
...
vect_var_.1436_2839 = vect_var_.1424_2829 + vect_var_.1424_2830;
vect_var_.1436_2840 = vect_var_.1436_2839 + vect_var_.1424_2831;
vect_var_.1436_2841 = vect_var_.1436_2840 + vect_var_.1424_2832;
vect_var_.1436_2842 = vect_var_.1436_2841 + vect_var_.1424_2833;
vect_var_.1436_2843 = vect_var_.1436_2842 + vect_var_.1424_2834;
vect_var_.1436_2844 = vect_var_.1436_2843 + vect_var_.1424_2835;
vect_var_.1436_2845 = vect_var_.1436_2844 +
[Bug middle-end/28831] [4.4/4.5/4.6/4.7 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
12:05:26 UTC ---
(In reply to comment #5)
Here's another example:
struct A { int i[100]; };
void f(struct A);
int main()
{
f((struct A){1});
}
Here we build up the compound literal on the stack and then copy it into the
argument slot.
This seems to be a problem with GIMPLE, as there's no way to represent that we
want a particular temporary object to live in the argument slot.
This is both more and less of a problem for C++, as it has many more temporary
struct objects, but also has pass-by-reference (and the ABI does transparent
pass-by-reference for non-POD structs).
I suppose it would be easy to add a decl flag DECL_ARGUMENT_SLOT, but of course
defering its allocation until we expand the call (if the argument is passed
by value) is going to be interesting, as we basically have the argument
setup visible in gimple. For your testcase it's passed by reference it
seems so that would be ok and we can simply avoid the argument slot
allocation and copying at expansion time.
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-01-12 12:11:03 UTC --- g++ -fabi-version=6 -shared foo.cpp foo.cpp -flto -std=c++11 is fine BTW.
[Bug target/29256] [4.4/4.5/4.6/4.7 regression] loop performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-*-* Component|middle-end |target --- Comment #41 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 12:26:59 UTC --- Seems to be more-or-less target dependent, so adding a list of targets affected. For powerpc we still use N induction variables after unrolling instead of just one. Which I suppose was the point of this regression report.
[Bug rtl-optimization/32283] [4.4/4.5/4.6 Regression] Missed induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING Known to work||4.7.0 Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 Regression] |regression] Missed |Missed induction variable |induction variable |optimization |optimization| --- Comment #31 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 12:51:02 UTC --- On trunk I now see .L3: sthu 10,2(9) bdnz .L3 which looks good. Removing 4.7 from the list of releases that do not work (somebody could check 4.6 please, where I think this should be fixed as well). I only checked powerpc.
[Bug tree-optimization/32306] [4.4/4.5/4.6/4.7 Regression] redundant || not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
13:02:25 UTC ---
Shorter testcase, compilable and to the point. We are not able to CSE
the b1 ... b8 sequence because we produce control-flow for it
during gimplification.
void bar (short *array,
short b1, short b2, short b3, short b4,
short b5, short b6, short b7, short b8)
{
array[0] = b1 b2 b3 b4 b5 b6 b7 b8;
array[1] = b1 b2 b3 b4 b5 b6 b7 b8;
}
[Bug c/32455] [4.4/4.5 Regression] ICE with modified va_list, allows declaration of __builtin_*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0, 4.7.0 Summary|[4.4/4.5/4.6/4.7|[4.4/4.5 Regression] ICE |regression] ICE with|with modified va_list, |modified va_list, allows|allows declaration of |declaration of __builtin_* |__builtin_* --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 13:05:20 UTC --- No longer ICEs since 4.6.
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot |gnu.org |gnu.org --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-12 13:20:01 UTC --- Please look into peep2_insn_data[from].live_before array and peep2_insn_data[from+1].live_before. You will see that the difference is only in ax register. This array is set with df_simulate_one_insn_forwards, and this particular function indeed clears set hard registers when REG_UNUSED note is found (this is OK for live analysis). I did and saw exactly that. The problem is that I missed the REG_UNUSED note for edx among the 3 other notes (and also that you specifically mentioned it in the comment #9). OK, DF appears to be correct here, or at least consistent. and since the difference between live registers before/after the insn is only ax register, the loop claims others (including dx reg) as available. The calculation, which register is _NOT_CLOBBERED_ by the pattern from live information is thus not enough, we have to look into the pattern and mark all hard registers that are set or clobbered as _NOT_AVAILABLE_ in the register set. Yes, this seems to be the correct approach.
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC||jsm28 at gcc dot gnu.org
Component|tree-optimization |c
--- Comment #23 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
13:42:39 UTC ---
Shorter testcase
extern __inline __attribute__ ((__always_inline__,__gnu_inline__))
void open ()
{
}
void open ()
{
open ();
}
fails on trunk like
./cc1 -quiet t.c -O
t.c: In function 'open':
t.c:5:6: error: inlining failed in call to always_inline 'open': function not
inlinable
t.c:7:8: error: called from here
and creates wrong code at -O0 (and probably would, at -On):
open:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$0, %eax
callopen
popq%rbp
.cfi_def_cfa 7, 8
ret
as the always-inline body was not inlined.
Note that the initial callgraph is already wrong:
Initial callgraph:
open/0 @0x75a2b6c0 (asm: open) analyzed needed reachable body finalized
redefined_extern_inline
called by: open/0 (1.00 per call)
calls: open/0 (1.00 per call)
References:
Refering this function:
variable pool:
as said, the C frontend needs to create two decls for open for this to
properly work.
OTOH, it is time to deprecate this extension and warn about it (after
all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce
the recursive open - how was this intended to work? ...) I don't have
3.2 (and 2.95 does not have always_inline).
The proper way to write the testcase is
extern __inline __attribute__ ((__always_inline__,__gnu_inline__))
void open ()
{
}
void open_1 () asm(open);
void open_1 ()
{
open ();
}
So, Joseph - would you be fine with changing behavior for this testcase
from ICEing at -On, miscompiling at -O0 to rejecting it? Thus,
Index: c-decl.c
===
--- c-decl.c(revision 183121)
+++ c-decl.c(working copy)
@@ -1855,21 +1855,10 @@ diagnose_mismatched_decls (tree newdecl,
{
if (DECL_INITIAL (olddecl))
{
- /* If both decls are in the same TU and the new declaration
-isn't overriding an extern inline reject the new decl.
+ /* If both decls are in the same TU reject the new decl.
In c99, no overriding is allowed in the same translation
unit. */
- if ((!DECL_EXTERN_INLINE (olddecl)
- || DECL_EXTERN_INLINE (newdecl)
- || (!flag_gnu89_inline
- (!DECL_DECLARED_INLINE_P (olddecl)
- || !lookup_attribute (gnu_inline,
-DECL_ATTRIBUTES (olddecl)))
- (!DECL_DECLARED_INLINE_P (newdecl)
- || !lookup_attribute (gnu_inline,
-DECL_ATTRIBUTES (newdecl
- )
- same_translation_unit_p (newdecl, olddecl))
+ if (same_translation_unit_p (newdecl, olddecl))
{
error (redefinition of %q+D, newdecl);
locate_old_decl (olddecl);
[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2012-01-12 13:47:04 UTC --- I think that SRA's part of the fix is what I have just posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00613.html
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz 2012-01-12 14:22:52 UTC --- OTOH, it is time to deprecate this extension and warn about it (after all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce the recursive open - how was this intended to work? ...) I don't have 3.2 (and 2.95 does not have always_inline). pre cgraph compilers handled it in a way that inline body was kept after parsing extern inline version and inlined into every new parsed function until the offline version was reached. Then the function was marked uninlinable, offline body was produced and all subsequentely parsed calls was not inlined (including calls in the offline body). I think extern inlines are sadly rather common to be deprecated... Honza
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #25 from rguenther at suse dot de rguenther at suse dot de 2012-01-12 14:27:12 UTC --- On Thu, 12 Jan 2012, hubicka at ucw dot cz wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz 2012-01-12 14:22:52 UTC --- OTOH, it is time to deprecate this extension and warn about it (after all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce the recursive open - how was this intended to work? ...) I don't have 3.2 (and 2.95 does not have always_inline). pre cgraph compilers handled it in a way that inline body was kept after parsing extern inline version and inlined into every new parsed function until the offline version was reached. Then the function was marked uninlinable, offline body was produced and all subsequentely parsed calls was not inlined (including calls in the offline body). I think extern inlines are sadly rather common to be deprecated... Well, not deprecating extern inlines but re-definitions in the same TU which miscompiles once the extern inline is used in that TU (ok, so you can say in 99% of all cases that won't happen). Thus, another workaround would be to avoid transitioning the attribute to the redefinition in merge_decls (under the exact same condition as we allow the redefinition). Richard.
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #26 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 14:30:31 UTC --- The patch fails to bootstrap in libquadmath btw: /space/rguenther/src/svn/trunk/libquadmath/math/cimagq.c:24:1: error: redefinition of 'cimagq' In file included from /space/rguenther/src/svn/trunk/libquadmath/quadmath-imp.h:26:0, from /space/rguenther/src/svn/trunk/libquadmath/math/cimagq.c:21: /space/rguenther/src/svn/trunk/libquadmath/quadmath.h:175:1: note: previous definition of 'cimagq' was here make[3]: *** [math/cimagq.lo] Error 1 which seems to make heavy use of gnu-inline always-inline.
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #27 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 14:31:28 UTC --- (In reply to comment #25) On Thu, 12 Jan 2012, hubicka at ucw dot cz wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz 2012-01-12 14:22:52 UTC --- OTOH, it is time to deprecate this extension and warn about it (after all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce the recursive open - how was this intended to work? ...) I don't have 3.2 (and 2.95 does not have always_inline). pre cgraph compilers handled it in a way that inline body was kept after parsing extern inline version and inlined into every new parsed function until the offline version was reached. Then the function was marked uninlinable, offline body was produced and all subsequentely parsed calls was not inlined (including calls in the offline body). I think extern inlines are sadly rather common to be deprecated... Well, not deprecating extern inlines but re-definitions in the same TU which miscompiles once the extern inline is used in that TU (ok, so you can say in 99% of all cases that won't happen). Thus, another workaround would be to avoid transitioning the attribute to the redefinition in merge_decls (under the exact same condition as we allow the redefinition). Only a workaround for the ICE, of course, not the miscompile (can anyone check if we ever did not miscompile this case?)
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #28 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-01-12 14:35:58 UTC --- On Thu, 12 Jan 2012, rguenther at suse dot de wrote: I think extern inlines are sadly rather common to be deprecated... Well, not deprecating extern inlines but re-definitions in the same TU which miscompiles once the extern inline is used in that TU (ok, so you can say in 99% of all cases that won't happen). I haven't tested it, but I'd expect extern inline + redefinition to be occur in various cases building glibc, or any other library with extern inlines in its headers. Though those cases may be less likely then to use the redefined function in the same TU.
[Bug tree-optimization/51799] [4.7 Regression] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799 --- Comment #5 from irar at gcc dot gnu.org 2012-01-12 14:41:51 UTC --- Author: irar Date: Thu Jan 12 14:41:44 2012 New Revision: 183126 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183126 Log: PR tree-optimization/51799 * tree-vect-patterns.c (vect_recog_over_widening_pattern): Check that the last operation is a type demotion. Added: trunk/gcc/testsuite/gcc.dg/vect/pr51799.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-widen-shift-u8.c trunk/gcc/tree-vect-patterns.c
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #29 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12
14:49:42 UTC ---
Btw, GCC 3.2.3 produces for
extern __inline __attribute__ ((__always_inline__))
void open ()
{
}
void open ()
{
open ();
}
open:
pushl %ebp
movl%esp, %ebp
callopen
popl%ebp
ret
so it's broken as well.
[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #30 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-12 14:54:04 UTC --- Of course the question is what we should really do here wrt name-lookup.
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 15:25:55 UTC --- (In reply to comment #2) error: /tmp/ccZEKdVj.o: multiple definition of '_ZNSt16allocator_traitsISaIiEE18__construct_helperIiJiEE5valueE' That symbol is an extra-name alias for std::allocator_traitsstd::allocatorint ::__construct_helperint, int::value created by mangle_decl for forward ABI compatibility. But I can't reproduce the bug; that variable isn't emitted at all when I compile the reduced testcase with r183124.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-01-12 15:47:53 UTC ---
--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-11
17:48:25 UTC ---
(In reply to comment #19)
I've just tried it with the vendor cxx (first disabling noexcept for C++
2011), and it also fails with EINVAL.
Well that's something vaguely positive at least ... the root cause probably
isn't a G++ front-end issue or libstdc++ issue.
True, though I still don't understand why it wouldn't work in C++ when a
similar C testcase does.
Given that this is mostly autoconf work, I could give it a try myself if
I can figure out where best to override the __GTHREAD_MUTEX_INIT
definition from gthr-default.h/gthr-posix.h. The problem seems to be
that autoconf results go into bits/c++config.h, which is included way
before bits/gthr.h.
Yes, that's why I thought of making it depend on some new
_GLIBCXX_BROKEN_GTHREAD_MUTEX_INIT macro set in bits/c++config.h by
autoconf,
rather trying to alter gthr-posix.h
then e.g.
class __mutex_base
{
protected:
typedef __gthread_mutex_t __native_type;
-#ifdef __GTHREAD_MUTEX_INIT
-#if defined __GTHREAD_MUTEX_INIT !defined
_GLIBCXX_BROKEN_GTHREAD_MUTEX_INIT
__native_type _M_mutex = __GTHREAD_MUTEX_INIT;
constexpr __mutex_base() noexcept = default;
#else
__native_type _M_mutex;
Unfortunately, we still need to provide __GTHREAD_MUTEX_INIT_FUNCTION,
and it seems best to do so in gthr-posix.h directly, as is done in
gthr-dce.h. Here's the patch I came up with so far. gthr-posix.h has
Tru64 UNIX-specific code already, so this isn't much worse that what we
already have. __GTHREAD_COND_INIT has the same issue, so it needs the
same workaround.
The std/mutex change is a hack to avoid
In file included from
/var/gcc/regression/trunk/5.1b-gcc/build/alpha-dec-osf5.1b/libstdc++-v3/include/future:40:0,
from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/30_threads/async/async.cc:27:
/var/gcc/regression/trunk/5.1b-gcc/build/alpha-dec-osf5.1b/libstdc++-v3/include/mutex:160:5:
error: function 'std::mutex::mutex()' defaulted on its first declaration with
an exception-specification that differs from the implicit declaration
'std::mutex::mutex()'
and the condition_variable.cc change accounts for the fact that gthr.h
only documents __GTHREAD_COND_INIT_FUNCTION (analogous to
__GTHREAD_MUTEX_INIT_FUNCTION), not __gthread_cond_init.
--- gthr-posix.h.distSat Jan 7 00:12:15 2012
+++ gthr-posix.hThu Jan 12 13:50:52 2012
@@ -62,7 +62,13 @@ typedef struct timespec __gthread_time_t
in gthr.h for details. */
#define __GTHREAD_HAS_COND1
+#ifndef __osf__
#define __GTHREAD_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER
+#define __GTHREAD_COND_INIT PTHREAD_COND_INITIALIZER
+#else
+#define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function
+#define __GTHREAD_COND_INIT_FUNCTION __gthread_cond_init_function
+#endif
#define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
#if defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER)
#define __GTHREAD_RECURSIVE_MUTEX_INIT PTHREAD_RECURSIVE_MUTEX_INITIALIZER
@@ -71,7 +77,6 @@ typedef struct timespec __gthread_time_t
#else
#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
__gthread_recursive_mutex_init_function
#endif
-#define __GTHREAD_COND_INIT PTHREAD_COND_INITIALIZER
#define __GTHREAD_TIME_INIT {0,0}
#if __GXX_WEAK__ _GLIBCXX_GTHREAD_USE_WEAK
@@ -730,6 +735,20 @@ __gthread_setspecific (__gthread_key_t _
return __gthrw_(pthread_setspecific) (__key, __ptr);
}
+static inline void
+__gthread_mutex_init_function (__gthread_mutex_t *__mutex)
+{
+ if (__gthread_active_p ())
+__gthrw_(pthread_mutex_init) (__mutex, NULL);
+}
+
+static inline void
+__gthread_cond_init_function (__gthread_cond_t *__cond)
+{
+ if (__gthread_active_p ())
+__gthrw_(pthread_cond_init) (__cond, NULL);
+}
+
static inline int
__gthread_mutex_destroy (__gthread_mutex_t *__mutex)
{
diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -157,7 +157,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#ifdef __GTHREAD_MUTEX_INIT
constexpr
#endif
-mutex() noexcept = default;
+//mutex() noexcept = default;
+mutex() = default;
~mutex() = default;
mutex(const mutex) = delete;
diff --git a/libstdc++-v3/src/condition_variable.cc
b/libstdc++-v3/src/condition_variable.cc
--- a/libstdc++-v3/src/condition_variable.cc
+++ b/libstdc++-v3/src/condition_variable.cc
@@ -36,10 +36,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#else
condition_variable::condition_variable() noexcept
{
-int __e = __gthread_cond_init(_M_cond, 0);
-
-if (__e)
- __throw_system_error(__e);
+__GTHREAD_COND_INIT_FUNCTION(_M_cond);
}
condition_variable::~condition_variable() noexcept
I've rebuilt
[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832 --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-01-12 16:15:32 UTC --- (In reply to comment #4) (In reply to comment #2) error: /tmp/ccZEKdVj.o: multiple definition of '_ZNSt16allocator_traitsISaIiEE18__construct_helperIiJiEE5valueE' That symbol is an extra-name alias for std::allocator_traitsstd::allocatorint ::__construct_helperint, int::value created by mangle_decl for forward ABI compatibility. But I can't reproduce the bug; that variable isn't emitted at all when I compile the reduced testcase with r183124. Hmm, that's strange. I've updated binutils and gcc just to double-check and it still fails: (Please note that foo.cpp occurs _twice_ below) % g++ -shared foo.cpp foo.cpp -flto -std=c++11 --save-temps /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: foo.o: multiple definition of 'std::allocator_traitsstd::allocatorint ::__construct_helperint, int::value' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: foo.o: previous definition here [Leaving LTRANS /tmp/ccXhj6nz.args] [Leaving LTRANS /tmp/ccLh8B76.ltrans.out] [Leaving LTRANS /tmp/ccIB53Wt.args] [Leaving LTRANS /tmp/ccLh8B76.ltrans0.o] collect2: error: ld returned 1 exit status % foo.res 2 foo.o 2 164 ac8416e1b427b8aa PREVAILING_DEF_IRONLY_EXP _ZNSt16allocator_traitsISaIiEE18__construct_helperIiJiEE5valueE 170 ac8416e1b427b8aa UNDEF _ZNSt16allocator_traitsISaIiEE18__construct_helperIiIiEE5valueE foo.o 2 164 ac8416e1b427b8aa PREEMPTED_IR _ZNSt16allocator_traitsISaIiEE18__construct_helperIiJiEE5valueE 170 ac8416e1b427b8aa UNDEF _ZNSt16allocator_traitsISaIiEE18__construct_helperIiIiEE5valueE % gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-initfini-array --with-gold --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-build-config=bootstrap-lto --with-boot-ldflags=-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=all,--icf-iterations=3 --enable-version-specific-runtime-libs --disable-libstdcxx-pch --enable-libstdcxx-time=yes Thread model: posix gcc version 4.7.0 20120112 (experimental) (GCC) % ld -v GNU gold (GNU Binutils 2.22.51.20120112) 1.11
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-12 16:16:30 UTC --- (In reply to comment #21) The std/mutex change is a hack to avoid In file included from /var/gcc/regression/trunk/5.1b-gcc/build/alpha-dec-osf5.1b/libstdc++-v3/include/future:40:0, from /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/30_threads/async/async.cc:27: /var/gcc/regression/trunk/5.1b-gcc/build/alpha-dec-osf5.1b/libstdc++-v3/include/mutex:160:5: error: function 'std::mutex::mutex()' defaulted on its first declaration with an exception-specification that differs from the implicit declaration 'std::mutex::mutex()' Does adding 'noexcept' to ~__mutex_base() make that hack unnecessary? The destructor should be implicitly noexcept, but G++ doesn't implement that yet (PR 50043) so adding 'noexcept' there is ok.
[Bug c++/51295] [C++11][noexcept] Wrong c'tor exception-specification with non-trivial d'tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51295 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-12 16:19:04 UTC --- is this just a dup of PR 50043 ?
[Bug tree-optimization/51782] Missing address-space information leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-12
16:19:14 UTC ---
(In reply to comment #7)
Please figure out where the address-space information is lost.
Is -f[no-]tree-sra enough information to find the bug for someone familiar with
RSA?
Here is an even simpler test case:
struct rgb { char r; };
char read_rgb_bug (const __pgm struct rgb *s)
{
struct rgb t = *s;
return t.r;
}
[Bug tree-optimization/51799] [4.7 Regression] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-12 16:49:21 UTC --- Fixed.
[Bug target/51756] wrong warning: uninitialized variable put into program memory area
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51756 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-12 16:51:44 UTC --- Author: gjl Date: Thu Jan 12 16:51:28 2012 New Revision: 183129 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183129 Log: PR target/51756 * config/avr/avr.c (avr_encode_section_info): Test for absence of DECL_EXTERNAL when checking for initializers of progmem variables. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/48754] FAIL: gcc.dg/binop-xor(1|3).c scan-tree-dump-times optimized bb[^]* *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48754 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-12 16:57:39 UTC --- This PR seems to have been fixed between revisions 176558 and 176584. Please reopen if this not the case for mips*-*-*.
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-12 16:58:36 UTC --- Closing as fixed.
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821
--- Comment #16 from Uros Bizjak ubizjak at gmail dot com 2012-01-12 17:00:48
UTC ---
(In reply to comment #15)
Yes, this seems to be the correct approach.
Patch that fixes the failure:
Index: recog.c
===
--- recog.c (revision 183053)
+++ recog.c (working copy)
@@ -3038,6 +3038,7 @@ peep2_find_free_register (int from, int to, const
static int search_ofs;
enum reg_class cl;
HARD_REG_SET live;
+ df_ref *def_rec;
int i;
gcc_assert (from MAX_INSNS_PER_PEEP2 + 1);
@@ -3051,12 +3052,14 @@ peep2_find_free_register (int from, int to, const
while (from != to)
{
- HARD_REG_SET this_live;
+ gcc_assert (peep2_insn_data[from].insn != NULL_RTX);
+ /* Don't use registers set or clobbered by the insn. */
+ for (def_rec = DF_INSN_DEFS (peep2_insn_data[from].insn);
+ *def_rec; def_rec++)
+ SET_HARD_REG_BIT (live, DF_REF_REGNO (*def_rec));
+
from = peep2_buf_position (from + 1);
- gcc_assert (peep2_insn_data[from].insn != NULL_RTX);
- REG_SET_TO_HARD_REG_SET (this_live, peep2_insn_data[from].live_before);
- IOR_HARD_REG_SET (live, this_live);
}
cl = (class_str[0] == 'r' ? GENERAL_REGS
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-12 17:02:20 UTC --- Closing as fixed for real this time.
[Bug testsuite/50435] FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-12 17:06:53 UTC --- Closing as fixed.
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2012-01-12 17:17:46 UTC --- Where is the address space information about a particular memory access stored in gimple/tree infrastructure? Do you happen to know if this bug started happening recently on the trunk? Thanks.
[Bug target/51756] wrong warning: uninitialized variable put into program memory area
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51756 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-12 17:23:38 UTC --- Author: gjl Date: Thu Jan 12 17:23:32 2012 New Revision: 183131 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183131 Log: Backport from mainline r183129 PR target/51756 * config/avr/avr.c (avr_encode_section_info): Test for absence of DECL_EXTERNAL when checking for initializers of progmem variables. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/avr/avr.c
[Bug target/51756] wrong warning: uninitialized variable put into program memory area
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51756 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-12 17:24:51 UTC --- Closed for the milestone
[Bug c++/51403] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51403 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 17:27:02 UTC --- Author: jason Date: Thu Jan 12 17:26:57 2012 New Revision: 183132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183132 Log: PR c++/51403 * pt.c (unify): Handle error_mark_node. Added: trunk/gcc/testsuite/g++.dg/template/arg8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48051] sorry, unimplemented: mangling overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48051 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 17:27:40 UTC --- Fixed for 4.7.
[Bug c++/48051] sorry, unimplemented: mangling overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48051 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 17:27:12 UTC --- Author: jason Date: Thu Jan 12 17:27:07 2012 New Revision: 183133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183133 Log: PR c++/48051 * mangle.c (write_expression): Mangle BASELINK scope if BASELINK_QUALIFIED_P. * search.c (adjust_result_of_qualified_name_lookup): Set BASELINK_QUALIFIED_P. * tree.c (cp_tree_equal) [BASELINK]: Compare BASELINK_QUALIFIED_P. * parser.c (cp_parser_postfix_dot_deref_expression): Don't call adjust_result_of_qualified_name_lookup for non-qualified names. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/parser.c trunk/gcc/cp/search.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/mangle48.C trunk/gcc/testsuite/g++.dg/abi/mangle58.C
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Attachment #26305|0 |1 is obsolete|| --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 17:31:37 UTC --- Created attachment 26307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26307 Improved version: POSIXly correct chmod as separate program Attached: A chmod program, which takes a string and a file name and should act as a POSIX chmod program would do. Thus, it honors the umask, allows for fancy combinations such as g+w-r,a+x,-w,o=u,u+s,+t. TODO: - Convert this into libgfortran/intrinsic/chmod.c - Write a fancy documentation for http://gcc.gnu.org/onlinedocs/gfortran/CHMOD.html which actually describes which modes are supported - and stats that the mode argument is in line with the chmod utility of POSIX (IEEE Std 1003.1-2001).
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org |
[Bug c++/36797] ICE mangling __is_empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 17:41:00 UTC --- The clang folks seem to agree with me, so I'll just improve the diagnostic.
[Bug c++/36797] ICE mangling __is_empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 17:48:03 UTC --- Created attachment 26308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26308 Patch for 4.8 Here's a patch, but it'll have to wait until we're in stage 1 again.
[Bug c++/51403] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51403 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 17:50:40 UTC --- Fixed.
[Bug c++/36797] ICE mangling __is_empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||ABI, patch Target Milestone|--- |4.8.0
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-12 18:09:13 UTC --- (In reply to comment #10) Where is the address space information about a particular memory access stored in gimple/tree infrastructure? You mean the ADDR_SPACE macros from tree.h?
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-12 18:17:56 UTC --- Does adding 'noexcept' to ~__mutex_base() make that hack unnecessary? The destructor should be implicitly noexcept, but G++ doesn't implement that yet (PR 50043) so adding 'noexcept' there is ok. Yep, that does the trick. Rainer
[Bug other/50925] [4.7 Regression][avr] ICE at spill_failure, at reload1.c:2118
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 --- Comment #14 from denisc at gcc dot gnu.org 2012-01-12 18:30:00 UTC --- Author: denisc Date: Thu Jan 12 18:29:54 2012 New Revision: 183136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183136 Log: PR target/50925 * config/avr/avr-protos.h (avr_hard_regno_nregs): Declare. * config/avr/avr.c (avr_can_eliminate): Simplify. (avr_initial_elimination_offset): Likewise. (avr_prologue_setup_frame): Use hard_frame_pointer_rtx. (expand_epilogue): Likewise. (avr_legitimize_address): Gut. (avr_legitimize_reload_address): Use hard_frame_pointer_rtx. (avr_hard_regno_nregs): New. (avr_hard_regno_ok): Allow only Pmode for arg and frame_pointers. (avr_regno_mode_code_ok_for_base_b): Handle arg and frame pointers. * config/avr/avr.h (FIXED_REGISTERS): Adjust arg pointer, add soft frame pointer. (CALL_USED_REGISTERS): Likewise. (REG_CLASS_CONTENTS): Likewise. (REGISTER_NAMES): Likewise. (HARD_REGNO_NREGS): Use avr_hard_regno_nregs. (HARD_FRAME_POINTER_REGNUM): New. (FRAME_POINTER_REGNUM): Use soft frame pointer. (ELIMINABLE_REGS): Eliminate from the soft frame pointer, remove the HARD_FRAME_POINTER self-elimination. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h
[Bug c++/41090] [4.4/4.5/4.6/4.7/4.8 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2012-01-12 19:05:32 UTC --- We should probably resurrect the decloning patch http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01147.html for this reason as well as the space optimization.
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit 32bit conversion produces incorrect results with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-01/msg00630.htm ||l --- Comment #17 from Uros Bizjak ubizjak at gmail dot com 2012-01-12 19:18:06 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00630.html
[Bug middle-end/51837] New: Use of result from 64*64-128 bit multiply via __uint128_t not optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51837
Bug #: 51837
Summary: Use of result from 64*64-128 bit multiply via
__uint128_t not optimized
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: svfue...@gmail.com
unsigned long long foo(unsigned long long x, unsigned long long y)
{
__uint128_t z = (__uint128_t)x * y;
return z ^ (z 64);
}
Compiles into
mov%rsi, %rax
mul%rdi
mov%rax, %r9
mov%rdx, %rax
xor%r9, %rax
retq
The final two mov instructions are not needed, and the above is equivalent to
mov%rsi, %rax
mul%rdi
xor%rdx, %rax
retq
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 19:25:31 UTC --- (In reply to comment #8) It honors the umask, allows for fancy combinations such as g+w-r,a+x,-w,o=u,u+s,+t. Seemingly, I misread POSIX: For my program o=u sets other to the original permissions. By contrast, GNU chmod sets it to the last permission. For: umask 022; mkdir foo; chmod g+w-r,a+x,-w,o=u foo the difference is whether other is r-x or rwx. In the code: Simply replace old_mode by file_mode. I have meanwhile also converted the fixed program into a libgfortran patch: http://gcc.gnu.org/ml/fortran/2012-01/msg00126.html
[Bug c/51838] New: Inefficient add of 128 bit quantity represented as 64 bit tuple to 128 bit integer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51838
Bug #: 51838
Summary: Inefficient add of 128 bit quantity represented as 64
bit tuple to 128 bit integer.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: svfue...@gmail.com
void foo(__uint128_t *x, unsigned long long y, unsigned long long z)
{
*x += y + ((__uint128_t) z 64);
}
Compiles into:
mov%rdx,%r8
mov%rsi,%rax
xor%edx,%edx
add(%rdi),%rax
mov%rdi,%rcx
adc0x8(%rdi),%rdx
xor%esi,%esi
add%rsi,%rax
adc%r8,%rdx
mov%rax,(%rcx)
mov%rdx,0x8(%rcx)
retq
The above can be optimized into:
add%rsi, (%rdi)
adc%rdx, 8(%rdi)
retq
[Bug c/51839] New: GCC not generating adc instruction for canonical multi-precision add sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51839
Bug #: 51839
Summary: GCC not generating adc instruction for canonical
multi-precision add sequence
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: svfue...@gmail.com
The multi-precision add
void foo(unsigned long long *x, unsigned long long y, unsigned long long z)
{
x[0] += y;
x[1] += z + (x[0] y);
}
compiles into:
mov%rsi,%rax
add(%rdi),%rax
add0x8(%rdi),%rdx
cmp%rax,%rsi
mov%rax,(%rdi)
seta %al
movzbl %al,%eax
add%rax,%rdx
mov%rdx,0x8(%rdi)
retq
Instead, gcc could use the adc instruction, yielding the wanted:
add%rsi, (%rdi)
adc%rdx, 8(%rdi)
retq
[Bug c++/51833] ICE in tsubst_copy, at cp/pt.c:11333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51833 --- Comment #5 from Richard Eames naddiseo at gmail dot com 2012-01-12 20:01:15 UTC --- I've reduced the testcase further. It appears to be a problem with templates. The reason I was passing a function type in the template was because std::functionbool(Arg*) wouldn't work for me. If I take out the first parameter so that it's just the function pointer, then std::function works with the lambda as a default argument, but as soon as the function is templated I get the IRC.
[Bug c++/51833] ICE in tsubst_copy, at cp/pt.c:11333
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51833 --- Comment #6 from Richard Eames naddiseo at gmail dot com 2012-01-12 20:01:52 UTC --- Created attachment 26309 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26309 Reduced test case
[Bug c++/44731] [4.5 Regression] Return value optimization produces inaccurate debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44731 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.5.0 |4.5.4
[Bug c/32511] [4.4/4.5 Regression] GCC rejects inline+weak function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.7
[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.2 |4.6.3
[Bug rtl-optimization/42502] [4.4/4.5 Regression] Poor register allocation in very simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:23:58 UTC --- Fixed so closing.
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 20:26:18 UTC --- Author: burnus Date: Thu Jan 12 20:26:10 2012 New Revision: 183137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183137 Log: 2012-01-12 Tobias Burnus bur...@net-b.de PR fortran/36755 * intrinsic.texi (CHMOD): Extend a bit and remove statement that /bin/chmod is called. 2012-01-12 Tobias Burnus bur...@net-b.de PR fortran/36755 * intrinsics/chmod.c (chmod_func): Replace call to /bin/chmod Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/chmod.c
[Bug target/42818] Static C++ linking breakage undefined reference to ___real__Znwj and others in libcygwin.a(_cygwin_crt0_common.o)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.5.3 |---
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.5.3 |4.5.0 Known to fail|| --- Comment #20 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:26:59 UTC --- Fixed so closing.
[Bug target/46788] unsigned int possible treated as signed in a union/struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46788 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:29:20 UTC --- Fixed.
[Bug tree-optimization/46693] incorrect code generation with -O2 optimization enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46693 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:31:24 UTC --- Fixed so closing as such.
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-12 20:29:19 UTC --- FIXED on the 4.7 trunk. Thanks HJ for the report!
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.3 |4.6.0 --- Comment #29 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:32:38 UTC --- Fixed.
[Bug target/45094] [arm] wrong instructions for dword move in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.3 |4.6.0 --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:34:14 UTC --- Fixed in 4.6.0.
[Bug target/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45616 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.5.3 |---
[Bug other/34687] as crashed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34687 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-12 20:39:01 UTC --- Since this works for many other people and it was a binary release it is hard for us to support this.
[Bug bootstrap/39968] Should plugins use shared library?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.5.3 |---
[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #15 from David Edelsohn dje at gcc dot gnu.org 2012-01-12 20:33:57 UTC --- It looks like POWER needs to accept and deal with the sequentially consistent semantics now specified for the __sync_* intrinsics, so I am closing this bug as WONTFIX. But we still need to fix the libstdc++ regression created by this change.
