[Bug c++/56389] New: Return types differs in block scope function declarations and function implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56389
Bug #: 56389
Summary: Return types differs in block scope function
declarations and function implementation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: foreve...@bk.ru
Code:
int main()
{
int f();
f();
}
void f() { }
http://liveworkspace.org/code/1zsrDJ$3
>From C++ standard:
par 3.3.2/10 Function declarations at block scope and variable declarations
with the extern specifier at block scope refer to declarations that are members
of an enclosing namespace, but they do not introduce new names into that scope.
So, block scope function declaration is allowed, but why there is no diagnostic
on return types? In C such code cause error
http://liveworkspace.org/code/1zsrDJ$4
[Bug tree-optimization/56350] [4.7/4.8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56350 --- Comment #6 from Jakub Jelinek 2013-02-19 09:14:41 UTC --- Author: jakub Date: Tue Feb 19 09:14:33 2013 New Revision: 196134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196134 Log: PR tree-optimization/56350 * tree-vect-loop.c (vectorizable_reduction): If orig_stmt, return false if haven't found reduction or nested cycle operand, rather than asserting we must find it. * gcc.dg/pr56350.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56350.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug c++/56389] Return types differs in block scope function declarations and function implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56389 niXman changed: What|Removed |Added CC||i.nixman at gmail dot com --- Comment #1 from niXman 2013-02-19 09:15:12 UTC --- (In reply to comment #0) > http://liveworkspace.org/code/1zsrDJ$4 Please publish this history item.
[Bug libmudflap/56390] New: [setjmp/longjmp] Mudflap false violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56390
Bug #: 56390
Summary: [setjmp/longjmp] Mudflap false violation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m.labanow...@gmail.com
Following correct ANSIC code generates Mudflap Violation:
$ gawk '{printf("%02u: %s\n", NR, $0);}' main.c
01: #include
02: #include
03: #include
04: int main(void) {
05: volatile int var = 56;
06: jmp_buf jmp;
07:if (0 == setjmp(jmp)) {
08: char bar [15];
09: memset(bar, 0, sizeof(bar));
10: var = 45;
11: longjmp(jmp, 1);
12:}
13:else {
14: char foo [11];
15: memset(foo, var, sizeof(foo));
16:}
17:return EXIT_SUCCESS;
18: }
$ gcc -fmudflap main.c -lmudflap -o a.out
$ ./a.out
***
mudflap violation 1 (register): time=1361265264.662245 ptr=0x7fff631e5370
size=11
pc=0x7f0823f195f1
/usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_register+0x41)
[0x7f0823f195f1]
./a.out(main+0xc0) [0x400a9c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f0823b7276d]
Nearby object 1: checked region begins 0B into and ends 10B into
mudflap object 0x908ba0: name=`main.c:8:11 (main) bar'
bounds=[0x7fff631e5370,0x7fff631e537e] size=15 area=stack check=0r/1w
liveness=1
alloc time=1361265264.662235 pc=0x7f0823f195f1
number of nearby objects: 1
***
mudflap violation 2 (unregister): time=1361265264.662597 ptr=0x7fff631e5370
size=11
pc=0x7f0823f19196
/usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_unregister+0x36)
[0x7f0823f19196]
./a.out(main+0xef) [0x400acb]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f0823b7276d]
Nearby object 1: checked region begins 0B into and ends 10B into
mudflap object 0x908ba0: name=`main.c:8:11 (main) bar'
number of nearby objects: 1
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-02-19 09:16:50 UTC --- The problem also exists on 4.8.0 trunk
[Bug tree-optimization/56350] [4.7 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56350 Jakub Jelinek changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] ICE in |[4.7 Regression] ICE in |vectorizable_reduction, at |vectorizable_reduction, at |tree-vect-loop.c:4731 |tree-vect-loop.c:4731 Known to fail|4.8.0 | --- Comment #7 from Jakub Jelinek 2013-02-19 09:19:34 UTC --- Fixed on the trunk so far.
[Bug c++/56389] Return types differs in block scope function declarations and function implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56389 --- Comment #2 from forever14 at bk dot ru 2013-02-19 09:20:11 UTC --- niXman, published. Sorry.
[Bug c++/56388] catch(...) in lambda rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56388
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #1 from Daniel Krügler
2013-02-19 09:23:34 UTC ---
The problem also exists for 4.7.2, so no regression. The diagnostics is
interesting:
"7:9: error: '...' handler must be the last handler for its try block
[-fpermissive]
catch(...){
^"
[Bug tree-optimization/56384] [4.8 Regression] ICE in fold_binary_loc, at fold-const.c:10422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56384 Richard Biener 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 2013-02-19 09:28:41 UTC --- Mine.
[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56377 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56377 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-02-19 09:58:16 UTC --- Yeah, diff between r190663 and r190664 output is: -pr56377.C: In substitution of ‘template typename T::type f() [with T = int]’: +pr56377.C: In substitution of ‘template typename T::type f() [with T = ]’:
[Bug tree-optimization/56384] [4.8 Regression] ICE in fold_binary_loc, at fold-const.c:10422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56384
--- Comment #3 from Richard Biener 2013-02-19
10:09:13 UTC ---
Ok, so the issue here is that we value-number
unsigned char b_20 = PHI
int a.4_25 = PHI
the same as value-numbers from BB 3 and BB 10 are still VN_TOP, so
static int
vn_phi_eq (const void *p1, const void *p2)
{
...
/* If the PHI nodes do not have compatible types
they are not the same. */
if (!types_compatible_p (TREE_TYPE (vp1->phiargs[0]),
TREE_TYPE (vp2->phiargs[0])))
return false;
compares "garbage".
I have a patch.
[Bug libquadmath/56379] libquadmath: Wrong result for strtoflt128.c if compiled with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56379 --- Comment #3 from Jakub Jelinek 2013-02-19 10:16:17 UTC --- Yeah, the bug is obvious. glibc refuses to compile with -O0, so it was never a problem for it. The problem is that while mpn_lshift_1 function is always_inline, at -O0 the __builtin_constant_p folds to 0 early in: if (__builtin_constant_p (count) && count == BITS_PER_MP_LIMB) and the else code isn't prepared to handle BITS_PER_MP_LIMB value. The function is always either called with constant BITS_PER_MP_LIMB count, or variable count that is always < BITS_PER_MP_LIMB, so it works fine for -O1+. To fix this, either mpn_lshift_1 could be rewritten as macro, or as a macro calling two different inline functions, or __builtin_constant_p (count) && could be guarded with #ifdef __OPTIMIZE__.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-19 CC||law at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Richard Biener 2013-02-19 10:27:13 UTC --- Confirmed.
[Bug c/56391] New: variable set but unused isn't reported. if it has been used prior to setting it to a new value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56391
Bug #: 56391
Summary: variable set but unused isn't reported. if it has been
used prior to setting it to a new value.
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: beg...@gmail.com
#include
#include
void release(void*);
void
release(void *ptr)
{
free(ptr);
ptr = NULL;
}
int
main(void)
{
int*a;
a = malloc(sizeof(int));
if(a == NULL){
perror("malloc");
return 1;
}
*a = 42;
printf("*a == %d\n", *a);
release(a);
if(a)
printf("*a == %d\n", *a);
return 0;
}
---
Compiling this with "gcc -Wall -Wextra" doesn't report anything (should
be varible set but unused at line 10). This is clearly isn't what the
programmer intended and is easy to catch. Just reset the unused flag
after setting the variable.
This is also the case with g++.
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #50 from Janne Blomqvist 2013-02-19 10:59:30 UTC --- (In reply to comment #47) > Am 18.02.2013 21:16, schrieb jb at gcc dot gnu.org: > >> Look at this piece of code: > >> > > >> > /* Seek to the head and overwrite the bogus length with the real > >> > length. */ > >> > > >> > if (unlikely (sseek (dtp->u.p.current_unit->s, - m - 2 * record_marker, > >> >SEEK_CUR) < 0)) > >> > goto io_error; > >> > > >> >This works if it happens within a buffer, but you cannot rely on that. > >> > > >> >I would therefore suggest to resolve this PR by issuing a well-defined > >> >error if we encounter a pipe on opening. > >> > > >> >I'll prepare a patch. > > As I explained in comment #23, this is already handled. When opening a > > file, we > > stat() the fd, and use the buffered I/O functions only if it's a regular > > file, > > otherwise the unbuffered raw I/O functions are used. > > This is part of the precipitate, not part of the solution ;-) > > For unformatted sequential, we first write a dummy record marker, write > the data and the final record marker, then seek to the first marker > and re-write that. Of course, this fails for an unbuffered fifo. > > If we want this to work, we should make sure we always use > _buffered_ I/O for unformatted sequential, setting a maximum > record length on open that we can handle with our buffer. The buffered I/O functions generally assume that the underlying fd is a regular file; if you break that be prepared to handle a bunch of subtle fallout. I tried playing that whack-a-mole game a few years ago until I got tired of it and restricted buffered I/O to regular files. Wrt to pipes, one regression we had (I don't remember the PR number) was a deadlock due to the buffering. E.g. one process writes "hello" to the pipe, the other one answers "hello, neighbor". The write part could be handled by executing the FLUSH statement, but I recall there was some problem on the read side as well, something to do with read() hanging due to there not being any data available in the pipe when it tried to fill the buffer. Anyway, I don't think this is something libgfortran can, or should, try to fix. If the user tries to do something requiring seeking on a special file that doesn't support seeking, they get what they deserve. The real bug here is that we try to seek even though the Fortran semantics don't require it (mind that the complaint in comment #22 which reopened this PR refers to formatted I/O).
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-19 Ever Confirmed|0 |1
[Bug c/56391] variable set but unused isn't reported. if it has been used prior to setting it to a new value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56391 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek 2013-02-19 11:22:21 UTC --- The variable is used, so it isn't something -Wunused-but-set-parameter is meant to warn for. That warning is emitted by the frontend, to warn in this case you'd need to warn in the middle-end during dead code elimination or similar, and it would have terrible ratio of false positives.
[Bug libquadmath/56379] libquadmath: Wrong result for strtoflt128.c if compiled with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56379 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-19 Ever Confirmed|0 |1 --- Comment #4 from Tobias Burnus 2013-02-19 11:28:27 UTC --- RFC patch to solve this upstream at GLIBC: http://www.sourceware.org/ml/libc-alpha/2013-02/msg00372.html
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #15 from Eric Botcazou 2013-02-19 11:32:24 UTC --- > Thanks for clarifying, I (think I) get it now. Not sure when I can revisit, > maybe this month, maybe the next, so I won't feel bad if someone beats me to > it. Sure, no urgency at all, thanks.
[Bug c++/56392] New: Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56392 Bug #: 56392 Summary: Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: s.jodo...@gmail.com Created attachment 29491 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29491 Source code to reproduce the problem I have written a very simple code to fill a 32x32 16bpp image with a constant value (1024). The pitch/stride of my image (i.e. the number of bytes between two successive lines) is large enough to hold an entire line, but is purposely set to an odd number. The code is attached to this report. I am using Linux x86_64 with gcc 4.6.1 (Ubuntu 11.10). The code runs fine with the -O0, -O1 and -O2 optimization levels. Valgrind does not report any access violation. However, as soon as I switch to -O3 or use the -ftree-vectorize option to enable auto-vectorization, the program crashes: # g++ -g -O2 -ftree-vectorize ./test.cpp -Wall -pedantic && ./a.out Segmentation fault The crash does not happen when I switch to 32bit binaries with the -m32 gcc flag. It does not occur either if I use an even pitch (e.g. pitch = width * 2 + 2). This is also a C++-related problem: the code does not crash when I use malloc() instead of the new[] operator. The problem is also present in g++ 4.4.6 and g++ 4.5.4. As I understand, this is related to memory alignment due to the odd pitch, but should not the code produced by gcc be protected against this?
[Bug c++/56392] Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56392 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Biener 2013-02-19 11:51:47 UTC --- You are dereferencing a pointer to uint16_t that is not sufficiently aligned for that type. The C standard prohibits this, resulting in undefined behavior.
[Bug c++/56392] Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56392 --- Comment #2 from s.jodogne at gmail dot com 2013-02-19 11:56:45 UTC --- (In reply to comment #1) > You are dereferencing a pointer to uint16_t that is not sufficiently aligned > for that type. The C standard prohibits this, resulting in undefined > behavior. Thanks for your answer, but should not a warning be generated by gcc in such a circumstance?
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387 --- Comment #2 from Paul Keir 2013-02-19 12:01:51 UTC --- Created attachment 29492 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29492 Another unexpected error; and also an internal compiler error
[Bug tree-optimization/56384] [4.8 Regression] ICE in fold_binary_loc, at fold-const.c:10422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56384 --- Comment #4 from Richard Biener 2013-02-19 12:11:03 UTC --- Author: rguenth Date: Tue Feb 19 12:10:48 2013 New Revision: 196136 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196136 Log: 2013-02-19 Richard Biener PR tree-optimization/56384 * tree-ssa-sccvn.h (struct vn_phi_s): Add type member. (vn_hash_type): Split out from ... (vn_hash_constant_with_type): ... here. * tree-ssa-sccvn.c (vn_phi_compute_hash): Use vn_hash_type. (vn_phi_eq): Compare types from vn_phi_s structure. (vn_phi_lookup): Populate vn_phi_s type. (vn_phi_insert): Likewise. * gcc.dg/torture/pr56384.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr56384.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h
[Bug tree-optimization/56384] [4.8 Regression] ICE in fold_binary_loc, at fold-const.c:10422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56384 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Biener 2013-02-19 12:13:48 UTC --- Fixed.
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387
--- Comment #3 from Paul Keir 2013-02-19 12:18:17
UTC ---
I've added gcc472aliastemplatebug.cpp which also displays an unexpected error;
shown below along with the code. This is hopefully a related (and simpler)
example. Also, by using the non-template alias, "ein2", and uncommenting the
last two statements of "test", an internal compiler error occurs. Again, an
online 4.8.0 compiler gives the same errors.
template
struct is1 {};
template
struct ein_helper;
template
struct ein_helper,N,N> {
typedef is1 type;
};
template
struct ein_helper,N,Ne> {
typedef typename ein_helper,N+1,Ne>::type type;
};
template
using ein1 = typename ein_helper,0,5>::type;
using ein2 = typename ein_helper,0,5>::type;
template class C, int ...Is>
inline void burst(C const &arg_ixs) {}
void test() {
ein1 abc;
// ein2 abc; // Use instead for an internal compiler error
burst(abc);
}
// Error messages:
gcc472aliastemplatebug.cpp: In function ‘void test()’:
gcc472aliastemplatebug.cpp:28:12: error: no matching function for call to
‘burst(ein1&)’
gcc472aliastemplatebug.cpp:28:12: note: candidate is:
gcc472aliastemplatebug.cpp:23:13: note: template >
class C, int ...Is> void burst(const C&)
gcc472aliastemplatebug.cpp:23:13: note: template argument
deduction/substitution failed:
gcc472aliastemplatebug.cpp:28:12: error: type/value mismatch at argument 1 in
template parameter list for ‘template > class C’
gcc472aliastemplatebug.cpp:28:12: error: expected a constant of type ‘int’,
got ‘int’
// Internal compiler error:
gcc472aliastemplatebug.cpp: In function ‘void test()’:
gcc472aliastemplatebug.cpp:28:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387
--- Comment #4 from Paul Keir 2013-02-19 12:20:39
UTC ---
Comment on attachment 29492
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29492
Another unexpected error; and also an internal compiler error
>template
>struct is1 {};
>
>template
>struct ein_helper;
>
>template
>struct ein_helper,N,N> {
> typedef is1 type;
>};
>
>template
>struct ein_helper,N,Ne> {
> typedef typename ein_helper,N+1,Ne>::type type;
>};
>
>template
>using ein1 = typename ein_helper,0,5>::type;
>
>using ein2 = typename ein_helper,0,5>::type;
>
>template class C, int ...Is>
>inline void burst(C const &arg_ixs) {}
>
>void test() {
> ein1 abc;
>// ein2 abc; // Use instead for an internal compiler error
> burst(abc);
>}
[Bug c++/56392] Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56392 --- Comment #3 from Richard Biener 2013-02-19 12:25:04 UTC --- (In reply to comment #2) > (In reply to comment #1) > > You are dereferencing a pointer to uint16_t that is not sufficiently aligned > > for that type. The C standard prohibits this, resulting in undefined > > behavior. > > Thanks for your answer, but should not a warning be generated by gcc in such a > circumstance? It is, with -Wcast-align, but only on targets where unaligned accesses are not supported. That vectorization ends up turing x86_64 into such one isn't considered by the warning code ...
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #26 from Martin Jambor 2013-02-19 12:54:27 UTC --- (In reply to comment #25) > > That won't work (read: it will cause miscompiles). I believe with the > most recent data-dependence reorg I added a bunch of testcases that show > how to create breaking testcases ;) Yes, it even already miscompiles a few testcases in the testsuite. I mainly wanted to say that the vectorizer is not the only problem. Which means that we probably want to preserve restrict across IPA optimizations. Another idea, which Honza mentioned last time I spoke to him, was that perhaps not lowering &x.u and other COMPONENT_REFs into MEM_REFs would be enough to figure out the accesses do not alias, but I am not sure that is true in gimple (or why tree-inline does this in the first place).
[Bug tree-optimization/56310] [4.8 Regression] ICE: in decide_about_value, at ipa-cp.c:3310 with -fipa-cp -fno-early-inlining -fipa-cp-clone --param=ipa-cp-eval-threshold=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56310 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED CC|mjambor at suse dot cz |jamborm at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #3 from Martin Jambor 2013-02-19 13:00:20 UTC --- Mine.
[Bug sanitizer/56393] New: SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Bug #: 56393
Summary: SIGSEGV when -fsanitize=address and dynamic lib with
global objects
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t-gcc-bugzi...@snowelm.com
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
Created attachment 29493
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29493
gdb session log
When linked with a dynamic library with a globally initialized class object, a
compiled code with address sanitizer dies with SIGSEGV. I think this is a
typical usecase...
Test case:
(boost 1.53 was installed with --build-type=complete.
tested by libs compiled with g++ 4.7.2 as well as libs compiled with head gcc)
-
#include
#include
int main() {
printf("hello\n");
boost::upgrade_mutex m;
}
--
$ g++ -g -fsanitize=address -I/usr/local/include hoge2.cpp -o a.out
-lboost_thread -lboost_system
$ ./a.out
Segmentation fault (core dumped)
The segfault is before the printf.
Without -fsanitize=address it runs normally. If the program is linked with
static libs (-lboost_thread-mt-s -lboost_system-mt-s), it runs normally.
Note that the libraries are compiled without -fsanitize=address.
I investigated the situation by gdb (with -lboost_thread-mt-d
-lboost_system-mt-d). Please see the attached log.
For me it seems that some initializer in the shared lib kicks sanitized code of
some object constructor before the sanitizer gets ready.
[Bug fortran/53537] [4.6/4.7 Regression] Explicit IMPORT of renamed USE-associated symbol fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537 Mikael Morin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | Target Milestone|4.6.4 |4.7.3 --- Comment #12 from Mikael Morin 2013-02-19 13:07:40 UTC --- The 4.6 backport gives a few regression. Namely: FAIL: gfortran.dg/import2.f90 -O (test for errors, line 40) FAIL: gfortran.dg/import2.f90 -O (test for errors, line 59) FAIL: gfortran.dg/import2.f90 -O (test for errors, line 65) FAIL: gfortran.dg/import2.f90 -O (test for errors, line 77) FAIL: gfortran.dg/import8.f90 -O (test for errors, line 15) FAIL: gfortran.dg/interface_derived_type_1.f90 -O (test for errors, line 16) The reason is in gfc_use_derived, gfc_find_symbol returns a symbol of flavor FL_DERIVED, so that no error is issued. On trunk the symbol is of flavor FL_PROCEDURE. I don't feel like spending too much time on this, so I will just leave 4.6 unfixed. Thus, FIXED for 4.7.3 and 4.8.0, WONTFIX for 4.6.*.
[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56301 --- Comment #8 from Matthias Klose 2013-02-19 13:17:55 UTC --- > so it's not about initializing the memory but the fact that it > _is_ aliased by other things. yes, the value returned was saved in a caching data structure.
[Bug c++/56387] Alias of class template wrongly seen as different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387 Paolo Carlini changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #5 from Paolo Carlini 2013-02-19 13:36:47 UTC --- Let's add Dodji about alias templates.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #27 from rguenther at suse dot de 2013-02-19 13:49:30 UTC --- On Tue, 19 Feb 2013, jamborm at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 > > --- Comment #26 from Martin Jambor 2013-02-19 > 12:54:27 UTC --- > (In reply to comment #25) > > > > That won't work (read: it will cause miscompiles). I believe with the > > most recent data-dependence reorg I added a bunch of testcases that show > > how to create breaking testcases ;) > > Yes, it even already miscompiles a few testcases in the testsuite. I > mainly wanted to say that the vectorizer is not the only problem. > Which means that we probably want to preserve restrict across IPA > optimizations. > > Another idea, which Honza mentioned last time I spoke to him, was that > perhaps not lowering &x.u and other COMPONENT_REFs into MEM_REFs would > be enough to figure out the accesses do not alias, but I am not sure > that is true in gimple (or why tree-inline does this in the first > place). Yes, preserving COMPONENT_REFs would help here, but it is not correct (even for this testcase the types do not match). Richard.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #32 from Andrey Belevantsev 2013-02-19 13:50:59 UTC --- Author: abel Date: Tue Feb 19 13:50:50 2013 New Revision: 196137 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196137 Log: 2012-02-19 Andrey Belevantsev PR middle-end/55889 * sel-sched.c: Include ira.h. (implicit_clobber_conflict_p): New function. (moveup_expr): Use it. * Makefile.in (sel-sched.o): Depend on ira.h. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/sel-sched.c
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #33 from Andrey Belevantsev 2013-02-19 13:54:00 UTC --- Fixed on trunk but is latent on 4.7 and I guess 4.6, since the introduction of register pressure sensitive code.
[Bug c++/56394] New: pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
Bug #: 56394
Summary: pointer arithmetic breaks with __attribute__((packed))
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: maxim.yegorush...@gmail.com
I stumbled upon strange behaviour of pointer arithmetic when
__attribute__((packed)) is used. Please consider the following:
$ cat test.cc
#include
#include
struct __attribute__((packed)) Xyz {
uint32_t seq_no;
uint64_t end_offset;
};
struct Mapping {
void* mem;
size_t len;
template
T* begin() {
return static_cast(mem);
}
template
T* end() {
auto e = reinterpret_cast(static_cast(mem) +
len);
return reinterpret_cast(e - e % sizeof(T));
}
};
int main() {
Mapping m{reinterpret_cast(0x4u), 0x1000u};
Xyz* beg = m.begin();
Xyz* end = m.end();
size_t len = end - beg;
printf("%p\n", beg);
printf("%p\n", end);
printf("%zx\n", len);
}
$ g++ -o test -std=gnu++11 -Wall -Wextra test.cc
$ ./test
0x4
0x40ff8
56aa < wrong
If -O optimization switch added the output is correct:
$ g++ -o test -O -std=gnu++11 -Wall -Wextra test.cc
$ ./test
0x4
0x40ff8
154 < correct
When __attribute__((packed)) is removed it also correctly outputs:
$ ./test
0x4
0x41000
100 < correct
I looked at the documentation for __attribute__((packed)) and it says nothing
about it changing the behaviour of pointer arithmetic.
[Bug target/56347] [4.8 Regression] FAIL: gfortran.dg/integer_exponentiation_2.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56347 --- Comment #8 from John David Anglin 2013-02-19 14:01:51 UTC --- Author: danglin Date: Tue Feb 19 14:01:40 2013 New Revision: 196139 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196139 Log: PR target/56347 * acinclude.m4 (LIBGFOR_CHECK_FOR_BROKEN_POWF): Remove check for broken powf. * configure.ac (LIBGFOR_CHECK_FOR_BROKEN_POWF): Likewise. * intrinsics/c99_functions.c: Likewise. * configure: Rebuilt. * config.h.in: Rebuilt. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/c99_functions.c
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #2 from Takaki Makino 2013-02-19 14:02:13 UTC --- Thanks Kostya. Unfortunately -static-libasan didn't help: $ g++ -g -fsanitize=address -I/usr/local/include hoge2.cpp -o a.out -lboost_thread-mt-d -lboost_system-mt-d -static-libasan $ ./a.out Segmentation fault (core dumped
[Bug target/56347] [4.8 Regression] FAIL: gfortran.dg/integer_exponentiation_2.f90 -O2 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56347 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from John David Anglin 2013-02-19 14:08:47 UTC --- Fixed.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #3 from Kostya Serebryany 2013-02-19 14:11:32 UTC --- Looks like __asan_init is not called early enough. To confirm, run ASAN_OPTIONS=verbosity=1 ./a.out if __asan_init is called it should print something like this: ==9255== Parsed ASAN_OPTIONS: verbosity=1 ==9255== AddressSanitizer: libc interceptors initialized || `[0x2000, 0x7fff]` || HighMem|| ... If you don't see this, the crash happens before __asan_init. Does this happen with clang? (Or, can you give the exact instructions on how to install boost 1.53?)
[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Biener 2013-02-19 14:15:18 UTC --- Also reproduces with optimization but with -fno-inline. The issue must be with the exact division: D.2616_5 = end.0_3 - beg.1_4; D.2617_6 = D.2616_5 /[ex] 12; the difference is 4088 but that does not divide by 12. Which means your computed end is not correct (the pointers cannot point to elements of an array of Xyz).
[Bug c++/56395] New: [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 Bug #: 56395 Summary: [4.7/4.8 Regression] ICE, Segmentation fault in tsubst Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org works with 4.7.2, fails with 4.7 20130215 and trunk 20130217. $ g++ -c Platform.ii ./openvdb/tree/TreeIterator.h:433:40: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate.
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 --- Comment #1 from Matthias Klose 2013-02-19 14:16:53 UTC --- Created attachment 29494 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29494 preprocessed source
[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
--- Comment #2 from Richard Biener 2013-02-19
14:17:16 UTC ---
(In reply to comment #1)
> Also reproduces with optimization but with -fno-inline. The issue must be
> with the exact division:
>
> D.2616_5 = end.0_3 - beg.1_4;
> D.2617_6 = D.2616_5 /[ex] 12;
>
> the difference is 4088 but that does not divide by 12. Which means your
> computed end is not correct (the pointers cannot point to elements of
> an array of Xyz).
That is, you probably want
template
T* end() {
auto e = reinterpret_cast(static_cast(mem) +
len);
return reinterpret_cast(e - len % sizeof(T));
}
instead.
[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
Maxim Yegorushkin changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #3 from Maxim Yegorushkin
2013-02-19 14:20:44 UTC ---
I can reproduce this without __attribute__((packed)) actually:
$ cat test.cc
#include
#include
struct Xyz
{
uint32_t seq_no;
uint32_t end_offset_lo, end_offset_hi;
};
struct Mapping
{
void* mem;
size_t len;
template
T* begin() {
return static_cast(mem);
}
template
T* end() {
auto e = reinterpret_cast(static_cast(mem) +
len);
return reinterpret_cast(e - e % sizeof(T));
}
};
int main() {
Mapping m{reinterpret_cast(0x4u), 0x1000u};
Xyz* beg = m.begin();
Xyz* end = m.end();
size_t len = end - beg;
printf("beg = %p\n", beg);
printf("end = %p\n", end);
printf("end - beg = %zx\n", len);
printf("sizeof(Xyz) == %zu\n", sizeof(Xyz));
}
$ g++ -o test -std=gnu++11 -Wall -Wextra test.cc
$ ./test
beg = 0x4
end = 0x40ff8
end - beg = 56aa < wrong
sizeof(Xyz) == 12
$ g++ -o test -std=gnu++11 -Wall -Wextra -O test.cc
$ ./test
beg = 0x4
end = 0x40ff8
end - beg = 154 < correct
sizeof(Xyz) == 12
[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
--- Comment #4 from Maxim Yegorushkin
2013-02-19 14:21:52 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Also reproduces with optimization but with -fno-inline. The issue must be
> > with the exact division:
> >
> > D.2616_5 = end.0_3 - beg.1_4;
> > D.2617_6 = D.2616_5 /[ex] 12;
> >
> > the difference is 4088 but that does not divide by 12. Which means your
> > computed end is not correct (the pointers cannot point to elements of
> > an array of Xyz).
>
> That is, you probably want
>
> template
> T* end() {
> auto e = reinterpret_cast(static_cast(mem) +
> len);
> return reinterpret_cast(e - len % sizeof(T));
> }
>
> instead.
Is there anything wrong with my original code?
-- Maxim
[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #5 from Richard Biener 2013-02-19
14:26:14 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Also reproduces with optimization but with -fno-inline. The issue must be
> > > with the exact division:
> > >
> > > D.2616_5 = end.0_3 - beg.1_4;
> > > D.2617_6 = D.2616_5 /[ex] 12;
> > >
> > > the difference is 4088 but that does not divide by 12. Which means your
> > > computed end is not correct (the pointers cannot point to elements of
> > > an array of Xyz).
> >
> > That is, you probably want
> >
> > template
> > T* end() {
> > auto e = reinterpret_cast(static_cast(mem) +
> > len);
> > return reinterpret_cast(e - len % sizeof(T));
> > }
> >
> > instead.
>
> Is there anything wrong with my original code?
Yes, pointer subtraction returns an index into an array, but your pointers
do not point to array elements but elsewhere. e % sizeof(T) depends on
the alignment of e, not on the size of the array.
> -- Maxim
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-19 Known to work|4.6.3 | Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 Known to fail|4.7.3, 4.8.0| --- Comment #2 from Richard Biener 2013-02-19 14:29:21 UTC --- Confirmed. ./openvdb/tree/TreeIterator.h:433:40: internal compiler error: tree check: accessed elt 4 of tree_vec with 3 elts in tsubst, at cp/pt.c:11228 0xf2f8a4 tree_vec_elt_check_failed(int, int, char const*, int, char const*) /space/rguenther/src/svn/trunk/gcc/tree.c:9131 0x5afeb9 tree_vec_elt_check(tree_node*, int, char const*, int, char const*) /space/rguenther/src/svn/trunk/gcc/tree.h:3869 0x657334 tsubst(tree_node*, tree_node*, int, tree_node*) /space/rguenther/src/svn/trunk/gcc/cp/pt.c:11228 0x65cd34 tsubst_copy /space/rguenther/src/svn/trunk/gcc/cp/pt.c:12463
[Bug c++/56394] pointer arithmetic breaks with __attribute__((packed))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
--- Comment #6 from Maxim Yegorushkin
2013-02-19 14:31:10 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > Also reproduces with optimization but with -fno-inline. The issue must
> > > > be
> > > > with the exact division:
> > > >
> > > > D.2616_5 = end.0_3 - beg.1_4;
> > > > D.2617_6 = D.2616_5 /[ex] 12;
> > > >
> > > > the difference is 4088 but that does not divide by 12. Which means your
> > > > computed end is not correct (the pointers cannot point to elements of
> > > > an array of Xyz).
> > >
> > > That is, you probably want
> > >
> > > template
> > > T* end() {
> > > auto e = reinterpret_cast(static_cast(mem) +
> > > len);
> > > return reinterpret_cast(e - len % sizeof(T));
> > > }
> > >
> > > instead.
> >
> > Is there anything wrong with my original code?
>
> Yes, pointer subtraction returns an index into an array, but your pointers
> do not point to array elements but elsewhere. e % sizeof(T) depends on
> the alignment of e, not on the size of the array.
You are right Richard, it should not take into consideration the base address
of
the mapping in end<>.
Thanks a lot.
[Bug tree-optimization/56396] New: [4.8 Regression] memory corruption in cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56396 Bug #: 56396 Summary: [4.8 Regression] memory corruption in cc1 Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 29495 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29495 preprocessed source seen on a x86_64 system with glibc-2.17. seen with trunk 20130217, works with the 4.7 branch. Lowering to -O1 or -O0 avoids the issue. $ gcc -fPIC -g -O2 -c subscribe.i subscribe.c: In function 'reply_421': subscribe.c:286:5: internal compiler error: Aborted int reply_421(struct sip_msg* msg) ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error in `/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1': double free or corruption (!prev): 0x0331e4c0 *** *** Error in `/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1': malloc(): memory corruption: 0x0331f210 ***
[Bug c/56397] New: Floating Point constant in C, with standard C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397
Bug #: 56397
Summary: Floating Point constant in C, with standard C99
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: argentinator.gcc.questi...@outlook.com
Created attachment 29496
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29496
Source code, ".i" file, and compiler output in a ".txt" file.
I think that the compiler doesn't recognize properly the type of the
floating-point constants for the standard C99.
A straight example is the simple sentence:
(1.1F & 1);
In this case, 1.1F should be considered as a 'float' constant,
but the compiler triggers this error message:
error: invalid operands to binary & (have 'long double' and 'int')
Thus, the compiler considers that 1.1F has type 'long double', but 'float' is
expected.
I am running GCC 4.6.1 with MinGW, under a Windows 7 system.
In my system, FLT_EVAL_METHOD == 2, but I think that this is not the problem,
and that we have actually some kind of compiler bug.
The source code is just this:
---
int main(void) {
1.1F & 1;
}
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #8 from Martin Jambor 2013-02-19 14:48:39 UTC --- Created attachment 29497 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29497 Patch to fix at least part of the problem This patch fixes Jakub's testcase and the one produced by multidelta too. It adds a new parameter to get_access_replacement alogn the lines of the patch in comment #7 of PR 54971 and makes other provisions as discussed yesterday on IRC. The patch passes bootstrap and testsuite on x86_64-linux, but on its own it does not fix the original problem, i.e. bootstrap with IPA-SRA disabled still fails due to a miscomparison. So I'll defer submitting it until after I figure out what problems are still outstanding and whether we want to deal with them in a single patch or not.
[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171
--- Comment #6 from Richard Biener 2013-02-19
14:50:52 UTC ---
Happens in insn-preds.c quite often:
case 'Y':
if (!strncmp (str, "Yi", 2))
return CONSTRAINT_Yi;
if (!strncmp (str, "Ym", 2))
return CONSTRAINT_Ym;
if (!strncmp (str, "Yp", 2))
return CONSTRAINT_Yp;
if (!strncmp (str, "Ya", 2))
return CONSTRAINT_Ya;
...
and later calls are predicted as cold and thus not expanded inline by
(define_expand "cmpstrnsi"
[(set (match_operand:SI 0 "register_operand" "")
(compare:SI (match_operand:BLK 1 "general_operand" "")
(match_operand:BLK 2 "general_operand" "")))
(use (match_operand 3 "general_operand" ""))
(use (match_operand 4 "immediate_operand" ""))]
""
{
rtx addr1, addr2, out, outlow, count, countreg, align;
if (optimize_insn_for_size_p () && !TARGET_INLINE_ALL_STRINGOPS)
FAIL;
the insn-preds.c code could also be optimized, for length 2 a simple
char equality test would be enough ...
[Bug tree-optimization/56398] New: [4.8 Regression] ICE (Segmentation fault) in dominated_by_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56398 Bug #: 56398 Summary: [4.8 Regression] ICE (Segmentation fault) in dominated_by_p Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 29498 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29498 preprocessed source works with the 4.7 branch, fails with trunk 20130217. lowering optimization to -O2 avoids the issue. $ g++ -c -g -O3 vtkLargeInteger.ii /home/packages/tmp/ice/vtk-5.8.0/Common/vtkLargeInteger.cxx: In function 'long int vtkpow(long int, long int)': /home/packages/tmp/ice/vtk-5.8.0/Common/vtkLargeInteger.cxx:36:6: internal compiler error: Segmentation fault long vtkpow(long a, long b) ^ Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x006ea65b in dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def const*) () (gdb) bt #0 0x006ea65b in dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def const*) () #1 0x00a2e450 in ?? () #2 0x00a30101 in ?? () #3 0x00a31b26 in vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node**, unsigned int, bool) () #4 0x00a22404 in vect_transform_loop(_loop_vec_info*) () #5 0x00a3ac3b in vectorize_loops() () #6 0x00860919 in execute_one_pass(opt_pass*) () #7 0x00860cf5 in execute_pass_list(opt_pass*) () #8 0x00860d07 in execute_pass_list(opt_pass*) () #9 0x00860d07 in execute_pass_list(opt_pass*) () #10 0x006c03be in ?? () #11 0x006c1977 in compile() () #12 0x006c1d9a in finalize_compilation_unit() () #13 0x00595fe9 in cp_write_global_declarations() () #14 0x008eee8d in ?? () #15 0x008f08fa in toplev_main(int, char**) () #16 0x76c55a55 in __libc_start_main (main=0x533f50 , argc=15, ubp_av=0x7fffe508, init=, fini=, rtld_fini=, stack_end=0x7fffe4f8) at libc-start.c:260 #17 0x005341b9 in _start ()
[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171 --- Comment #7 from Jakub Jelinek 2013-02-19 15:05:01 UTC --- (In reply to comment #6) > Happens in insn-preds.c quite often: > > case 'Y': > if (!strncmp (str, "Yi", 2)) > return CONSTRAINT_Yi; > if (!strncmp (str, "Ym", 2)) > return CONSTRAINT_Ym; > if (!strncmp (str, "Yp", 2)) > return CONSTRAINT_Yp; > if (!strncmp (str, "Ya", 2)) > return CONSTRAINT_Ya; Well, for insn-preds.c we could also argue that the generator should emit for this case 'Y': if (str[1] == 'i') return CONSTRAINT_Yi; if (str[1] == 'm') return CONSTRAINT_Ym; etc.
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek 2013-02-19 15:05:49 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189298 Reducing.
[Bug c/56397] Floating Point constant in C, with standard C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397 --- Comment #1 from Jonathan Wakely 2013-02-19 15:12:56 UTC --- I get the expected result with 4.7.2 on MinGW and with all versions on GNU/Linux
[Bug fortran/56385] [4.6/4.7/4.8 Regression] [OOP] ICE with allocatable function result in a procedure-pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56385
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #3 from janus at gcc dot gnu.org 2013-02-19 15:20:45 UTC ---
(In reply to comment #2)
> Author: janus
> Date: Fri Nov 5 18:14:52 2010
> New Revision: 166368
Mine, obviously (although I don't directly see how this commit is the cause for
the ICE).
In any case, it is easy to fix:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 195974)
+++ gcc/fortran/trans-array.c(working copy)
@@ -7547,8 +7547,8 @@ structure_alloc_comps (gfc_symbol * der_type, tree
called_dealloc_with_status = false;
gfc_init_block (&tmpblock);
- if (c->attr.allocatable
- && (c->attr.dimension || c->attr.codimension))
+ if (c->attr.allocatable && (c->attr.dimension || c->attr.codimension)
+ && !c->attr.proc_pointer)
{
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
@@ -7730,7 +7730,8 @@ structure_alloc_comps (gfc_symbol * der_type, tree
continue;
}
- if (c->attr.allocatable && !cmp_has_alloc_comps)
+ if (c->attr.allocatable && !c->attr.proc_pointer
+ && !cmp_has_alloc_comps)
{
rank = c->as ? c->as->rank : 0;
tmp = gfc_duplicate_allocatable (dcmp, comp, ctype, rank);
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #4 from Takaki Makino 2013-02-19 15:22:38 UTC --- Created attachment 29499 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29499 reduced testcase I tried to made a fairly reduced testcase from boost. Attached please find the tarball. make CXX=/your/head/gcc two programs are built and run. The statically linked one, a.out.static, runs happily, while a.out.dynamic, the dynamically linked one, fails with SIGSEGV. Tested on linux x86_64.
[Bug c++/56392] Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56392 Jonas Wielicki changed: What|Removed |Added CC||org.gnu.gcc.bugtracker at ||sotecware dot net --- Comment #4 from Jonas Wielicki 2013-02-19 15:25:32 UTC --- Is there a way we could get a warning for doing this? Seems to be like a hole one could easily fall in.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #5 from Takaki Makino 2013-02-19 15:26:41 UTC --- To reply Kostya's comment, As shown in the reduced testcase, the program crashes before ASAN_OPTIONS=verbosity=1 takes effect.
[Bug c++/56392] Crash while filling an odd-pitch 16bpp image with auto-vectorization enabled on x86_64 Linux platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56392 --- Comment #5 from Jonathan Wakely 2013-02-19 15:52:31 UTC --- Any code containing reinterpret_cast should serve as a warning!
[Bug middle-end/56363] over aggressive division folding ignores sign conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363 --- Comment #4 from Jay 2013-02-19 16:18:02 UTC --- ah, here is more info; I reported the bug better years ago but it was never looked at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679 There I don't claim bad code, but a failure with -enable-checking. Something, like, you are supposed to have type = type / type we start with int64 = int64 / int64 but end up with int64 = uint64 / uint64 which "enable-checking" doesn't like. It is possible enable-checking has been relaxed in the years since I checked. I can try again. - Jay
[Bug middle-end/56363] over aggressive division folding ignores sign conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363 --- Comment #5 from Jakub Jelinek 2013-02-19 16:23:03 UTC --- At least from what is described in that PR, it would look like it is just fine to use EXACT_DIV_EXPR, but that we should pass op0 and op1 to the fold_build2_loc call, instead of arg0/arg1.
[Bug c/56368] GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368 --- Comment #1 from Karlson2k 2013-02-19 16:41:03 UTC --- Looks like confusing naming. 'objdir' in 'configure' means 'relative path to directory for objects files', usually '.libs'. 'objdir' in makefile means 'absolute path to main build directory'. First few times 'objdir' in configure used like makefile's objdir and should be fixed.
[Bug c/56397] Floating Point constant in C, with standard C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397 --- Comment #2 from argentinator.gcc.questions at outlook dot com 2013-02-19 16:56:52 UTC --- (In reply to comment #1) > I get the expected result with 4.7.2 on MinGW and with all versions on > GNU/Linux I have reinstalled MinGW in my computer, under Windows 7. Now I have GCC 4.7.2, and I still get the non-expected result, that is, I obtain again the same error message that considers 1.1F as a 'long double' constant. (The compiler option is always -std=c99).
[Bug c/56399] New: Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399
Bug #: 56399
Summary: Adding int to float generates incorrect results
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: johnfox...@yahoo.com
The following program demonstrates the bug. Tested with 32-bit GCC 4.7.2.
#include
void main()
{
int x = 107376;
float f = 12;
f += x;
printf("expected:%d\ncomputed:%f\n", x + 12, f);
}
[Bug c/56397] Floating Point constant in C, with standard C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397 Jonathan Wakely changed: What|Removed |Added Target||*-*-mingw32 --- Comment #3 from Jonathan Wakely 2013-02-19 17:10:10 UTC --- (In reply to comment #2) > (The compiler option is always -std=c99). Ah sorry, although I used -std=c99 on GNU/Linux, I didn't on MinGW, and can confirm it says 'long double' with 4.7.2 on MinGW, so it looks like a target issue.
[Bug c/56397] Floating Point constant in C, with standard C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397 --- Comment #4 from joseph at codesourcery dot com 2013-02-19 17:10:46 UTC --- This looks like it's just an issue with the diagnostic text (binary_op_error being called with the type in which the floating-point operand is being represented, rather than with its semantic type).
[Bug tree-optimization/55110] [4.8 Regression] Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110 --- Comment #5 from Jakub Jelinek 2013-02-19 17:16:02 UTC --- Author: jakub Date: Tue Feb 19 17:15:53 2013 New Revision: 196140 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196140 Log: Backported from mainline 2012-11-27 Jakub Jelinek PR tree-optimization/55110 * tree-vect-loop.c (vectorizable_reduction): Don't assert that STMT_VINFO_RELATED_STMT of orig_stmt is stmt. * gcc.dg/pr55110.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr55110.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-loop.c
[Bug c++/56217] ICE: OpenMP: when combining shared() and a move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56217 --- Comment #5 from Jakub Jelinek 2013-02-19 17:19:41 UTC --- Author: jakub Date: Tue Feb 19 17:19:36 2013 New Revision: 196141 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196141 Log: Backported from mainline 2013-02-06 Jakub Jelinek PR middle-end/56217 * omp-low.c (use_pointer_for_field): Return false if lower_send_shared_vars doesn't generate any copy-out code. * g++.dg/gomp/pr56217.C: New test. * testsuite/libgomp.c++/pr56217.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/gomp/pr56217.C branches/gcc-4_7-branch/libgomp/testsuite/libgomp.c++/pr56217.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/omp-low.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgomp/ChangeLog
[Bug c++/56237] [4.6/4.7 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56237 --- Comment #7 from Jakub Jelinek 2013-02-19 17:21:14 UTC --- Author: jakub Date: Tue Feb 19 17:21:08 2013 New Revision: 196142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196142 Log: Backported from mainline 2013-02-07 Jakub Jelinek PR c++/56237 * decl.c (push_local_name): Look at DECL_DISCRIMINATOR (t) only if DECL_DISCRIMINATOR_SET_P (t) rather than just DECL_LANG_SPECIFIC (t). * g++.dg/abi/mangle61.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/abi/mangle61.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/decl.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/56239] [4.6/4.7 Regression] parse error calling operator() on parenthesized value-initialized temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56239 --- Comment #7 from Jakub Jelinek 2013-02-19 17:22:51 UTC --- Author: jakub Date: Tue Feb 19 17:22:43 2013 New Revision: 196145 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196145 Log: Backported from mainline 2013-02-07 Jakub Jelinek PR c++/56239 * parser.c (cp_parser_token_starts_cast_expression): Renamed to... (cp_parser_tokens_start_cast_expression): ... this. Change parameter to cp_parser *, call cp_lexer_peek_token first. For CPP_OPEN_PAREN, return true only if 2nd token isn't CPP_CLOSE_PAREN. (cp_parser_cast_expression): Adjust caller. * g++.dg/parse/pr56239.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/parse/pr56239.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/parser.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab 2013-02-19 17:24:18 UTC --- float cannot represent 107388 exactly, since it has only 24 bits of precision.
[Bug c++/56241] [4.6/4.7 Regression] ICE in toplev.c:332 on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56241 --- Comment #7 from Jakub Jelinek 2013-02-19 17:24:48 UTC --- Author: jakub Date: Tue Feb 19 17:24:37 2013 New Revision: 196146 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196146 Log: Backported from mainline 2013-02-07 Jakub Jelinek PR c++/56241 * init.c (build_vec_init): Don't append NULL values into new_vec. (build_zero_init_1): Don't push anything into v if recursive call returned NULL_TREE. (build_value_init_noctor): Don't push anything into v if build_value_init call returned NULL_TREE. * g++.dg/parse/crash61.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/parse/crash61.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/init.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/56250] Wrong constant folding on unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56250 --- Comment #8 from Jakub Jelinek 2013-02-19 17:26:15 UTC --- Author: jakub Date: Tue Feb 19 17:26:04 2013 New Revision: 196147 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196147 Log: Backported from mainline 2013-02-08 Jakub Jelinek PR tree-optimization/56250 * fold-const.c (extract_muldiv_1) : Don't optimize if type is unsigned and code isn't MULT_EXPR. * gcc.c-torture/execute/pr56250.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr56250.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/fold-const.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug other/56245] -fsanitize=address miscompiles GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 --- Comment #12 from Jakub Jelinek 2013-02-19 17:27:06 UTC --- Author: jakub Date: Tue Feb 19 17:26:56 2013 New Revision: 196148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196148 Log: Backported from mainline 2013-02-09 Jakub Jelinek PR other/56245 * regex.c (PTR_INT_TYPE): Define. (EXTEND_BUFFER): Change incr type from int to PTR_INT_TYPE. Modified: branches/gcc-4_7-branch/libiberty/ChangeLog branches/gcc-4_7-branch/libiberty/regex.c
[Bug c++/56381] [4.7 Regression] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56381 --- Comment #8 from Jakub Jelinek 2013-02-19 17:28:17 UTC --- Author: jakub Date: Tue Feb 19 17:28:11 2013 New Revision: 196149 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196149 Log: Backported from mainline 2013-02-19 Jakub Jelinek PR tree-optimization/56381 * tree-ssa-pre.c (create_expression_by_pieces): Fix up last argument to fold_build3. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-pre.c
[Bug tree-optimization/56350] [4.7 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56350 --- Comment #8 from Jakub Jelinek 2013-02-19 17:30:35 UTC --- Author: jakub Date: Tue Feb 19 17:30:27 2013 New Revision: 196150 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196150 Log: Backported from mainline 2013-02-19 Jakub Jelinek PR tree-optimization/56350 * tree-vect-loop.c (vectorizable_reduction): If orig_stmt, return false if haven't found reduction or nested cycle operand, rather than asserting we must find it. * gcc.dg/pr56350.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr56350.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-loop.c
[Bug c++/56217] ICE: OpenMP: when combining shared() and a move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56217 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2013-02-19 17:38:02 UTC --- Fixed for 4.7.3+.
[Bug c++/56237] [4.6/4.7 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56237 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek 2013-02-19 17:38:57 UTC --- Fixed for 4.7+.
[Bug c++/56239] [4.6 Regression] parse error calling operator() on parenthesized value-initialized temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56239 Jakub Jelinek changed: What|Removed |Added Summary|[4.6/4.7 Regression] parse |[4.6 Regression] parse |error calling operator() on |error calling operator() on |parenthesized |parenthesized |value-initialized temporary |value-initialized temporary --- Comment #8 from Jakub Jelinek 2013-02-19 17:39:42 UTC --- Fixed for 4.7.3+.
[Bug c++/56241] [4.6/4.7 Regression] ICE in toplev.c:332 on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56241 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek 2013-02-19 17:41:11 UTC --- Fixed for 4.7.3+, error-recovery, so not fixing on 4.6 branch.
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 johnfoxrep at yahoo dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Severity|blocker |enhancement --- Comment #2 from johnfoxrep at yahoo dot com 2013-02-19 17:43:09 UTC --- This seems to be dangerous. I would expect at least 32-bit int precision from floating point variables. MS C++ treats float as double. Why should GCC not do the same? It would prevent many hard to find bugs in existing programs where I have encountered this bug.
[Bug tree-optimization/56250] Wrong constant folding on unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56250 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek 2013-02-19 17:43:36 UTC --- Fixed for 4.7.3+.
[Bug c++/56381] [4.7 Regression] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56381 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek 2013-02-19 17:44:30 UTC --- Fixed.
[Bug tree-optimization/56350] [4.7 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56350 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek 2013-02-19 17:45:32 UTC --- Fixed.
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 johnfoxrep at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from johnfoxrep at yahoo dot com 2013-02-19 17:47:38 UTC --- Sorry, the info about MS C++ is incorrect.
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 --- Comment #4 from Jakub Jelinek 2013-02-19 17:50:16 UTC --- Your expectations are wrong then. Size and format of float is part of ABI, so can't be changed just because somebody has bad expectations, furthermore, for many uses IEEE 754 single format is sufficient, can be faster than double and is more compact, having float the same as double doesn't make much sense, if you need bigger than float precision/exponent range, just use double (similarly for long double if double isn't big enough, or __float128 if available, or mpfr).
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
--- Comment #4 from Georg-Johann Lay 2013-02-19
17:58:36 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
>
>> This cannot work because ISO/IEC TR18037 forces these literals into generic
>> space.
>>
>
> ISO/IEC TR18037
> 5.1.2 Address-space type qualifiers:
>
> If the type of an object is qualified by an address space name, the
> object is allocated in the specified address space; otherwise, the object is
> allocated in the generic address space.
>
> I just re-read the standard.
> I could not find any reason not permitted to place the data in __flash address
> space in that case:
>
> const char __flash* const __flash names[] = {"flash_str1", "flash_str2"};
The initializer at the righ side has type "const char *const[]" thus names[] is
located in flash because names[] is qualified __flash. However, the Embedded C
does not say anything about the literals like "flash_str1" of type "const
char*". Therefore, vanilla C applies which says that these literals go into
generic space.
> IAR compilers it does, and that hinders gcc do the same?
> I think it's an easy misunderstanding, preventing common sense ...
It's a shortcoming in the Embedded C paper and I agree with you that more
elaborate Embedded C paper would be more convenient here.
There are two ways out of this:
1) Extend the Embedded C paper and propose an addendum to the ISO WG14.
2) Implement this extension no matter whether Embedded C comes with this
extension. Find someone who implements this extension, supports it and makes
sure there are no conflicts with the vanilla Embedded C.
Notice that with the extension, in the following example "init" would be
located in flash but "assign" would still be located in RAM.
void f_init (void)
{
const __flash char *str = "init";
}
void f_assign (void)
{
const __flash char *str;
str = "assign";
}
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 --- Comment #5 from johnfoxrep at yahoo dot com 2013-02-19 18:08:54 UTC --- I think float should be a thing of the past as the CPU should be able to process double as fast as float today. Using double by default would prevent hard to find bugs. There could be a compiler option to treat float as double.
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 --- Comment #6 from Jonathan Wakely 2013-02-19 18:24:55 UTC --- Or just stop typing 'float' and type 'double' instead.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-02-19
Ever Confirmed|0 |1
--- Comment #6 from Kostya Serebryany 2013-02-19
18:33:32 UTC ---
The problem also shows up with clang.
Funny. C++ global init has greater priority than C global init.
This is the usual place from where __asan_init is called:
gcc:
#0 __asan_init_v1 () at ../../../../gcc/libsanitizer/asan/asan_rtl.cc:315
#1 0x00417819 in _GLOBAL__sub_I_00099_1_g ()
#2 0x0041788d in __libc_csu_init ()
#3 0x7761b700 in __libc_start_main
#4 0x00401ec9 in _start ()
clang:
#0 __asan_init_v1 ()
#1 0x00419dcd in asan.module_ctor ()
#2 0x00419e8d in __libc_csu_init ()
#3 0x7761b700 in __libc_start_main
#4 0x00419b15 in _start ()
This is where your test case crashes:
#0 0x0041a864 in boost::exception_ptr
boost::get_static_exception_object() ()
#1 0x77ff62c9 in __cxx_global_var_init () from ./libhoge.so
#2 0x77ff62f9 in global constructors keyed to a () from ./libhoge.so
#3 0x77de9306 in call_init
#4 0x77de93df in call_init
#5 _dl_init
#6 0x77ddb6ea in _dl_start_user
Apparently, _dl_start_user starts before _start.
In fact, I think that we saw something like this before and this is why
in one of our settings we run __asan_init from the preinit array. I.e. from
here:
#0 __asan_init_v1 () at
#1 0x77de943e in _dl_init
#2 0x77ddb6ea in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Looks like it's time to enable the preinit hack by default on linux, it's
pretty stable now.
Thoughts?
You may temporary change "defined(ASAN_USE_PREINIT_ARRAY)" to '1' in
asan_rtl.cc,
or add something like this into your code:
__attribute__((section(".preinit_array")))
typeof(__asan_init) *__asan_preinit =__asan_init;
[Bug c/56397] Floating Point constant in C, with standard C99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397
--- Comment #5 from argentinator.gcc.questions at outlook dot com 2013-02-19
18:58:17 UTC ---
(In reply to comment #4)
> This looks like it's just an issue with the diagnostic text
> (binary_op_error being called with the type in which the floating-point
> operand is being represented, rather than with its semantic type).
Is this "type/semantic type" issue related to the following observation?
I tried to print the value of fpclassify for a 'subnormal' value whose type is
'float' or 'double', but it seems the compiler considers everything as a 'long
double'. The source code would be:
--
#include
#include
#include
int main(void) {
double x = DBL_MIN / 1024.0;
long double z = LDBL_MIN / 1024.0;
printf("x == %a\n\nClass of x == %X\n\nClass of z == %X\n",
x, fpclassify(x), fpclassify(z));
}
--
(As always, I am running on Windows 7, MinGW, GCC 4.7.2,
command line option -std=c99, and I have FLT_EVAL_METHOD == 2).
My output is:
x == 0x8p-1035/* This is a 'double subnormal' value */
Class of x == 400 /* x is 'double' and normal, so this seems wrong */
Class of z == 4400/* z is 'long double' and 'subnormal': OK */
[Bug tree-optimization/56396] [4.8 Regression] memory corruption in cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56396
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-02-19
CC||jakub at gcc dot gnu.org
Version|4.7.3 |4.8.0
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek 2013-02-19
19:02:17 UTC ---
Reduced testcase:
/* PR tree-optimization/56396 */
/* { dg-do compile } */
/* { dg-options "-O2 -fpic -g" } */
struct S { char *s; int z; };
struct T { int t; } *c, u;
void bar (int, const char *);
inline void *
foo (void *x, char *y, int z)
{
struct S s;
char b[256];
s.s = b;
s.z = __builtin___sprintf_chk (s.s, 1, __builtin_object_size (s.s, 2),
"Require");
if (s.z < 0)
bar (u.t | c->t, "rls");
if (foo (x, s.s, s.z))
{
}
return (void *) 0;
}
[Bug tree-optimization/56396] [4.8 Regression] memory corruption in cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56396 --- Comment #2 from Jakub Jelinek 2013-02-19 19:09:34 UTC --- Created attachment 29500 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29500 gcc48-pr56396.patch Untested fix.
[Bug c/56399] Adding int to float generates incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56399 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez 2013-02-19 19:30:12 UTC --- BTW, Wconversion tells you this: manu@localhost:~$ gcc -Wconversion test.c -c test.c: In function ‘main’: test.c:6:9: warning: conversion to ‘float’ from ‘int’ may alter its value [-Wconversion] f += x; ^
