[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:33:36 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=181172
[Bug tree-optimization/55964] [4.7/4.8 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.3 Summary|Segmentation fault with -O |[4.7/4.8 Regression] |-ftree-loop-distribution|Segmentation fault with -O |-funswitch-loops|-ftree-loop-distribution ||-funswitch-loops Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:34:08 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=181172
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.3 |4.8.0 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:35:19 UTC --- Please ignore previous comment, it was meant for PR55964.
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:42:33 UTC --- Created attachment 29159 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29159 gcc48-pr55955.patch Untested fix.
[Bug c/55967] New: rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967
Bug #: 55967
Summary: rightshift an unsigned value (X) by it's number of
bits does not always yield 0, when X is an unsigned
that's leftshifted by it's number of bits and offset
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b1262...@rmqkr.net
Hi,
I'm curring gcc via MinGW on a 32 bit PC:
The output of the following
//
#include stdio.h
int main(void)
{
printf(%lu\n, ((1U(32;
printf(%lu\n, ((1U(32))) + 0x8000U);
printf(%lu\n, (((1U(32))) + 0x8000U) 32U); /* expecting 0 but get
0x8000U instead. BUG */
printf(%lu\n, ( 0x8000U) 32U); /* compare: here
correctly get 0! */
printf(%lu\n, (((1U(32))) ) 32U); /* compare: here
correctly get 0! */
return 0;
return 0;
}
//
is:
0
2147483648
2147483648 // Bug!
0
0
THE 3rd output line IS A BUG, right? I expect to get 0.
And why do I expect 0. Because I've got a 32-bit number and rightshift it by
32.
Ouput lines 4 and 5 do that correctly: they yield 0.
So what's going on in line 3 ?
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32
--prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
Thanks.
[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967 --- Comment #1 from JoeSoe b1262178 at rmqkr dot net 2013-01-14 12:53:24 UTC --- Of course I get warnings... go.c:146:3: warning: left shift count = width of type [enabled by default] go.c:146:3: warning: right shift count = width of type [enabled by default] And of course ((1U(32))) is also undefined behaviour, since the www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=578 states on undefined behaviour: An expression is shifted by a negative number or by an amount greater than or equal to the width of the promoted expression (6.5.7). Bit even if this is undefined behaviour, I would like gcc to handle this gracefully, as is the case with (((1U(32))) ) 32U which gracefully yields 0. So the following should also do the graceful thing and yield 0, right? ((1U(32))) + 0x8000U) 32U
[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 13:02:12 UTC --- The testcase is invalid, the bug is only on the side of the testcase.
[Bug tree-optimization/55964] [4.7/4.8 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 13:14:33 UTC --- Mine.
[Bug bootstrap/55961] [4.8 Regression] system.h includes gmp.h but system.h is included for build and not just target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55961 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 13:16:40 UTC --- Btw, previously we'd have #ifndef GENERATOR_FILE around gmp.h includes. I didn't see the point of this, but if it's not really required there we can re-instantiate it. Not sure if it's a good idea to change effective system.h behavior though - system.h is included in configure tests. I doubt we properly separate tests for build vs. host. Do we?
[Bug web/55954] Bugzilla breaks mail threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55954 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 13:18:58 UTC --- (In reply to comment #3) Without the New I can't keep track of new bugs at http://gcc.gnu.org/ml/gcc-bugs/2013-01/ which is how I monitor and respond to libstdc++ bugs. Me too, I'd rather not lose New: markers. Pretty please. Thus - WONTFIX. It's a MUA error not to look at In-Reply-To.
[Bug sanitizer/55488] Implement cold calls in tsan run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-14 13:20:01 UTC --- thanks! I confirmed the fix.
[Bug rtl-optimization/55950] Invalid sqrt constant propagation with -frounding-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55950 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 13:21:45 UTC --- Confirmed. real.c has all the bells and whistles to implement this I think.
[Bug target/55945] alloca aligns aligned pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55945 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 13:23:00 UTC --- Confirmed.
[Bug middle-end/55943] [4.8 Regression] ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|ICE in gen_reg_rtx |[4.8 Regression] ICE in ||gen_reg_rtx Known to fail||4.8.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 13:23:53 UTC --- At least a regression in 4.8 then.
[Bug tree-optimization/55968] New: Bytemark HUFFMAN 11% slower with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55968 Bug #: 55968 Summary: Bytemark HUFFMAN 11% slower with -ftree-vectorize Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz with -fno-tree-vectorize HUFFMAN :5232 : 145.08 : 46.33 without -fno-tree-vectorize HUFFMAN : 4640.9 : 128.69 : 41.10 CFLAGS = -fomit-frame-pointer -Wall -O3 -funroll-loops -g0 -march=corei7 -ffast-math -fno-PIE -fno-exceptions -fno-stack-protector -static CPU Sandy Bridge
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2013-01-14 13:37:14 UTC --- (In reply to comment #2) How did I configure which GCC? The cross compiler or the native one? The crosscompiler.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #34 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14
13:42:36 UTC ---
static void
output_node_opt_summary (struct output_block *ob,
struct cgraph_node *node,
lto_symtab_encoder_t encoder)
{
...
gcc_assert (EXPR_LOCATION (map-new_tree) == UNKNOWN_LOCATION);
isn't recursively checking EXPR_LOCATION.
Index: gcc/lto-cgraph.c
===
--- gcc/lto-cgraph.c(revision 195144)
+++ gcc/lto-cgraph.c(working copy)
@@ -1492,6 +1492,22 @@ output_edge_opt_summary (struct output_b
{
}
+static tree
+verify_no_location (tree *tp, int *walk_subtrees, void *)
+{
+ if (EXPR_P (*tp))
+gcc_assert (EXPR_LOCATION (*tp) == UNKNOWN_LOCATION);
+ else
+*walk_subtrees = 0;
+ return NULL_TREE;
+}
+
+static void
+verify_no_location (tree expr)
+{
+ walk_tree (expr, verify_no_location_r, NULL, NULL);
+}
+
/* Output optimization summary for NODE to OB. */
static void
@@ -1536,7 +1552,9 @@ output_node_opt_summary (struct output_b
mechanism to store function local declarations into summaries. */
gcc_assert (parm);
streamer_write_uhwi (ob, parm_num);
- gcc_assert (EXPR_LOCATION (map-new_tree) == UNKNOWN_LOCATION);
+#ifdef ENABLE_CHECKING
+ verify_no_location (map-new_tree);
+#endif
stream_write_tree (ob, map-new_tree, true);
bp = bitpack_create (ob-main_stream);
bp_pack_value (bp, map-replace_p, 1);
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #35 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14
13:48:47 UTC ---
And the following may fix it at a single central place.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 195144)
+++ gcc/tree-inline.c (working copy)
@@ -2563,11 +2563,11 @@ setup_one_parameter (copy_body_data *id,
basic_block bb, tree *vars)
{
gimple init_stmt = NULL;
- tree var;
- tree rhs = value;
+ tree var, rhs;
tree def = (gimple_in_ssa_p (cfun)
? ssa_default_def (id-src_cfun, p) : NULL);
+ rhs = value = unshare_expr_without_location (value);
if (value
value != error_mark_node
!useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #36 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14
13:50:49 UTC ---
Or more conservative, dropping less locations:
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 195144)
+++ gcc/tree-inline.c (working copy)
@@ -5190,7 +5190,7 @@ tree_function_versioning (tree old_decl,
replace_info = (*tree_map)[i];
if (replace_info-replace_p)
{
- tree op = replace_info-new_tree;
+ tree op = unshare_expr_without_location (replace_info-new_tree);
if (!replace_info-old_tree)
{
int i = replace_info-parm_num;
@@ -5199,18 +5199,10 @@ tree_function_versioning (tree old_decl,
i --;
replace_info-old_tree = parm;
}
-
-
- STRIP_NOPS (op);
-
- if (TREE_CODE (op) == VIEW_CONVERT_EXPR)
- op = TREE_OPERAND (op, 0);
-
gcc_assert (TREE_CODE (replace_info-old_tree) == PARM_DECL);
+
init = setup_one_parameter (id, replace_info-old_tree,
- replace_info-new_tree, id.src_fn,
- NULL,
- vars);
+ op, id.src_fn, NULL, vars);
if (init)
init_stmts.safe_push (init);
}
[Bug go/55969] New: libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 Bug #: 55969 Summary: libgo fails to build on darwin Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: rgue...@gcc.gnu.org Target: x86_64-darwin Created attachment 29160 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29160 preprocessed source I get /Users/richard/obj/./gcc/xgcc -B/Users/richard/obj/./gcc/ -B/usr/local/x86_64-apple-darwin12.2.0/bin/ -B/usr/local/x86_64-apple-darwin12.2.0/lib/ -isystem /usr/local/x86_64-apple-darwin12.2.0/include -isystem /usr/local/x86_64-apple-darwin12.2.0/sys-include-DHAVE_CONFIG_H -I. -I../../../src/trunk/libgo -I ../../../src/trunk/libgo/runtime -I../../../src/trunk/libgo/../libffi/include -I../libffi/include -pthread -fexceptions -fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../src/trunk/libgo/../libgcc -I ../../../src/trunk/libgo/../libbacktrace -I ../../gcc/include -O2 -g -MT go-main.o -MD -MP -MF .deps/go-main.Tpo -c -o go-main.o `test -f 'runtime/go-main.c' || echo '../../../src/trunk/libgo/'`runtime/go-main.c -save-temps In file included from ../../../src/trunk/libgo/runtime/runtime.h:18:0, from ../../../src/trunk/libgo/runtime/go-main.c:17: /usr/include/ucontext.h:43:2: error: #error The deprecated ucontext routines require _XOPEN_SOURCE to be defined #error The deprecated ucontext routines require _XOPEN_SOURCE to be defined ^
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 14:09:53 UTC --- dnl See whether setcontext changes the value of TLS variables. AC_CACHE_CHECK([whether setcontext clobbers TLS variables], probably doesn't check what it should because of this, too.
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 14:24:32 UTC --- Created attachment 29161 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29161 gcc48-pr48766.patch Untested fix. Seems in the previous option processing the negative options cancel their corresponding positive options (and vice versa), and only the last occurrence of the option from the command line remains and the patch just disables -fwrapv if -ftrapv comes after -fwrapv, and vice versa. So e.g. -fwrapv -ftrapv -fwrapv results in -fwrapv -fwrapv -ftrapv results in -ftrapv -fwrapv -ftrapv -fno-wrapv results in -ftrapv -ftrapv -fwrapv -fno-trapv results in -fwrapv etc.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Summary|__attribute__ in class |[4.8 regression] |function declaration cause |__attribute__ in class |prototype does not match |function declaration cause |errors. |prototype does not match ||errors. Ever Confirmed|0 |1 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-01-14 14:33:21 UTC --- As I was saying on IRC, this is a change of behavior of the target attribute relative to 4.7, and therefore needs to be fixed for 4.8. The 4.7 behavior for this testcase must be restored, and MV needs to come up with a way of distinguishing between a redeclaration that omits optional attributes (as in this testcase) and an overload between two different versions. Perhaps use something like __attribute ((target (any)) for the default version so that it's clear that a declaration with no target attribute is a redeclaration (which is ambiguous if there are already multiple versions).
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.8.0
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 14:38:04 UTC --- I'd say once a target attribute appears at a declaration (non-definition) MV needs to be disabled. Or, the declarations target attribute and those at the MV definitions need to be merged. Thus, a declarations target attribute applies to all definitions (thus all MV variants).
[Bug tree-optimization/55970] New: [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970
Bug #: 55970
Summary: [x86] Avoid reverse order of function argument
gimplifying
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ysrum...@gmail.com
One important customer met with this problem in a process of porting app from
ARN to IA. The issue can be illustrated by attached example and essential for
x86 platform since only it defines 'PUSH_ARGS_REVERSED' macros. Note also that
attached code is not compliant with C99 standard since it assume definite order
of argument calculation.
gcc -O3 t.c t_main.c
./a.out
Test Failed
gcc -O3 t.c t_main_fix.c
./a.out
Test Passed
diff t_main.c t_main_fix.c
13c13,14
if (foo (foo1(), foo1()))
---
int x1 = foo1(), x2 = foo1();
if (foo (x1, x2))
You can see that gimplifying of function arguments (gimplify.c,
dimplify_call_expr) uses reverse order of arguments:
/* Finally, gimplify the function arguments. */
if (nargs 0)
{
for (i = (PUSH_ARGS_REVERSED ? nargs - 1 : 0);
PUSH_ARGS_REVERSED ? i = 0 : i nargs;
PUSH_ARGS_REVERSED ? i-- : i++)
{
...
I assume that we must no use reverse order in this place, i.e. loop header must
look like
for (i = 0; i nargs; i++)
[Bug middle-end/50199] [4.7/4.8 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de 2013-01-14 14:45:48 UTC --- On 1/11/13 5:02 PM, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 16:02:24 UTC --- I guess it is again too late to really fix this for 4.8, can we at least error out on -fno-merge-constants used together with -flto ? We'll still fail for targets that don't support mergeable string sections, but generally, it makes no sense to use -fno-merge-constants together with -flto. We could, I suppose. I'm not sure this isn't an issue without LTO though (possibly way harder to trigger though).
[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-01-14 14:46:48 UTC --- Created attachment 29162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29162 testcase
[Bug middle-end/50199] [4.7/4.8 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 14:55:45 UTC --- (In reply to comment #14) I'm not sure this isn't an issue without LTO though (possibly way harder to trigger though). I don't see how. -fno-merge-constants doesn't say that constants aren't merged within the same TU, they are merged always, -fno-merge-constants is about not allowing constants to be merged between different object files. As without LTO we operate at the level of individual TUs, we don't have issues with that. -fno-merge-constants is the only possible thing on targets that don't have needed support on the assembler/linker side though.
[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 14:56:23 UTC --- It's done that way to push to the stack in optimal order. Depending on function arg oder of evaluation is wrong.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 15:13:47 UTC --- Either use a different name of the attribute (replace target with mv_target or whatever), or require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8).
[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970 --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-01-14 15:15:52 UTC --- I pointed out that this code is not C standard compliant but it occurred in customer application that should be ported to x86 platform. This bug is not issued by gcc and very hard detected. Customer has more then 2000 such patterns in its application and he is not sure that all such patterns were found. So I still assume that we should fix it for x86 platform. Note also that icc does not have such issue.
[Bug preprocessor/55971] New: Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
Bug #: 55971
Summary: Preprocessor macros with C++11 raw string literals
fail to compile
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nachms+...@gmail.com
It does not seem possible to create a macro which contains a C++ raw string
literal, when it should be.
Example:
-
#include iostream
#define CREATE_CLIENTS R(CREATE TABLE clients(
clientId INTEGER PRIMARY KEY AUTOINCREMENT,
clientName VARCHAR(64) UNIQUE
))
int main()
{
std::cout CREATE_CLIENTS std::endl;
return 0;
}
-
g++ -W -Wall -o test test.cpp -std=c++11
test.cpp:3:24: error: unterminated raw string
test.cpp:6:3: warning: missing terminating character [enabled by default]
test.cpp:6:1: error: missing terminating character
test.cpp:10:3: error: stray ‘R’ in program
test.cpp:4:3: error: expected unqualified-id before string constant
On the other hand, clang seems to be able to handle it:
clang++ -W -Wall -o test test.cpp -std=c++11
./test
CREATE TABLE clients(
clientId INTEGER PRIMARY KEY AUTOINCREMENT,
clientName VARCHAR(64) UNIQUE
)
[Bug sanitizer/55938] g++.dg/asan/deep-stack-uaf-1.C fails at r195092 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-14 15:32:42 UTC --- Failure no longer present at r195150 remerged with llvm compiler-rt r172419 .
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-14 15:39:35 UTC --- probably another dup of Bug 52852
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-14 15:39:48 UTC --- Shouldn't this be part of PR46986? I was unaware that any of those issues mentioned in that PR had been addressed in gcc trunk for darwin yet.
[Bug middle-end/55943] [4.6/4.7/4.8 Regression] ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.8 Regression] ICE in |[4.6/4.7/4.8 Regression] |gen_reg_rtx |ICE in gen_reg_rtx Known to fail||4.4.1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 15:44:50 UTC --- I don't have 4.3 around, but 4.4.1 certainly ICEs on this, both with -O0 and with optimizations. The ICE is during reload, similarly to the trunk ICE. I guess the testcase in the testsuite should be just limited to x86_64/i686 and perhaps few others where the r resp. =r constraint can be handled.
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 --- Comment #2 from Nach nachms+gcc at gmail dot com 2013-01-14 15:47:25 UTC --- Does look similar. Although this bug here is in the definition of the macro, while that bug is in the call of the macro. I'm sure they're related, but it'd be a shame if one was fixed, and the other was overlooked.
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2013-01-14 15:48:41 UTC --- (In reply to comment #12) Created attachment 29161 [details] gcc48-pr48766.patch Untested fix. Seems in the previous option processing the negative options cancel their corresponding positive options (and vice versa), and only the last occurrence of the option from the command line remains and the patch just disables -fwrapv if -ftrapv comes after -fwrapv, and vice versa. So e.g. -fwrapv -ftrapv -fwrapv results in -fwrapv -fwrapv -ftrapv results in -ftrapv -fwrapv -ftrapv -fno-wrapv results in -ftrapv -ftrapv -fwrapv -fno-trapv results in -fwrapv etc. Why not use Negative in common.opt?
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342
--- Comment #7 from Michael Matz matz at gcc dot gnu.org 2013-01-14 15:55:51
UTC ---
The patch should lead to wrong code at some places (when peeling for
alignment actually does something). The problem is, you
calculate base and step before peeling and cache that. Caching the step
is fine, but caching the base is not, as the peeling specifically changes
the initial value of the accessed pointer. For instance in the testcase
of pr53185.c we have this loop after peeling:
bb_6 (preds = {bb_8 bb_26 }, succs = {bb_8 bb_23 })
{
# .MEM_27 = PHI .MEM_21(8), .MEM_51(26)
# e.1_29 = PHI e.4_22(8), e.1_52(26)
_10 = (long unsigned int) e.1_29;
_11 = _10 * 4;
_12 = f_5(D) + _11;
_14 = (int) e.1_29;
_16 = _14 * pretmp_38;
_17 = (long unsigned int) _16;
_18 = _17 * 4;
_19 = pretmp_35 + _18;
# VUSE .MEM_27
_20 = *_19;
# .MEM_21 = VDEF .MEM_27
*_12 = _20;
e.4_22 = e.1_29 + 1;
if (e.4_22 a.5_26)
goto bb 8;
else
goto bb 23;
}
Note the initial value of e.1_52 for e.1_29. But your cached
information sets
iv.base = pretmp_35
iv.step = (long unsigned int) pretmp_38 * 4
It actually should be iv.base
= pretmp_35 + 4 * ((long unsigned int) (pretmp_38 * (int) e.1_52))
The casts here are actually the cause for simple_iv not working in this
case. This expression would have to be calculated outside the loop
and used as stride_base. I don't see where this could easily be done
from existing places (like where the peeling loop is generated).
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-14 15:56:02 UTC --- I think basically the preprocessor doesn't support raw strings. Fix that and both bugs should go away.
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 16:01:36 UTC --- Because it behaves differently. ./xgcc -B ./ -fwrapv -ftrapv -fno-trapv -fverbose-asm -S -xc /dev/null -o - 21 | grep rapv # -march=x86-64 -auxbase-strip - -fno-trapv -fverbose-asm with Negative(fwrapv) resp. Negative(ftrapv) added instead of this patch, while with that patch it was -fwrapv.
[Bug bootstrap/55961] [4.8 Regression] system.h includes gmp.h but system.h is included for build and not just target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55961 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2013-01-14 16:05:48 UTC --- We run configure for the build system in a subdirectory, when build != host. # auto-host.h is the file containing items generated by autoconf and is # the first file included by config.h. # If host=build, it is correct to have bconfig include auto-host.h # as well. If host!=build, we are in error and need to do more # work to find out the build config parameters. if test x$host = x$build then build_auto=auto-host.h else # We create a subdir, then run autoconf in the subdir. # To prevent recursion we set host and build for the new # invocation of configure to the build for this invocation # of configure. [...]
[Bug c++/55972] New: cannot access private member from lambda used in NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972
Bug #: 55972
Summary: cannot access private member from lambda used in NSDMI
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
The following short translation unit shows the issue:
class C
{
void f();
int j = 10;
int i = [this]() { return this-j; }();
};
$ g++ -std=c++11 x.cc
x.cc: In lambda function:
x.cc:4:11: error: ‘int C::j’ is private
x.cc:5:39: error: within this context
Non-static data member initializers (and lambdas used therein) should be able
to access private members of their class.
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 16:35:52 UTC --- That's not the case, because most of the raw string support is in the preprocessor.
[Bug c++/55720] [C++11] Linkage errors of static data member initializers with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55720 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1
[Bug c++/55972] cannot access private member from lambda used in NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-14 16:43:55 UTC --- Thanks, Jakub, for some reason I thought it had ben done in the FE. Let's confirm this then, it's not an exact dup.
[Bug target/55948] __atomic_clear / __atomic_store_n ignore HLE_RELEASE flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948 --- Comment #1 from uros at gcc dot gnu.org 2013-01-14 16:45:04 UTC --- Author: uros Date: Mon Jan 14 16:44:55 2013 New Revision: 195155 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195155 Log: PR target/55948 * config/i386/sync.md (atomic_storemode_1): New pattern. (atomic_storemode): Call atomic_storemode_1 for IX86_HLE_RELEASE memmodel flag. testsuite/ChangeLog PR target/55948 * gcc.target/i386/hle-clear-rel.c: New file * gcc.target/i386/hle-store-rel.c: New file. Added: trunk/gcc/testsuite/gcc.target/i386/hle-clear-rel.c trunk/gcc/testsuite/gcc.target/i386/hle-store-rel.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sync.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 16:45:11 UTC --- Can't we then compute the final values of the bases after the peeling loop, and add those gimplified after the peeling loop, then use them in the next loop?
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #11 from davidxl xinliangli at gmail dot com 2013-01-14 17:17:21 UTC --- (In reply to comment #9) I'd say once a target attribute appears at a declaration (non-definition) MV needs to be disabled. Or, the declarations target attribute and those at the MV definitions need to be merged. Thus, a declarations target attribute applies to all definitions (thus all MV variants). This might reduce the usefulness of MV -- using declarations with attributes to indicate MV candidates is the intended use model. David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #12 from davidxl xinliangli at gmail dot com 2013-01-14 17:20:56 UTC --- (In reply to comment #10) Either use a different name of the attribute (replace target with mv_target or whatever), or require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8). I like this proposal: require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8) David
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||tromey at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14
17:33:02 UTC ---
This is about:
if (pfile-state.in_directive
|| pfile-state.parsing_args
|| pfile-state.in_deferred_pragma)
{
cur--;
type = CPP_OTHER;
cpp_error_with_line (pfile, CPP_DL_ERROR, token-src_loc, 0,
unterminated raw string);
break;
}
in lex_raw_string, in this case state.in_directive is true, as it is in #define
directive. But just removing state.in_directive from that condition isn't
enough,
1537 _cpp_process_line_notes (pfile, false);
1538 if (!_cpp_get_fresh_line (pfile))
doesn't handle this case correctly.
[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-14 17:34:28 UTC --- (In reply to comment #3) Maybe we should warn about these cases just like we warn for the other unspecified behavior which causes undefined behavior (aka a+=a+1).
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #3 from Ian Lance Taylor ian at airs dot com 2013-01-14 17:35:21 UTC --- Gccgo doesn't work on Darwin anyhow. I don't think the problems are hard to fix.
[Bug other/55973] New: r195150 doesn't properly handle out of tree isl 0.11.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55973 Bug #: 55973 Summary: r195150 doesn't properly handle out of tree isl 0.11.1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The commit... Author: rguenth Date: Mon Jan 14 15:01:13 2013 New Revision: 195150 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195150 Log: 2013-01-14 Richard Biener rguent...@suse.de * configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG 0.18.0. * configure: Re-generate doesn't handle out of tree installations of isl 0.11.1 as config/isl.m4 needs to be taught how to handle revision numbers in the complete version number. The proposed patch in... http://gcc.gnu.org/ml/gcc/2012-12/msg00195.html does this. The current commit also has a stray instance of... ISL_CHECK_VERSION(0,10) in configure.ac and doesn't recognize that the current checks are still hard-coded to a specific version. So either isl 0.11 or 0.11.1 was be designated in configure.ac.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #13 from Sriraman Tallam tmsriram at google dot com 2013-01-14 17:45:42 UTC --- (In reply to comment #12) (In reply to comment #10) Either use a different name of the attribute (replace target with mv_target or whatever), or require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8). I like this proposal: I too like just using a different attribute name. I will prepare a patch asap for this. Thanks Sri. require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8) David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #14 from davidxl xinliangli at gmail dot com 2013-01-14 17:49:59 UTC --- (In reply to comment #13) (In reply to comment #12) (In reply to comment #10) Either use a different name of the attribute (replace target with mv_target or whatever), or require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8). I like this proposal: I too like just using a different attribute name. I will prepare a patch asap for this. Thanks Sri. require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8) David I mean Jacub's second alternative -- adding additional attribute that alters the meaning of 'target' attribute -- when it is present, no merging will be done. David
[Bug fortran/55618] [4.6 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 --- Comment #9 from Paul Thomas pault at gcc dot gnu.org 2013-01-14 17:59:13 UTC --- Author: pault Date: Mon Jan 14 17:59:07 2013 New Revision: 195159 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195159 Log: 2013-01-14 Paul Thomas pa...@gcc.gnu.org PR fortran/55618 * trans-expr.c (gfc_conv_procedure_call): Dereference scalar character function arguments to elemental procedures in scalarization loops. 2013-01-14 Paul Thomas pa...@gcc.gnu.org PR fortran/55618 * gfortran.dg/elemental_scalar_args_2.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/elemental_scalar_args_2.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #15 from Sriraman Tallam tmsriram at google dot com 2013-01-14 18:07:28 UTC --- (In reply to comment #14) (In reply to comment #13) (In reply to comment #12) (In reply to comment #10) Either use a different name of the attribute (replace target with mv_target or whatever), or require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8). I like this proposal: I too like just using a different attribute name. I will prepare a patch asap for this. Thanks Sri. require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8) David I mean Jacub's second alternative -- adding additional attribute that alters the meaning of 'target' attribute -- when it is present, no merging will be done. Ok, so the two options are : 1) int foo __attribute__ ((mv_target (sse4.2))); 2) int foo __attribute__ ((target(sse4.2)), mv); I dont have a strong preference. David
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de 2013-01-14 18:23:21 UTC --- ian at airs dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #3 from Ian Lance Taylor ian at airs dot com 2013-01-14 17:35:21 UTC --- Gccgo doesn't work on Darwin anyhow. I don't think the problems are hard to fix. I expected to get go excluded then as not supported...
[Bug target/55974] New: [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 Bug #: 55974 Summary: [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: g...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr Suffixes for these macros are L resp. UL, but with -mint8 they must be LL resp. ULL
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 18:25:41 UTC --- I guess if for multiversioning you want the two decls to be independent, like overloaded functions with different argument types are, then IMHO the mv attribute alternative and not merging anything at all in that case (neither the decls, nor any of the attributes (not just target attribute) is better.
[Bug target/55974] [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-01-14 18:28:37 UTC --- Author: gjl Date: Mon Jan 14 18:28:24 2013 New Revision: 195169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195169 Log: PR target/55974 * config/avr/avr-c.c (avr_cpu_cpp_builtins): Define __FLASH etc. to 1 and not to __flash. Use LL suffix for __INT24_MAX__ with -mint8. Use ULL suffix for __UINT24_MAX__ with -mint8. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c
[Bug target/55974] [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-01-14 18:32:19 UTC --- Author: gjl Date: Mon Jan 14 18:32:05 2013 New Revision: 195170 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195170 Log: Backport from 2013-01-14 trunk r195169. PR target/55974 * config/avr/avr-c.c (avr_cpu_cpp_builtins): Define __FLASH etc. to 1 and not to __flash. Use LL suffix for __INT24_MAX__ with -mint8. Use ULL suffix for __UINT24_MAX__ with -mint8. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr-c.c
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 18:32:44 UTC --- Actually, what you'd merge is everything as usually if mv attribute isn't on either of the decls, or if mv attribute is present on either one, and both decls have either the same target attribute, or no target attribute at all. If mv attribute is on newdecl or olddecl, and target attribute is either present on just one of the decls, or on both, but with different argument, it would treat them as decls that mangle differently and won't be merged.
[Bug target/55974] [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-01-14 18:33:35 UTC --- Fixed in 4.7.3
[Bug fortran/55618] [4.6, 4.7, 4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|[4.6 Regression] Failures |[4.6, 4.7, 4.8 Regression] |with ISO_Varying_String |Failures with |test suite |ISO_Varying_String test ||suite --- Comment #10 from Paul Thomas pault at gcc dot gnu.org 2013-01-14 18:44:42 UTC --- Fixed on 4.6, 4.7 and 4.8 - thanks for the report. Paul
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
19:06:02 UTC ---
Here's a test case. This requires the libstdc++ HLE patch from
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00673.html
g++ -std=gnu++0x
#include atomic
#define ACQ memory_order_acquire | __memory_order_hle_acquire
#define REL memory_order_release | __memory_order_hle_release
int main()
{
using namespace std;
atomic_ulong au = ATOMIC_VAR_INIT(0);
if (!au.fetch_and(1, ACQ))
au.fetch_and(-1, REL);
unsigned lock = 0;
__atomic_fetch_and(lock, 1, __ATOMIC_HLE_ACQUIRE|__ATOMIC_ACQUIRE);
return 0;
}
The first fetch_and generates incorrectly:
.L2:
movq%rax, %rcx
movq%rax, %rdx
andl$1, %ecx
lock; cmpxchgq %rcx, -24(%rsp)
jne .L2
The second generates correctly:
lock;
.byte 0xf3
andq$-1, -24(%rsp)
The __atomic_fetch_and generates correctly:
lock;
.byte 0xf2
andl$1, -28(%rsp)
The first fetch_and should generate the same code sequence.
[Bug sanitizer/55975] New: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 Bug #: 55975 Summary: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org Target: powerpc64-*-* ==4629== AddressSanitizer CHECK failed: ../../../../../libsanitizer/asan/asan_thread.cc:74 ((AddrIsInMem(stack_bottom_))) != (0) (0x0, 0x0) = ==4629== ERROR: AddressSanitizer: unknown-crash on address 0x3fffdcef88d0 at pc 0x3fffae6bcb1c bp 0x3fffdcef7400 sp 0x3fffdcef7470 WRITE of size 1 at 0x3fffdcef88d0 thread T0 ==4629== AddressSanitizer: while reporting a bug found another one.Ignoring. This only fails with -m64, the -m32 test works.
[Bug target/27338] Violation of mips o64 ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27338 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2013-01-14 19:25:36 UTC --- Yeah, trh(In reply to comment #2) Richard, has the need for any documentation change been removed by the age of this defect? Perhaps it should just be closed now. Yeah, that would probably be best. I hang my head in shame at how long it's taken me to do nothing.
[Bug inline-asm/55775] [4.8 Regression] ICE when building pari
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55775 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2013-01-14 19:35:10 UTC --- Author: steven Date: Mon Jan 14 19:35:03 2013 New Revision: 195173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195173 Log: * ira-build.c (ira_flattening): Comment fix. Port the following LRA changes on trunk back to the LRA branch: 2013-01-10 Vladimir Makarov vmakarov at redhat dot com PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2012-12-21 Vladimir Makarov vmakarov at redhat dot com PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. 2012-12-21 Steve Ellcey sellcey at mips dot com PR bootstrap/54128 * ira.c (build_insn_chain): Check only NONDEBUG instructions for register usage. 2012-12-11 Jakub Jelinek jakub at redhat dot com PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: branches/lra/gcc/ChangeLog branches/lra/gcc/ira-build.c branches/lra/gcc/ira.c branches/lra/gcc/lra-assigns.c branches/lra/gcc/lra-constraints.c branches/lra/gcc/lra-eliminations.c branches/lra/gcc/lra-int.h
[Bug rtl-optimization/55193] [4.8 Regression] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2013-01-14 19:35:10 UTC --- Author: steven Date: Mon Jan 14 19:35:03 2013 New Revision: 195173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195173 Log: * ira-build.c (ira_flattening): Comment fix. Port the following LRA changes on trunk back to the LRA branch: 2013-01-10 Vladimir Makarov vmakarov at redhat dot com PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2012-12-21 Vladimir Makarov vmakarov at redhat dot com PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. 2012-12-21 Steve Ellcey sellcey at mips dot com PR bootstrap/54128 * ira.c (build_insn_chain): Check only NONDEBUG instructions for register usage. 2012-12-11 Jakub Jelinek jakub at redhat dot com PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: branches/lra/gcc/ChangeLog branches/lra/gcc/ira-build.c branches/lra/gcc/ira.c branches/lra/gcc/lra-assigns.c branches/lra/gcc/lra-constraints.c branches/lra/gcc/lra-eliminations.c branches/lra/gcc/lra-int.h
[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 --- Comment #18 from Steven Bosscher steven at gcc dot gnu.org 2013-01-14 19:35:10 UTC --- Author: steven Date: Mon Jan 14 19:35:03 2013 New Revision: 195173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195173 Log: * ira-build.c (ira_flattening): Comment fix. Port the following LRA changes on trunk back to the LRA branch: 2013-01-10 Vladimir Makarov vmakarov at redhat dot com PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2012-12-21 Vladimir Makarov vmakarov at redhat dot com PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. 2012-12-21 Steve Ellcey sellcey at mips dot com PR bootstrap/54128 * ira.c (build_insn_chain): Check only NONDEBUG instructions for register usage. 2012-12-11 Jakub Jelinek jakub at redhat dot com PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: branches/lra/gcc/ChangeLog branches/lra/gcc/ira-build.c branches/lra/gcc/ira.c branches/lra/gcc/lra-assigns.c branches/lra/gcc/lra-constraints.c branches/lra/gcc/lra-eliminations.c branches/lra/gcc/lra-int.h
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 Matt Fago fago at earthlink dot net changed: What|Removed |Added CC||fago at earthlink dot net --- Comment #12 from Matt Fago fago at earthlink dot net 2013-01-14 19:35:43 UTC --- FYI, I recently ran into this issue as well building gcc 4.7.2 on MacOS 10.7.5 with XCode 4.1 installed. Configured via: ../gcc-4.7.2/configure --enable-languages=c,c++,fortran --enable-lto \ --program-suffix=-4.7 --enable-checking=release This command will use Apple's gcc 4.2.1. Bootstrap fails due to an ICE (I believe during the glibc build). First setting: export CC=gcc-4.4 export CXX=g++-4.4 fails with the error described in this bug report, while including -D_FORTIFY_SOURCE=0 in the above exports allows gcc to bootstrap.
[Bug c/55976] New: -Werror=return-type should error on returning a value from a void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
Bug #: 55976
Summary: -Werror=return-type should error on returning a value
from a void function
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lu_z...@gentoo.org
Stupid testcase
#include stdio.h
void t () { return 1; } // does not error
int b () { return; }// does
int main()
{
t(); b();
return 0;
}
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2013-01-14 19:44:36 UTC --- (In reply to comment #2) Vlad, can you please have a look? Thanks. Ok, I started to work on this.
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14 19:52:03 UTC --- Created attachment 29163 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29163 preprocessed testcase
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Attachment #29163|0 |1 is obsolete|| --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14 20:15:11 UTC --- Created attachment 29164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29164 preprocessed test case Sorry earlier was the wrong file
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #18 from davidxl xinliangli at gmail dot com 2013-01-14 20:17:45 UTC --- All target attributes on decls not tagged with 'mv' attribute should be merged into the default definition. Any decl tagged with 'mv' should be treated as a new decl. David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 20:23:54 UTC --- That wouldn't work, because you would then have the default (non-mv) version, possibly mv version with no target attribute, and then some other mv versions with target attributes. The problem with that is that the first two mangle the same. This means that a non-mv and mv with no target attribute needs to be treated as the same decl (i.e. merged together).
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #20 from davidxl xinliangli at gmail dot com 2013-01-14 20:29:54 UTC --- (In reply to comment #19) That wouldn't work, because you would then have the default (non-mv) version, possibly mv version with no target attribute, and then some other mv versions with target attributes. The problem with that is that the first two mangle the same. This means that a non-mv and mv with no target attribute needs to be treated as the same decl (i.e. merged together). that makes sense -- mv annotated decl without target attribute gets merged with default version -- basically it has no actual effect. David
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||dominiq at lps dot ens.fr Resolution|FIXED | --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2013-01-14 20:32:04 UTC --- ICE noted by Dominique d'Humieres with module m type :: foobar real, pointer :: array(:) procedure (), pointer, nopass :: f end type contains elemental subroutine fooAssgn (a1, a2) type(foobar), intent(out) :: a1 type(foobar), intent(in) :: a2 allocate (a1%array(size(a2%array))) a1%array = a2%array a1%f = a2%f end subroutine end module m Dominique also provided the fix on #gfortran: in gfc_check_pointer_assign of ../../gcc/fortran/expr.c:3540 replacing if (s2-attr.proc_pointer with if (s2 s2-attr.proc_pointer lets the code compile. Will commit as 'obvious' as soon as it has bootstrapped and regtested. Paul
[Bug other/55973] r195150 doesn't properly handle out of tree isl 0.11.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55973 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-14 20:49:22 UTC --- The change in r195150 doesn't take in account that the results from each call to ISL_CHECK_VERSION() is cached. So the results from a failed first test of ISL_CHECK_VERSION(0,10) are used when ISL_CHECK_VERSION(0,11) instead of actually compiling the isl version check again for 0.11.x. -g -O2 -I/opt/mp/include -I/opt/mp/include checking for version 0.10 of ISL... no -g -O2 -I/opt/mp/include -I/opt/mp/include checking for version 0.11 of ISL... (cached) no configure: error: Unable to find a usable ISL. See config.log for details.
[Bug libstdc++/55977] New: [C++11] vector range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977
Bug #: 55977
Summary: [C++11] vector range construction imposes unnecessary
conversion constraints
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code compiled with gcc 4.8.0 20130113 (experimental) using the
flags
-Wall -std=c++11 -pedantic
is rejected:
//-
#include memory
#include utility
#include vector
#include iterator
#include iostream
template class T
struct MyAllocator {
std::allocatorT base;
typedef T value_type;
MyAllocator() = default;
template class U
MyAllocator(const MyAllocatorU other) : base(other.base) {}
T* allocate(std::size_t n) { return base.allocate(n); }
void deallocate(T* p, std::size_t n) { return base.deallocate(p, n); }
template class U, class... Args
void construct(U* p, Args... args)
{
::new (static_castvoid*(p)) T(std::forwardArgs(args)...);
}
};
struct A {
private:
friend class MyAllocatorA;
A(int value) : value(value) {}
int value;
public:
A() : value() {}
int get() const { return value; }
};
int main()
{
std::vectorA, MyAllocatorA v1;
const int i = 1;
v1.emplace_back(i); // OK
std::vectorA, MyAllocatorA v2(std::istream_iteratorint(std::cin), {});
// Error
}
//-
[..]gcc\include\c++\4.8.0\bits\stl_vector.h||In instantiation of 'void
std::vector_Tp, _Alloc::_M_range_initialize(_InputIterator, _InputIterator,
std::input_iterator_tag) [with _InputIterator = std::istream_iteratorint; _Tp
= A; _Alloc = MyAllocatorA]':|
[..]gcc\include\c++\4.8.0\bits\stl_vector.h|1178|required from 'void
std::vector_Tp, _Alloc::_M_initialize_dispatch(_InputIterator,
_InputIterator, std::__false_type) [with _InputIterator =
std::istream_iteratorint; _Tp = A; _Alloc = MyAllocatorA]'|
[..]gcc\include\c++\4.8.0\bits\stl_vector.h|396|required from 'std::vector_Tp,
_Alloc::vector(_InputIterator, _InputIterator, const allocator_type) [with
_InputIterator = std::istream_iteratorint; template-parameter-2-2 = void;
_Tp = A; _Alloc = MyAllocatorA; std::vector_Tp, _Alloc::allocator_type =
MyAllocatorA]'|
main.cpp|38|required from here|
main.cpp|26|error: 'A::A(int)' is private|
[..]gcc\include\c++\4.8.0\bits\stl_vector.h|1188|error: within this context
The error is due to a call of push_back with an previous int-A conversion.
Such an conversion from the iterator's value_type to the containers value_type
is not feasible. The specification of the corresponding constructor is
(indirectly) ruled by Table 100, expression X(i, j):
Requires: T shall be EmplaceConstructible into X from *i.
Move/CopyConstructible or Convertible to value_type are not required.
Instead of invoking push_back this constructor should internally invoke the
equivalent of emplace_back.
The same problem also occurs for other standard containers such as std::list.
[Bug fortran/55978] New: [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 Bug #: 55978 Summary: [4.8 Regression] class_optional_2.f90 -Os fails Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org This is for Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local Thread model: posix gcc version 4.8.0 20130113 (experimental) (GCC) FAIL: gfortran.dg/class_optional_2.f90 -Os execution test May be related to PR 55483.
[Bug fortran/54767] [4.7/4.8 Regression] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2013-01-14 21:01:34 UTC --- Workaround: -fno-tree-vrp
[Bug libstdc++/55979] New: [C++11] std::list range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55979
Bug #: 55979
Summary: [C++11] std::list range construction imposes
unnecessary conversion constraints
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code provided by Jonathan compiled with gcc 4.8.0 20130113
(experimental) using the flags
-Wall -std=c++11 -pedantic
is rejected:
//---
#include list
struct A
{
A(int) { }
A(const A) = delete;
A operator=(const A) = delete;
};
int main()
{
int i[] = {1, 2};
std::listA li(i, i + 2);
}
//---
[..]gcc\include\c++\4.8.0\bits\stl_list.h||In instantiation of
'std::_List_node_Tp::_List_node(_Args ...) [with _Args = {A}; _Tp = A]':|
[..]\gcc\include\c++\4.8.0\ext\new_allocator.h|120|required from 'void
__gnu_cxx::new_allocator_Tp::construct(_Up*, _Args ...) [with _Up =
std::_List_nodeA; _Args = {A}; _Tp = std::_List_nodeA]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|506|required from 'std::list_Tp,
_Alloc::_Node* std::list_Tp, _Alloc::_M_create_node(_Args ...) [with _Args
= {A}; _Tp = A; _Alloc = std::allocatorA; std::list_Tp, _Alloc::_Node =
std::_List_nodeA]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|1558|required from 'void
std::list_Tp, _Alloc::_M_insert(std::list_Tp, _Alloc::iterator, _Args
...) [with _Args = {A}; _Tp = A; _Alloc = std::allocatorA; std::list_Tp,
_Alloc::iterator = std::_List_iteratorA]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|1022|required from 'void
std::list_Tp, _Alloc::push_back(std::list_Tp, _Alloc::value_type) [with
_Tp = A; _Alloc = std::allocatorA; std::list_Tp, _Alloc::value_type = A]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|1491|required from 'void
std::list_Tp, _Alloc::_M_initialize_dispatch(_InputIterator, _InputIterator,
std::__false_type) [with _InputIterator = int*; _Tp = A; _Alloc =
std::allocatorA]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|628|required from 'std::list_Tp,
_Alloc::list(_InputIterator, _InputIterator, const allocator_type) [with
_InputIterator = int*; template-parameter-2-2 = void; _Tp = A; _Alloc =
std::allocatorA; std::list_Tp, _Alloc::allocator_type =
std::allocatorA]'|
main.cpp|13|required from here|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|115|error: use of deleted function
'A::A(const A)'|
main.cpp|6|error: declared here
The error is due to a call of push_back with an previous int-A conversion.
Such an conversion from the iterator's value_type to the containers value_type
is not feasible. The specification of the corresponding constructor is
(indirectly) ruled by Table 100, expression X(i, j):
Requires: T shall be EmplaceConstructible into X from *i.
Move/CopyConstructible or Convertible to value_type are not required.
Instead of invoking push_back this constructor should internally invoke the
equivalent of emplace_back.
This issue is similar to bug 55977 involving std::vector, but occurs even with
the default allocator and for all iterator categories except input iterator,
therefore this issue is reported separately.
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2013-01-14 21:22:35 UTC --- The problem is, that in failed case maybe_emit_op() gets target register to return the result to, so with after=false, it expands via optab-mem_fetch_before. Unfortunately, atomic_fetch_logic or atomic_logic_fetch do not exist for x86 target, so generic expander falls back to exchange loop.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #22 from janus at gcc dot gnu.org 2013-01-14 21:24:43 UTC --- Author: janus Date: Mon Jan 14 21:24:36 2013 New Revision: 195178 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195178 Log: 2013-01-14 Janus Weil ja...@gcc.gnu.org PR fortran/55072 * trans-array.c (gfc_conv_array_parameter): No packing was done for full arrays of derived type. 2013-01-14 Janus Weil ja...@gcc.gnu.org PR fortran/55072 * gfortran.dg/internal_pack_13.f90: New test. * gfortran.dg/internal_pack_14.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/internal_pack_13.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/internal_pack_14.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-array.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2013-01-14 21:25:13
UTC ---
Following testcase will expand to a cmpxchg loop:
int hle_and (int *p, int v)
{
return __atomic_fetch_and_4 (p, v, __ATOMIC_ACQUIRE | __ATOMIC_HLE_ACQUIRE);
}
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 --- Comment #4 from lailavrazda1979 at gmail dot com 2013-01-14 21:26:36 UTC --- I tried building several compilers (4.7.2), none of which understand the '-mfxsr' option. One was configured with: ../gcc-4.7.2/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --prefix=$CROSS_DIR --libexecdir=$CROSS_DIR/lib --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-targets=all --enable-cloog-backend=ppl --disable-shared --disable-nls --disable-werror --with-host-libstdcxx=-lstdc++ -lsupc++ --with-local-prefix=$CROSS_DIR --with-sysroot=$CROSS_DIR --with-ppl=$CROSS_DIR --with-cloog=$CROSS_DIR make all-gcc make install-gcc After that, I build the mingw-w64 library, went back to my GCC build dir, and did: make make install
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-14
21:29:25 UTC ---
For -O0, valgrind complains about
==15263== Conditional jump or move depends on uninitialised value(s)
==15263==at 0x4F26355: _gfortran_internal_pack (in_pack_generic.c:54)
==15263==by 0x403762: a3a1.2119 (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x400B26: MAIN__ (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x408F0E: main (in /home/ig25/Krempel/Os/a.out)
and
==15263==
==15263== Conditional jump or move depends on uninitialised value(s)
==15263==at 0x4F26447: _gfortran_internal_pack (in_pack_generic.c:159)
==15263==by 0x403762: a3a1.2119 (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x400B26: MAIN__ (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x408F0E: main (in /home/ig25/Krempel/Os/a.out)
which is
size = GFC_DESCRIPTOR_SIZE (source);
switch (type_size)
and
dim = GFC_DESCRIPTOR_RANK (source);
respectively.
Reduced test case (run with -fcoarray=single):
! { dg-do run }
! { dg-options -fcoarray=single }
!
! PR fortran/50981
! PR fortran/54618
!
implicit none
type t
integer, allocatable :: i
end type t
type, extends (t):: t2
integer, allocatable :: j
end type t2
call a3a()
contains
subroutine a3a(z, z2, z3)
type(t2), optional :: z(4)
type(t2), optional, pointer :: z2(:)
type(t2), optional, allocatable :: z3(:)
type(t2), allocatable :: x(:)
type(t2), pointer :: y(:)
y = null()
call a4t2(y)
end subroutine a3a
subroutine a4t2(x)
type(t2), intent(in), optional :: x(4)
if (present (x)) call abort ()
!print *, present(x)
end subroutine a4t2
end
[Bug target/55777] Inlining nomips16 function into mips16 function can result in undefined builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777 --- Comment #1 from Steve Ellcey sje at gcc dot gnu.org 2013-01-14 21:34:09 UTC --- gcc.target/mips/mips32-dspr2.c fails for the same reason.
[Bug fortran/55980] New: missed optimizations with internal_pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55980
Bug #: 55980
Summary: missed optimizations with internal_pack
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
This is a tracking bug for possible remaining problems of PR 55072:
---
1) In PR 55072 comment 13, Mikael writes about this patchlet:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 194517)
+++ gcc/fortran/trans-array.c(working copy)
@@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
this_array_result = false;
/* Passing address of the array if it is not pointer or assumed-shape. */
- if (full_array_var g77 !this_array_result)
+ if (full_array_var g77 !this_array_result
+ sym-ts.type != BT_DERIVED sym-ts.type != BT_CLASS)
{
tmp = gfc_get_symbol_decl (sym);
It feels like a hack (that what there before) to blindly disable derived types
here. The real problem is that the code under the if condition supports only
bare variables without subreferences.
On the other hand it looks like a correct hack WRT the existing behaviour.
---
2) In http://gcc.gnu.org/ml/fortran/2012-12/msg00098.html, Tobias writes:
Without experimenting more carefully, I have the gut feeling that there are
still cases where we might end up with invalid code and there is missed
optimization. [For more details see his full post.]
---
3) In http://gcc.gnu.org/ml/fortran/2013-01/msg00091.html, Mikael writes:
For:
@@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
this_array_result = false;
/* Passing address of the array if it is not pointer or
assumed-shape. */
- if (full_array_var g77 !this_array_result)
+ if (full_array_var g77 !this_array_result
+ sym-ts.type != BT_DERIVED sym-ts.type != BT_CLASS)
I would have used instead:
expr-expr_type == EXPR_VARIABLE ref == NULL)
to make the optimization available to variables of derived type.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from janus at gcc dot gnu.org 2013-01-14 21:45:17 UTC --- The wrong-code regression has been fixed on all branches (4.6, 4.7 and trunk). For all remaining problems (missed optimizations etc), I have opened PR 55980. Closing this one as fixed.
[Bug fortran/54767] [4.7/4.8 Regression] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2013-01-14 21:46:17 UTC --- It is caused by revision 176918: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01186.html
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-14 21:50:35 UTC --- Author: tkoenig Date: Mon Jan 14 21:50:28 2013 New Revision: 195179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195179 Log: 2013-01-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55806 * frontend-passes.c (optimize_reduction): New function, including prototype. (callback_reduction): Likewise. (gfc_run_passes): Also run optimize_reduction. (copy_walk_reduction_arg): New function. (dummy_code_callback): New function. 2013-01-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55806 * gfortran.dg/array_constructor_40.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_40.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2013-01-14 21:53:16 UTC --- (In reply to comment #4) I tried building several compilers (4.7.2), none of which understand the '-mfxsr' option. One was configured with: True. -mfxsr option was added to 4.8.0. After that, I build the mingw-w64 library, went back to my GCC build dir, and did: make make install This command should first build a 4.8.0 crosscompiler, and then compile the library with the newly built compiler. The command should look like: /home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../gcc-svn/trunk/libgcc -I../../../gcc-svn/trunk/libgcc/. -I../../../gcc-svn/trunk/libgcc/../gcc -I../../../gcc-svn/trunk/libgcc/../include -I../../../gcc-svn/trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o crtfastmath.o -MT crtfastmath.o -MD -MP -MF crtfastmath.dep -mfxsr -msse -c ../../../gcc-svn/trunk/libgcc/config/i386/crtfastmath.c As you can see, using -mfxsr does not fail here.
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-14 21:58:40 UTC --- (In reply to comment #12) FYI, I recently ran into this issue as well building gcc 4.7.2 on MacOS 10.7.5 with XCode 4.1 installed. Configured via: ../gcc-4.7.2/configure --enable-languages=c,c++,fortran --enable-lto \ --program-suffix=-4.7 --enable-checking=release This command will use Apple's gcc 4.2.1. Bootstrap fails due to an ICE (I believe during the glibc build). First setting: export CC=gcc-4.4 export CXX=g++-4.4 fails with the error described in this bug report, while including -D_FORTIFY_SOURCE=0 in the above exports allows gcc to bootstrap. Make sure you have run 'make check' on the gmp build you installed. The earlier gmp 5.0.x releases had issues with the change to the llvm-gcc compiler in Xcode 4.1. FYI, since you are on Lion, you can upgrade to Xcode 4.5.2 which provides a very stable clang compiler as the system cc/cxx compiler.
