[Bug middle-end/84433] New: gcc 7 and before miscompile loop and remove exit due to incorrect range calculation

[acsawdey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84433

Bug ID: 84433
   Summary: gcc 7 and before miscompile loop and remove exit due
to incorrect range calculation
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le

Created attachment 43446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43446=edit
test case for range error bug

An incorrect range calculation results in the cunroll pass thinking that the
loop exit conditional branch can never happen:

Analyzing # of iterations of loop 1
  exit condition [15, + , 4294967295] != 0
  bounds on difference of bases: -15 ... -15
  result:
# of iterations 15, bounded by 15
Loop 1 iterates 15 times.
Loop 1 iterates at most 14 times.
Loop 1 likely iterates at most 14 times.
Analyzing # of iterations of loop 1
  exit condition [15, + , 4294967295] != 0
  bounds on difference of bases: -15 ... -15
  result:
# of iterations 15, bounded by 15
Removed pointless exit: if (ivtmp_24 != 0)

As a result gcc 7 and below (I've also tested 5.4.0 and 6.4.1) generate an
infinite loop here with -O2 or -O3. -O1 generates working code.

It appears this is fixed in gcc 8 as trunk does not have this failure. Not sure
if this can be fixed in 7 or 6 but I think I will see if this little test case
can go into the testsuite to make sure we don't run into this again.

[Bug c++/83911] [6/7/8 Regression] ICE with target attribute on constructor in gimplify_expr at gimplify.c:11321

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83911

--- Comment #2 from Jason Merrill  ---
Created attachment 43445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43445=edit
patch

The problem here is that we're substituting a dispatcher function for a
constructor, and the dispatcher function isn't marked as being a constructor. 
This seems like a general issue that the dispatcher lacks all language-specific
information that might be helpful, but in this specific instance it's easy
enough to copy DECL_CXX_CONSTRUCTOR_P.

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Detect illegal component|[F08] Detect illegal
   |initialization in   |component initialization in
   |pdt_27.f03  |pdt_27.f03

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> pdt_27.f03 is illegal wrt F08:C458.

That constraint seems to be missing in F03 AFAICS. I find the neighboring
clauses (C457/459) as C446/447 in F03, but not F08:C458.

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #2 from Jerry DeLisle  ---
Mine

[Bug fortran/84432] New: Detect illegal component initialization in pdt_27.f03

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432

Bug ID: 84432
   Summary: Detect illegal component initialization in pdt_27.f03
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

https://github.com/nncarlson/gfortran.dg/issues/13

pdt_27.f03 is illegal wrt F08:C458. gfortran should check for that constraint.

[Bug c/84431] New: Suboptimal code for masked shifts (x86/x86-64)

[nruslan_devel at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84431

Bug ID: 84431
   Summary: Suboptimal code for masked shifts (x86/x86-64)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

In x86 and x86-64, the assumption is that upper bits of the CL register are
unused (i.e., masked) when doing a shift operation. It is not possible to do
shift for more than (WORD_BITS - 1) positions. Normally, the compiler has to
check whether the specified shift value exceeds the word size before generating
corresponding shld/shl commands (shrd/shr, etc).

Now, if the shift value is given by some variable, it is normally unknown at
compile time whether it is exceeding (WORD_BITS - 1), so the compiler has to
generate corresponding checks. On the other hand, it is very easy to give a
hint to the compiler (if it is known that the shift < WORD_BITS) by masking
shift value like this (the example below is for i386; for x86-64 the type will
be __uint128_t and mask 63):

unsigned long long func(unsigned long long a, unsigned shift)
{
   return a << (shift & 31);
}

In the ideal scenario, the compiler has to just load value to CL without even
masking it because it is implied already by the shift operation.

Note that clang/LLVM recognizes this pattern (at least for i386) by generating
the following assembly code:
func:   # @func
pushl   %esi
movl8(%esp), %esi
movb16(%esp), %cl
movl12(%esp), %edx
movl%esi, %eax
shldl   %cl, %esi, %edx
shll%cl, %eax
popl%esi
retl


GCC generates suboptimal code in this case:
func:
pushl   %esi
pushl   %ebx
movl20(%esp), %ecx
movl16(%esp), %esi
movl12(%esp), %ebx
andl$31, %ecx
movl%esi, %edx
shldl   %ebx, %edx
movl%ebx, %eax
xorl%ebx, %ebx
sall%cl, %eax
andl$32, %ecx
cmovne  %eax, %edx
cmovne  %ebx, %eax
popl%ebx
popl%esi
ret

[Bug c++/84430] New: [7/8 Regression] ICE with #pragma omp simd in lambda

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84430

Bug ID: 84430
   Summary: [7/8 Regression] ICE with #pragma omp simd in lambda
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-std=c++1z -fopenmp")
triggers an ICE since GCC 7.1.0:

===
void foo()
{
  []{
#pragma omp simd
for (int i = 0; i < 10; ++i)
  ;
  };
}
===

bug.cc: In lambda function:
bug.cc:7:3: sorry, unimplemented: unexpected AST of kind omp_simd
   };
   ^
bug.cc:7:3: internal compiler error: in potential_constant_expression_1, at
cp/constexpr.c:5993
0x857e92 potential_constant_expression_1
../../gcc/gcc/cp/constexpr.c:5993
0x8975c6 finish_function(bool)
../../gcc/gcc/cp/decl.c:15671
0x8d83c2 finish_lambda_function(tree_node*)
../../gcc/gcc/cp/lambda.c:1384
0x91d8c1 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10675
0x91d8c1 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10176
0x91d8c1 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5257
0x9301bc cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x930d90 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91117f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x91198a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x913164 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9476
0x913878 cp_parser_expression
../../gcc/gcc/cp/parser.c:9645
0x915538 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:2
0x91b8ad cp_parser_statement
../../gcc/gcc/cp/parser.c:10916
0x91cdc0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91ce97 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11209
0x933610 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21750
0x933610 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21787
0x933ec0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26688
0x934bd7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26604
Please submit a full bug report, [etc.]

[Bug c++/84429] New: [8 Regression] ICE capturing variable-sized array

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84429

Bug ID: 84429
   Summary: [8 Regression] ICE capturing variable-sized array
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE on trunk:

=
void foo(int i)
{
  char x[i];
  [&]{ [&]{ return x; }; };
}
=

bug.cc: In lambda function:
bug.cc:4:20: internal compiler error: in build_capture_proxy, at
cp/lambda.c:459
   [&]{ [&]{ return x; }; };
^
0x8d5615 build_capture_proxy(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:459
0x8d5926 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/gcc/cp/lambda.c:660
0x8d5ece add_default_capture(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:710
0x9abfe8 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc/gcc/cp/semantics.c:3541
0x91dd9c cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5607
0x9301bc cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x930d90 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91117f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x91198a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x913164 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9476
0x913878 cp_parser_expression
../../gcc/gcc/cp/parser.c:9645
0x91c01b cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12396
0x91c01b cp_parser_statement
../../gcc/gcc/cp/parser.c:10810
0x91cdc0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91d897 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10669
0x91d897 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10176
0x91d897 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5257
0x9301bc cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x930d90 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91117f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
Please submit a full bug report, [etc.]

The regression was introduced between 2017-09-26 and 2017-10-07.

[Bug c++/84139] C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE

[cjdb.ns at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84139

--- Comment #5 from Christopher Di Bella  ---
It appears this is now compiling on trunk: https://godbolt.org/g/L9igrS.
Thanks.

Is it safe to close this issue yet?

[Bug target/84361] Fails to use vfmaddsub* for complex multiplication

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84361

Marc Glisse  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81904

--- Comment #2 from Marc Glisse  ---
Related to one part of bug 81904.

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996

--- Comment #9 from Neil Carlson  ---
With today's version (r257782) I'm still seeing the same thing Dominique
reported in comment 7, except that there is no longer any abort -- the programs
terminate successfully (0 exit code) despite the reported runtime error.  I'm
not sure what to make of that.

Example error:

 $ ./a.out
gfortran-20171114a.f90:48: runtime error: member access within misaligned
address 0x0060ab25 for type 'struct foo', which requires 8 byte alignment
0x0060ab25: note: pointer points here
 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00
00 00 00 00 00 00  00
 ^

[Bug fortran/84270] [7/8 Regression] optimization bug with assumed size array argument

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84270

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Thomas Koenig  ---
Fixed on all affected branches, closing.

[Bug c++/79064] Cannot overload member function templates on type of literal

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79064

Andreas Schwab <sch...@linux-m68k.org> changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-02-17
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #4 from Andreas Schwab <sch...@linux-m68k.org> ---
FAIL: g++.dg/template/overload15.C  -std=c++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20180217/gcc/testsuite/g++.dg/template/overload15.C:14:10:
error: call of overloaded 'f<0>(char (*)[1])' is ambiguous
/daten/aranym/gcc/gcc-20180217/gcc/testsuite/g++.dg/template/overload15.C:15:10:
error: no matching function for call to 'f<0>(char (*)[7])'

[Bug fortran/84270] [7/8 Regression] optimization bug with assumed size array argument

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84270

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Feb 17 16:01:50 2018
New Revision: 257784

URL: https://gcc.gnu.org/viewcvs?rev=257784=gcc=rev
Log:
2018-02-17  Thomas Koenig  

Backport from trunk
PR fortran/84270
* frontend-passes (scalarized_expr):  If the expression
is an assumed size array, leave in the last reference
and pass AR_SECTION instead of AR_FULL to gfc_resolve
in order to avoid an error.

2018-02-17  Thomas Koenig  

Backport from trunk
PR fortran/84270
* gfortran.dg/inline_matmul_22.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/inline_matmul_22.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/frontend-passes.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/84270] [7/8 Regression] optimization bug with assumed size array argument

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84270

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Feb 17 15:53:07 2018
New Revision: 257783

URL: https://gcc.gnu.org/viewcvs?rev=257783=gcc=rev
Log:
2018-02-17  Thomas Koenig  

PR fortran/84270
* frontend-passes (scalarized_expr):  If the expression
is an assumed size array, leave in the last reference
and pass AR_SECTION instead of AR_FULL to gfc_resolve
in order to avoid an error.

2018-02-17  Thomas Koenig  

PR fortran/84270
* gfortran.dg/inline_matmul_22.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #60 from Francois-Xavier Coudert  ---
(In reply to Jonathan Wakely from comment #59)
> Should be fixed on trunk, please test and confirm.

Confirmed fixed on trunk. Many thanks.

Could you please backport to gcc-7-branch and gcc-6-branch? Or okay the
backport, which I would be happy to apply.

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Feb 17 14:05:34 2018
New Revision: 257782

URL: https://gcc.gnu.org/viewcvs?rev=257782=gcc=rev
Log:
2018-02-17  Thomas Koenig  

PR fortran/84381
* gfortran.dg/abort_shoulfail.f90: New test.
* gcc.target/powerpc/ppc-fortran/pr80108-1.f90: Replace CALL ABORT
by STOP n.
* gfortran.dg/PR19754_2.f90: Likewise.
* gfortran.dg/PR19872.f: Likewise.

... and so on. The full ChangeLog was rejected because it was too long :-)

[Bug fortran/84094] several correctness issues in gfortran.dg

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094
Bug 84094 depends on bug 84381, which changed state.

Bug 84381 Summary: replace non-std 'call abort' by 'stop 1' in gfortran 
testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

--- Comment #6 from Thomas Koenig  ---
(In reply to Neil Carlson from comment #5)
> Thomas, I saw you generated a patch with "stop n".  I'd love to see how you
> did it -- the regexp and counting magic.

At first, I tried to find the all-inclusive regexp to do this, but
that didn't work fast enough, so I settled for running different
scripts for different cases.  I didn't actually save all the
scripts.

The first one was

#! /usr/bin/perl
$n = 1;
$abort = "call *abort *([(] *[)])?";

while (<>)
{
if (/$abort/) {
s/$abort/STOP $n/;
$n++;
}
print;
}

and another one

$n = 1;
while (<>)
{
if (/call\s*abort$/i) {
s/call\s*abort/STOP $n/i;
$n++;
}
print;
}

and invoked them with

find . -type f -name '*.[fF]*' -exec perl -i ./c2.pl '{}'  ';'

Not the most general solution, but it got me there :-)

[Bug c++/84423] [concepts] ICE with invalid using declaration

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84423

--- Comment #2 from Volker Reichelt  ---
I can still reproduce the crash with a clean trunk from 2 hours ago (r257780).

[Bug fortran/84115] [8 Regression] Failure in associate construct with concatenated character target

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Paul Thomas  ---
Forgot to close it :-)

[Bug fortran/84115] [8 Regression] Failure in associate construct with concatenated character target

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115

--- Comment #7 from Paul Thomas  ---
Fixed on trunk, thanks for the report.

Paul

[Bug fortran/84115] [8 Regression] Failure in associate construct with concatenated character target

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Sat Feb 17 11:07:32 2018
New Revision: 257781

URL: https://gcc.gnu.org/viewcvs?rev=257781=gcc=rev
Log:
2018-02-17  Paul Thomas  

PR fortran/84115
* resolve.c (resolve_assoc_var): If a non-constant target expr.
has no string length expression, make the associate variable
into a deferred length, allocatable symbol.
* trans-decl.c (gfc_is_reallocatable_lhs): Add and use a ptr to
the symbol.
* trans-stmt.c (trans_associate_var): Null and free scalar
associate names that are allocatable. After assignment, remove
the allocatable attribute to prevent reallocation.

2018-02-17  Paul Thomas  

PR fortran/84115
* gfortran.dg/associate_35.f90: Remove error, add stop n's and
change to run.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_35.f90

[Bug tree-optimization/82965] [8 regression][armeb] gcc.dg/vect/pr79347.c starts failing after r254379

[amker.cheng at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #10 from bin.cheng  ---
a proposed patch @https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02419.html

[Bug fortran/74600] [openacc] duplicate data map error

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74600

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Thomas Schwinge from comment #2)
> Cesar posted patch:
> , waiting for
> review.

Jakub said it'd require more discussion; I'll add the "patch" keyword in the
meantime

[Bug target/70713] msp430 interrupt attribute prevents overriding weak symbols

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70713

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to d...@gcc.gnu.org from comment #3)
> Author: dj
> Date: Tue Sep 13 20:06:47 2016
> New Revision: 240123
> 
> URL: https://gcc.gnu.org/viewcvs?rev=240123=gcc=rev
> Log:
> 2016-09-13  Joe Seymour  
> 
> gcc/
> PR target/70713
> * config/msp430/msp430.c (msp430_start_function): Emit an error
> if a function is both weak and specifies an interrupt number.
> 
> gcc/testsuite/
> PR target/70713
> * gcc.target/msp430/function-attributes-1.c: New test.
> * gcc.target/msp430/function-attributes-2.c: New test.
> * gcc.target/msp430/function-attributes-3.c: New test.
> 
> Added:
> trunk/gcc/testsuite/gcc.target/msp430/function-attributes-1.c
> trunk/gcc/testsuite/gcc.target/msp430/function-attributes-2.c
> trunk/gcc/testsuite/gcc.target/msp430/function-attributes-3.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/msp430/msp430.c
> trunk/gcc/testsuite/ChangeLog

Did this fix it?

[Bug sanitizer/67899] build failure in the sanitizer libs on sparc-linux-gnu

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67899

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Mikael Pettersson from comment #7)
> Patch posted:
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00647.html

The reply was that it should be sent upstream. Adding the "patch" keyword here
for now anyways though.