https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548
--- Comment #4 from Jakub Jelinek ---
On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote:
> > I think Honza ran into this himself.
> Yep, i converted code to use wide-ints. But it is nice to have short
> testcase.
For the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #29 from Jakub Jelinek ---
Friday 13th's test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #24 from Jakub Jelinek ---
Yet another test.
--- Comment #25 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #23 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #22 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #19 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #18 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #17 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #16 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #15 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #14 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #13 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #12 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #11 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #10 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #8 from Jakub Jelinek ---
Yet another test.
--- Comment #9 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #7 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #6 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #5 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #4 from Jakub Jelinek ---
Yet another test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #12 from Jakub Jelinek jakub at redhat dot com ---
On Mon, Oct 06, 2014 at 10:22:21PM +0200, Jan Hubicka wrote:
this patch implements the lowring. Each call with warn attribute triggers
code
in cgraphunit that inserts call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #14 from Jakub Jelinek jakub at redhat dot com ---
On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
Hi,
I am testing this variant of the patch.
For gcc-4.9 branch it may make sense to enable the new patch for LTO only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #16 from Jakub Jelinek jakub at redhat dot com ---
On Tue, Oct 07, 2014 at 12:18:24AM +0200, Jan Hubicka wrote:
On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
Hi,
I am testing this variant of the patch
--- Comment #46 from jakub at redhat dot com 2009-11-24 13:11 ---
Subject: Re: [4.5 Regression] dsymutil Assertion failed ...
assembly for problem object file in libssp.0.dylib that causes dsymutil to
assert
You forgot -dA, without that it is not very readable.
--
http
--- Comment #8 from jakub at redhat dot com 2007-11-27 15:59 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
I think the problems only appeared if allow_rhs_cond_expr was enabled
for the gimplification pass (when called from the loop optimizer
--- Comment #9 from jakub at redhat dot com 2007-11-02 14:24 ---
The only at least partially workable way of linking statically against NPTL
libpthread.a is -Wl,--whole-archive -lpthread -Wl,--no-whole-archive.
There is just a huge amount of issues if you don't have everything
--- Comment #18 from jakub at redhat dot com 2007-08-23 14:49 ---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On Thu, Aug 23, 2007 at 01:45:11PM -, dberlin at dberlin dot org wrote:
If you take address of the whole struct rather than
ReportedBy: jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28409
--- Comment #12 from jakub at redhat dot com 2006-07-17 12:21 ---
The patch in #4 is insufficient. Consider paths like ././../.././../etc/passwd
which satisfies the depth tests, yet clearly escapes the current dir tree.
Another question is about symlinks, if there is a foo
--- Comment #4 from jakub at redhat dot com 2006-07-17 20:04 ---
Well, C++ implies unit-at-a-time, so when gimplifying we could very well
change the TREE_PUBLIC bits of anon namespace objects. Till then this either
could be always recomputed using decl_anon_ns_mem_p etc., or be stored
--- Comment #95 from jakub at redhat dot com 2006-07-15 10:34 ---
Can this be revisited now?
namespaces now can have the visibility attribute, although it has to be
present on each opening namespace.
Guess sticking __attribute__((__visibility__(default))) into
_GLIBCXX_BEGIN_NAMESPACE
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28390
--- Comment #23 from jakub at redhat dot com 2005-12-15 10:48 ---
The problem seems to be that strength_reduce - loop_givs_reduce reduces a giv
that is not always_computable (and as shown on the segfault, it really can't be
computed unconditionally).
p *bl-giv
$16 = {insn
Severity: critical
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla
--- Additional Comments From jakub at redhat dot com 2005-08-19 11:09
---
Created an attachment (id=9546)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9546action=view)
pr23478.C
Testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
--- Additional Comments From jakub at redhat dot com 2005-08-19 13:36
---
caller-save.c inserts the restore insns after the can_throw_internal ()
CALL_INSN
and as the rest of reload excepts fixup_abnormal_edges to fix the mess up.
But, fixup_abnormal_edges only inserts the instructions
--- Additional Comments From jakub at redhat dot com 2005-08-19 18:51
---
It can't be inserted just on abnormal critical edges:
gcc_assert (!((e-flags EDGE_ABNORMAL) EDGE_CRITICAL_P (e)));
So I guess we could insert it on the EH edges if !EDGE_CRITICAL_P and only
only avoid caller
--- Additional Comments From jakub at redhat dot com 2005-08-19 19:16
---
I have a preliminary fix, will work on testcases now, then test it thoroughly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc{,64}-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
--- Additional Comments From jakub at redhat dot com 2005-08-09 17:02
---
Created an attachment (id=9456)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9456action=view)
pr23299.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
--- Additional Comments From jakub at redhat dot com 2005-08-09 17:27
---
The problem is in insert_insn_end_bb.
That function is called to hoist the common expression to the end of bb0.
But, bb0 ends with a call that can throw, so insert_insn_end_bb decides not
to put it after the call
--- Additional Comments From jakub at redhat dot com 2005-08-09 17:43
---
Fixed on mainline with
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01416.html
I'll add the testcase, test the patch and submit for gcc-4_0-branch inclusion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23260
--- Additional Comments From jakub at redhat dot com 2005-07-29 06:54
---
Do we want to check the comdat5* testcase in?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17828
--- Additional Comments From jakub at redhat dot com 2005-07-22 12:37
---
I have partly written patch, but would like to understand whether ordering
matters or not.
Is the following all valid f77/f90/f95?
subroutine foo
character*8 c
character*1 d, f
dimension d
--- Additional Comments From jakub at redhat dot com 2005-07-20 11:41
---
I have done a binary search and at least for the failures and at least those
problems mentioned in PR c++/18556 are fixed by PR middle-end/17799 without
the need for PR c++/18556 patch.
Now, the question is I
--- Additional Comments From jakub at redhat dot com 2005-07-20 21:23
---
Can you please also backport http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00126.html
to gcc-4_0-branch? The testcase fails on gcc-4_0-branch ATM. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20842
--- Additional Comments From jakub at redhat dot com 2005-07-14 12:46
---
First patch posted here
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00478.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
--- Additional Comments From jakub at redhat dot com 2005-07-14 12:48
---
That patch fixes the original testcase, but unfortunately does not fix
the following one.
cat P.c EOF
#include dlfcn.h
#include pthread.h
void *
tf (void *arg)
{
void *h = dlopen (./libP.so, RTLD_LAZY);
void
--- Additional Comments From jakub at redhat dot com 2005-07-14 13:37
---
Another patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00993.html
To test whether _M_get_thread_id/_M_initialize/_M_destroy_thread_key works
I was using following testcase under debugger:
#include
gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22489
--- Additional Comments From jakub at redhat dot com 2005-07-14 15:24
---
IMHO either we want to just force what must have default visibility to have
the default visibility (in mt_allocator.h case it is _S_get_pool), as in:
--- ext/mt_allocator.h 2005-05-20 03:36:29.0 +0200
--- Additional Comments From jakub at redhat dot com 2005-07-14 15:33
---
Any reason why this hasn't been fixed on gcc-4_0-branch as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
--- Additional Comments From jakub at redhat dot com 2005-07-11 22:28
---
Oops. Untested patch, will do more testing tomorrow^Wtoday:
2005-07-12 Jakub Jelinek [EMAIL PROTECTED]
PR fortran/22417
* scanner.c (preprocessor_line): Fix file left but not entered
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
--- Additional Comments From jakub at redhat dot com 2005-07-05 16:48
---
Yes, that's the same thing apparently.
I'm pretty sure a reproducer can be written even for libstdc++ not configured
to default to the mt allocator, by including ext/mt_allocator.h etc. or
however you explicitely
--- Additional Comments From jakub at redhat dot com 2005-07-03 12:08
---
Strange, I have certainly bootstrapped/regtested the initial -fstack-protector
patch on ia64-linux and there were no regressions, neither on HEAD
(20050625 tree + those patches) nor in the 4.0.1 backport.
g++.dg
--- Additional Comments From jakub at redhat dot com 2005-07-03 13:40
---
Ok, I can now reproduce the g++.dg/eh/cond1.C failure with trunk GCC.
It works well when run against 4.0 libstdc++.so, or 20050625 HEAD one
(but in that case built with the -fstack-protector patch in).
Now, g
-size-[1234].c
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC
: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22043
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu
--- Additional Comments From jakub at redhat dot com 2005-04-13 09:46
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null
on entry
On Tue, Apr 12, 2005 at 05:54:58PM -, mmitchel at gcc dot gnu dot org wrote:
--- Additional Comments From
--- Additional Comments From jakub at redhat dot com 2005-04-13 11:38
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null
on entry
On Wed, Apr 13, 2005 at 12:05:35PM +0200, Bernd Schmidt wrote:
Jakub Jelinek wrote:
PR target/20126
* loop.c
--- Additional Comments From jakub at redhat dot com 2005-04-05 10:19
---
Subject: [PATCH] Fix PR preprocessor/19475
Hi!
This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn,
for ISO C99 if there is no whitespace between macro definition and
replacement
--- Additional Comments From jakub at redhat dot com 2005-04-05 11:57
---
Subject: Re: [PATCH] Fix PR preprocessor/19475
On Tue, Apr 05, 2005 at 08:32:58PM +0900, Neil Booth wrote:
Jakub Jelinek wrote:-
Is there some limitation on how many bytes or error messages
dejagnu groks
--- Additional Comments From jakub at redhat dot com 2005-04-05 16:54
---
Subject: Re: [PATCH] Fix PR preprocessor/19475
On Tue, Apr 05, 2005 at 09:49:19AM -0700, Zack Weinberg wrote:
This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn,
for ISO C99
--- Additional Comments From jakub at redhat dot com 2005-03-30 07:56
---
Subject: Re: [PR tree-optimization/20640] add phi args to dests of
dce-redirected edges
On Wed, Mar 30, 2005 at 02:56:24AM -0300, Alexandre Oliva wrote:
When remove_dead_stmt() redirects a control stmt
--- Additional Comments From jakub at redhat dot com 2005-03-09 08:51
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote:
On Mar 8, 2005, Jakub Jelinek [EMAIL PROTECTED] wrote
--- Additional Comments From jakub at redhat dot com 2005-03-09 09:23
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote:
On Mar 8, 2005, Jakub Jelinek [EMAIL PROTECTED] wrote
--- Additional Comments From jakub at redhat dot com 2005-03-09 01:47
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mon, Mar 07, 2005 at 06:56:19PM -0300, Alexandre Oliva wrote:
loop attempts to eliminate a biv represented by a pseudo in favor
74 matches
Mail list logo
