http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #8 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #6)
> We are doing the correct thing for this testcase (the testcase should change
> also) though most likely you can generate a testcase which short-circuits
> the check.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #13 from Alexey Samsonov ---
I don't think fork() issue will be relevant here, at least for the minimalistic
TSan test cases. Let's wait till we have libbacktrace symbolizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
--- Comment #4 from Jeffrey A. Law ---
The tree-ssa-threadupdate.c code seems to want to avoid threading to an empty
loop latch block. No reason other than it was "useless" was given. But that's
clearly wrong. We can easily have a loop where th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
--- Comment #7 from Jerry DeLisle ---
Author: jvdelisle
Date: Tue Dec 17 03:06:04 2013
New Revision: 206039
URL: http://gcc.gnu.org/viewcvs?rev=206039&root=gcc&view=rev
Log:
2013-12-16 Jerry DeLisle
PR libfortran/59419
* io/file_pos.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #2 from Oleg Endo ---
I have quickly tried adding a peephole pass shortly after initial RTL
expansion:
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #1 from Oleg Endo ---
The shll trick above will not work properly in the following case:
int
test_00 (unsigned char* a, int b)
{
return a[0] - (a[0] < 128);
}
results in:
mov.b @r4,r1
extu.b r1,r0
exts.b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> We are doing the correct thing for this testcase
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 for the reasons why I say
this testcase is being handled c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #6 from Andrew Pinski ---
We are doing the correct thing for this testcase (the testcase should change
also) though most likely you can generate a testcase which short-circuits the
check.
And then we should add a check for trapping of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #5 from Andrew Pinski ---
Note in this fortran testcase: l .or. (is_f5 .and. f5 .ne. 6.5) is already not
short-circuit by the definition of the language. Though I don't know if the
reduction part for OMP can be done by not short-circu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
Jakub Jelinek changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468
--- Comment #8 from Jan Hubicka ---
Both strange and non-invalid testcases are welcome. A lot has changed in IPA
in 4.9 and I definitely have to chase out bugs in side cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #24 from Kai Tietz ---
(In reply to Anton Mitrofanov from comment #23)
> >Is it possible to write a test with eax_live == true and r10_live == true?
> I am really dunno. As I said I can't write sample which will trigger it
> (that is w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468
--- Comment #7 from Dmitry Gorbachev ---
Are such strange testcases useful for you? Should I file another bug report for
this new TC?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468
--- Comment #6 from Dmitry Gorbachev ---
Created attachment 31453
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31453&action=edit
TC: ICE in function_and_variable_visibility, at ipa.c:997
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #3 from Uroš Bizjak ---
The denormal in f5.0_16 is directly loaded from
f5.0_16 = .omp_data_i_14(D)->f5.0;
_17 = .omp_data_i_14(D)->is_f5;
_18 = *_17;
_43 = e5.1_15 != 8;
if (_18 < _43)
goto ;
else
goto ;
:
...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468
--- Comment #5 from Dmitry Gorbachev ---
I also saw something similar with normal, non-invalid code. This TC is from
Delta-reduced code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #2 from Uroš Bizjak ---
Sorry, Firefox's editor has some issues, this part should be at the top of
session, so:
Following session can be obtained:
(gdb) r
The program being debugged has been started already.
Start it from the beginni
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
Uroš Bizjak changed:
What|Removed |Added
Version|unknown |4.9.0
--- Comment #1 from Uroš Bizjak ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
Bug ID: 59534
Summary: [4.9 Regression] FAIL: libgomp.fortran/retval1.f90
execution test due to denormals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #23 from Anton Mitrofanov ---
>Is it possible to write a test with eax_live == true and r10_live == true?
I am really dunno. As I said I can't write sample which will trigger it (that
is why it is only comment and not new bug report).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54949
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54949
--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 16 22:01:58 2013
New Revision: 206033
URL: http://gcc.gnu.org/viewcvs?rev=206033&root=gcc&view=rev
Log:
2013-12-16 Janus Weil
PR fortran/54949
* symbol.c (che
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
Bug ID: 59533
Summary: [SH] Missed cmp/pz opportunity
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #20 from Jan Hubicka ---
Hmm, it may be someone altering the insns during streaming process. You may
try to check
who is doing that while streaming out the relevant .o file.
Is it compilation->linker streaming or wpa->ltrans?
UIDs are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #22 from H.J. Lu ---
That piece of code is only trigged by -mstack-arg-probe, which is
specific to Windows:
else if (!ix86_target_stack_probe ()
|| frame.stack_pointer_offset < CHECK_STACK_LIMIT)
{
pro_epilogue_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #19 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #18)
> > Just double-checked. And yes, unfortunately it's 100% reproducible.
>
> Can not think of much of reason for this. How much off the index is? Just
> sligh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59532
Bug ID: 59532
Summary: -mstack-arg-probe is undocumented
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #18 from Jan Hubicka ---
> Just double-checked. And yes, unfortunately it's 100% reproducible.
Can not think of much of reason for this. How much off the index is? Just
slightly or is it completely random number?
Honza
>
> --
> Yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #6 from Dominique d'Humieres ---
> on x86_64-apple-darwin12. Can someone confirm that we have both support
> for floating-point exceptions and the required hook on darwin?
I cannot answer these questions.
> If so, I suspect we are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
--- Comment #6 from Jan Hubicka ---
OK, somewhat confusing on the testcase above is that j is defined, but C++ FE
never consider it uses and thus never passes it to middle-end.
The problem is that C++ FE chose to first assemble alias:
#0 assembl
-1000/gcc-4.9-20131216/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/
-L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/.libs
-latomic -fno-diagnostics-show-caret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #3 from Jack Howarth ---
Created attachment 31451
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31451&action=edit
preprocessed source for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #4 from Jack Howarth ---
Created attachment 31452
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31452&action=edit
assembly file for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
--- Comment #5 from Jan Hubicka ---
> Even better something that uses it and that even declares the original:
> extern int j;
> static int i __attribute__((weakref("j")));
>
> int
> foo (void)
> {
> return &i ? i : 0;
> }
>
> This ICEs with cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514
Chris Sakalis changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #9 from Jan Hubicka ---
> Honza,
>
> I've tested your patch from comment 7 and it doesn't work.
> However your suggestion "to simply return NULL when inner_binfo is NULL"
> does seem to work fine. I've successfully build Chromium with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
Geoff Romer changed:
What|Removed |Added
CC||gromer at google dot com
--- Comment #5 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531
Bug ID: 59531
Summary: string_view overrun in copy operation
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59530
Bug ID: 59530
Summary: Incorrect check on string_view operator[]
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #21 from Anton Mitrofanov ---
It should be:
t = plus_constant (Pmode, stack_pointer_rtx,
allocate + UNITS_PER_WORD);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59529
Bug ID: 59529
Summary: fix experimental/string_view end-of-string edge cases
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #20 from Anton Mitrofanov ---
I was talking about:
if (r10_live && eax_live)
{
t = plus_constant (Pmode, stack_pointer_rtx, allocate);
emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #19 from H.J. Lu ---
(In reply to Anton Mitrofanov from comment #18)
> This patch is ok for mingw32 target but may produce incorrect code for
> x86_64 linux target in case of saving/restoring both rax and r10. In that
> case during res
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #3 from Oleg Endo ---
(In reply to Oleg Endo from comment #2)
> As of rev 204180 (4.9) this problem still exists.
> As far as I understand, the actual root of the problem is that the 'unsigned
> char' mem loads into regs are neither si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Anton Mitrofanov changed:
What|Removed |Added
CC||BugMaster at narod dot ru
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #12 from H.J. Lu ---
(In reply to H.J. Lu from comment #11)
> It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
> But stage3 cc1plus fails.
It is very sensitive PCH load address.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
--- Comment #2 from Teresa Johnson ---
I will take a look and report back. -freorder-blocks-and-partition was
recently enabled by default, which presumably exposed this issue.
Thanks,
Teresa
On Mon, Dec 16, 2013 at 8:21 AM, octoploid at yandex do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59466
--- Comment #1 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Dec 16 18:24:54 2013
New Revision: 206023
URL: http://gcc.gnu.org/viewcvs?rev=206023&root=gcc&view=rev
Log:
2013-12-16 Vladimir Makarov
PR rtl-optimization/59466
* em
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #11 from H.J. Lu ---
It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
But stage3 cc1plus fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
--- Comment #3 from Jeffrey A. Law ---
Andrew, no.
4.2 didn't muck things up at all. The 4.2 code is clearly better (unless
you're vectorizing the loop).
What's happening is the IV code changes the loop structure enough that
VRP2/DOM2 are unabl
-gnu/sys-include /tmp/x.cc -quiet -dumpbase x.cc
-mtune=corei7 -march=corei7 -auxbase-strip /tmp/x.s -g -g -O2 -O2 -std=gnu++11
-version -fdiagnostics-color=never -fmessage-length=0 -ffunction-sections
-fdata-sections -o /tmp/x.s
GNU C++ (GCC) version 4.9.0 20131216 (experimental) [trunk revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #22 from Jan Hubicka ---
00010 // This file implements the stickier parts of the SymbolTableListTraits
class,
00011 // and is explicitly instantiated where needed to avoid defining all this
code
00012 // in a widely used header.
I wou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #16 from Jan Hubicka ---
> Executing: c++ -o js -Wall -Wpointer-arith -Woverloaded-virtual
> -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
> -Wsign-compare -Wno-invalid-offsetof -Wcast-align -flto=4 -fprofile-u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #6 from Oleg Endo ---
(In reply to Jonathan Wakely from comment #5)
> Users can specialize std::set::find to do something
> different, e.g. write to a file, and it must not do that if they call
> std::find.
>
> It's not a matter of wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #9 from Jakub Jelinek ---
Note this must be PCH related, can't reproduce it without PCH even with --param
ggc-min-expand=0 --param ggc-min-heapsize=0.
Unfortunately I only reproduce it two i686 builds ago and don't remember the
exact r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59528
Bug ID: 59528
Summary: Profiledbootstrap should use stage1 compiler during
stagefeedback
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #1 from Zhendong Su ---
Below is simpler testcase that triggers the same ICE:
int a, b, c, d;
void
foo ()
{
for (; d; d++)
for (b = 0; b < 14; b++)
{
c |= 1;
if (a)
bre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #5 from Jonathan Wakely ---
Users can specialize std::set::find to do something different,
e.g. write to a file, and it must not do that if they call std::find.
It's not a matter of whether the type is the library's iterator type or n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #10)
> ktkachov,
>
> It seems to be working fine for me with my arm-eabi cross compiler. Perhaps
> you could provide some more details:
>
> make check-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514
--- Comment #1 from Jonathan Wakely ---
I think this is already fixed on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
Ollie Wild changed:
What|Removed |Added
CC||aaw at gcc dot gnu.org
--- Comment #4 from O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #3 from Martin Jambor ---
It should be easy to make SRA safely cope with BIT_FIELD_REFs,
REALPART_EXPRs and IMAGPART_EXPRs under a VIEW_CONVERT_EXPR (as
opposed to those under a COMPONENT_REF, ARRAY_REF, MEM_REF or
similar). I'd prefe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 31447
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31447&action=edit
unreduced testcase
% g++ -w -r -nostdlib -fprofile-use -fprofile-correction -march=amdfam10
-fno-exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #8 from H.J. Lu ---
On Linux/x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #12 from Alexander Potapenko ---
I wonder if https://code.google.com/p/address-sanitizer/issues/detail?id=253 is
relevant here. In the case TSan tests do fork() (which I'm not expecting from
them, however) the parent and the child will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #11 from Jakub Jelinek ---
Patches have been posted, but haven't been reviewed yet.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00964.html
Various tsan testcases right now fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 16 15:33:42 2013
New Revision: 206017
URL: http://gcc.gnu.org/viewcvs?rev=206017&root=gcc&view=rev
Log:
PR libgomp/59337
* openmp.c (resolve_omp_atomic): Adjust error messa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #15 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #14)
> Fixed. Thank you for testing it. The Firefox ICE
> Seems to fix Mozilla build untill the next (unrelated) ICE:
>
> /var/tmp/mozilla-central/js/src/vm/Stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58296
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #5 from joseph at codesourcery dot com ---
On Thu, 12 Dec 2013, algrant at acm dot org wrote:
> demonstrates the same lack of ordering. You suggest that this might
> be a problem with the atomic built-ins - and yes, if this had been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
Bug ID: 59527
Summary: [4.9 Regression] ICE: in fixup_reorder_chain, at
cfgrtl.c:3739 during PGO Firefox build
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #21 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #20)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> >
> > --- Comment #17 from Markus Trippelsdorf ---
> > In the non-lto case one has:
> > lib/libLLVMAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54949
--- Comment #4 from janus at gcc dot gnu.org ---
Both test cases give an ICE at least with 4.6 on upward, but not with 4.4, so
the ICE is technically a regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Mon Dec 16 13:37:43 2013
New Revision: 206014
URL: http://gcc.gnu.org/viewcvs?rev=206014&root=gcc&view=rev
Log:
PR ipa/59265
* ipa-profile.c (ipa_profile_generate_summary): Do not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56645
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59526
Bug ID: 59526
Summary: [C++11] Defaulted special member functions don't
accept noexcept if a member has a non-trivial noexcept
operator in the corresponding special member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #20 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
>
> --- Comment #17 from Markus Trippelsdorf ---
> In the non-lto case one has:
> lib/libLLVMAsmParser.so:
> U
> _ZN4llvm21SymbolTableListTraitsINS_10BasicB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #12 from Jan Hubicka ---
OK, will commit it shortly (after re-testing with break replaced by continue).
You may just ask for write access and write me as garant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #19 from Jan Hubicka ---
> I can't reproduce this.
> What platform is this? What is the command line?
I used x86-64 and you apparently need LTO to trigger it. I used same
commandline
as in original report
g++ -flto-partition=none -fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
--- Comment #1 from Sarantis Pantazis ---
Created attachment 31446
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31446&action=edit
Minimal working example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59525
Bug ID: 59525
Summary: Inheritance problems
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #10)
> Yes, this patch is OK, will you test and commit it? I will also re-test the
> patch that should prevent early passes from missing this optimization.
I've t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
1 - 100 of 127 matches
Mail list logo
