[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||bernds at gcc dot gnu.org Depends on||48403 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2013-01-19 10:06:06 UTC --- Similar to (or the same as) PR 48403.
[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 #39 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-19 10:14:04 UTC --- Then to fix that perhaps we want to change ix86_valid_target_attribute_tree and its caller. Currently ix86_valid_target_attribute_tree returns NULL_TREE both when the target string(s) are invalid (i.e. when ix86_valid_target_attribute_inner_p returned false) and when the target flags match the default ones. So, let's change ix86_valid_target_attribute_tree to e.g. return error_mark_node instead of NULL_TREE if the attribute is invalid, and NULL_TREE only if it matches the default. Then, ix86_valid_target_attribute_p could treat new_target == error_mark_node similarly to new_target == NULL_TREE with the exception of ret.
[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2013-01-19 10:17:43 UTC --- The scheduler passes block boundary here and schedules insns from the next block. This is the difference to the compilation w/o -g and to gcc-4_7 branch. ;; == ;; -- basic block 10 from 99 to 102 -- before reload ;; == ;; --- forward dependences: ;; --- Region Dependences --- b 10 bb 5 ;; insn codebb dep prio cost reservation ;; -- --- --- ;; 99-110 0 0 0 nothing: 43 100 ;; 100-110 1 0 0 nothing: ;; 102 18410 0 2 2 (ev4_ib1+ev4_bbox),ev4_bbox: 44 ;; --- Region Dependences --- b 4 bb 6 ;; insn codebb dep prio cost reservation ;; -- --- --- ;; 2952 4 0 9 2 (ev4_ib0+ev4_ebox): 44 30 ;; 30 159 4 1 7 2 (ev4_ib0+ev4_ebox): 44 31 ;; 31 159 4 1 5 2 (ev4_ib0+ev4_ebox): 44 39 ;; 35 159 4 0 5 2 (ev4_ib0+ev4_ebox): 44 39 ;; 37 NOTE_INSN_DELETED ;; 38 NOTE_INSN_DELETED ;; 3941 4 2 3 2 (ev4_ib0+ev4_ebox): 44 ;; 40 NOTE_INSN_DELETED ;; 41 3 4 0 2 2 (ev4_ib0+ev4_ebox): 44 ;; 42 NOTE_INSN_DELETED ;; 43 3 4 0 2 2 (ev4_ib0+ev4_ebox): 44 ;; 44 184 4 8 2 2 (ev4_ib1+ev4_bbox),ev4_bbox: ;;dependencies resolved: insn 99 ;;tick updated: insn 99 into ready ;;dependencies resolved: insn 102 ;;Ready--Q: insn 102: queued for 2 cycles. ;;tick updated: insn 102 into queue with cost=2 ;;dependencies resolved: insn 29/b6 ;;Ready--Q: insn 29/b6: queued for 2 cycles. ;;tick updated: insn 29/b6 into queue with cost=2 ;;dependencies resolved: insn 35/b6 ;;Ready--Q: insn 35/b6: queued for 2 cycles. ;;tick updated: insn 35/b6 into queue with cost=2 ;;dependencies resolved: insn 41/b6 ;;Ready--Q: insn 41/b6: queued for 2 cycles. ;;tick updated: insn 41/b6 into queue with cost=2 ;;dependencies resolved: insn 43/b6 ;;Ready--Q: insn 43/b6: queued for 2 cycles. ;;tick updated: insn 43/b6 into queue with cost=2 ;;Advanced a state. ;; ...
[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 Attachment #29207|0 |1 is obsolete|| --- Comment #40 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-19 10:28:02 UTC --- Created attachment 29217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29217 gcc48-pr55742-2.patch The following I mean (incremental patch). No test coverage for that, of course that needs to be added. BTW, I've noticed wrong ChangeLog entries, your gcc/ChangeLog-2012 CL entries refer to c-family/ (and cp/) files, while those should be moved (without prefix) to corresponding c-family/ChangeLog resp. cp/ChangeLog-2012.
[Bug objc/56044] New: Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044
Bug #: 56044
Summary: Add dialect option to gobjc to prevent instance
variables from posing as local variables inside
methods.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dpapa...@gmail.com
Class instance variables in Objective-C can be accessed as if they were local
variables (without self-) inside class methods which luckily can be avoided
simply by not using the feature. The only problem is that in that case you're
prevented from using an actual local variable or method argument with the same
name. This can often be useful for instance in cases such as these:
-(SomeOmbject *)initWithBuffer: (char *buffer)
{
[super init];
self-buffer = buffer;
return self;
}
In this case the compile would warn about variable shadowing and to avoid that
you have to find some other name for the variable which can get annoying. It
would be nice therefore if this feature could be disabled for those that do not
like to use it.
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 ph dunski koala01 at free dot fr changed: What|Removed |Added CC||koala01 at free dot fr --- Comment #10 from ph dunski koala01 at free dot fr 2013-01-19 11:34:35 UTC --- Hello, I know this bug is fixed since a long time, but there is the same problem when trying to compile the gcc-4.8-20130106.tar.bz2 tarball for mingw-w64. Same prolems having, usually same issues, adding the line // See libstdc++/37522. #define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1 in the libstdc++-v3/config/os/mingw32-w64/os_defines.h file seems to allow the build. Should i open a new bug, or can you take it in acount from here?
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-19 11:38:12 UTC --- (In reply to comment #10) Hello, I know this bug is fixed since a long time, but there is the same problem when trying to compile the gcc-4.8-20130106.tar.bz2 tarball for mingw-w64. Same prolems having, usually same issues, adding the line // See libstdc++/37522. #define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1 in the libstdc++-v3/config/os/mingw32-w64/os_defines.h file seems to allow the build. Should i open a new bug, or can you take it in acount from here? Don't open an new bug, don't reopen this bug. I assume you are using none-trunk version of mingw-w64, are you? If so, please switch to trunk-version.
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 --- Comment #12 from ph dunski koala01 at free dot fr 2013-01-19 11:47:08 UTC --- (In reply to comment #11) Don't open an new bug, don't reopen this bug. I assume you are using none-trunk version of mingw-w64, are you? If so, please switch to trunk-version. i'm using the version taken at http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v2.0.7.tar.gz/download . I think it is the trunk version, isn't it?
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 --- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-19 11:53:08 UTC --- (In reply to comment #12) (In reply to comment #11) Don't open an new bug, don't reopen this bug. I assume you are using none-trunk version of mingw-w64, are you? If so, please switch to trunk-version. i'm using the version taken at http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v2.0.7.tar.gz/download . I think it is the trunk version, isn't it? No, it isn't. It is v2.x branch as written even in file-name. But please stop using gcc-bugreports to get answered your user-questions. Use mingw-w64's mailing-list instead.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-19 12:07:54 UTC --- This code surely is not valid. Lambda expressions are restricted and they are neither allowed in constant expressions (5.19 p2 b8) nor can they appear in an unevaluated operand (5.1.2 p2).
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #8 from Paul E. McKenney paulmck at linux dot vnet.ibm.com 2013-01-19 12:35:12 UTC --- Indeed, different hardware implementations can cause all sorts of mischief. Nevertheless, the compiler should not also provide mischief in these cases. In addition, as noted in comment 5, there is legacy software. I understand and completely support use of atomics when they are generally available (having assisted in their definition), but many projects will need to work with older compilers for quite some time to come. Therefore, volatile loads, which are only idiom available in these older compilers, needs to continue to provide the needed functionality. Again as noted in comment 5, volatile stores of reasonably-sized basic types must be atomic.
[Bug bootstrap/56045] New: include file `marvell-pj4.md' not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56045 Bug #: 56045 Summary: include file `marvell-pj4.md' not found Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: denis.onische...@gmail.com Created attachment 29218 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29218 output include file `marvell-pj4.md' not found when building ARM cross compiler trunk revision 195304
[Bug c/56046] New: the buffer overflow can escape from the stack protection in 64-bit linux system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56046
Bug #: 56046
Summary: the buffer overflow can escape from the stack
protection in 64-bit linux system
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ws0...@qq.com
Created attachment 29219
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29219
the bug code
system version :64-bit Ubuntu 12.04 lts
gcc version: 4.6.3
options:gcc source.c -o source
When compile and run a program with an error which will cause buffer
overflow,the compiler can not dectect it.
The program below can compile and run correctly in my system(also works on my
friend system which is no ubuntu but with gcc version 4.5.0)
#include stdio.h
#include string.h
main()
{
const char *a=123456789abcdef;
char b[10];
int i=0;
while((b[i]=a[i])!='\0')
++i;
printf(%s,%d\n,b,strlen(b));
return 0;
}
I attempt to copy a string whose length is 15 to a array whose length is 10,and
it compiles and run correctly.The output is 123456789abcdef,15.
p.s. This will not succeed in 32-bit linux system.
[Bug c/56046] the buffer overflow can escape from the stack protection in 64-bit linux system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56046 --- Comment #1 from CocooWang ws0520 at qq dot com 2013-01-19 13:54:22 UTC --- My freinds tests my code in CentOS!
[Bug c++/27403] T() can be an integer constant but is rejected as not one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27403
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-19
14:22:55 UTC ---
Wolfgang is right, the testcase is invalid, T() is parsed as a function type,
not an expression that value-initializes a T.
[temp.arg]p2, In a template-argument, an ambiguity between a type-id and an
expression is resolved to a type-id, regardless of the form of the
corresponding template-parameter.
i.e. it doesn't matter that the argument is expecting a non-type parameter of
type int, because T() can be a type-id it is interpreted as one.
(This happened to be discussed last month on the committee reflectors)
Using T{} in C++11 works because that cannot be a type-id and is unambiguously
an initialization of T.
[Bug c++/56041] Constexpr conversion function definition not found in template argument context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56041 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-19 Ever Confirmed|0 |1
[Bug c++/56037] Spurious syntax error triggered before ambiguity resolution of type-id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56037 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-19 Ever Confirmed|0 |1
[Bug fortran/55960] [OOP] ICE in replace_comp, at fortran/expr.c:4356
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55960
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-19
Ever Confirmed|0 |1
--- Comment #4 from janus at gcc dot gnu.org 2013-01-19 15:14:31 UTC ---
(In reply to comment #2)
Yet another variant:
[...]
gives me (four times!):
real, dimension(this%getdims()) :: getx
1
Error: Function 'this' at (1) must be PURE
which is of course bogus, since 'this' is not even a function, and getdims is
actually pure.
The wording of the error message can be fixed by this patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 195310)
+++ gcc/fortran/expr.c(working copy)
@@ -2962,18 +2962,24 @@ gfc_specification_expr (gfc_expr *e)
return FAILURE;
}
- comp = gfc_get_proc_ptr_comp (e);
- if (e-expr_type == EXPR_FUNCTION
- !e-value.function.isym
- !e-value.function.esym
- !gfc_pure (e-symtree-n.sym)
- (!comp || !comp-attr.pure))
+ if (e-expr_type == EXPR_FUNCTION)
{
- gfc_error (Function '%s' at %L must be PURE,
- e-symtree-n.sym-name, e-where);
- /* Prevent repeat error messages. */
- e-symtree-n.sym-attr.pure = 1;
- return FAILURE;
+ comp = gfc_get_proc_ptr_comp (e);
+ if (comp !comp-attr.pure)
+{
+ gfc_error (Procedure pointer component '%s' at %L must be PURE,
+ comp-name, e-where);
+ return FAILURE;
+}
+ else if (!comp !e-value.function.isym !e-value.function.esym
+!gfc_pure (e-symtree-n.sym))
+{
+ gfc_error (Function '%s' at %L must be PURE,
+ e-symtree-n.sym-name, e-where);
+ /* Prevent repeat error messages. */
+ e-symtree-n.sym-attr.pure = 1;
+ return FAILURE;
+}
}
if (e-rank != 0)
With this ones gets:
real, dimension(this%getdims()) :: getx
1
Error: Procedure pointer component 'getdims' at (1) must be PURE
This still leaves us with some problems:
1) That we get the error at all. The interface of getdims is clearly PURE, but
it seems that its resolution happens too late, so that the attributes have not
yet been copied from the interface when the pureness check is done.
2) getdims is identified as a PPC in the error message, though it is a
type-bound procedure. The reason for this is that internally this%getdims()
is resolved to this-_vptr-getdims (where getdims is a PPC of _vptr).
3) The error message still comes four times (not sure why).
[Bug fortran/56047] New: [4.6 Regression] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 Bug #: 56047 Summary: [4.6 Regression] ICE in in gfc_conv_expr_op Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: juergen.reu...@desy.de Created attachment 29220 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29220 File that triggers the ICE I get the following ICE: gfortran -c process_libraries.f90 process_libraries.f90: In function ‘process_variant_def_allocate_by_name’: process_libraries.f90:47:0: internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:2469 if (template%type_string () == name) then ^ process_libraries.f90:47:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) In the code attached, iso_varying_string.f90 is the standard implementation: http://www.fortran.com/iso_varying_string.f95
[Bug fortran/56008] [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #4 from Paul Thomas pault at gcc dot gnu.org 2013-01-19 15:54:50 UTC --- Created attachment 29221 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29221 Fix for this PR and PR 47517 Bootstraps and regtests OK The data pointers of allocatable components need to be nullified, after (re)allocation, before the assignment starts because of the test in allocation for the allocation status of these components. It's nearly 'obvious' but took me an age to get it :-) I'll submit properly once I am back in France (tomorrow night if snow allows). Paul
[Bug fortran/56047] [4.8 Regression] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-19 Summary|[4.6 Regression] ICE in in |[4.8 Regression] ICE in in |gfc_conv_expr_op|gfc_conv_expr_op Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-19 16:01:12 UTC --- Revision 190356 (2012-08-13) is OK; revision 190442 (2012-08-16) gives the ICE.
[Bug c/56046] the buffer overflow can escape from the stack protection in 64-bit linux system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56046 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-19 16:16:08 UTC --- The stack protection code cannot guarantee to detect every error.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #2 from Hubert Tong hstong at ca dot ibm.com 2013-01-19 16:38:31 UTC --- (In reply to comment #1) re: 5.19 p2 b8 5.19 p2 (before the referenced bullet list) reads: ..., but subexpressions of logical AND (5.14), logical OR (5.15) and conditional (5.16) operations that are not evaluated are not considered... re: 5.1.2 p2 The use of the lambda expression in the code snippet does not appear as the operand of either typeid, sizeof, noexcept or decltype.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-19 17:11:23 UTC --- Opened radar://13048248 in case these failing test cases represent an unwinder bug on darwin.
[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 #41 from Sriraman Tallam tmsriram at google dot com 2013-01-19 17:18:02 UTC --- (In reply to comment #40) Created attachment 29217 [details] gcc48-pr55742-2.patch The following I mean (incremental patch). No test coverage for that, of course that needs to be added. The incremental patch is fine, thanks. However, the supports_function_versions target hook is no longer necessary and can be removed. I will add the tests for it. BTW, I've noticed wrong ChangeLog entries, your gcc/ChangeLog-2012 CL entries refer to c-family/ (and cp/) files, while those should be moved (without prefix) to corresponding c-family/ChangeLog resp. cp/ChangeLog-2012. Sorry about this Thanks Sri
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2013-01-19 17:20:21 UTC ---
(In reply to comment #2)
You make a good point, but my remaining argument would focus on the fact that
the expression
false [](){}
is always invalid because it attempts to combine a boolean expression and a
void expression (Not covered by 5.14). This is presumably easy to fix by
ensuring that the lambda expressions return a boolean value. This code still
not accepted by gcc 4.8 nor by clang 3.2. While you may try to insist that it
should, this looks like a potential core language issue to me. I'm forwarding
this problem to CWG. I don't think that any compiler change will be done before
that decision, because the CWG group intentionally tried to forbid lambda
expressions within template declarations because of some known technical
problems.
[Bug c/56048] New: -Werror=format=2 does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56048
Bug #: 56048
Summary: -Werror=format=2 does not work
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hda...@gmail.com
Created attachment 29222
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29222
format-warning.c
format-warning.c:
#include stdio.h
int main(void)
{
const char *s = %s\n;
printf(s, abcd);
return 0;
}
$ gcc -Wall -Werror -Werror=format=2 -o format-warning format-warning.c (no
error)
$ gcc -Wall -Werror -Werror=format -Werror=format-nonliteral
-Werror=format-security -Werror=format-y2k -o format-warning format-warning.c
format-warning.c: Na função ‘main’:
format-warning.c:6:2: error: format not a string literal, argument types not
checked [-Werror=format-nonliteral]
[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023
--- Comment #9 from Uros Bizjak ubizjak at gmail dot com 2013-01-19 19:46:12
UTC ---
Following patch fixes bootstrap comparison failure:
--cut here--
Index: haifa-sched.c
===
--- haifa-sched.c (revision 195276)
+++ haifa-sched.c (working copy)
@@ -3684,6 +3684,9 @@ fix_inter_tick (rtx head, rtx tail)
INSN_TICK (head) = tick;
}
+ if (DEBUG_INSN_P (head))
+ continue;
+
FOR_EACH_DEP (head, SD_LIST_RES_FORW, sd_it, dep)
{
rtx next;
--cut here--
We should not update tick status of instructions, dependent on debug insn.
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-19 20:07:30 UTC --- Did you try -Wshadow ?
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-19 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-19 20:08:45 UTC --- Also do you have a self contained testcase for this?
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #4 from Hubert Tong hstong at ca dot ibm.com 2013-01-19 20:10:59
UTC ---
(In reply to comment #3)
I seem to find that the expression in question
false [](){}
is valid because there is a implicit conversion sequence consisting of a
user-defined conversion to pointer-to-function followed by a conversion to bool
from the pointer type.
I'm forwarding this problem to CWG. I don't think that any compiler change
will be done before that decision, because the CWG group intentionally tried
to forbid lambda expressions within template declarations because of some
known technical problems.
Sure. While I may not have a full appreciation of the difficultly for having an
implementation which works with this, I am aware that there is at least the
issue with mangling hinted at by the note in 14.5.6.1 [temp.over.link] p7 with
regards to the linking of equivalent declarations.
I am not sure, though, that implementation difficulty is a good reason to
remove the ability to have SFINAE applied on statements such as the declaration
in the IsConstructibleImpl specialization above.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com
2013-01-19 20:20:43 UTC ---
(In reply to comment #4)
(In reply to comment #3)
I seem to find that the expression in question
false [](){}
is valid because there is a implicit conversion sequence consisting of a
user-defined conversion to pointer-to-function followed by a conversion to
bool
from the pointer type.
I agree, I missed the existence of the conversion function when arguing about
the expression.
Let me add that for exactly the use-case you presented here
(std::is_constructible) I would have loved to have it defined in terms of a
lambda expression. But I guess that this is not what will be decided on that
guess (but maybe I'm just biased)
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-19
20:42:14 UTC ---
Jason, I'd like to try and fix this, but need some clues.
A minimal example that fails to compile is:
struct S { } s;
S r{s};
I find that in call.c:reference_binding we get compatible_p = false, which
seems to be wrong. Even if compatible_p is true we don't take the branch that
looks like it should be used:
/* Directly bind reference when target expression's type is compatible with
the reference and expression is an lvalue. In DR391, the wording in
[8.5.3/5 dcl.init.ref] is changed to also require direct bindings for
const and rvalue references to rvalues of compatible class type.
We should also do direct bindings for non-class xvalues. */
if (compatible_p
(is_lvalue
|| (((CP_TYPE_CONST_NON_VOLATILE_P (to)
!(flags LOOKUP_NO_RVAL_BIND))
|| TYPE_REF_IS_RVALUE (rto))
(gl_kind
|| (!(flags LOOKUP_NO_TEMP_BIND)
(CLASS_TYPE_P (from)
|| TREE_CODE (from) == ARRAY_TYPE))
Naively I would expect compatible_p and is_lvalue to be true for the case
above. Does the code earlier in the function need to be adjusted for the case
where a braced-init-list has a single element of reference-compatible lvalue
type?
[Bug testsuite/51875] FAIL: gfortran.dg/guality/pr41558.f90 -O0 line 7 s == 'foo'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51875 --- Comment #4 from Tilo Schwarz t...@tilo-schwarz.de 2013-01-19 20:44:46 UTC --- Also seen on platform Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux using % gfortran -v Using built-in specs. COLLECT_GCC=gfortran-master COLLECT_LTO_WRAPPER=/home/tschwarz/Unix/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/tschwarz/Unix --program-suffix=-master --disable-multilib --enable-languages=fortran --disable-bootstrap Thread model: posix gcc version 4.8.0 20130118 (experimental) (GCC)
[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-01/msg01011.htm ||l --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2013-01-19 21:07:06 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01011.html
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-19 AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-19 21:32:37 UTC --- Created attachment 29223 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29223 Patch for demonstrating the concept Here's a patch which partially does the job. It converts [foo, bar] binop baz into [foo binop baz, bar binop baz] (but only going this way).
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 --- Comment #15 from Jan Hubicka hubicka at ucw dot cz 2013-01-19 21:48:12 UTC --- Clearing of address-taken does not work: two/1 (two) @0x7fafc0e29818 Type: function Visibility: prevailing_def_ironly Address is taken. References: Referring: main/3 (addr) Availability: available Function flags: analyzed body finalized Called by: Calls: that is, we do not re-compute address-taken after IPA inline transform stage and thus do not reclaim indirectly inlined functions that we no longer need. We can't recompute here because inlining transform happens during the final compilation stage, so the functions are already beging output to the assembly. IPA-prop needs to realize that indirect inlining is going to optimize out the address operation and remove the reference. I assume this is not too hard to implement - we only need to record when the function parameter is used _only_ of the stuff represented by jump functions and indirect edges. I was trying to convince Martin to implement this for a while :) Virtual functions are ven harder than indirect calls since we need to figure out the vtable will become unreachable at the IPA stage. Honza
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #3 from Dimitris Papavasiliou dpapavas at gmail dot com 2013-01-19 22:27:30 UTC --- Created attachment 29224 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29224 Testcase
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #4 from Dimitris Papavasiliou dpapavas at gmail dot com 2013-01-19 22:29:10 UTC --- I have considered -Wshadow and this is the way I think I'll go for now because thinking up of variable names is hard enough without having to think of synonyms on top. The problems with -Wshadow are that: 1) It also disables other warnings about variable shadowing which are pretty useful and 2) It doesn't solve the opposite side of the problem: If you decide not to use this instance-var-as-auto convention then if for some reason, say due to a typo, you do use it inadvertently the compiler will not complain but silently do something you didn't mean to do. (BTW while researching this in hope of finding something like the requested switch, I've found numerous other complaints and questions along the same lines so it seems it would be useful to others as well). Testcase attached. Just use it with gcc -c autoivar.m Let me know if there's anything more I can do to help.
[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #9 from Mikael Morin mikael at gcc dot gnu.org 2013-01-19
22:54:06 UTC ---
Maybe we could remove gfc_copy_formal_args{,_ppc} completely. After all, we
keep a pointer to the interface, so the dummy arguments remain available
through sym-ts.interface-formal.
[Bug fortran/56047] [4.8 Regression] ICE in in gfc_conv_expr_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2013-01-19 23:02:54 UTC --- And the culprit is... ... not me! Though I was not very far. :-) http://gcc.gnu.org/viewcvs?view=revisionrevision=190420
[Bug libstdc++/55861] [C++11] `std::shared_future::get' is not const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55861 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-19 23:43:01 UTC --- Author: redi Date: Sat Jan 19 23:42:55 2013 New Revision: 195314 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195314 Log: PR libstdc++/55861 * include/std/future (_State_base::_S_check(const shared_ptrT)): Fix return type. (__basic_future::_M_get_result()): Const qualify. (shared_future::get()): Likewise. * testsuite/30_threads/shared_future/members/get.cc: Use const objects. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/get.cc
[Bug libstdc++/55861] [C++11] `std::shared_future::get' is not const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55861 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-19 23:44:16 UTC --- fixed for 4.8
[Bug other/56042] Many errors building GCC trunk with mingw-w64 rev. 5542
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56042 --- Comment #2 from lailavrazda1979 at gmail dot com 2013-01-20 02:13:29 UTC --- Strange, it seems to work with the last release of mingw-w64. I configured the headers with: ./configure --build=$CROSS_HOST --host=$CROSS_TGT --prefix=$CROSS_DIR
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 --- Comment #10 from Jeffrey A. Law law at gcc dot gnu.org 2013-01-20 05:01:04 UTC --- Author: law Date: Sun Jan 20 05:00:56 2013 New Revision: 195318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195318 Log: PR tree-optimization/52631 * tree-ssa-sccvn (visit_use): Before looking up the original statement, try looking up the simplified expression. PR tree-optimization/52631 * tree-ssa/pr52631.c: New test. * tree-ssa/ssa-fre-9: Update expected output. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr52631.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-9.c trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution||FIXED Target Milestone|4.7.3 |4.8.0 --- Comment #11 from Jeffrey A. Law law at redhat dot com 2013-01-20 05:02:28 UTC --- Fixed on trunk.
[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 --- Comment #22 from Jeffrey A. Law law at redhat dot com 2013-01-20 06:16:21 UTC --- I must have been looking at something else; the 4.6 and trunk loops are effectively the same, so this is no longer a regression. We might will want the fwprop patch, so I've attached this to the 4.9 pending patches meta bug.
[Bug debug/53135] Duplicates cause size explosion (vta/dwarf)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Summary|Duplicate cause size|Duplicates cause size |explosion (vta/dwarf) |explosion (vta/dwarf) --- Comment #15 from Jeffrey A. Law law at redhat dot com 2013-01-20 06:24:43 UTC --- Removing regression marker as workaround is on trunk. Leaving open so we don't lose track of this bug as we'd really like to do better.
